@@ -2894,8 +2894,12 @@ static int mxf_init(AVFormatContext *s)
if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) {
const AVPixFmtDescriptor *pix_desc = av_pix_fmt_desc_get(st->codecpar->format);
- // TODO: should be avg_frame_rate
- AVRational tbc = st->time_base;
+ AVRational tbc = (AVRational){ 0, 0 };
+ if (st->avg_frame_rate.num > 0 && st->avg_frame_rate.den > 0)
+ tbc = av_inv_q(st->avg_frame_rate);
+ else if (st->r_frame_rate.num > 0 && st->r_frame_rate.den > 0)
+ tbc = av_inv_q(st->r_frame_rate);
+
// Default component depth to 8
sc->component_depth = 8;
sc->h_chroma_sub_sample = 2;
@@ -1 +1 @@
-d408aba82d62a90ed7f46a1999b014f1
+b28d4ca13029fdc80a114b56467be9d7
The time_base was a bad guess. Currently, fate-time_base test data assumed that overriding the input time_base would affect the frame_rate, but this behaviour is not documented, so just fix the fate data now that this is fixed. Fix regression since 10185e2d4c1e9839bc58a1d6a63c861677b13fd0: previously, when streamcopying, the time_base was guessed from the frame_rate considering it is often constant, so guessing the frame_rate back from the time_base was often not a problem. To reproduce: ffmpeg -i fate-suite/mpeg2/dvd_still_frame.vob -an -c copy out.mxf Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris> --- libavformat/mxfenc.c | 8 ++++++-- tests/ref/fate/time_base | 2 +- 2 files changed, 7 insertions(+), 3 deletions(-)