Opened 2 months ago

Last modified 6 weeks ago

#9856 new enhancement

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

Reported by: Pierre-Anthony Lemieux Owned by:
Priority: normal Component: avformat
Version: unspecified Keywords: mxf
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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.

Change History (8)

comment:1 by Tomas Härdin, 2 months ago

Component: undeterminedavformat
Type: defectenhancement

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.

comment:2 by Pierre-Anthony Lemieux, 2 months ago

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

Last edited 2 months ago by Pierre-Anthony Lemieux (previous) (diff)

comment:3 by Pierre-Anthony Lemieux, 2 months ago

@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.

comment:4 by Tomas Härdin, 2 months ago

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

in reply to:  4 comment:5 by Pierre-Anthony Lemieux, 2 months ago

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.

comment:6 by Pierre-Anthony Lemieux, 2 months ago

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.

comment:7 by Tomas Härdin, 2 months ago

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.

comment:8 by Pierre-Anthony Lemieux, 6 weeks ago

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

Note: See TracTickets for help on using tickets.