_INVALID_BITSTREAM,
FF_DECODE_ERROR_MISSING_REFERENCE, or both, since as you mentioned they
describe the errors that could take place in
ff_h264_execute_decode_slices() just fine.
>
> Thanks
>
>
> On Sun, Jun 9, 2019 at 10:15 PM James Almer wrote:
>
>> On 6/10/2019 12
On 6/14/2019 11:52 AM, Reimar Döffinger wrote:
>
>
> On 14.06.2019, at 03:15, Chris Cunningham wrote:
>
>> Only "succeed" to read a header if the codec is valid. Otherwise
>> return AVERROR_INVALIDDATA.
>
> That doesn't sound right to me, an unknown codec in (possibly) a single
> stream is no
On 6/15/2019 7:00 PM, Michael Niedermayer wrote:
> Fixes: Direct leak of 536 byte(s) in 1 object(s)
> Fixes:
> 15266/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_BINK_fuzzer-5629530426834944
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/f
On 6/13/2019 3:32 PM, Michael Niedermayer wrote:
> Fixes: signed integer overflow: -2147483648 - 1 cannot be represented in type
> 'int'
> Fixes:
> 14880/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5130977304641536
>
> Found-by: continuous fuzzing process
> https://github.com/
On 6/17/2019 12:42 AM, Andreas Rheinhardt wrote:
> Up until now, ff_cbs_write_packet always initialized the packet
> structure it received without documenting this behaviour; furthermore,
> the packet's buffer would (on success) be overwritten with the new
> buffer without unreferencing the old. Th
On 6/17/2019 9:44 AM, James Almer wrote:
> On 6/17/2019 12:42 AM, Andreas Rheinhardt wrote:
>> Up until now, ff_cbs_write_packet always initialized the packet
>> structure it received without documenting this behaviour; furthermore,
>> the packet's buffer would (on succes
On 6/17/2019 12:42 AM, Andreas Rheinhardt wrote:
> ff_cbs_delete_unit never fails if the index of the unit to delete is
> valid; document this behaviour explicitly and remove the checks for
> whether ff_cbs_delete_unit failed, because all the callers of
> ff_cbs_delete_unit already make sure that t
On 6/17/2019 12:42 AM, Andreas Rheinhardt wrote:
> Deleting a unit from a fragment in CBS only fails if there is no unit
> in the fragment corresponding to the position given as argument to
> ff_cbs_delete_unit. Given that ff_cbs_h264_delete_sei_message asserts
> this to be so, we know that the cal
On 6/17/2019 11:34 AM, Andreas Rheinhardt wrote:
> James Almer:
>> On 6/17/2019 9:44 AM, James Almer wrote:
>>> On 6/17/2019 12:42 AM, Andreas Rheinhardt wrote:
>>>> Up until now, ff_cbs_write_packet always initialized the packet
>>>> structure it r
On 6/17/2019 6:54 PM, Michael Niedermayer wrote:
> On Sun, Jun 16, 2019 at 11:10:43PM -0300, James Almer wrote:
>> On 6/13/2019 3:32 PM, Michael Niedermayer wrote:
>>> Fixes: signed integer overflow: -2147483648 - 1 cannot be represented in
>>> type 'int&#x
On 6/19/2019 6:22 AM, Michael Niedermayer wrote:
> On Mon, Jun 17, 2019 at 07:55:45PM -0300, James Almer wrote:
>> On 6/17/2019 6:54 PM, Michael Niedermayer wrote:
>>> On Sun, Jun 16, 2019 at 11:10:43PM -0300, James Almer wrote:
>>>> On 6/13/2019 3:32 PM, Michael
On 6/19/2019 3:13 PM, Michael Niedermayer wrote:
> On Wed, Jun 19, 2019 at 12:54:25PM -0300, James Almer wrote:
>> On 6/19/2019 6:22 AM, Michael Niedermayer wrote:
>>> On Mon, Jun 17, 2019 at 07:55:45PM -0300, James Almer wrote:
>>>> On 6/17/2019 6:54 PM, Michael N
On 6/19/2019 3:19 PM, Bodecs Bela wrote:
>
> 2019.06.19. 19:37 keltezéssel, Michael Niedermayer írta:
>> On Wed, Jun 19, 2019 at 10:03:51AM +, Bodecs Bela wrote:
>>> ffmpeg | branch: master | Bodecs Bela | Mon Jun
>>> 17 23:05:21 2019 +0200| [09a4853930e7950f423e9161004871afe659ed84] |
>>> co
On 6/19/2019 11:11 PM, Chris Cunningham wrote:
> On Wed, Jun 19, 2019 at 11:25 AM Michael Niedermayer
> wrote:
>
> breaks:
> ./ffmpeg -i bgc.sub.dub.ogm -vframes 3 -y test.webm
> sample: http://samples.mplayerhq.hu/ogg/bgc.sub.dub.ogm
>
> [...]
>
> --
> Michael GnuP
On 6/19/2019 3:59 PM, James Almer wrote:
> On 6/19/2019 3:13 PM, Michael Niedermayer wrote:
>> On Wed, Jun 19, 2019 at 12:54:25PM -0300, James Almer wrote:
>>> On 6/19/2019 6:22 AM, Michael Niedermayer wrote:
>>>> On Mon, Jun 17, 2019 at 07:55:45PM -0300, James Almer
On 6/2/2019 1:48 PM, Mark Thompson wrote:
> On 06/05/2019 22:02, Mark Thompson wrote:
>> The maxDpbPicBuf value which is used in the DPB size calculation depends
>> on the profile (it's usually 6, but 7 for screen-extended profiles).
>> ---
>> libavcodec/h265_profile_level.c | 86 -
The spec states they can't be higher than the respective dimensions of the
stream in CTBs.
Signed-off-by: James Almer
---
I don't think it's wise further limiting the range to the maximum currently
defined for level 6.2 using those two HEVC_ defines, since a stream could in
theory
The spec states they are in units of CTBs.
Signed-off-by: James Almer
---
libavcodec/cbs_h265_syntax_template.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/cbs_h265_syntax_template.c
b/libavcodec/cbs_h265_syntax_template.c
index d2a20ddb35..571c9d3544
On 6/19/2019 4:08 PM, Michael Niedermayer wrote:
> On Wed, Jun 19, 2019 at 04:39:47AM +0200, Andreas Rheinhardt wrote:
>> This commit uses smaller types for some static const arrays to reduce
>> their size in case the entries can be represented in the smaller type.
>> The biggest savings came from
As defined in section F.14.2.8 and F.14.3.8
Signed-off-by: James Almer
---
https://trac.ffmpeg.org/attachment/ticket/7965/puppets_with_alpha_hevc.mov
libavcodec/cbs_h2645.c| 1 +
libavcodec/cbs_h265.h | 12 +
libavcodec/cbs_h265_syntax_template.c | 37
On 6/21/2019 1:24 AM, Gyan wrote:
>
>
> On 20-06-2019 11:15 PM, James Almer wrote:
>> The spec states they can't be higher than the respective dimensions of
>> the
>> stream in CTBs.
>>
>> Signed-off-by: James Almer
>> ---
>> I don
On 6/21/2019 10:36 AM, Derek Buitenhuis wrote:
> This packet was not necessarily unreferenced.
>
> Signed-off-by: Derek Buitenhuis
> ---
> fftools/ffprobe.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
> index 3becb6330
On 6/21/2019 11:13 AM, Derek Buitenhuis wrote:
> On 21/06/2019 14:46, James Almer wrote:
>> Why not just call this unconditionally instead of the init() + zero below?
>
> I wasn't sure from a quick skim if these packets were
> referenced elsewhere (and thus unref
On 6/21/2019 11:15 AM, Derek Buitenhuis wrote:
> This packet was not necessarily unreferenced.
>
> Signed-off-by: Derek Buitenhuis
> ---
> fftools/ffprobe.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
> index 3becb6330e..dac70ba5a1 100644
> -
On 6/21/2019 11:39 AM, Derek Buitenhuis wrote:
> On 21/06/2019 15:26, James Almer wrote:
>> Remove the three lines below as well before pushing. They are
>> superfluous as av_packet_unref() does the same internally.
>
> OK.
>
> The documentation for av_packet_unref
On 6/21/2019 11:41 AM, Derek Buitenhuis wrote:
> This packet was not necessarily unreferenced.
>
> Signed-off-by: Derek Buitenhuis
> ---
> fftools/ffprobe.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
> index 3becb6330e..5aad
ionality. I'd rather not change h2645_parse for this and risk
unpredictable behavior from the decoder.
>
> James Almer:
>> As defined in section F.14.2.8 and F.14.3.8
>>
>> Signed-off-by: James Almer
>> ---
>> https://trac.ffmpeg.org/attachme
On 5/16/2019 7:29 PM, Andreas Rheinhardt wrote:
> This commit replaces copying attached pictures by using references to
> the already existing buffers.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/matroskadec.c | 16 ++--
> 1 file changed, 10 insertions(+), 6 deletions(-
On 5/16/2019 7:29 PM, Andreas Rheinhardt wrote:
> and drop the redundant checks contained in ebml_read_uint and
> ebml_read_sint.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/matroskadec.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/libavformat/ma
On 5/16/2019 7:29 PM, Andreas Rheinhardt wrote:
> When the new incremental parser was introduced, the old parser was
> kept, because the new parser was unable to handle the way SSA packets
> are put into Matroska. But since 2014 (since c7d8dbad) this is no
> longer needed, so that the old parser ca
On 5/16/2019 7:29 PM, Andreas Rheinhardt wrote:
> By default, the data_offset member of the AVFormatInternal of the
> AVFormatContext associated with the MatroskaDemuxContext has not been
> initialized explicitly by any Matroska-specific function, so that it was
> initialized by default to the offs
On 5/16/2019 7:29 PM, Andreas Rheinhardt wrote:
> The earlier code relied on the length of clusters always being coded on
> eight bytes as was the behaviour of libavformat's Matroska muxer until
> recently. But given that our own Matroska muxer now (and mkvmerge from
> time immemorial) creates file
On 5/16/2019 7:29 PM, Andreas Rheinhardt wrote:
> Before this commit, the Matroska muxer would read a block when required
> to do so, parse the block, create and return the necessary AVPackets and
> yet keep the blocks (in a dynamically allocated list), although they
> aren't used at all any more.
On 5/16/2019 7:29 PM, Andreas Rheinhardt wrote:
> Every new element of an EbmlList is zeroed initially in
> ebml_parse_elem, so that in particular a SimpleBlock's duration is
> initialized to zero. Therefore it is unnecessary to initialize this
> field again (for SimpleBlocks) in matroska_parse_clu
On 6/23/2019 1:28 AM, Andreas Rheinhardt wrote:
> James Almer:
>> On 5/16/2019 7:29 PM, Andreas Rheinhardt wrote:
>>> The earlier code relied on the length of clusters always being coded on
>>> eight bytes as was the behaviour of libavformat's Matroska muxer until
On 5/16/2019 7:29 PM, Andreas Rheinhardt wrote:
> This commit fixes a number of bugs:
>
> 1. There was no check that no read error/EOF occured during
> ebml_read_uint, ebml_read_sint and ebml_read_float.
> 2. ebml_read_ascii and ebml_read_binary did sometimes not forward
> error codes; instead the
On 6/23/2019 1:01 PM, Andreas Rheinhardt wrote:
> James Almer:
>> On 5/16/2019 7:29 PM, Andreas Rheinhardt wrote:
>>> This commit fixes a number of bugs:
>>>
>>> 1. There was no check that no read error/EOF occured during
>>> ebml_read_ui
On 5/16/2019 7:29 PM, Andreas Rheinhardt wrote:
> ebml_read_num had a number of flaws:
>
> 1. The check for read errors/EOF was totally wrong. E.g. an EBML number
> beginning with the invalid 0x00 would be considered a read error,
> although it is just invalid data.
> 2. The check for read errors/
On 5/16/2019 7:29 PM, Andreas Rheinhardt wrote:
> It is only necessary to zero the initial allocated memory used to store
> the size of laced frames if the block used Xiph lacing. Otherwise no
> unintialized data was ever used, so use av_malloc instead of av_mallocz.
>
> Also use the correct type
On 6/23/2019 8:42 PM, Andreas Rheinhardt wrote:
> ebml_read_num had a number of flaws:
>
> 1. The check for read errors/EOF was totally wrong. E.g. an EBML number
> beginning with the invalid 0x00 would be considered a read error,
> although it is just invalid data.
> 2. The check for read errors/
On 6/24/2019 10:08 PM, Andreas Rheinhardt wrote:
> ebml_read_num had a number of flaws:
>
> 1. The check for read errors/EOF was totally wrong. E.g. an EBML number
> beginning with the invalid 0x00 would be considered a read error,
> although it is just invalid data.
> 2. The check for read errors
On 6/23/2019 8:42 PM, Andreas Rheinhardt wrote:
> Up until now, when an element was skipped, it was relied upon
> ffio_limit to make sure that there is enough data available to skip.
> ffio_limit itself relies upon the availability of the file's size. As
> this needn't be available, the check has b
On 5/16/2019 7:30 PM, Andreas Rheinhardt wrote:
> Up until now, the SimpleBlock was treated specially: It basically had
> its own EBML category and it was also included in the BlockGroup EBML
> syntax (although a SimpleBlock must not exist in a BlockGroup according
> to the Matroska specifications)
On 6/23/2019 8:42 PM, Andreas Rheinhardt wrote:
> This commit fixes a number of bugs:
>
> 1. There was no check that no read error/EOF occured during
> ebml_read_uint, ebml_read_sint and ebml_read_float.
> 2. ebml_read_ascii and ebml_read_binary did sometimes not forward
> error codes; instead the
On 6/23/2019 10:26 PM, Philip Langdale wrote:
> On Sun, 23 Jun 2019 06:46:12 +0200
> Andreas Rheinhardt wrote:
>
>> The mov flavour of timed text uses the first two bytes of the packet
>> as a length field. And up until 11bef2fe said length field has been
>> read correctly in the mov2textsub bsf.
On 6/25/2019 5:55 AM, Michael Niedermayer wrote:
> Fixes: signed integer overflow: -2147483648 - 1 cannot be represented in type
> 'int'
> Fixes:
> 14880/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5130977304641536
>
> Found-by: continuous fuzzing process
> https://github.com/
On 6/25/2019 10:30 AM, James Almer wrote:
> On 6/25/2019 5:55 AM, Michael Niedermayer wrote:
>> +num_tile_columns_minus1 >= sps->width - 1) {
>
> Should be sps->ctb_width
>
> From 7.4.3.3.1:
>
> "num_tile_columns_minus1 plus 1 specifies the
On 6/25/2019 5:55 AM, Michael Niedermayer wrote:
> Suggested-by: James Almer
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/hevc_ps.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc
On 6/25/2019 1:44 PM, Chris Cunningham wrote:
> Friendly ping.
>
> On Thu, Jun 20, 2019 at 11:17 AM Chris Cunningham
> wrote:
>
>> On Thu, Feb 28, 2019 at 9:13 AM James Almer wrote:
>>
>>> On 2/26/2019 10:18 PM, Chris Cunningham wrote:
>>>>
On 6/26/2019 9:41 AM, Michael Niedermayer wrote:
> On Tue, Jun 25, 2019 at 10:30:45AM -0300, James Almer wrote:
>> On 6/25/2019 5:55 AM, Michael Niedermayer wrote:
>>> Fixes: signed integer overflow: -2147483648 - 1 cannot be represented in
>>> type 'int&#x
On 6/26/2019 3:00 AM, Li, Zhong wrote:
>
>
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Li, Zhong
>> Sent: Tuesday, April 16, 2019 10:32 AM
>> To: FFmpeg development discussions and patches
>>
>> Subject: Re: [FFmpeg-devel] [PATCH v
On 6/27/2019 3:01 AM, Adrian Tong wrote:
> Anyone interested in reviewing this patch ?
>
> Thanks
> -Adrian
>
> On Mon, 24 Jun 2019 at 13:57, wrote:
>
>> From: Adrian Tong
>>
>> On internal benchmark, I see a noisy-level difference (more likely to be
>> an improvement) in ff_h264_decode_mb_cab
On 6/27/2019 10:44 AM, Nicolas George wrote:
> Kieran Kunhya (12019-06-27):
>> I'm happy to do it now that I am aware of the issue. I will do it when I am
>> at home in a few days.
>
> Thanks. I am sure Steven will not mind waiting a few days.
>
>> This absolutism is absurd.
>
> Do you have an e
On 6/27/2019 11:26 PM, Linjie Fu wrote:
> Previously, media driver provided planar format(like 420 8 bit), but
> for HEVC Range Extension (422/444 8/10 bit), the decoded image is
> produced in packed format.
>
> Y210/AYUV/Y410 are packed formats which are needed in HEVC Rext decoding
> for both VA
On 6/27/2019 2:47 PM, Andreas Rheinhardt wrote:
> This commit fixes mixed declarations and code introduced in 1889e316.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> Sorry for the oversight.
>
> libavformat/mux.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/lib
On 6/27/2019 9:59 AM, Zhong Li wrote:
> Signed-off-by: Zhong Li
> ---
> libavcodec/mjpeg_parser.c | 158
> +-
> 1 file changed, 157 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/mjpeg_parser.c b/libavcodec/mjpeg_parser.c
> index 07a6b2b..f5
From 7.4.3.3.1:
num_tile_columns_minus1 shall be in the range of 0 to PicWidthInCtbsY - 1,
inclusive.
num_tile_rows_minus1 shall be in the range of 0 to PicHeightInCtbsY - 1,
inclusive.
Signed-off-by: James Almer
---
Sorry for not noticing it when reviewing c692051252 and 3b2082c663
On 6/30/2019 7:01 PM, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes ticket #7979 for me, please comment.
>
> Thank you, Carl Eugen
>
>
> 0001-lavf-rawenc-Do-not-allow-encoding-0-audio-channels.patch
>
> From 976b294c10be32667852729c3652dbec466ac091 Mon Sep 17 00:00:00 2001
> From: Car
On 6/30/2019 7:16 PM, Michael Niedermayer wrote:
> Fixes:
> 15295/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5675655187922944
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
>
On 6/30/2019 10:43 PM, James Almer wrote:
> On 6/30/2019 7:16 PM, Michael Niedermayer wrote:
>> Fixes:
>> 15295/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5675655187922944
>>
>> Found-by: continuous fuzzing process
>> https://github.com/goo
On 7/1/2019 11:24 AM, Michael Niedermayer wrote:
> On Sun, Jun 30, 2019 at 11:18:55PM -0300, James Almer wrote:
>> On 6/30/2019 10:43 PM, James Almer wrote:
>>> On 6/30/2019 7:16 PM, Michael Niedermayer wrote:
>>>> Fixes:
>>>> 15295/clusterfuzz-testcas
On 7/2/2019 5:56 PM, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> doc/APIchanges | 3 +++
> libavutil/mem.h | 13 +
> libavutil/version.h | 2 +-
> 3 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
On 7/4/2019 10:43 AM, Matthieu Bouron wrote:
> ---
> libavcodec/mediacodec_wrapper.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/mediacodec_wrapper.h b/libavcodec/mediacodec_wrapper.h
> index f0de16d669..58e5dc7d39 100644
> --- a/libavcodec/mediacodec_wrapper.h
> +++ b/l
On 6/30/2019 5:45 PM, James Almer wrote:
> From 7.4.3.3.1:
>
> num_tile_columns_minus1 shall be in the range of 0 to PicWidthInCtbsY - 1,
> inclusive.
> num_tile_rows_minus1 shall be in the range of 0 to PicHeightInCtbsY - 1,
> inclusive.
>
> Signed-off-by: James Alme
On 7/5/2019 11:13 AM, Michael Niedermayer wrote:
> On Sun, Jun 30, 2019 at 05:45:58PM -0300, James Almer wrote:
>> From 7.4.3.3.1:
>>
>> num_tile_columns_minus1 shall be in the range of 0 to PicWidthInCtbsY - 1,
>> inclusive.
>> num_tile_rows_minus1 shall be in t
On 7/6/2019 1:59 PM, Andreas Rheinhardt wrote:
> This commit fixes an overflow introduced in a569a7b3 that affected EBML
> elements that the Matroska demuxer doesn't want to parse like CRC-32
> elements. The return value of avio_skip (the new position on success or
> an AVERROR on failure) has been
On 6/19/2019 8:45 PM, Andreas Rheinhardt wrote:
> This commit adds an option to not only update the bitstream parameters
> when using the vp9_metadata bitstream filter, but also the relevant
> AVCodecParameters. The new option is on by default.
>
> This commit also adds documentation for this valu
On 7/9/2019 3:34 PM, Derek Buitenhuis wrote:
> Port to the new send/receive API by: James Almer .
>
> Signed-off-by: Derek Buitenhuis
> ---
> Lots of stuff happened since v3!
>
> * The C API / library is now in rav1e's main repo, and officially supported.
> * rav1e
As defined in sections F.14.2.8 and F.14.3.8
Signed-off-by: James Almer
---
libavcodec/cbs_h2645.c| 1 +
libavcodec/cbs_h265.h | 12 +++
libavcodec/cbs_h265_syntax_template.c | 29 +++
libavcodec/hevc_sei.h | 1
On 7/10/2019 9:22 AM, Derek Buitenhuis wrote:
> On 09/07/2019 22:06, James Almer wrote:
>>> @@ -3174,6 +3176,7 @@ libopenmpt_demuxer_deps="libopenmpt"
>>> libopus_decoder_deps="libopus"
>>> libopus_encoder_deps="libopus"
>>>
On 7/11/2019 9:29 AM, Michael Niedermayer wrote:
> Fixes: memleak
> Fixes:
> 15535/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SMACKER_fuzzer-5692162424963072
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael
On 7/11/2019 6:49 PM, Michael Niedermayer wrote:
> Fixes: left shift of negative value -456
> Fixes:
> 15561/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPC8_fuzzer-5758130404720640
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>
On 7/11/2019 6:49 PM, Michael Niedermayer wrote:
> Fixes: signed integer overflow: -2147483648 - 1 cannot be represented in type
> 'int'
> Fixes:
> 15568/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-5634719611355136
>
> Found-by: continuous fuzzing process
> https://github.com
On 7/13/2019 1:48 PM, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/avformat.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 734ae54cac..6eb329f13f 100644
> --- a/libavforma
On 7/9/2019 3:34 PM, Derek Buitenhuis wrote:
> Port to the new send/receive API by: James Almer .
>
> Signed-off-by: Derek Buitenhuis
> ---
> Lots of stuff happened since v3!
>
> * The C API / library is now in rav1e's main repo, and officially supported.
> * rav1e
Signed-off-by: James Almer
---
See
https://git.videolan.org/?p=vlc.git;a=commitdiff;h=d86c4c87aa78130a4fd00294e25df865d0e2b327
libavcodec/avcodec.h | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 2528bd89ab
On 7/15/2019 11:23 AM, Derek Buitenhuis wrote:
> On 13/07/2019 19:37, James Almer wrote:
>> Just use av_reallocp(). Each call will make the buffer bigger, so you're
>> not really making use the no-op benefits from av_fast_realloc(), which
>> only trigger if newsize <=
On 7/15/2019 6:20 PM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> configure | 1 +
> libavcodec/Makefile | 1 +
> libavcodec/allcodecs.c | 1 +
> libavcodec/avcodec.h| 1 +
> libavcodec/codec_desc.c | 7 ++
> libavcodec/imm5.c | 234 +++
On 7/16/2019 9:19 AM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> configure | 1 +
> libavcodec/Makefile | 1 +
> libavcodec/allcodecs.c | 1 +
> libavcodec/avcodec.h| 1 +
> libavcodec/codec_desc.c | 7 ++
> libavcodec/imm5.c | 171 +++
On 7/16/2019 10:42 AM, Paul B Mahol wrote:
> On 7/16/19, James Almer wrote:
>> On 7/16/2019 9:19 AM, Paul B Mahol wrote:
>>> +ret = avcodec_receive_frame(codec_avctx, frame);
>>> +if (ret < 0)
>>> +return ret;
>>
>> avcodec_re
It hasn't been experimental for a long time.
Closes ticket #7961
Signed-off-by: James Almer
---
libavformat/movenc.c | 9 +-
libavformat/movenc.h | 1 -
tests/fate/mov.mak| 2 +-
tests/fate/vcode
On 7/16/2019 12:41 PM, Dave Rice wrote:
> Hi James,
>
>> On Jul 16, 2019, at 9:47 AM, James Almer wrote:
>>
>> -{ "write_colr", "Write colr atom (Experimental, may be renamed or
>> changed, do not use from scripts)", 0, AV_OPT_TYPE_C
It hasn't been experimental for a long time.
Closes ticket #7961
Signed-off-by: James Almer
---
Decided to deprecate the flag and making it a no-op instead of changing its
behavior to be enabled by default. Otherwise doing something like "-movflags
faststart" instead of "
On 7/15/2019 11:39 AM, James Almer wrote:
> Signed-off-by: James Almer
> ---
> See
> https://git.videolan.org/?p=vlc.git;a=commitdiff;h=d86c4c87aa78130a4fd00294e25df865d0e2b327
>
> libavcodec/avcodec.h | 12
> 1 file changed, 8 insertions(+), 4 deletions
On 7/17/2019 4:47 PM, Paul B Mahol wrote:
> LGTM
>
> On 7/15/19, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> See
>> https://git.videolan.org/?p=vlc.git;a=commitdiff;h=d86c4c87aa78130a4fd00294e25df865d0e2b327
>>
>> libavcodec/avco
The API does not allow it.
Also set poutbuf and poutbuf_size to NULL/0 on error to avoid leaving
them uninitialized.
Signed-off-by: James Almer
---
libavcodec/tak_parser.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/libavcodec/tak_parser.c b/libavcodec
The API does not allow it.
Also set poutbuf and poutbuf_size to NULL/0 on error to avoid leaving
them uninitialized.
Signed-off-by: James Almer
---
libavcodec/tak_parser.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/libavcodec/tak_parser.c b
Should fix ticket #6634
Signed-off-by: James Almer
---
libavformat/aacdec.c | 44 +---
1 file changed, 29 insertions(+), 15 deletions(-)
diff --git a/libavformat/aacdec.c b/libavformat/aacdec.c
index 8a5450880b..5b00b3f664 100644
--- a/libavformat
On 7/20/2019 10:54 AM, Mark Thompson wrote:
> On 09/07/2019 22:27, James Almer wrote:
>> As defined in sections F.14.2.8 and F.14.3.8
>>
>> Signed-off-by: James Almer
>> ---
>> libavcodec/cbs_h2645.c| 1 +
>> libavcodec/cbs_h265.h
On 7/20/2019 12:33 PM, Carl Eugen Hoyos wrote:
>
>
>
>> Am 20.07.2019 um 15:13 schrieb James Almer :
>>
>> Should fix ticket #6634
>>
>> Signed-off-by: James Almer
>> ---
>> libavformat/aacdec.c | 44 +--
On 7/20/2019 1:29 PM, Michael Niedermayer wrote:
> On Thu, Jul 18, 2019 at 07:37:57PM -0300, James Almer wrote:
>> The API does not allow it.
>>
>> Also set poutbuf and poutbuf_size to NULL/0 on error to avoid leaving
>> them uninitialized.
>>
>> Signed-off
On 7/20/2019 12:41 PM, James Almer wrote:
> On 7/20/2019 12:33 PM, Carl Eugen Hoyos wrote:
>>
>>
>>
>>> Am 20.07.2019 um 15:13 schrieb James Almer :
>>>
>>> Should fix ticket #6634
>>>
>>>
On 7/23/2019 9:39 PM, Kieran Kunhya wrote:
>>
>> What was the cause of the slow decoding? Does this actually fix it, or
>> does it just swipe it "under the carpet"?
>> If someone ever found a sample with a different solution, how would they
>> know that they shouldn't just remove this again? Withou
On 7/24/2019 6:37 AM, Paul B Mahol wrote:
> Hi,
>
> patch attached.
> From dc6473383580af963a120a7de89bdc34c460d000 Mon Sep 17 00:00:00 2001
> From: Paul B Mahol
> Date: Wed, 24 Jul 2019 11:11:35 +0200
> Subject: [PATCH] avcodec/adxenc: add EOF header
>
> Fixes #8031.
>
> ---
> libavcodec/adx
Prevents muxing ultimately broken and spec non-compliant files.
Signed-off-by: James Almer
---
libavformat/movenc.c | 37 ++---
1 file changed, 22 insertions(+), 15 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index a96139077b
On 7/28/2019 8:56 AM, Michael Niedermayer wrote:
> On Sun, Jul 28, 2019 at 12:45:36AM +0200, Reimar Döffinger wrote:
>>
>>
>> On 28.07.2019, at 00:31, Michael Niedermayer wrote:
>>
>>> This merges several byte operations and avoids some shifts inside the loop
>>>
>>> Improves: Timeout (330sec -> 1
On 7/29/2019 11:44 AM, Linjie Fu wrote:
> Flush encoders when dimension change happens, reset draining to resume
> encode.
>
> If encoder doesn't support variable dimension, stop encoding and
> report errors.
>
> Signed-off-by: Linjie Fu
> ---
> fftools/ffmpeg.c| 13 +
> libavco
On 7/29/2019 11:19 PM, Juan De León wrote:
> On Mon, Jul 29, 2019 at 12:48 PM Mark Thompson wrote:
>
>> This doesn't belong in the commit message.
>>
>> What does belong here would be some commentary on why you want this
>> feature.
>>
> Here is the, somewhat outdated, design document, this shoul
On 7/30/2019 2:59 AM, Limin Wang wrote:
>> +if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER) {
>> +EB_BUFFERHEADERTYPE *header_ptr = NULL;
>> +
>> +svt_ret = EbH265EncStreamHeader(svt_enc->svt_handle, &header_ptr);
>> +if (svt_ret != EB_ErrorNone) {
>> +av_log
On 7/30/2019 6:33 AM, Carl Eugen Hoyos wrote:
> Am Di., 30. Juli 2019 um 11:25 Uhr schrieb Fu, Linjie :
>>
>>> -Original Message-
>>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>>> Of Carl Eugen Hoyos
>>> Sent: Tuesday, July 30, 2019 16:06
>>> To: FFmpeg developme
701 - 800 of 11335 matches
Mail list logo
