When used aggressively, calling SubmitDecoderBuffers() just after
ReleaseDecoderBuffer() may have the buffers not used properly and created
decoding artifacts.
It's likely due to the time to copy the submitted buffer in CPU mapped memory
to GPU memory. SubmitDecoderBuffers() doesn't appear to wait
On 2020-08-05 9:07, Steve Lhomme wrote:
When used aggressively, calling SubmitDecoderBuffers() just after
ReleaseDecoderBuffer() may have the buffers not used properly and created
*creates
decoding artifacts.
It's likely due to the time to copy the submitted buffer in CPU mapped memory
to GPU
When used aggressively, calling SubmitDecoderBuffers() just after
ReleaseDecoderBuffer() may have the buffers not used properly and created
decoding artifacts.
It's likely due to the time to copy the submitted buffer in CPU mapped memory
to GPU memory. SubmitDecoderBuffers() doesn't appear to wait
On Wed, 5 Aug 2020, Steve Lhomme wrote:
When used aggressively, calling SubmitDecoderBuffers() just after
ReleaseDecoderBuffer() may have the buffers not used properly and created
decoding artifacts.
It's likely due to the time to copy the submitted buffer in CPU mapped memory
to GPU memory. S
On Thu, 30 Jul 2020, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
libavutil/Makefile | 2 ++
libavutil/mpegts_audio_desc_metadata.c | 33
libavutil/mpegts_audio_desc_metadata.h | 57 ++
3
On Thu, 30 Jul 2020, Nicolas George wrote:
Also add and update some tests.
Change the semantic a little, because for filesytem paths
symlinks complicate things.
See the comments in the code for detail.
Signed-off-by: Nicolas George
---
libavformat/tests/url.c | 17 ++-
libavformat/url.c
On Sun, Jul 26, 2020 at 8:26 PM Jun Zhao wrote:
>
> From: Jun Zhao
>
> Respecting the framerate in the libopenh264enc codec context.
>
> Both the libx264 and libx264 encoders already contain similar logic
> to first check the framerate before falling back to the timebase.
>
> Signed-off-by: Jun Z
On Wed, 5 Aug 2020, myp...@gmail.com wrote:
On Sun, Jul 26, 2020 at 8:26 PM Jun Zhao wrote:
From: Jun Zhao
Respecting the framerate in the libopenh264enc codec context.
Both the libx264 and libx264 encoders already contain similar logic
to first check the framerate before falling back to t
On 2020-08-05 9:55, Marton Balint wrote:
On Wed, 5 Aug 2020, Steve Lhomme wrote:
When used aggressively, calling SubmitDecoderBuffers() just after
ReleaseDecoderBuffer() may have the buffers not used properly and created
decoding artifacts.
It's likely due to the time to copy the submitted bu
On Wed, Aug 5, 2020 at 4:26 PM Martin Storsjö wrote:
>
> On Wed, 5 Aug 2020, myp...@gmail.com wrote:
>
> > On Sun, Jul 26, 2020 at 8:26 PM Jun Zhao wrote:
> >>
> >> From: Jun Zhao
> >>
> >> Respecting the framerate in the libopenh264enc codec context.
> >>
> >> Both the libx264 and libx264 encod
This way it's possible to use the wait_copy feature with the old API as well.
If it's NULL, wait_copies remains NULL and is not used.
---
doc/APIchanges | 3 +++
libavcodec/d3d11va.h | 6 ++
libavcodec/dxva2.c | 38 +++---
libavcodec/version.h | 2 +-
When used aggressively, calling SubmitDecoderBuffers() just after
ReleaseDecoderBuffer() may have the buffers not used properly and creates
decoding artifacts.
It's likely due to the time to copy the submitted buffer in CPU mapped memory
to GPU memory. SubmitDecoderBuffers() doesn't appear to wait
v3 with support for the old API as well.
On 2020-08-05 12:07, Steve Lhomme wrote:
This way it's possible to use the wait_copy feature with the old API as well.
If it's NULL, wait_copies remains NULL and is not used.
---
doc/APIchanges | 3 +++
libavcodec/d3d11va.h | 6 ++
libavc
On Tue, 28 Jul 2020 at 16:31, wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
>
Hi,
There is already libdvbpsi or bitstream for these kind of applications, it
should not go in FFmpeg, nor in public API.
Kieran
___
ffmpeg-devel mailing
On Wed, Aug 05, 2020 at 09:55:52AM +0200, Marton Balint wrote:
>
>
> On Thu, 30 Jul 2020, lance.lmw...@gmail.com wrote:
>
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavutil/Makefile | 2 ++
> > libavutil/mpegts_audio_desc_metadata.c | 33 +
On Wed, Aug 05, 2020 at 11:14:39AM +0100, Kieran Kunhya wrote:
> On Tue, 28 Jul 2020 at 16:31, wrote:
>
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> >
>
> Hi,
>
> There is already libdvbpsi or bitstream for these kind of applications, it
> should not go in FFmpeg, nor in p
On Mon, Jul 20, 2020 at 09:18:55 +0200, Alexander Strasser wrote:
> On 2020-07-19 19:47 -0400, Andriy Gelman wrote:
> > > > This check seems dead code. Looking at xcb sources, cursor is just an
> > > > offset in
> > > > memory from ci so I don't think it can be null here.
> > But anyway, this par
for example
avformat_alloc_output_context2(&putFmtCtx, NULL, "rtmp",
"rtmp://1.1.1.1/live");
or
avformat_open_input(&InputFmtCtx, "rtmp://1.1.1.1/live", 0, 0)
how to set http proxy? thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://
Signed-off-by: Michael Niedermayer
---
libavcodec/mpegaudiodec_template.c | 40 +++---
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/libavcodec/mpegaudiodec_template.c
b/libavcodec/mpegaudiodec_template.c
index 7f0088161a..de10f71e7b 100644
--- a/libavco
Fixes: shift exponent 32 is too large for 32-bit type 'int'
Fixes:
24566/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-6033783737024512
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
Ping for the trivial patch.
> On Jul 29, 2020, at 1:02 AM, Zhao Zhili wrote:
>
> ---
> libavformat/utils.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 807d9f10cb..af1cca0c7d 100644
> --- a/libavformat/uti
Signed-off-by: Nicolas George
---
libavformat/tests/url.c | 34
libavformat/url.c | 70 +
libavformat/url.h | 41
tests/ref/fate/url | 45 ++
4 files changed, 190 inserti
From: hwren
Signed-off-by: hbj
Signed-off-by: hwren
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/avs3dec.c| 75
3 files changed, 77 insertions(+)
create mode 100644 libavformat/avs3dec.c
diff --git a/libavforma
Also add and update some tests.
Change the semantic a little, because for filesytem paths
symlinks complicate things.
See the comments in the code for detail.
Signed-off-by: Nicolas George
---
libavformat/tests/url.c | 60 -
libavformat/url.c | 261 ---
From: hwren
=== Version1 ===
These patches are to supplement the third generation of Audio Video Coding
Standard,
part 2: video (AVS3-P2), aka IEEE1857.10, decoding support via libuavs3d
wrapper.
The uAVS3d decoder could be found in https://github.com/uavs3/uavs3d
AVS3 sample streams could be
From: hwren
Signed-off-by: hbj
Signed-off-by: hwren
---
libavcodec/codec_desc.c | 7 +++
libavcodec/codec_id.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 9f8847544f..ad55d992d3 100644
--- a/libavcodec/codec_desc.c
+++ b/l
From: hwren
Signed-off-by: hbj
Signed-off-by: hwren
---
Changelog | 1 +
configure | 4 +
doc/decoders.texi | 21 +++
doc/general.texi | 8 ++
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/libuavs3d.c | 283 ++
From: hwren
Signed-off-by: hbj
Signed-off-by: hwren
---
libavcodec/Makefile | 1 +
libavcodec/avs3_parser.c | 184 +++
libavcodec/parsers.c | 1 +
3 files changed, 186 insertions(+)
create mode 100644 libavcodec/avs3_parser.c
diff --git a/liba
Marton Balint (12020-08-05):
> memmove, because out and in can overlap or they can be the same when
> buf == base in ff_make_absolute_url()
Good catch. Fixed.
> A problem with the function type change is that previously the caller
> assumed that even if there is not enough space, buf will be a 0
On Wed, 5 Aug 2020 at 12:54, wrote:
> On Wed, Aug 05, 2020 at 11:14:39AM +0100, Kieran Kunhya wrote:
> > On Tue, 28 Jul 2020 at 16:31, wrote:
> >
> > > From: Limin Wang
> > >
> > > Signed-off-by: Limin Wang
> > > ---
> > >
> >
> > Hi,
> >
> > There is already libdvbpsi or bitstream for these k
Nicolas George (12020-08-05):
> --- a/libavformat/url.c
> +++ b/libavformat/url.c
> @@ -27,6 +27,7 @@
> #if CONFIG_NETWORK
> #include "network.h"
> #endif
> +#include "libavutil/avassert.h"
Moved this to the first patch.
> #include "libavutil/avstring.h"
> +if (use_base_path) {
> +
Commit a500b975 removed NULL input handling from this function,
moving the check higher up the call tree in one branch. However,
there is another call to set_string_video_rate() which may pass
NULL, and future users of the function may not be clear that
a NULL check is required. This patch restores
Fair enough, I agree an assert would be better - I'll send another patch.
I was not intending to advocate for defensive programming - the patch was
done this way in order to restore the previous behaviour. Although I agree
with you that the outcome of passing NULL to strcmp is pretty much
certainl
On Wed, Aug 5, 2020 at 8:43 PM Michael Niedermayer
wrote:
>
> Fixes: shift exponent 32 is too large for 32-bit type 'int'
> Fixes:
> 24566/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-6033783737024512
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-f
On Wed, Aug 05, 2020 at 10:45:14PM +0530, Gautam Ramakrishnan wrote:
> On Wed, Aug 5, 2020 at 8:43 PM Michael Niedermayer
> wrote:
> >
> > Fixes: shift exponent 32 is too large for 32-bit type 'int'
> > Fixes:
> > 24566/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-60337837370
On Wed, Aug 05, 2020 at 05:06:23PM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/mpegaudiodec_template.c | 40 +++---
> 1 file changed, 20 insertions(+), 20 deletions(-)
will apply
[...]
--
Michael GnuPG fingerprint: 9FF21
Zane van Iperen:
> Signed-off-by: Zane van Iperen
> ---
> Changelog| 1 +
> libavformat/Makefile | 1 +
> libavformat/allformats.c | 1 +
> libavformat/argo_asf.c | 127 ++-
> libavformat/version.h| 2 +-
> 5 files changed, 130
On 8/5/2020 1:18 PM, hwr...@126.com wrote:
> From: hwren
>
> Signed-off-by: hbj
> Signed-off-by: hwren
> ---
> Changelog | 1 +
> configure | 4 +
> doc/decoders.texi | 21 +++
> doc/general.texi | 8 ++
> libavcodec/Makefile| 1 +
> libavcodec
On Tue, Aug 04, 2020 at 06:28:02PM +0530, gautamr...@gmail.com wrote:
> From: Gautam Ramakrishnan
>
> This patch allows the encoder to use SOP and EPH
> markers. This would be useful as these markers
> provide better error detection mechanisms.
> ---
> libavcodec/j2kenc.c | 28 ++
On Wed, 5 Aug 2020 23:09:45 +0200
"Andreas Rheinhardt" wrote:
> > +
> > +static int argo_asf_write_trailer(AVFormatContext *s)
> > +{
> > +int16_t ret;
>
> Using an int16_t here is wrong: It may mask errors and apart from that
> it may lead to warnings from static analyzers.
>
Good catch,
On Wed, Aug 5, 2020 at 4:27 AM Takio Yamaoka wrote:
>
> Thank you for the review!
> It is my first time to send a patch. So I was relieved to hear that.
>
> Is it OK to wait to merge?
>
> Best Regards,
> Takio
>
Sorry, decided to take a look at the logic but didn't have the time to
actually test
Hello everyone,
This is the first time for me to send a patch via email. Is this the
correct format?
I would appreciate it if someone could confirm, and if there is anything
else I need to do to get it into upcoming releases.
Best,
*• **Yiğit (Yeet) Uyan*
*•* Smart Home Intelligence | Google
Signed-off-by: Andreas Rheinhardt
---
libavformat/vividas.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavformat/vividas.c b/libavformat/vividas.c
index b0f9f35ac2..708adc8801 100644
--- a/libavformat/vividas.c
+++ b/libavformat/vividas.c
@@ -432,19 +432,20 @@
Signed-off-by: Andreas Rheinhardt
---
libavformat/vividas.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/libavformat/vividas.c b/libavformat/vividas.c
index 708adc8801..36c007b0d2 100644
--- a/libavformat/vividas.c
+++ b/libavformat/vividas.c
@@ -440,7 +44
It leads to an assert in ff_read_packet().
Signed-off-by: Andreas Rheinhardt
---
libavformat/sierravmd.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavformat/sierravmd.c b/libavformat/sierravmd.c
index 531fc41531..40bcb77986 100644
--- a/libavformat/sierravmd.c
+++ b/libavformat/s
2020年8月6日(木) 7:24 Jan Ekström :
>
> Sorry, decided to take a look at the logic but didn't have the time to
> actually test it locally.
Thank you for replying. It sounds good for me.
> I have now tested it locally and it works as expected with the
> following test cases:
> and chromaoffset 0 (sti
On Thu, 6 Aug 2020 01:33:57 +0200
"Andreas Rheinhardt" wrote:
>
> static void load_sb_block(AVFormatContext *s, VividasDemuxContext *viv,
> unsigned expected_size)
> @@ -608,7 +606,7 @@ static int viv_read_header(AVFormatContext *s)
> ret = track_index(viv, s, buf, v);
> av_free(buf)
On Wed, Aug 05, 2020 at 05:50:56PM +0100, Kieran Kunhya wrote:
> On Wed, 5 Aug 2020 at 12:54, wrote:
>
> > On Wed, Aug 05, 2020 at 11:14:39AM +0100, Kieran Kunhya wrote:
> > > On Tue, 28 Jul 2020 at 16:31, wrote:
> > >
> > > > From: Limin Wang
> > > >
> > > > Signed-off-by: Limin Wang
> > > >
> On Aug 6, 2020, at 6:38 AM, Yiğit (Yeet) Uyan
> wrote:
>
> Hello everyone,
>
> This is the first time for me to send a patch via email. Is this the
> correct format?
>
> I would appreciate it if someone could confirm, and if there is anything
> else I need to do to get it into upcoming rel
> On Aug 6, 2020, at 10:46 AM, zhilizhao wrote:
>
>
>
>> On Aug 6, 2020, at 6:38 AM, Yiğit (Yeet) Uyan
>> wrote:
>>
>> Hello everyone,
>>
>> This is the first time for me to send a patch via email. Is this the
>> correct format?
>>
>> I would appreciate it if someone could confirm, and i
Hey Zhilizhao,
The RTSPState you mentioned is ok, but we need to get the char control_uri
buffer from 1024 characters to 2048. Some of the long rtsps links are
getting cut, and cannot play. Can you help getting this patch to the next
version? The patch does not show up in https://patchwork.ffmpeg.
It can be tested with the model generated with below python script:
import tensorflow as tf
import os
import numpy as np
import imageio
from tensorflow.python.framework import graph_util
name = 'floor'
pb_file_path = os.getcwd()
if not os.path.exists(pb_file_path+'/{}_savemodel/'.format(name)):
>
> It's audio descriptor information although it's stored in PSI table, but
> it'll map to
> specific audio packet in the end, so I don't think it's hacky. I have
> tested
> with mpts with multiple audio stream, it's pass-by if copy specifc audio
> stream.
>
Why not just parse the AC-3 packet hea
53 matches
Mail list logo
