On 02/04/2023 22:07, Michael Niedermayer wrote:
> On Sat, Apr 01, 2023 at 07:11:45PM +0200, Jerome Martinez wrote:
> [...]
>>   mxfenc.c |   10 ++++++----
>>   1 file changed, 6 insertions(+), 4 deletions(-)
>> 2b3a2cc619fcaf2dd1da7aa4b566b390eced62a3  0001-avformat-mxfenc-replace-ffv1-version-related-assert-.patch
>>  From 65f6fba9434fa9ab4b5d2b91c3f930c1e3cb4bef Mon Sep 17 00:00:00 2001
>> From: Jerome Martinez <jerome@mediaarea.net>
>> Date: Sat, 1 Apr 2023 19:04:25 +0200
>> Subject: [PATCH] avformat/mxfenc: replace ffv1 version related assert by error
>>   message
>>
>> ---
>>   libavformat/mxfenc.c | 10 ++++++----
>>   1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
>> index 9eba208ffb..0a1ae5353c 100644
>> --- a/libavformat/mxfenc.c
>> +++ b/libavformat/mxfenc.c
>> @@ -2489,8 +2489,8 @@ static int mxf_parse_ffv1_frame(AVFormatContext *s, AVStream *st, AVPacket *pkt)
>>           ff_init_range_decoder(&c, st->codecpar->extradata, st->codecpar->extradata_size);
>>           ff_build_rac_states(&c, 0.05 * (1LL << 32), 256 - 8);
>>           v = get_ffv1_unsigned_symbol(&c, state);
>> -        av_assert0(v >= 2);
>> -        if (v > 4) {
>> +        if (v < 2) {
>> +            av_log(s, AV_LOG_ERROR, "Invalid version in ffv1 global header\n");
>>               return 0;
>>           }
> should this not also fail with v > 4 as before ?

I preferred during the change to copy the code in ffv1dec.c for more 
coherency, and ffv1dec.c considers version 5 in ver01 header as invalid 
and version 5 with extra metadata as legit.
Actually, a bigger issue is that ffv1dec.c accepts version 5 as if it 
can decode it, e.g. with hacked ffv1 stream having version 5:

$ ./ffmpeg -hide_banner -loglevel error -i level5_like_level1.mkv -f 
null /dev/null 2> >(grep -i  "version")
[ffv1 @ 0x7fffc04c81c0] invalid version 5 in ver01 header
$ mediainfo --Details=1 level5_like_level3.mkv | grep "version"
1B1        version:                         5 (0x00000005) - 
Error=FFV1-HEADER-version-LATERVERSION:1
$ ./ffmpeg -hide_banner -loglevel error -i level5_like_level3.mkv -f 
null /dev/null && echo $?
0

It works only because my hacked file is a version 4 in reality but it 
should be rejected for when we have a version 5 not compatible with 
version 4.
I suggest to keep the previous patch as is for coherency with ffv1dec.c 
then add the new attached patch that add a check on ffv1 version > 4 for 
both ffv1dec.c and mxfenc.c; for ffv1dec.c I also check micro_version 
for version 4 because FFV1 spec hints that micro_version before the one 
flagged as stable may be incompatible with previous micro_versions.
With the additional patch:
$ ./ffmpeg -hide_banner -loglevel error -i level5_like_level3.mkv -f 
null /dev/null
[ffv1 @ 0x7fffc290e640] unsupported version 5
Error while opening decoder for input stream #0:0 : Not yet implemented 
in FFmpeg, patches welcome
$ ./ffmpeg -hide_banner -loglevel error -i level4.3.mkv -f null /dev/null
[ffv1 @ 0x7fffc5b27640] unsupported version 4 micro_version 3
Error while opening decoder for input stream #0:0 : Not yet implemented 
in FFmpeg, patches welcome
$ ./ffmpeg -hide_banner -loglevel error -i level5_like_level3.mkv -r 25 
-c:v copy -f mxf /dev/null
[ffv1 @ 0x7fffe422bf00] unsupported version 5
[mxf @ 0x7fffda8b4080] unsupported ffv1 version 5
[out#0/mxf @ 0x7fffd34470c0] Error muxing a packet

Jérôme