> From: ffmpeg-devel On Behalf Of Fu,
> Linjie
> Sent: Monday, May 18, 2020 15:17
> To: ffmpeg-devel@ffmpeg.org
> Cc: Xu, Guangxin
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] lavc/hevc_refs: Fix the logic of
> find_ref_idx()
>
> > From: Fu, Linjie
> > Sent: Tuesday, May 12, 2020 21:44
> > To: ffm
James Almer:
> On 5/20/2020 11:36 PM, Andreas Rheinhardt wrote:
>> The TTA muxer writes a seektable in a dynamic buffer as it receives
>> packets and when writing the trailer, closes the dynamic buffer using
>> avio_close_dyn_buf(), writes the seektable and frees the buffer. But
>> the TTA muxer al
May 20, 2020, 22:43 by s...@jkqxz.net:
> On 19/05/2020 22:29, Lynne wrote:
>
>> May 19, 2020, 20:50 by s...@jkqxz.net:
>>
>>> On 13/05/2020 16:53, Lynne wrote:
>>>
This, along with the next patch, are the last missing pieces to being
interoperable with libplacebo.
There is no dange
On 5/20/2020 11:36 PM, Andreas Rheinhardt wrote:
> The TTA muxer writes a seektable in a dynamic buffer as it receives
> packets and when writing the trailer, closes the dynamic buffer using
> avio_close_dyn_buf(), writes the seektable and frees the buffer. But
> the TTA muxer already has a deinit
The size of a single allocation performed by av_malloc() or av_realloc()
is supposed to be bounded by max_alloc_size, which defaults to INT_MAX
and can be set by the user; yet currently this is not completely
honoured: The actual value used is max_alloc_size - 32. How this came
to be can only be un
The TTA muxer writes a seektable in a dynamic buffer as it receives
packets and when writing the trailer, closes the dynamic buffer using
avio_close_dyn_buf(), writes the seektable and frees the buffer. But
the TTA muxer already has a deinit function which unconditionally
calls ffio_free_dyn_buf()
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskadec.c | 27 +++
1 file changed, 11 insertions(+), 16 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 4fa32365c3..c02c2561c1 100644
--- a/libavformat/matroskadec.c
+++ b/libavfo
May 20, 2020, 22:56 by s...@jkqxz.net:
> On 19/05/2020 21:56, Lynne wrote:
>
> "Each pNext member of any structure (including this one) in the pNext chain
> must be either NULL or a pointer to a valid instance of ... [big list which
> does not include VkPhysicalDeviceFeatures]." Was that meant
On Thu, May 21, 2020 at 4:09 AM Martin Storsjö wrote:
>
> The framerate field is the one users are supposed to set, but not
> all users might be setting it, so it might be good to fall back
> time_base in that case.
> ---
> libavcodec/mfenc.c | 10 +-
> 1 file changed, 9 insertions(+), 1
Hi Guys,
I've just finished a bunch of research on encoding audio .flac files into
MP4/AAC using ffmpeg, and we're seeing a detail in the header data that is
keeping some audio players from correctly interpreting the metadata in the MP4
elst box.
Long story short, the issue is that MOV_TIMESCA
On Wed, May 20, 2020 at 12:08 PM James Almer wrote:
>
> It's been a wrapper for a simple av_bsf_free() call since c96904f525.
>
> Signed-off-by: James Almer
> ---
> libavcodec/decode.c | 7 +--
> libavcodec/decode.h | 2 --
> libavcodec/utils.c | 4 ++--
> 3 files changed, 3 insertions(+),
On Wed, May 20, 2020 at 10:29:17PM +0100, Mark Thompson wrote:
> On 20/05/2020 22:16, Michael Niedermayer wrote:
> > On Wed, May 20, 2020 at 08:56:29PM +0200, Michael Niedermayer wrote:
> >> On Mon, Apr 20, 2020 at 07:34:44PM -0300, James Almer wrote:
> >>> On 4/20/2020 7:03 PM, Michael Niedermayer
Michael Niedermayer:
> On Tue, May 19, 2020 at 12:45:58PM +0200, Andreas Rheinhardt wrote:
>> A buffer whose size is not a multiple of four has been initialized using
>> consecutive writes of 32bits. This results in a stack-buffer-overflow
>> reported by ASAN in the checkasm-sw_scale FATE-test.
>>
On Wed, 20 May 2020, Emanuele Oriani wrote:
If that was the only concern against it, then I'd say it is acceptable.
> But there are some other concerns, also it seems to me xcbgrab can be
> improved to reach the same smoothness as this attempt, and that was the
> main distinctive feature of i
myp...@gmail.com:
> On Tue, May 19, 2020 at 7:10 PM Andreas Rheinhardt
> wrote:
>>
>> ff_id3v2_free_extra_meta() takes a ID3V2ExtraMeta ** so that it can
>> already reset the pointer.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavformat/hls.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>
On 19/05/2020 21:56, Lynne wrote:
> May 19, 2020, 20:57 by s...@jkqxz.net:
>
>> On 13/05/2020 16:53, Lynne wrote:
>>
>>> With this, the puzze of making libplacebo, ffmpeg and any other Vulkan
>>> API users interoperable is complete.
>>> Users of both libraries can initialize one another's context
On 03/05/2020 23:38, Mark Thompson wrote:
> On 03/05/2020 19:14, Michael Niedermayer wrote:
>> On Sun, May 03, 2020 at 04:30:00PM +0100, Mark Thompson wrote:
>>> If the RPS we are predicting from has maximum size then at least one of
>>> the pictures in it must be discarded before adding the curren
On 19/05/2020 22:29, Lynne wrote:
> May 19, 2020, 20:50 by s...@jkqxz.net:
>
>> On 13/05/2020 16:53, Lynne wrote:
>>
>>> This, along with the next patch, are the last missing pieces to being
>>> interoperable with libplacebo.
>>> There is no danger of users running into this API break because the
On 20/05/2020 22:16, Michael Niedermayer wrote:
> On Wed, May 20, 2020 at 08:56:29PM +0200, Michael Niedermayer wrote:
>> On Mon, Apr 20, 2020 at 07:34:44PM -0300, James Almer wrote:
>>> On 4/20/2020 7:03 PM, Michael Niedermayer wrote:
The limit is based on hevcdec.c
Fixes:
20854/cl
On 5/20/2020 6:16 PM, Michael Niedermayer wrote:
> On Wed, May 20, 2020 at 08:56:29PM +0200, Michael Niedermayer wrote:
>> On Mon, Apr 20, 2020 at 07:34:44PM -0300, James Almer wrote:
>>> On 4/20/2020 7:03 PM, Michael Niedermayer wrote:
The limit is based on hevcdec.c
Fixes:
20854/c
On Wed, May 20, 2020 at 08:56:29PM +0200, Michael Niedermayer wrote:
> On Mon, Apr 20, 2020 at 07:34:44PM -0300, James Almer wrote:
> > On 4/20/2020 7:03 PM, Michael Niedermayer wrote:
> > > The limit is based on hevcdec.c
> > > Fixes:
> > > 20854/clusterfuzz-testcase-minimized-ffmpeg_BSF_HEVC_MET
This was a mistake in my own additions in
050b72ab5ef318605b305aa6cb920e8b52f1002e.
---
libavcodec/mfenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/mfenc.c b/libavcodec/mfenc.c
index dd8188dae3..e62ae4019a 100644
--- a/libavcodec/mfenc.c
+++ b/libavcodec/mfenc
Fixes: out of array read
Fixes:
21804/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MV30_fuzzer-5673678898724864
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/mv30.c | 4 ++--
1 file cha
On Wed, May 20, 2020 at 1:17 AM Michael Niedermayer
wrote:
>
> In file included from ./libavutil/avutil.h:296:0,
> from ./libavutil/log.h:25,
> from ./libavutil/thread.h:34,
> from libavdevice/alldevices.c:22:
> ./libavutil/common.h: In function
On Wed, 20 May 2020, Reto Kromer wrote:
Michael Niedermayer wrote:
4.3 is on my todo list, i should have made that already but i
didnt.
realistically 4.3 might happen in 1-2 weeks, if nothing
interferes and nothing unexpected happens.
Thank you, most appreciated! Reto
Sorry, I just reali
On Wed, May 20, 2020 at 08:48:41PM +0530, Gautam Ramakrishnan wrote:
> On Tue, Apr 21, 2020 at 3:41 AM Michael Niedermayer
> wrote:
> >
> > On Mon, Apr 20, 2020 at 04:13:44PM +0530, Gautam Ramakrishnan wrote:
> > > On Mon, Apr 20, 2020 at 3:38 PM Michael Niedermayer
> > > wrote:
> > > >
> > > > O
The framerate field is the one users are supposed to set, but not
all users might be setting it, so it might be good to fall back
time_base in that case.
---
libavcodec/mfenc.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/libavcodec/mfenc.c b/libavcodec/mfenc.c
ind
The old resync logic had some bugs, for example the packet size could stuck
into 192 bytes, because pos47_full was not updated for every packet, and for
unseekable inputs the resync logic simply skipped some 0x47 sync bytes,
therefore the calculated distance between sync bytes was a multiple of 188
Michael Niedermayer wrote:
>4.3 is on my todo list, i should have made that already but i
>didnt.
>realistically 4.3 might happen in 1-2 weeks, if nothing
>interferes and nothing unexpected happens.
Thank you, most appreciated! Reto
___
ffmpeg-devel ma
On Wed, 20 May 2020, Michael Niedermayer wrote:
On Tue, May 19, 2020 at 09:06:59PM +0200, Marton Balint wrote:
pos47_full is not updated for every packet, and for unseekable inputs the
resync logic might simply skip some 0x47 sync bytes. In order to detect these
let's check for modulo instead
On 5/20/2020 3:56 PM, Andreas Rheinhardt wrote:
> Anton Khirnov:
>> Make it clear that the returned reference is owned by the caller.
>> ---
>> libavcodec/avcodec.h | 8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> in
Anton Khirnov:
> Make it clear that the returned reference is owned by the caller.
> ---
> libavcodec/avcodec.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index c9baf859ac..cadd213301 100644
> --- a/libavcodec/avc
On Mon, May 11, 2020 at 01:07:54AM +0200, Paul B Mahol wrote:
> NAK
>
> please remove this code fully.
Id like to apply this and backport to the releases branches because
sonic is in the releases
are you ok with that ?
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611
On Mon, Apr 20, 2020 at 07:34:44PM -0300, James Almer wrote:
> On 4/20/2020 7:03 PM, Michael Niedermayer wrote:
> > The limit is based on hevcdec.c
> > Fixes:
> > 20854/clusterfuzz-testcase-minimized-ffmpeg_BSF_HEVC_METADATA_fuzzer-5160442882424832
> > Fixes: out of array access
> >
> > Found-by:
On Wed, 20 May 2020, Anton Khirnov wrote:
Quoting Marton Balint (2020-05-20 10:35:07)
On Wed, 20 May 2020, Anton Khirnov wrote:
> Quoting Marton Balint (2020-05-18 20:32:53)
>>
>>
>> On Mon, 18 May 2020, Anton Khirnov wrote:
>>
>> > Quoting Marton Balint (2020-05-16 15:52:22)
>> >> Hi,
On 5/20/2020 3:10 AM, Martin Storsjö wrote:
> Sticking a full frame in the extradata works, as the code for writing
> the avcC/hvcC extracts the relevant parameter set NAL units - provided
> that they actually exist in the frame.
>
> Some encoders don't provide split out extradata directly on init
On 5/20/2020 9:52 AM, Anton Khirnov wrote:
> Make it clear that the returned reference is owned by the caller.
> ---
> libavcodec/avcodec.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index c9baf859ac..cadd213301 1
On Wed, 20 May 2020, Limin Wang wrote:
On Wed, May 20, 2020 at 08:26:37AM +0200, Marton Balint wrote:
On Wed, 20 May 2020, lance.lmw...@gmail.com wrote:
>On Tue, May 19, 2020 at 09:06:59PM +0200, Marton Balint wrote:
>>pos47_full is not updated for every packet, and for unseekable inputs t
On Tue, May 19, 2020 at 03:51:32PM +0200, Reto Kromer wrote:
> Michael Niedermayer wrote:
>
> >Its quite a while since 4.2.2 so i intend to make 4.2.3 soon
> >if you want something backported, backport it now
>
> Good news, thank you!
>
> Out of curiosity, are you also preparing the 4.3 major r
On Tue, Apr 21, 2020 at 3:41 AM Michael Niedermayer
wrote:
>
> On Mon, Apr 20, 2020 at 04:13:44PM +0530, Gautam Ramakrishnan wrote:
> > On Mon, Apr 20, 2020 at 3:38 PM Michael Niedermayer
> > wrote:
> > >
> > > On Mon, Apr 20, 2020 at 01:36:47AM +0530, gautamr...@gmail.com wrote:
> > > > From: Ga
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/mpegtsenc.c | 92 +
1 file changed, 47 insertions(+), 45 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index bf1a7ee..9909d25 100644
--- a/libavformat/mpegts
From: Limin Wang
Merge the short lines after the last commit
Signed-off-by: Limin Wang
---
libavformat/mpegtsenc.c | 92 -
1 file changed, 29 insertions(+), 63 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 990
On Wed, 20 May 2020, James Almer wrote:
On 5/20/2020 5:17 AM, Michael Niedermayer wrote:
On Mon, May 18, 2020 at 03:24:59PM -0700, Dale Curtis wrote:
On Mon, May 18, 2020 at 3:24 PM Dale Curtis wrote:
On Mon, May 18, 2020 at 2:22 PM Michael Niedermayer
wrote:
38cfdcfc9d4fa1c1239dc01a76
On Tue, May 19, 2020 at 08:45:22AM +0200, Paul B Mahol wrote:
> it looks fine to me.
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.
si
On Sat, May 09, 2020 at 02:00:04PM +, Zane van Iperen wrote:
> single: Single-track
> track{0,1}: Dual-track
> trunc-t1: Truncated track 1
> trunc-t2-track{0,1}: Fully-truncated track 2
> trunc-t2a-track{0,1}: Partially-truncated track 2
> trunc-h2:
On Mon, May 18, 2020 at 03:38:33PM -0700, Dale Curtis wrote:
> 2d8d554f15a7a27cfeca81467cc9341a86f784e2 added a new error condition
> to mov_read_stsz() but forgot to free a temporary buffer when it
> occurs.
>
> Signed-off-by: Dale Curtis
> ---
> libavformat/mov.c | 1 +
> 1 file changed, 1 ins
On Tue, May 19, 2020 at 12:45:58PM +0200, Andreas Rheinhardt wrote:
> A buffer whose size is not a multiple of four has been initialized using
> consecutive writes of 32bits. This results in a stack-buffer-overflow
> reported by ASAN in the checkasm-sw_scale FATE-test.
>
> Signed-off-by: Andreas R
On 5/20/2020 5:17 AM, Michael Niedermayer wrote:
> On Mon, May 18, 2020 at 03:24:59PM -0700, Dale Curtis wrote:
>> On Mon, May 18, 2020 at 3:24 PM Dale Curtis wrote:
>>
>>> On Mon, May 18, 2020 at 2:22 PM Michael Niedermayer
>>> wrote:
>>>
> 38cfdcfc9d4fa1c1239dc01a766e369b20a0232a sat_
On 20.05.2020 14:31, Nicolas George wrote:
Anton Khirnov (12020-05-20):
You said it: "from the user". The user chose it. The documentation says
"this demuxer user OpenGL, don't use it if applications are not ready
for it", the user chose to use it.
That means we are now forcing all the applica
Make it clear that the returned reference is owned by the caller.
---
libavcodec/avcodec.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index c9baf859ac..cadd213301 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec
On Tue, May 19, 2020 at 09:06:59PM +0200, Marton Balint wrote:
> pos47_full is not updated for every packet, and for unseekable inputs the
> resync logic might simply skip some 0x47 sync bytes. In order to detect these
> let's check for modulo instead of exact value.
>
> Also skip unrecognized syn
Anton Khirnov (12020-05-20):
> > You said it: "from the user". The user chose it. The documentation says
> > "this demuxer user OpenGL, don't use it if applications are not ready
> > for it", the user chose to use it.
>
> That means we are now forcing all the application to be aware that
> certain
Quoting Nicolas George (2020-05-20 11:34:04)
> Anton Khirnov (12020-05-20):
> > To a calling program, this demuxer would appear as any other demuxer.
> > Many programs using libavformat will take the demuxer name from the user
> > and use it as-is, which might break them in non-obvious ways if they
Quoting Dale Curtis (2020-04-24 01:33:21)
> This is a patch Chromium has carried for a while, we forgot to send it
> upstream. 7546ac2fee4 made it so that the start_time for mp3 files is
> adjusted for skip_samples. However, this appears incorrect because
> subsequent packet timestamps are not adju
On Wed, May 20, 2020 at 08:26:37AM +0200, Marton Balint wrote:
>
>
> On Wed, 20 May 2020, lance.lmw...@gmail.com wrote:
>
> >On Tue, May 19, 2020 at 09:06:59PM +0200, Marton Balint wrote:
> >>pos47_full is not updated for every packet, and for unseekable inputs the
> >>resync logic might simply
Anton Khirnov (12020-05-20):
> To a calling program, this demuxer would appear as any other demuxer.
> Many programs using libavformat will take the demuxer name from the user
> and use it as-is, which might break them in non-obvious ways if they use
> OpenGL themselves.
You said it: "from the use
Quoting Marton Balint (2020-05-20 10:35:07)
>
>
> On Wed, 20 May 2020, Anton Khirnov wrote:
>
> > Quoting Marton Balint (2020-05-18 20:32:53)
> >>
> >>
> >> On Mon, 18 May 2020, Anton Khirnov wrote:
> >>
> >> > Quoting Marton Balint (2020-05-16 15:52:22)
> >> >> Hi,
> >> >>
> >> >> As you ma
Quoting Nicolas George (2020-05-20 10:47:57)
> Anton Khirnov (12020-05-20):
> > For what my opinion is worth, I agree with Lynne here. Messing with
> > OpenGL global state in the libraries is something we absolutely should
> > not do.
>
> Good thing we would not be "messing with" anything. We woul
Anton Khirnov (12020-05-20):
> For what my opinion is worth, I agree with Lynne here. Messing with
> OpenGL global state in the libraries is something we absolutely should
> not do.
Good thing we would not be "messing with" anything. We would be using
the global OpenGL state at the request of the
Quoting Lynne (2020-05-19 21:52:29)
>
> That's a driver issue, no fault of kmsgrab, and I can't even confirm seeing
> those bugs happen to anyone
> using kmsgrab, either on intel or amd, so maybe your system state was
> somewhat broken?
> Either way, there's still the issue of OpenGL state, Open
On Wed, 20 May 2020, Anton Khirnov wrote:
Quoting Marton Balint (2020-05-18 20:32:53)
On Mon, 18 May 2020, Anton Khirnov wrote:
> Quoting Marton Balint (2020-05-16 15:52:22)
>> Hi,
>>
>> As you may know, a recent patchset enabled AVCodecContext->profile
>> constants to reside in encoders
Quoting Marton Balint (2020-05-18 20:32:53)
>
>
> On Mon, 18 May 2020, Anton Khirnov wrote:
>
> > Quoting Marton Balint (2020-05-16 15:52:22)
> >> Hi,
> >>
> >> As you may know, a recent patchset enabled AVCodecContext->profile
> >> constants to reside in encoders.
> >>
> >> In order to make
On Mon, May 18, 2020 at 03:24:59PM -0700, Dale Curtis wrote:
> On Mon, May 18, 2020 at 3:24 PM Dale Curtis wrote:
>
> > On Mon, May 18, 2020 at 2:22 PM Michael Niedermayer
> > wrote:
> >
> >>
> >> > 38cfdcfc9d4fa1c1239dc01a766e369b20a0232a sat_math_builtin_v5.patch
> >>
> >
> > Latest upload is
On Sat, May 09, 2020 at 09:45:05AM +0200, Matthieu Bouron wrote:
> On Tue, Mar 31, 2020 at 10:03:08AM +0200, Matthieu Bouron wrote:
> > ---
> > libavcodec/mediacodecdec_common.c | 100 ++
> > 1 file changed, 100 insertions(+)
> >
> > diff --git a/libavcodec/mediacodecd
> If that was the only concern against it, then I'd say it is acceptable.
> But there are some other concerns, also it seems to me xcbgrab can be
> improved to reach the same smoothness as this attempt, and that was the
> main distinctive feature of it. With that advantage lost, I'd say fixing
> x
65 matches
Mail list logo
