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. But since then the next two
> bytes are read as if
This commit changes how levels are handled: If the level used for
ebml_parse ends directly after an element that has been consumed, then
ebml_parse ends the level itself (and any known-length levels that end
there as well) and informs the caller via the return value; if the
current level is of
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/EOF was done just once, after reading the
first byte of the
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 been refined: First one byte
less than intended is
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 they simply returned AVERROR(EIO).
3. In particular,
Fixes: Infinite loop
Fixes:
15337/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QDM2_fuzzer-5757428949319680
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/qdm2.c | 4 ++--
1 file
Fixes: signed integer overflow: 2147483646 + 2 cannot be represented in type
'int'
Fixes: infinite loop
Fixes:
15396/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QDM2_fuzzer-5116605501014016
Found-by: continuous fuzzing process
Instead we ask for a sample, its unclear what to do in this case.
Fixes: index 30 out of bounds for type 'int8_t [30][64]'
Fixes:
15339/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QDM2_fuzzer-5749441484554240
Found-by: continuous fuzzing process
Am Mi., 19. Juni 2019 um 20:54 Uhr schrieb Michael Niedermayer
:
>
> On Wed, Jun 19, 2019 at 01:43:28PM +0200, Carl Eugen Hoyos wrote:
> > Hi!
> >
> > Attached patch fixes ticket #7962 for me, please comment.
> >
> > Thank you, Carl Eugen
>
> > tableprint_vlc.h |1 +
> > 1 file changed, 1
+1 vote Ada
2019.06.23. 13:02 keltezéssel, Reto Kromer írta:
FFMPEG 4.2 PANDORA?
FFmpeg 4.2 CARLS CANS
Ada
(She deserves much better than that horrible programming language!)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
James Almer:
> 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
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
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_uint, ebml_read_sint and ebml_read_float.
>>> 2.
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_uint, ebml_read_sint and ebml_read_float.
>> 2. ebml_read_ascii and ebml_read_binary did sometimes not forward
>>
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
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
>>> recently. But given that our
>> FFMPEG 4.2 PANDORA?
>
> FFmpeg 4.2 CARLS CANS
Ada
(She deserves much better than that horrible programming language!)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit
On 6/23/19, Radsl wrote:
>
>> On 21-05-2019 12:09 AM, Michael Niedermayer wrote:
>>> Hi
>>>
>>> Its quite some time since 4.1 so its probably getting time to branch
>>> 4.2.
>>>
>>> If there are any bugs you want fixed in 4.2 its probably a good idea to
>>> fix them soon.
>>>
>>> Are there any
On 21-05-2019 12:09 AM, Michael Niedermayer wrote:
Hi
Its quite some time since 4.1 so its probably getting time to branch
4.2.
If there are any bugs you want fixed in 4.2 its probably a good idea to
fix them soon.
Are there any suggestions for a name ?
If not ill pick something from unused
On Thu, 13 Jun 2019, Andreas Håkon wrote:
Hi Andriy,
I'm glad you're interested in this patch.
> This patch implements a new optional "parallel muxing mode" in the MPEGTS
muxer.
> The strategy that implements the current mux (selected by default) is based on
> writing full PES packages
On Sun, Jun 23, 2019 at 06:33:02PM +1000, Peter Ross wrote:
> On Sun, Jun 23, 2019 at 12:30:54AM +0200, Michael Niedermayer wrote:
> > This checks the ham value much stricter and avoids hitting cases which
> > cannot be reached
> > with data from the libavformat demuxer.
> >
> > Fixes: out of
On Sun, Jun 23, 2019 at 12:30:54AM +0200, Michael Niedermayer wrote:
> This checks the ham value much stricter and avoids hitting cases which cannot
> be reached
> with data from the libavformat demuxer.
>
> Fixes: out of array access
> Fixes:
>
On Tue, 4 Jun 2019, Andreas Håkon wrote:
Hi,
Before coding of a new patch, I prefer to ask here for your ideas and thus
improve the changes
of acceptance of the patch.
I posted before a patch to select which pid will carry the PCR timestamps. This
makes sense in
several scenarios: when
23 matches
Mail list logo
