On 7/20/2020 3:01 PM, James Zern wrote:
> similar to:
> 36e51c190b avcodec/libaomenc: use pix_fmt descriptors where useful
>
> Signed-off-by: James Zern
> ---
> libavcodec/libvpxenc.c | 13 +++--
> 1 file changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/libavcodec/libvpxenc.c
On 7/20/2020 11:12 PM, Andreas Rheinhardt wrote:
> The loop variable here that can be as high as UINT16_MAX - 1 gets
> left-shifted by 16 bits which is outside the range of int. So use
> unsigned.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/rmdec.c | 2 +-
> 1 file changed, 1
by setting the AVFMT_HEADER_CLEANUP flag.
(Btw: concat_read_close() is not idempotent (it frees cat->files, but
doesn't reset cat->nb_files), so this demuxer was incompatible with
simply calling read_close generically upon read_header failure.)
Signed-off-by: Andreas Rheinhardt
---
For both the RealMedia as well as the IVR demuxer (which share the same
context) each AVStream's priv_data contains an AVPacket that might
contain data (even when reading the header) and therefore needs to be
unreferenced. Up until now, this has not always been done:
The RealMedia demuxer didn't
by setting the AVFMT_HEADER_CLEANUP flag.
Signed-off-by: Andreas Rheinhardt
---
libavformat/paf.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/libavformat/paf.c b/libavformat/paf.c
index a31d01502b..9072c79edd 100644
--- a/libavformat/paf.c
+++
The loop variable here that can be as high as UINT16_MAX - 1 gets
left-shifted by 16 bits which is outside the range of int. So use
unsigned.
Signed-off-by: Andreas Rheinhardt
---
libavformat/rmdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/rmdec.c
The RealMedia demuxer uses the priv_data of its streams to store a
structure containing an AVPacket. These packets are unreferenced in the
read_close function, yet said function simply presumed that the
priv_data has been successfully allocated. This implies that it mustn't
be called when an
The RealMedia demuxer's read_header function initially initializes ret,
the variable designated for the return variable to -1. Afterwards, chunks
of the file are parsed in a loop until an error happens or until the actual
frame data is encountered. If the first function whose return
value is put
by setting the AVFMT_HEADER_CLEANUP flag.
Signed-off-by: Andreas Rheinhardt
---
libavformat/mxfdec.c | 24 +++-
1 file changed, 7 insertions(+), 17 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 90546d42b3..06c6e0890b 100644
---
On 7/20/2020 9:35 PM, Andreas Rheinhardt wrote:
> James Almer:
>> On 7/19/2020 5:47 PM, Andreas Rheinhardt wrote:
>>> If reading the header fails, the demuxer's read_close() function (if
>>> existing) is not called automatically; instead several demuxers call it
>>> via "goto fail" in
On 7/20/2020 6:32 PM, Brian Kim wrote:
> Just wanted to check if there was any consensus on what we wanted to do
> with these changes. Are we holding off until a future module wide change?
No, i'll push v3 soon if my argumentation below was not enough to
convince Nicolas or Michael. My intention
James Almer:
> On 7/19/2020 5:47 PM, Andreas Rheinhardt wrote:
>> If reading the header fails, the demuxer's read_close() function (if
>> existing) is not called automatically; instead several demuxers call it
>> via "goto fail" in read_header().
>>
>> This commit intends to change this by adding
On 7/19/2020 5:47 PM, Andreas Rheinhardt wrote:
> If reading the header fails, the demuxer's read_close() function (if
> existing) is not called automatically; instead several demuxers call it
> via "goto fail" in read_header().
>
> This commit intends to change this by adding a flag to
On Mon, Jul 20, 2020 at 11:04:38PM +0200, Marton Balint wrote:
> 50/60 fps timecode is using the field bit (which is the same as the phase
> correction bit) to signal the least significant bit of a 50/60 fps timecode.
> See SMPTE ST 12-1:2014 section 12.1.
>
> Let's add support for this by using
On 20 Jul 2020, at 23:53, Steinar H. Gunderson wrote:
On Mon, Jul 20, 2020 at 04:28:02PM -0400, Zachariah Brown wrote:
Paul, no body attacked you in anyway personally. I don't know what
happened
in the past because I've only been here for a couple of months, but
it was
very clear that
Just wanted to check if there was any consensus on what we wanted to do
with these changes. Are we holding off until a future module wide change?
On Wed, Jul 15, 2020 at 8:09 AM James Almer wrote:
> On 7/15/2020 4:06 AM, Nicolas George wrote:
> > Michael Niedermayer (12020-07-14):
> >> Let me
On Mon, Jul 20, 2020 at 04:28:02PM -0400, Zachariah Brown wrote:
> Paul, no body attacked you in anyway personally. I don't know what happened
> in the past because I've only been here for a couple of months, but it was
> very clear that Steinar was being purely objective about your patch.
Like I
I'm just an independent observer who has submitted just a single trivial
patch that decided to stay subscribed to this mailing list to keep up to
date with what is happening. I have no bone in this game but I feel like
something needs to be said.
Let me just say that this entire thread does
On Mon, 20 Jul 2020, Marton Balint wrote:
This feature looks like it belongs to
av_timecode_get_smpte_from_framenum and not into decklink.
I just sent a patch which implements this, because I confirmed that other
code using av_timecode_get_smpte_from_framenum also seem to require the
Signed-off-by: Marton Balint
---
libavutil/timecode.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/libavutil/timecode.c b/libavutil/timecode.c
index cb916970ef..b528e4a510 100644
--- a/libavutil/timecode.c
+++ b/libavutil/timecode.c
@@ -71,7 +71,7 @@ uint32_t
50/60 fps timecode is using the field bit (which is the same as the phase
correction bit) to signal the least significant bit of a 50/60 fps timecode.
See SMPTE ST 12-1:2014 section 12.1.
Let's add support for this by using the recently added av_timecode_get_smpte
function which handles this
We are not providing a binary group pack with the flags and the biphase
polarity flag is destroying 50/60 fps timecode bits.
Signed-off-by: Marton Balint
---
libavformat/dvenc.c | 1 -
tests/ref/lavf/dv | 2 +-
tests/ref/lavf/dv_ntsc | 2 +-
On 7/20/20, Nicolas George wrote:
> Michael Niedermayer (12020-07-20):
>> shouldnt code which is used by multiple filters be shared and available
>> to all filters ?
>
> Yes indeed. Since a fixed-size window on samples is a recurring pattern
> in filters, a helper API for it would be very
On Sat, 18 Jul 2020 20:29:01 +0300
Aleksey Skripka wrote:
> Greetings!
>
> unconditional AVFMT_TS_DISCONT also helps to survive when pts
> rollover in mpegts occurs. seems like this patch will break again
> reading long-lasting hls.
>
Right.
The flag on the InputFormat says the format
On Thu, Jul 16, 2020 at 09:27:27AM +0200, Michael Niedermayer wrote:
> Fixes: out of array access
> Fixes: crash.asf
>
> Found-by: anton listov
> Reviewed-by: anton listov
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/tdsc.c | 21 ++---
> 1 file changed, 10
Michael Niedermayer (12020-07-20):
> shouldnt code which is used by multiple filters be shared and available
> to all filters ?
Yes indeed. Since a fixed-size window on samples is a recurring pattern
in filters, a helper API for it would be very welcome. But it should not
make the evolution of
On Thu, Jun 11, 2020 at 08:31:57PM +0200, Nicolas George wrote:
> Paul B Mahol (12020-06-11):
> > Signed-off-by: Paul B Mahol
> > ---
> > libavfilter/avfilter.c | 61 +-
> > libavfilter/filters.h | 17
> > 2 files changed, 72 insertions(+), 6
On 7/20/20, Paul B Mahol wrote:
> Look at thread:
>
> avfilter: add ff_inlink_peek_samples and ff_inlink_skip samples
>
> Another developer is constantly blocking my patches.
>
If TC does not act soon I will be forced to do it myself.
___
ffmpeg-devel
On Mon, Jul 20, 2020 at 09:34:07AM +0800, Fei Wang wrote:
> This fixed FATE fail report by filter-pixfmts* for x2rgb10le on big
> endian hardware.
> ---
> libswscale/input.c | 11 ++-
> libswscale/yuv2rgb.c | 6 +-
> 2 files changed, 11 insertions(+), 6 deletions(-)
will apply
On Sun, Jul 19, 2020 at 10:47:55PM +0200, Andreas Rheinhardt wrote:
> wc3_read_header() might fail after having read some data into a packet
> in which case this data would leak. Fix this by setting the
> AVFMT_HEADER_CLEANUP flag that ensures that the demuxer's read_close
> function is called (it
On Sun, Jul 19, 2020 at 10:47:54PM +0200, Andreas Rheinhardt wrote:
> If reading the header fails, the demuxer's read_close() function (if
> existing) is not called automatically; instead several demuxers call it
> via "goto fail" in read_header().
>
> This commit intends to change this by adding
similar to:
36e51c190b avcodec/libaomenc: use pix_fmt descriptors where useful
Signed-off-by: James Zern
---
libavcodec/libvpxenc.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 8e0ea42375..3d5e6c12e3
On Sun, Jul 19, 2020 at 08:29:29PM +0200, Steinar H. Gunderson wrote:
> lzwenc stores a function pointer to either put_bits or put_bits_le;
> however, after the recent change, the function pointer's prototype
> would depend on BitBuf. BitBuf is defined in put_bits.h, whose
> definition depends on
On Sun, Jul 19, 2020 at 07:51:47PM +0200, Nicolas George wrote:
> Michael Niedermayer (12020-07-19):
> > Fixes: signed integer overflow: 339867072 + 9195561788997000192
> > cannot be represented in type 'long'
> > Fixes:
> >
Signed-off-by: Andreas Rheinhardt
---
Will apply this triviality in two days if there are no objections.
libavformat/matroskadec.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 6abb5412de..b1ef344aa7 100644
On Mon, Jul 20, 2020 at 12:28 AM Carl Eugen Hoyos wrote:
>
> Am So., 19. Juli 2020 um 20:18 Uhr schrieb Gautam Ramakrishnan
> :
> >
> > On Sun, Jul 19, 2020 at 11:33 PM Thomas Volkert wrote:
> > >
> > > Hi,
> > >
> > > On 19.07.2020 18:10, Gautam Ramakrishnan wrote:
> > > > On Thu, Jul 16, 2020
Alexander Strasser:
> On 2020-07-19 23:38 +0200, Andreas Rheinhardt wrote:
>> Alexander Strasser:
> [...]
>>>
>>> On 2020-07-17 13:14 +0200, Andreas Rheinhardt wrote:
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/au.c | 13 ++---
> 1
On Mon, 20 Jul 2020, lance.lmw...@gmail.com wrote:
On Sun, Jul 19, 2020 at 09:05:33AM +0200, Marton Balint wrote:
On Sun, 19 Jul 2020, lance.lmw...@gmail.com wrote:
> On Sat, Jul 18, 2020 at 08:38:16PM +0200, Marton Balint wrote:
> >
> >
> > On Sat, 18 Jul 2020, lance.lmw...@gmail.com
On Mon, 20 Jul 2020 10:46:29 +
"Zane van Iperen" wrote:
>
> Signed-off-by: Zane van Iperen
> ---
> libavformat/apm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
This is a trivial fix, will apply tomorrow if no objections.
___
On Fri, May 15, 2020 at 3:21 PM Fu, Linjie wrote:
>
> > From: ffmpeg-devel On Behalf Of
> > Mark Thompson
> > Sent: Sunday, March 8, 2020 00:15
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH 4/4] vaapi_encode_h265: Enable 4:2:2
> > support
> >
> > On 05/03/2020 02:49, Fu,
This enables VAAPI encoding support for 422 10-bit(Y210).
Signed-off-by: Linjie Fu
---
libavcodec/vaapi_encode.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 1de43cc..6766641 100644
--- a/libavcodec/vaapi_encode.c
+++
On Sun, Jul 19, 2020 at 09:05:33AM +0200, Marton Balint wrote:
>
>
> On Sun, 19 Jul 2020, lance.lmw...@gmail.com wrote:
>
> > On Sat, Jul 18, 2020 at 08:38:16PM +0200, Marton Balint wrote:
> > >
> > >
> > > On Sat, 18 Jul 2020, lance.lmw...@gmail.com wrote:
> > >
> > > > On Sat, Jul 18, 2020
On Mon, Jul 20, 2020 at 10:18 AM Steven Liu wrote:
>
> Jun Zhao 于2020年7月18日周六 下午7:56写道：
> >
> > From: Jun Zhao
> >
> > Enable the custom callback in sub-demuxer
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavformat/hls.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git
On Mon, Jul 20, 2020 at 10:18 AM Steven Liu wrote:
>
> Jun Zhao 于2020年7月18日周六 下午8:19写道：
> >
> > From: Jun Zhao
> >
> > Enable the custom callback in sub-demuxer
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavformat/dashdec.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git
Signed-off-by: Zane van Iperen
---
libavformat/apm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/apm.c b/libavformat/apm.c
index 0d88e1099a..fe95a9ad7a 100644
--- a/libavformat/apm.c
+++ b/libavformat/apm.c
@@ -126,8 +126,8 @@ static int
> -Original Message-
> From: ffmpeg-devel On Behalf Of Guo,
> Yejun
> Sent: Monday, July 20, 2020 01:46 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] dnn/native: add native support for
> avg_pool
>
>
>
> > -Original Message-
>
On 2020-07-19 23:38 +0200, Andreas Rheinhardt wrote:
> Alexander Strasser:
[...]
> >
> > On 2020-07-17 13:14 +0200, Andreas Rheinhardt wrote:
> >> Andreas Rheinhardt:
> >>> Signed-off-by: Andreas Rheinhardt
> >>> ---
> >>> libavformat/au.c | 13 ++---
> >>> 1 file changed, 6
Look at thread:
avfilter: add ff_inlink_peek_samples and ff_inlink_skip samples
Another developer is constantly blocking my patches.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe,
The Matroska demuxer currently always opens a GetByteContext to read the
content of the projection's private data buffer; it does this even if
there is no private data buffer in which case opening the GetByteContext
will lead to a NULL + 0 which is undefined behaviour.
Furthermore, in this case
Hi Andriy!
On 2020-07-19 19:47 -0400, Andriy Gelman wrote:
> On Sun, 19. Jul 23:19, Alexander Strasser wrote:
> > On 2020-07-16 23:54 -0400, Andriy Gelman wrote:
> > > On Tue, 14. Jul 14:14, Moritz Barsnick wrote:
[...]
> > > > --- a/libavdevice/xcbgrab.c
> > > > +++ b/libavdevice/xcbgrab.c
> > >
When parsing MXF encountering some tags leads to allocations. And when
these tags were encountered repeatedly, this could lead to memleaks,
because the pointer to the old data got simply overwritten with a
pointer to the new data (or to NULL on allocation failure). This has
been fixed.
Said array contains pointers to other structs and both the designated
new element as well as other stuff contained in it (e.g. strings) leak
if the new element can't be added to the array.
Signed-off-by: Andreas Rheinhardt
---
libavformat/mxfdec.c | 14 +++---
1 file changed, 7
The MXF demuxer uses an array of pointers to different structures of
metadata (all containing a common initial sequence containing a type
field to distinguish them) and some of these structures contain pointers
to separately allocated subelements. If an error happens while reading
and creating the
53 matches
Mail list logo
