---
configure | 2 +-
libavcodec/mv30.c | 22 ++
2 files changed, 3 insertions(+), 21 deletions(-)
diff --git a/configure b/configure
index 4d4c429be9..f008559fd8 100755
--- a/configure
+++ b/configure
@@ -2790,7 +2790,7 @@ msmpeg4v3_decoder_select="h263_decoder"
---
libavcodec/mv30.c | 16
1 file changed, 16 deletions(-)
diff --git a/libavcodec/mv30.c b/libavcodec/mv30.c
index ffa04ac493..6e25ed647b 100644
--- a/libavcodec/mv30.c
+++ b/libavcodec/mv30.c
@@ -86,14 +86,6 @@ static const uint8_t luma_tab[] = {
25, 31, 42, 48, 58, 72,
On other platforms, the functions are named get_cabac_inline_xxx but not
this one. There's also a define.
Signed-off-by: Rosen Penev
---
libavcodec/mips/cabac.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/mips/cabac.h b/libavcodec/mips/cabac.h
index
get_cabac_inline for mips uses inline asm that relies on mips32
instructions.
Signed-off-by: Rosen Penev
---
libavcodec/mips/cabac.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/mips/cabac.h b/libavcodec/mips/cabac.h
index 2a05e5ab3c..cc40dbba15 100644
---
On Sat, Apr 11, 2020 at 10:55 PM Carl Eugen Hoyos wrote:
>
> Am Sa., 11. Apr. 2020 um 15:53 Uhr schrieb Jun Zhao :
> >
> > From: Jun Zhao
> >
> > add a new sidedata type for Dolby Vision.
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavcodec/avpacket.c | 1 +
> > libavcodec/packet.h | 9
On Sat, Apr 11, 2020 at 11:01 PM Jan Ekström wrote:
>
> On Sat, Apr 11, 2020 at 5:49 PM Carl Eugen Hoyos wrote:
> >
> > Am Sa., 11. Apr. 2020 um 16:08 Uhr schrieb Jun Zhao :
> > >
> > > From: vacinfang
> > >
> > > add dolby vision related header
> >
> > Apart from the name of the header file:
>
On Sat, Apr 11, 2020 at 10:48 PM Carl Eugen Hoyos wrote:
>
> Am Sa., 11. Apr. 2020 um 16:24 Uhr schrieb myp...@gmail.com
> :
> >
> > On Mon, Mar 30, 2020 at 4:52 PM myp...@gmail.com wrote:
> > >
> > > On Mon, Mar 30, 2020 at 4:31 PM Jun Zhao wrote:
> > > >
> > > > From: qoroliang
> > > >
> >
On Sat, Apr 11, 2020 at 10:18 PM Jean-Baptiste Kempf wrote:
>
> I really do not think it is a good idea to have a header with the name dolby
> in it.
>
Can you give some details, I don't why is a bad idea.
> On Sat, Apr 11, 2020, at 15:44, Jun Zhao wrote:
> > From: vacinfang
> >
> > add dolby
On Sun, Apr 12, 2020 at 3:40 AM Moritz Barsnick wrote:
>
> On Sat, Apr 11, 2020 at 21:44:07 +0800, Jun Zhao wrote:
> > From: Jun Zhao
> >
> > dump dolby vison side data.
> ^ You have this typo in several of your commit messages
>and sources.
>
> Moritz
Will
If writing uncoded frames in noninterleaved mode fails at the preparatory
steps (i.e. before it reaches write_packet()), the packet would not be
unreferenced and the frame would leak. This is fixed by unreferencing
the packet in write_uncoded_frame_internal() instead.
This also makes it possible
Currently uncoded frames (i.e. packets whose data actually points to an
AVFrame) are not refcounted. As a consequence, calling av_packet_unref()
on them will not free them, but may simply make sure that they leak by
losing the pointer to the frame.
This commit changes this by actually making
Am So., 12. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos
:
>
> Am So., 5. Apr. 2020 um 14:03 Uhr schrieb Michael Niedermayer
> :
> >
> > On Sat, Apr 04, 2020 at 12:46:36AM +0200, Carl Eugen Hoyos wrote:
> > > Hi!
> > >
> > > Attached patch makes the alloc array functions more similar to
> > >
Andreas Rheinhardt:
> Forgotten in ab502fab.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> Sorry for this mistake in ab502fab.
>
> 054ce5f786f0bff2491bda5497850d2390621176 is not a real fix, because
> --disable-everything --enable-muxer=ilbc would still fail.
>
> libavformat/Makefile | 2 +-
>
Am So., 5. Apr. 2020 um 14:03 Uhr schrieb Michael Niedermayer
:
>
> On Sat, Apr 04, 2020 at 12:46:36AM +0200, Carl Eugen Hoyos wrote:
> > Hi!
> >
> > Attached patch makes the alloc array functions more similar to
> > av_malloc, depending on max_alloc_size instead of INT_MAX.
> >
> > Allows a
Marton Balint:
>
>
> On Sat, 11 Apr 2020, James Almer wrote:
>
>> On 4/11/2020 6:35 PM, Andreas Rheinhardt wrote:
>>> James Almer:
On 4/11/2020 6:19 PM, Andreas Rheinhardt wrote:
> Currently uncoded frames (i.e. packets whose data actually points
> to an
> AVFrame) are not
On Sat, 11 Apr 2020, James Almer wrote:
On 4/11/2020 6:35 PM, Andreas Rheinhardt wrote:
James Almer:
On 4/11/2020 6:19 PM, Andreas Rheinhardt wrote:
Currently uncoded frames (i.e. packets whose data actually points to an
AVFrame) are not refcounted. As a consequence, calling
On Fri, Apr 10, 2020 at 11:18 PM James Zern wrote:
>
> On Fri, Apr 10, 2020 at 10:50 PM James Zern wrote:
> >
> > On Fri, Apr 3, 2020 at 2:07 PM Wang Cao wrote:
> > >
> > > Signed-off-by: Wang Cao
> > > ---
> > > doc/encoders.texi | 9 +
> > > libavcodec/libaomenc.c | 7 +++
>
On 4/11/2020 6:35 PM, Andreas Rheinhardt wrote:
> James Almer:
>> On 4/11/2020 6:19 PM, Andreas Rheinhardt wrote:
>>> Currently uncoded frames (i.e. packets whose data actually points to an
>>> AVFrame) are not refcounted. As a consequence, calling av_packet_unref()
>>> on them will not free them,
James Almer:
> On 4/11/2020 6:19 PM, Andreas Rheinhardt wrote:
>> Currently uncoded frames (i.e. packets whose data actually points to an
>> AVFrame) are not refcounted. As a consequence, calling av_packet_unref()
>> on them will not free them, but may simply make sure that they leak by
>> losing
On Sat, Apr 11, 2020 at 03:20:39PM +0100, Mark Thompson wrote:
> On 11/04/2020 11:18, Michael Niedermayer wrote:
> > On Sat, Apr 11, 2020 at 12:29:37AM -0300, James Almer wrote:
> >> On 4/10/2020 11:49 PM, James Almer wrote:
> >>> On 4/10/2020 9:00 PM, James Almer wrote:
> On 4/10/2020 8:53
On 4/11/2020 6:19 PM, Andreas Rheinhardt wrote:
> Currently uncoded frames (i.e. packets whose data actually points to an
> AVFrame) are not refcounted. As a consequence, calling av_packet_unref()
> on them will not free them, but may simply make sure that they leak by
> losing the pointer to the
The documentation of av_write_frame() explicitly states that the function
doesn't take ownership of the packets sent to it; while av_write_frame()
does not directly unreference the packets after having written them, it
nevertheless modifies the packet in various ways:
1. The timestamps might be
write_packet() currently saves the original timestamps of the packet it
got and restores them in case writing fails. This is unnecessary as we
are no longer working directly with the user-supplied AVPacket here; and
it is also pointless because the timestamps may already have been
altered before
When an error happened in ff_interleave_add_packet() when adding
a packet to the packet queue, said packet would not be unreferenced
in ff_interleave_add_packet(), but would be zeroed in
av_interleaved_write_frame(), which results in a memleak.
This has been fixed: ff_interleave_add_packet() now
If writing uncoded frames in noninterleaved mode fails at the preparatory
steps (i.e. before it reaches write_packet()), the packet would not be
unreferenced and the frame would leak. This is fixed by unreferencing
the packet in write_uncoded_frame_internal() instead.
This also makes it possible
Now that ff_interleave_add_packet() always returns blank packets, the
input packet to ff_interleave_packet_per_dts() will always be blank on
return as well (if supplied) and the same goes for interleave_packet()
in mux.c. Document these facts and remove the redundant resetting that
happened in
Currently uncoded frames (i.e. packets whose data actually points to an
AVFrame) are not refcounted. As a consequence, calling av_packet_unref()
on them will not free them, but may simply make sure that they leak by
losing the pointer to the frame.
This commit changes this by mimicking what is
On 4/11/2020 12:06 PM, Anton Khirnov wrote:
> Non-refcounted frames are deprecated and there is no good reason to use
> them.
> ---
> doc/examples/demuxing_decoding.c | 28 ++--
> 1 file changed, 6 insertions(+), 22 deletions(-)
>
> diff --git
On Fri, 10 Apr 2020 21:49:35 +
John Stebbins wrote:
> On Fri, 2020-04-10 at 14:12 -0700, Philip Langdale wrote:
> > On Fri, 10 Apr 2020 13:02:16 -0600
> > John Stebbins wrote:
> >
> > > Patch set makes return codes from subtitle encoders more
> > > meaningful and consistent. Also fixes
On 4/11/20, Zane van Iperen wrote:
> On Fri, 10 Apr 2020 12:26:50 +
> "Zane van Iperen" wrote:
>
>> Signed-off-by: Zane van Iperen
>> ---
>> Changelog | 1 +
>> doc/general.texi | 2 +-
>> libavcodec/Makefile| 1 +
>> libavcodec/adpcmenc.c | 30
On Sat, Apr 11, 2020 at 21:44:07 +0800, Jun Zhao wrote:
> From: Jun Zhao
>
> dump dolby vison side data.
^ You have this typo in several of your commit messages
and sources.
Moritz
___
ffmpeg-devel mailing list
On Mon, 6 Apr 2020, Nicolas George wrote:
Marton Balint (12020-04-06):
The same goal can be achieved using the WRAPPED_AVFRAME codec with the existing
API.
These two APIs are somewhat redundant, but we need to discuss which one
we want to keep.
WRAPPED_AVFRAME is nice because it goes
Also change the default to that.
Signed-off-by: Marton Balint
---
libavdevice/opengl_enc.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/libavdevice/opengl_enc.c b/libavdevice/opengl_enc.c
index ae03caa8c5..2bdb8da732 100644
---
Also change the default to that.
Signed-off-by: Marton Balint
---
libavdevice/xv.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/libavdevice/xv.c b/libavdevice/xv.c
index c3ed2e48bd..50dc4e0d04 100644
--- a/libavdevice/xv.c
+++ b/libavdevice/xv.c
@@
On 4/11/2020 2:59 PM, Anton Khirnov wrote:
> Quoting James Almer (2020-04-11 19:46:03)
>> On 4/11/2020 12:06 PM, Anton Khirnov wrote:
>>
>> Instead of this, it might be better to call receive_frame() one time
>> after each call to send_packet(), regardless of the latter consuming the
>> packet or
Quoting James Almer (2020-04-11 19:46:03)
> On 4/11/2020 12:06 PM, Anton Khirnov wrote:
>
> Instead of this, it might be better to call receive_frame() one time
> after each call to send_packet(), regardless of the latter consuming the
> packet or not. If it doesn't, then you just keep it around
On 4/11/2020 12:06 PM, Anton Khirnov wrote:
> ---
> doc/examples/demuxing_decoding.c | 177 ---
> 1 file changed, 91 insertions(+), 86 deletions(-)
>
> diff --git a/doc/examples/demuxing_decoding.c
> b/doc/examples/demuxing_decoding.c
> index 9bde927321..803e35d25c
On 4/11/20, Carl Eugen Hoyos wrote:
> Am Sa., 11. Apr. 2020 um 15:10 Uhr schrieb Paul B Mahol :
>>
>> On 4/11/20, Carl Eugen Hoyos wrote:
>> > Am So., 5. Apr. 2020 um 02:05 Uhr schrieb Carl Eugen Hoyos
>> > :
>> >>
>> >> Am So., 5. Apr. 2020 um 01:02 Uhr schrieb Carl Eugen Hoyos
>> >> :
>> >> >
On Sat, Apr 11, 2020 at 12:10:08PM +0530, gautamr...@gmail.com wrote:
> From: Gautam Ramakrishnan
>
> This patch fixes an error where the COC marker
> overrides all data of the SPcod field of the
> COD marker. It must override only one bit of
> SPcod field. This now allows p0_08.j2k to be
>
On Sat, Apr 11, 2020 at 12:10:09PM +0530, gautamr...@gmail.com wrote:
> From: Gautam Ramakrishnan
>
> The calculation of precinct boundaries has been
> fixed. The precinct boundaries were calculated
> as an offset to the band boundary, but must
> instead be calculated as an offset from the
>
On Sat, Apr 11, 2020 at 10:55:04AM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2020-04-09 20:12:11)
> > Fixes: shift exponent 32 is too large for 32-bit type 'int'
> > Fixes:
> > 21200/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_XAN_DPCM_fuzzer-5754704894361600
> >
> >
On Fri, 10 Apr 2020 12:26:50 +
"Zane van Iperen" wrote:
> Signed-off-by: Zane van Iperen
> ---
> Changelog | 1 +
> doc/general.texi | 2 +-
> libavcodec/Makefile| 1 +
> libavcodec/adpcmenc.c | 30 ++
> libavcodec/allcodecs.c | 1 +
>
On Sat, 11. Apr 18:56, Jan Ekström wrote:
> On Sat, Apr 11, 2020 at 6:43 PM Andriy Gelman wrote:
> >
> > On Sat, 11. Apr 15:56, Mark Thompson wrote:
> > > On 04/04/2020 21:26, Andriy Gelman wrote:
> > > > From: Andriy Gelman
> > > >
> > > > The dequeued packets from vp8 (s5p-mfc) encoder are
On Tue, 07 Apr 2020 10:48:53 +
"Zane van Iperen" wrote:
> Adds support for the soundbank files used by the Pro Pinball series
> of games.
>
> Please CC for review.
>
> v8:
> - change "goto done" to a return + "goto fail"
> - Handle truncated files
> - Fix potential byte counter
On Sat, Apr 11, 2020 at 6:43 PM Andriy Gelman wrote:
>
> On Sat, 11. Apr 15:56, Mark Thompson wrote:
> > On 04/04/2020 21:26, Andriy Gelman wrote:
> > > From: Andriy Gelman
> > >
> > > The dequeued packets from vp8 (s5p-mfc) encoder are output in ivf format
> > > which breaks the stream when the
Apr 11, 2020, 15:56 by s...@jkqxz.net:
> On 04/04/2020 21:26, Andriy Gelman wrote:
>
>> From: Andriy Gelman
>>
>> The dequeued packets from vp8 (s5p-mfc) encoder are output in ivf format
>> which breaks the stream when the packets are muxed in avformat. This commit
>> adds an option to remove
> From: ffmpeg-devel On Behalf Of Fu,
> Linjie
> Sent: Saturday, March 28, 2020 23:02
> To: FFmpeg development discussions and patches de...@ffmpeg.org>; myp...@gmail.com
> Subject: Re: [FFmpeg-devel] [PATCH 3/3] lavc/vaapi_encode_h265: add h265
> tile encoding support
>
> > From: ffmpeg-devel
Hi!
I would like to discuss this patch, but I can't find who is the maintainer
of this codec.
https://github.com/FFmpeg/FFmpeg/blob/master/MAINTAINERS
Does anyone know?
If something was BAD, I would like to rewrite it better.
If splitting this patch into gray support and lossless support patch
On 4/10/2020 12:41 PM, Anton Khirnov wrote:
> ---
> Not sure what to do with AVFieldOrder. It gets moved to codec_par.h
> since it is used in AVCodecParameters, but it isn't precisely the right
> place for it, though it's not horribly wrong either.
How about moving it to lavu's pixfmt.h,
On Sat, 11. Apr 15:56, Mark Thompson wrote:
> On 04/04/2020 21:26, Andriy Gelman wrote:
> > From: Andriy Gelman
> >
> > The dequeued packets from vp8 (s5p-mfc) encoder are output in ivf format
> > which breaks the stream when the packets are muxed in avformat. This commit
> > adds an option to
On Wed, 08. Apr 20:51, Andriy Gelman wrote:
> On Wed, 01. Apr 10:38, Ming Qian wrote:
> > when the last frame of capture is dequeueed,
> > driver may send this V4L2_EVENT_EOS event,
> > If this event is received, then the capture buffers have been flushed and
> >
Carl Eugen Hoyos:
> Am Sa., 11. Apr. 2020 um 16:41 Uhr schrieb Andreas Rheinhardt
> :
>>
>> This is required to use it as an AVCodec.supported_samplerates array.
>> Adding the sentinel has been forgotten in 4679a474.
>> Without it e.g. the FATE-test ffmpeg-filter_complex_audio fails with ASAN.
>
---
doc/examples/muxing.c | 95 ++-
1 file changed, 39 insertions(+), 56 deletions(-)
diff --git a/doc/examples/muxing.c b/doc/examples/muxing.c
index 9af9aae483..c1d42303af 100644
--- a/doc/examples/muxing.c
+++ b/doc/examples/muxing.c
@@ -78,15 +78,45 @@
---
doc/examples/demuxing_decoding.c | 177 ---
1 file changed, 91 insertions(+), 86 deletions(-)
diff --git a/doc/examples/demuxing_decoding.c b/doc/examples/demuxing_decoding.c
index 9bde927321..803e35d25c 100644
--- a/doc/examples/demuxing_decoding.c
+++
Non-refcounted frames are deprecated and there is no good reason to use
them.
---
doc/examples/demuxing_decoding.c | 28 ++--
1 file changed, 6 insertions(+), 22 deletions(-)
diff --git a/doc/examples/demuxing_decoding.c b/doc/examples/demuxing_decoding.c
index
Am Sa., 11. Apr. 2020 um 10:12 Uhr schrieb Zane van Iperen
:
>
> Signed-off-by: Zane van Iperen
> ---
> libavcodec/adpcm.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
> index e9abddc43c..ee18875579 100644
>
On Sat, Apr 11, 2020 at 5:49 PM Carl Eugen Hoyos wrote:
>
> Am Sa., 11. Apr. 2020 um 16:08 Uhr schrieb Jun Zhao :
> >
> > From: vacinfang
> >
> > add dolby vision related header
>
> Apart from the name of the header file:
> Could you explain why it is needed?
>
> Is the Dolby Vision metadata not
Am Sa., 11. Apr. 2020 um 15:10 Uhr schrieb Paul B Mahol :
>
> On 4/11/20, Carl Eugen Hoyos wrote:
> > Am So., 5. Apr. 2020 um 02:05 Uhr schrieb Carl Eugen Hoyos
> > :
> >>
> >> Am So., 5. Apr. 2020 um 01:02 Uhr schrieb Carl Eugen Hoyos
> >> :
> >> >
> >> > Am Sa., 4. Apr. 2020 um 00:44 Uhr
On 04/04/2020 21:26, Andriy Gelman wrote:
> From: Andriy Gelman
>
> The dequeued packets from vp8 (s5p-mfc) encoder are output in ivf format
> which breaks the stream when the packets are muxed in avformat. This commit
> adds an option to remove the container and thus support the encoder.
>
>
Am Sa., 11. Apr. 2020 um 15:53 Uhr schrieb Jun Zhao :
>
> From: Jun Zhao
>
> add a new sidedata type for Dolby Vision.
>
> Signed-off-by: Jun Zhao
> ---
> libavcodec/avpacket.c | 1 +
> libavcodec/packet.h | 9 +
> 2 files changed, 10 insertions(+)
>
> diff --git
Am Sa., 11. Apr. 2020 um 16:08 Uhr schrieb Jun Zhao :
>
> From: vacinfang
>
> add dolby vision related header
Apart from the name of the header file:
Could you explain why it is needed?
Is the Dolby Vision metadata not a black box that libavformat
has to provide to interested decoders?
Carl
Am Sa., 11. Apr. 2020 um 16:24 Uhr schrieb myp...@gmail.com :
>
> On Mon, Mar 30, 2020 at 4:52 PM myp...@gmail.com wrote:
> >
> > On Mon, Mar 30, 2020 at 4:31 PM Jun Zhao wrote:
> > >
> > > From: qoroliang
> > >
> > > Fix an occasional crash for hevc decoder in ARM 64 platform, the
> >
Am Sa., 11. Apr. 2020 um 16:41 Uhr schrieb Andreas Rheinhardt
:
>
> This is required to use it as an AVCodec.supported_samplerates array.
> Adding the sentinel has been forgotten in 4679a474.
> Without it e.g. the FATE-test ffmpeg-filter_complex_audio fails with ASAN.
lgtm
Thank you, Carl Eugen
This is required to use it as an AVCodec.supported_samplerates array.
Adding the sentinel has been forgotten in 4679a474.
Without it e.g. the FATE-test ffmpeg-filter_complex_audio fails with ASAN.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ac3tab.c | 2 +-
libavcodec/ac3tab.h | 2 +-
2
On 11/04/2020 11:18, Michael Niedermayer wrote:
> On Sat, Apr 11, 2020 at 12:29:37AM -0300, James Almer wrote:
>> On 4/10/2020 11:49 PM, James Almer wrote:
>>> On 4/10/2020 9:00 PM, James Almer wrote:
On 4/10/2020 8:53 PM, Michael Niedermayer wrote:
> On Fri, Apr 10, 2020 at 05:44:25PM
On Mon, Mar 30, 2020 at 4:52 PM myp...@gmail.com wrote:
>
> On Mon, Mar 30, 2020 at 4:31 PM Jun Zhao wrote:
> >
> > From: qoroliang
> >
> > Fix an occasional crash for hevc decoder in ARM 64 platform, the
> typo: it's ARM 32 bits platform, not 64,
> fixed in local
> >
On 4/11/2020 11:04 AM, Anton Khirnov wrote:
> Quoting James Almer (2020-04-11 15:21:24)
>>
>> Not necessarily better, just in line with the decode API. It would be
>> nice to have all our decoupled input/output APIs behaving the same,
>> instead of each featuring one small difference here and
Hi,
On Fri, Apr 10, 2020 at 5:27 PM Nicolas George wrote:
>
> Hi.
>
> In the comments on a recent patch to implement statistics outputs for a
> specific filter, I noted that this is something that many filters need
> to do, and therefore in need of unification. I also observed some JSON
> code
I really do not think it is a good idea to have a header with the name dolby in
it.
On Sat, Apr 11, 2020, at 15:44, Jun Zhao wrote:
> From: vacinfang
>
> add dolby vision related header
>
> Signed-off-by: vacinfang
> ---
> libavutil/Makefile| 1 +
>
From: Jun Zhao
enable dvcC/dvvC box support from sidedata
Signed-off-by: Jun Zhao
---
libavformat/movenc.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 6db09b7..bdd4467 100644
--- a/libavformat/movenc.c
+++
From: vacinfang
add dolby vision related header
Signed-off-by: vacinfang
---
libavutil/Makefile| 1 +
libavutil/dolby_vision_meta.h | 58 +++
2 files changed, 59 insertions(+)
create mode 100644 libavutil/dolby_vision_meta.h
diff --git
Quoting James Almer (2020-04-11 15:21:24)
>
> Not necessarily better, just in line with the decode API. It would be
> nice to have all our decoupled input/output APIs behaving the same,
> instead of each featuring one small difference here and there.
We could also change the decode API to be in
On 4/10/20, Nicolas George wrote:
> Hi.
>
> In the comments on a recent patch to implement statistics outputs for a
> specific filter, I noted that this is something that many filters need
> to do, and therefore in need of unification. I also observed some JSON
> code in a filter, which does not
Fixes: Timeout
Fixes:
20791/clusterfuzz-testcase-minimized-ffmpeg_BSF_AV1_FRAME_SPLIT_fuzzer-5659537719951360
Fixes:
21214/clusterfuzz-testcase-minimized-ffmpeg_BSF_MPEG2_METADATA_fuzzer-5165560875974656
Fixes:
On 4/11/20, Nicolas George wrote:
> Paul B Mahol (12020-04-11):
>> I never found developer that have coverity in brain or run patches via
>> it.
>
> Exactly. And I hope you have the insight to count yourself in these
> numbers.
>
> This is exactly why we need reviews: individually, we are
Paul B Mahol (12020-04-11):
> I never found developer that have coverity in brain or run patches via it.
Exactly. And I hope you have the insight to count yourself in these
numbers.
This is exactly why we need reviews: individually, we are fallible,
collectively we are still fallible, but much
From: vacingfang
support DOVIVideo Stream Descriptor from Dolby Vision Streams
Within the MPEG-2 Transport Stream Format V1.2
From the spec: https://www.dolby.com/us/en/technologies/\
dolby-vision/dolby-vision-bitstreams-in-mpeg-2-transport-\
stream-multiplex-v1.2.pdf.
export the Dolby Vision
From: Jun Zhao
add a new sidedata type for Dolby Vision.
Signed-off-by: Jun Zhao
---
libavcodec/avpacket.c | 1 +
libavcodec/packet.h | 9 +
2 files changed, 10 insertions(+)
diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index ad020ee..276beeb 100644
---
On 4/11/20, Nicolas George wrote:
> Paul B Mahol (12020-04-11):
>> Or they want to force someone into specific nits.
>
> Respectfully, I think things would go a lot better around here if people
> were to assume good will instead of ill intent. We are all working for
> the good of FFmpeg, here, or
From: Jun Zhao
V2:
- used sidedata for Dolby Vision information (tks Jan Ekström's suggestion)
- enabled dumping Dolby Vision sidedata for ffmpeg/ffprobe tools
- enable dvcC/dvvC box from Dolby Vision sidedata
Jun Zhao (4):
lavc: add a new sidedata type for Dolby Vision
lavf/dump: dump
From: vacingfang
support dvcC/dvcC box from spec Dolby Vision Streams Within the
ISO Base MediaFile Format Version 2.1.2
(https://www.dolby.com/in/en/technologies/dolby-vision/dolby-vision\
-bitstreams-within-the-iso-base-media-file-format-v2.1.2.pdf)
export the Dolby Vision information to
From: Jun Zhao
support dolby vision sidedata.
Signed-off-by: Jun Zhao
---
fftools/ffprobe.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index e3f221f..108e837 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -36,6 +36,7 @@
From: Jun Zhao
dump dolby vison side data.
Signed-off-by: Jun Zhao
---
libavformat/dump.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/libavformat/dump.c b/libavformat/dump.c
index 220f404..be0028b 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -27,6
Paul B Mahol (12020-04-11):
> Or they want to force someone into specific nits.
Respectfully, I think things would go a lot better around here if people
were to assume good will instead of ill intent. We are all working for
the good of FFmpeg, here, or at least we are.
As for the merits of
On 4/11/2020 5:33 AM, Anton Khirnov wrote:
> Quoting James Almer (2020-04-10 17:42:23)
>> On 4/10/2020 11:07 AM, Derek Buitenhuis wrote:
>>> On 10/04/2020 00:09, James Almer wrote:
EAGAIN is returned when input is provided but can't be consumed. The
filtering
process is unaffected
On 4/11/20, Carl Eugen Hoyos wrote:
> Am So., 5. Apr. 2020 um 02:05 Uhr schrieb Carl Eugen Hoyos
> :
>>
>> Am So., 5. Apr. 2020 um 01:02 Uhr schrieb Carl Eugen Hoyos
>> :
>> >
>> > Am Sa., 4. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos
>> > :
>> > >
>> > > Am Sa., 4. Apr. 2020 um 00:40 Uhr
On Sat, Apr 11, 2020 at 12:26:42PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Sat, Apr 11, 2020 at 12:29:37AM -0300, James Almer wrote:
> >> On 4/10/2020 11:49 PM, James Almer wrote:
> >>> On 4/10/2020 9:00 PM, James Almer wrote:
> On 4/10/2020 8:53 PM, Michael Niedermayer
Am Mi., 30. Jan. 2019 um 21:08 Uhr schrieb Carl Eugen Hoyos
:
>
> 2019-01-30 20:33 GMT+01:00, Paul B Mahol :
> > On 1/30/19, Carl Eugen Hoyos wrote:
> >> 2019-01-29 22:47 GMT+01:00, Carl Eugen Hoyos :
>
> >>> Attached patch fixes decoding NO_DATA amr-wb frames.
> >>
> >> Now with patch.
>
> > Are
Am Di., 7. Apr. 2020 um 16:05 Uhr schrieb Anton Khirnov :
>
> Quoting Carl Eugen Hoyos (2020-04-06 15:32:43)
> > Am Mo., 6. Apr. 2020 um 10:42 Uhr schrieb Anton Khirnov :
> > >
> > > Quoting Carl Eugen Hoyos (2020-04-05 17:37:15)
> > > > Am So., 5. Apr. 2020 um 02:01 Uhr schrieb Carl Eugen Hoyos
Am Mo., 6. Apr. 2020 um 07:29 Uhr schrieb Rosen Penev :
>
> Place HAVE_MIPSFPU further up so that functions that use floating point
> ASM are defined away. Otherwise compilation failures result when soft
> float in enabled on the toolchain.
Patch applied.
Thank you, Carl Eugen
Am So., 5. Apr. 2020 um 02:05 Uhr schrieb Carl Eugen Hoyos :
>
> Am So., 5. Apr. 2020 um 01:02 Uhr schrieb Carl Eugen Hoyos
> :
> >
> > Am Sa., 4. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos
> > :
> > >
> > > Am Sa., 4. Apr. 2020 um 00:40 Uhr schrieb James Almer :
> > > >
> > > > On 4/3/2020
On 4/11/20, Anton Khirnov wrote:
> Quoting Paul B Mahol (2020-04-11 11:29:40)
>> On 4/11/20, Anton Khirnov wrote:
>> > 100%? Meaning you think no patches should go to the mailing list?
>> >
>> > Or only some specific patches are exempt? Based on what criterion? And
>> > who applies it?
>> > And
Quoting Paul B Mahol (2020-04-11 11:29:40)
> On 4/11/20, Anton Khirnov wrote:
> > 100%? Meaning you think no patches should go to the mailing list?
> >
> > Or only some specific patches are exempt? Based on what criterion? And
> > who applies it?
> > And most importantly, why?
>
> Only trivial
Quoting Carl Eugen Hoyos (2020-04-11 11:56:40)
>
> > > Furthermore, I would strongly suggest you stop making such
> > > comments that are not helpful.
> >
> > What about my comment is "not helpful"?
> > And how is you expressing your personal opinion different
> > from me doing the same?
>
>
Thanks!
Strange, bash history says:
git format-patch --to=ffmpeg-devel@ffmpeg.org HEAD~..HEAD
git send-email *.patch
But i do have this gitconfig:
[diff]
noprefix = true
Seems format-patch uses it That was unexpected, removing that config.
-Mattias
On Sat, Apr 11, 2020 at 12:59 PM Carl Eugen
Am Sa., 11. Apr. 2020 um 11:53 Uhr schrieb Mattias Wadman
:
>
> Regression since 8d3630c5402fdda2889fe4f74f7dcdd50ebca654 where keys were
> changed
> to not be touppered but the picture block strcmp was not changed to be
> case-insensitive.
> ---
> libavformat/oggparsevorbis.c | 2 +-
> 1 file
On 4/11/20, Anton Khirnov wrote:
> Quoting Paul B Mahol (2020-04-11 10:59:34)
>> On 4/11/20, Anton Khirnov wrote:
>> > Quoting Carl Eugen Hoyos (2020-04-09 18:13:53)
>> >> Am Do., 9. Apr. 2020 um 14:39 Uhr schrieb Andreas Rheinhardt
>> >> :
>> >> >
>> >> > Signed-off-by: Andreas Rheinhardt
>>
Michael Niedermayer:
> On Sat, Apr 11, 2020 at 12:29:37AM -0300, James Almer wrote:
>> On 4/10/2020 11:49 PM, James Almer wrote:
>>> On 4/10/2020 9:00 PM, James Almer wrote:
On 4/10/2020 8:53 PM, Michael Niedermayer wrote:
> On Fri, Apr 10, 2020 at 05:44:25PM -0300, James Almer wrote:
On Sat, Apr 11, 2020 at 12:29:37AM -0300, James Almer wrote:
> On 4/10/2020 11:49 PM, James Almer wrote:
> > On 4/10/2020 9:00 PM, James Almer wrote:
> >> On 4/10/2020 8:53 PM, Michael Niedermayer wrote:
> >>> On Fri, Apr 10, 2020 at 05:44:25PM -0300, James Almer wrote:
> On 4/10/2020 5:23
Separate the initialization procedure into different functions.
Make it more readable and easier to be extended.
Signed-off-by: Linjie Fu
---
libavcodec/libopenh264enc.c | 283 +++-
1 file changed, 174 insertions(+), 109 deletions(-)
diff --git
1 - 100 of 143 matches
Mail list logo
