[FFmpeg-devel] [PATCH] avformat/mov: validate chunk_count vs stsc_data

Bad content may contain stsc boxes with a first_chunk index that exceeds stco.entries (chunk_count). This ammends the existing check to include cases where chunk_count == 0. It also patches up the case when stsc refers to unknown chunks, but stts has no samples (so we can simply ignore stsc). ---

[FFmpeg-devel] [PATCH] avformat/oggparseogm: sync avctx w/ codecpar

Codec information may change while reading ogg packets. Update the stream's internal avctx to match. --- libavformat/oggparseogm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavformat/oggparseogm.c b/libavformat/oggparseogm.c index a07453760b..b07a5d55ba 100644 ---

[FFmpeg-devel] [PATCH] avformat/mov.c: require tfhd to begin parsing trun

Detecting missing tfhd avoids re-using tfhd track info from the previous moof. For files with multiple tracks, this may make a mess of the avindex and fragindex, which can later trigger av_assert0 in mov_read_trun(). --- libavformat/isom.h | 1 + libavformat/mov.c | 10 ++ 2 files

[FFmpeg-devel] [PATCH] avformat/mov: validate chunk_count vs stsc_data

Bad content may contain stsc boxes with a first_chunk index that exceeds stco.entries (chunk_count). This ammends the existing check to include cases where chunk_count == 0. --- libavformat/mov.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/libavformat/mov.c

[FFmpeg-devel] [PATCH] avformat/mov: validate chunk_count vs stsc_data

Bad content may contain stsc boxes with a first_chunk index that exceeds stco.entries (chunk_count). mov_get_stsc_samples now checks for this and returns 0 when values are invalid. --- libavformat/mov.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavformat/mov.c

[FFmpeg-devel] [PATCH] avformat/isom.h: use usnigned types in MOVStsc

Unsigned types match the isobmff spec. --- libavformat/isom.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libavformat/isom.h b/libavformat/isom.h index e629663949..8e0d8355b3 100644 --- a/libavformat/isom.h +++ b/libavformat/isom.h @@ -59,9 +59,9 @@ typedef struct

[FFmpeg-devel] [PATCH] avformat/mov: validate chunk_count vs stsc_data

Bad content may contain stsc boxes with a first_chunk index that exceeds stco.entries (chunk_count). mov_get_stsc_samples now checks for this and returns 0 when values are invalid. Also updates MOVStsc to use unsigned ints, per spec. --- libavformat/isom.h | 6 +++--- libavformat/mov.c | 4

[FFmpeg-devel] [PATCH] avcodec/gsm_parser: return -1 on parse error

Return replaces an assert0. libfuzzer generated a testcase that triggered this assert (codec=0), causing a crash of chrome's renderer. --- libavcodec/gsm_parser.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/gsm_parser.c b/libavcodec/gsm_parser.c index

[FFmpeg-devel] [PATCH] lavf/id3v2: fail read_apic on EOF reading mimetype

avio_read may return EOF, leaving the mimetype array unitialized. fail early when this occurs to avoid using the array in an unitialized state. --- libavformat/id3v2.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/libavformat/id3v2.c b/libavformat/id3v2.c index

[FFmpeg-devel] [PATCH] lavf/mov: ensure only one tkhd per trak

Chromium fuzzing produced a whacky file with extra tkhds. This caused an AVStream that was already in use to be corrupted by assigning it a new id, which blows up later in mov_read_trun because the MOVFragmentStreamInfo.index_entry now points OOB. --- libavformat/mov.c | 12 +++- 1 file

[FFmpeg-devel] [PATCH] lavf/id3v2: fail read_apic on EOF reading mimetype

avio_read may return EOF, leaving the mimetype array unitialized. fail early when this occurs to avoid using the array in an unitialized state. --- libavformat/id3v2.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/libavformat/id3v2.c b/libavformat/id3v2.c index

[FFmpeg-devel] [PATCH] lavf/id3v2: fail read_apic on EOF reading mimetype

avio_read may return EOF, leaving the mimetype array unitialized. fail early when this occurs to avoid using the array in an unitialized state. --- libavformat/id3v2.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/libavformat/id3v2.c b/libavformat/id3v2.c index

[FFmpeg-devel] [PATCH] lavf/mov: ensure only one tkhd per trak

Chromium fuzzing produced a whacky file with extra tkhds. This caused an AVStream that was already in use to be corrupted by assigning it a new id, which blows up later in mov_read_trun because the MOVFragmentStreamInfo.index_entry now points OOB. --- libavformat/isom.h | 3 ++- libavformat/mov.c

[FFmpeg-devel] [PATCH] vp9_parser: set profile in AVCodecContext

--- libavcodec/vp9_parser.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavcodec/vp9_parser.c b/libavcodec/vp9_parser.c index 9531f34a32..b6b621198b 100644 --- a/libavcodec/vp9_parser.c +++ b/libavcodec/vp9_parser.c @@ -43,6 +43,8 @@ static int parse(AVCodecParserContext *ctx,

[FFmpeg-devel] [PATCH] libavformat/matroskadec: Add test for seeking with codec delay.

From: Chris Cunningham Also cleanup parens for the skip_to_timecode check. --- libavformat/matroskadec.c | 2 +- tests/fate/seek.mak| 3 +++ tests/ref/seek/mkv-codec-delay | 48 ++ 3 files changed, 52

[FFmpeg-devel] [PATCH] avformat/utils: Check negative bps before shifting in ff_get_pcm_codec_id()

From: Chris Cunningham Fixes: undefined shift. --- libavformat/utils.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/utils.c b/libavformat/utils.c index 5f5f03e..d1e4306 100644 --- a/libavformat/utils.c +++ b/libavformat/utils.c @@

[FFmpeg-devel] [PATCH] avformat/mp3dec: prefer "fast_seek" to TOC seek for CBR files.

From: Chris Cunningham "Fast seek" uses linear interpolation to find the position of the requested seek time. For CBR this is more direct than using the mp3 TOC and bypassing the TOC avoids problems with TOC precision. (see https://crbug.com/545914#c13) For VBR, fast

[FFmpeg-devel] [PATCH] avformat/mp3dec: prefer "fast_seek" to TOC seek for CBR files.

From: Chris Cunningham "Fast seek" uses linear interpolation to find the position of the requested seek time. For CBR this is more direct than using the mp3 TOC and bypassing the TOC avoids problems with TOC precision. (see https://crbug.com/545914#c13) For VBR, fast

[FFmpeg-devel] [PATCH] avformat/mp3dec: prefer "fast_seek" to TOC seek for CBR files.

From: Chris Cunningham "Fast seek" uses linear interpolation to find the position of the requested seek time. For CBR this is more direct than using the mp3 TOC and bypassing the TOC avoids problems with TOC precision. (see https://crbug.com/545914#c13) For VBR, fast

[FFmpeg-devel] [PATCH] avformat/mp3dec: prefer "fast_seek" to TOC seek for CBR files.

From: Chris Cunningham "Fast seek" uses linear interpolation to find the position of the requested seek time. For CBR this is more direct than using the mp3 TOC and bypassing the TOC avoids problems with TOC precision. (see https://crbug.com/545914#c13) For VBR, fast

[FFmpeg-devel] [PATCH] avformat/mp3dec: prefer "fast_seek" to TOC seek for CBR files.

From: Chris Cunningham "Fast seek" uses linear interpolation to find the position of the requested seek time. For CBR this is more direct than using the mp3 TOC and bypassing the TOC avoids problems when the TOC is corrupted (e.g. https://crbug.com/545914). For VBR,