MXF demuxer does not set AVStream::avg_frame_rate and ::r_frame_rate

[Pierre-Anthony Lemieux]

The MXF demuxer does not set AVStream::avg_frame_rate and AVStream::::r_frame_rate. As a result, the MOV muxer, which uses AVStream::avg_frame_rate to determine the timecode frame rate, will fail when copying a track:

ffmpeg -f imf -i countdown-small/CPL_bb2ce11c-1bb6-4781-8e69-967183d02b9b.xml -map 0 -c copy -t 5 -shortest build/out.mov

Suggest setting the avg_frame_rate and r_frame_rate of the video stream to the edit_rate of the MXF track.

[Tomas Härdin]

A sample would be nice. It seems for most samples that we have r_frame_rate is probed at the codec level. However frame rate and timecode have little to do with each other and avg_frame_rate and r_frame_rate are not the proper fields to carry such information in. Carrying timecode information between MXF and MOV likely involves parsing TimecodeComponent to some common format.

[Pierre-Anthony Lemieux]

Try

ffmpeg -i fate-suite/imf/countdown/countdown-small.mxf -map 0 -c copy -t 5 -timecode 01:00:00:00 -shortest build/out.mov

[Pierre-Anthony Lemieux]

@thardin For better or for worse, movenc.c uses avg_frame_rate to determine the timecode frame rate if a timecode is specified as metadata ("timecode"). See mov_check_timecode_track() at movenc.c.

[Tomas Härdin]

Strange, countdown-small.mxf r_frame_rate=24/1 but avg_frame_rate=0/0. Perhaps some way to specify time code rate and drop frame via metadata would be an appropriate solution? In my experience relying on frame rate is brittle

[Pierre-Anthony Lemieux]

Replying to Tomas Härdin:

Strange, countdown-small.mxf r_frame_rate=24/1 but avg_frame_rate=0/0. Perhaps some way to specify time code rate and drop frame via metadata would be an appropriate solution? In my experience relying on frame rate is brittle

I like the idea of specifying timecode start, rate and drop frame in the metadata channels -- as opposed to merely specifying timecode start.

Independently, I think it would be good if the MXF demuxer filled in avg_frame_rate for video tracks since it knows that information.

[Pierre-Anthony Lemieux]

Thinking some more about this: it is very unusual for the timecode stream to have a frame rate that is not equal to the video frame rate rounded to the nearest integer. Furthermore the dropframe flag is already determined based on whether the last separator is a ":" or a ";", so I am not sure that the current "timecode" metadata value needs to be changed.

[Tomas Härdin]

It usually is something like this yes, but not always. In my experience it is better to be explicit with these things. In this case the intent is clearly to transport timecode information from MXF to MOV, and libavformat should not invent its own values in that case.

[Pierre-Anthony Lemieux]

Regardless of deeper solution re: timecode, I think it would be good if the MXF demuxer set AVStream::avg_frame_rate and AVStream::r_frame_rate, at least in the case where they are know, e.g. in the case of J2K image frames wrapped according to SMPTE ST 422, Table A.1 (​https://doi.org/10.5594/SMPTE.ST422.2019).

Below is a suggested minimal patch:

​https://github.com/sandflow/ffmpeg-imf/pull/101

[Pierre-Anthony Lemieux]

Fixed at 48fa27e77a6d71be89f216cee13ae7e99d2b5003