mpeg2video can't be TFF with progressive source

[Paul Pacifico]

I use to use mpeg2video for XDCAM HD422 creation, I always encode with top field first that is working with an interlaced input BUT I can't make it TFF with an progressive source file.

Summary of the bug:
How to reproduce:

% ffmpeg -i input -an -c:v mpeg2video -b:v 50M -pix_fmt yuv422p -flags +ildct+ilme -top 1 output.mxf

ffmpeg version N-102564-g2261cc6d8a
built on Apple clang version 12.0.5

Thanks for any advice,
Paul.

[Carl Eugen Hoyos]

Please provide the command line you tested together with the complete, uncut console output to make this a valid ticket.

[Paul Pacifico]

Replying to Carl Eugen Hoyos:

Please provide the command line you tested together with the complete, uncut console output to make this a valid ticket.

Here is the command:

ffmpeg -i "/Users/paulpacifico/Desktop/C0002.MP4" -an -c:v mpeg2video -b:v 50M -pix_fmt yuv422p -flags +ildct+ilme -top 1 "/Users/paulpacifico/Desktop/output.mxf"

and the log:

ffmpeg version N-102564-g2261cc6d8a Copyright (c) 2000-2021 the FFmpeg developers
  built with Apple clang version 12.0.5 (clang-1205.0.22.9)
  configuration: --cc=/usr/bin/clang --prefix=/Users/paulpacifico/FFmpeg/WORKSPACE/builds --extra-cflags='-framework openAL' --extra-ldflags='-framework openAL' --pkg-config-flags=--static --extra-ldexeflags=-Bstatic --shlibdir='@loader_path' --disable-static --enable-shared --enable-gpl --enable-version3 --enable-sdl2 --enable-openal --enable-opengl --enable-fontconfig --enable-iconv --enable-libass --enable-libdav1d --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libsnappy --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libzimg --enable-lzma --enable-zlib --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libxvid --enable-libgsm --enable-libsvtav1 --enable-appkit --enable-avfoundation --enable-coreimage --enable-audiotoolbox
  libavutil      57.  0.100 / 57.  0.100
  libavcodec     59.  1.100 / 59.  1.100
  libavformat    59.  2.100 / 59.  2.100
  libavdevice    59.  0.100 / 59.  0.100
  libavfilter     8.  0.101 /  8.  0.101
  libswscale      6.  0.100 /  6.  0.100
  libswresample   4.  0.100 /  4.  0.100
  libpostproc    56.  0.100 / 56.  0.100
Guessed Channel Layout for Input Stream #0.1 : stereo
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/Users/paulpacifico/Desktop/C0002.MP4':
  Metadata:
    major_brand     : XAVC
    minor_version   : 16785407
    compatible_brands: XAVCmp42iso2
    creation_time   : 2021-06-28T08:50:33.000000Z
  Duration: 00:00:05.76, start: 0.000000, bitrate: 47893 kb/s
  Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc), 1920x1080 [SAR 1:1 DAR 16:9], 46146 kb/s, 25 fps, 25 tbr, 25k tbn (default)
    Metadata:
      creation_time   : 2021-06-28T08:50:33.000000Z
      handler_name    : Video Media Handler
      vendor_id       : [0][0][0][0]
      encoder         : AVC Coding
  Stream #0:1(und): Audio: pcm_s16be (twos / 0x736F7774), 48000 Hz, stereo, s16, 1536 kb/s (default)
    Metadata:
      creation_time   : 2021-06-28T08:50:33.000000Z
      handler_name    : Sound Media Handler
      vendor_id       : [0][0][0][0]
  Stream #0:2(und): Data: none (rtmd / 0x646D7472), 204 kb/s (default)
    Metadata:
      creation_time   : 2021-06-28T08:50:33.000000Z
      handler_name    : Timed Metadata Media Handler
      timecode        : 22:56:08:05
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> mpeg2video (native))
Press [q] to stop, [?] for help
[swscaler @ 0x138070000] deprecated pixel format used, make sure you did set range correctly
Output #0, mxf, to '/Users/paulpacifico/Desktop/output.mxf':
  Metadata:
    major_brand     : XAVC
    minor_version   : 16785407
    compatible_brands: XAVCmp42iso2
    encoder         : Lavf59.2.100
  Stream #0:0(und): Video: mpeg2video (4:2:2), yuv422p(tv, progressive), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 50000 kb/s, 25 fps, 25 tbn (default)
    Metadata:
      creation_time   : 2021-06-28T08:50:33.000000Z
      handler_name    : Video Media Handler
      vendor_id       : [0][0][0][0]
      encoder         : Lavc59.1.100 mpeg2video
    Side data:
      cpb: bitrate max/min/avg: 0/0/50000000 buffer size: 0 vbv_delay: N/A
frame=  144 fps=103 q=2.0 Lsize=    7660kB time=00:00:05.72 bitrate=10970.5kbits/s speed=4.11x    
video:7539kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.603199%

Thanks,
Paul.

[Paul Pacifico]

I've just tested on FFmpeg 4.3.2 and it works with no problem.

Since version 4.4 it does not output a TFF file from mpeg2video with a progressive source file.

[jeeb]

Can you check with -field_order tb, or any other of the non-progressive field orders?

"progressive",,
"tt",
"bb",
"tb",
"bt",

[Paul Pacifico]

I've also tested, but with no luck.

Here is a sample file (progressive source) if you want to try: ​https://www.shutterencoder.com/Paul/Sync%2025.mov

[pdr0]

A workaround is -vf setfield=tff

[Paul Pacifico]

Replying to pdr0:

A workaround is -vf setfield=tff

Thank you so much! I've tried everything except this.

Paul.

[Paul Pacifico]

Replying to pdr0:

A workaround is -vf setfield=tff

Thank you so much! I've tried everything except this.

Paul.

[jeeb]

Yes, since 4.4 the AVFrame's metadata is being correctly passed onto the encoder for autodetection, unlike earlier where you'd have to specifically specify things for the encoder separately (this goes the same way for various other video frame metadata as well). So in a sense, flagging the frames as they should be interpreted is the "proper" way :) .

That said, I have found the issue why -top wouldn't work (the override was being applied before the autodetection was handled, and thus getting overridden by the autodetection). I have now posted a patch to fix that, but as far as I can see that would match what -field_order would do (tt for -top 1 and bb for -top 0). So if there's still some issue, then it's something else?

[jeeb]

The -top option should now be fixed in current FFmpeg master as of commit 4c694093be68d401c60819e5171817c62afef8b2 (the field order autodetection until now overwrote the overridden value due to the two pieces of logic being in the incorrect order).

[Paul Pacifico]

Thanks a lot for your effort Jeeb, unfortunately I still have the same issue after compiling FFmpeg from latest Git.

[jeeb]

Alright, that's unfortunate. Then the only remaining block that was moved in my commits which improved ffmpeg.c's passing of input frame metadata was the following. You may test with it removed, but I would be surprised if that would change the result:

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index b0ce7c7c32..45949202a7 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -3485,10 +3485,6 @@ static int init_output_stream_encode(OutputStream *ost, AVFrame *frame)
 
         // Field order: autodetection
         if (frame) {
-            if (enc_ctx->flags & (AV_CODEC_FLAG_INTERLACED_DCT | AV_CODEC_FLAG_INTERLACED_ME) &&
-                ost->top_field_first >= 0)
-                frame->top_field_first = !!ost->top_field_first;
-
             if (frame->interlaced_frame) {
                 if (enc_ctx->codec->id == AV_CODEC_ID_MJPEG)
                     enc_ctx->field_order = frame->top_field_first ? AV_FIELD_TT:AV_FIELD_BB;

Otherwise, the issue would have to be ​bisected, although unfortunately one would have to apply the -top fix on top when testing commits after my ffmpeg.c rework set.

As a silver lining, at the very least specifically utilizing setfield video filter does lead to the right result thanks to that autodetection based on input frame metadata I added :) .

[Balling]

Is -vf setfield=tff broken now too????

[Paul Pacifico]

Thanks a lot Jeeb for your work, I will check that.

Currently setfield=tff does the job perfectly.

[Balling]

So, when is bisect happening? I suppose I no longer reproduce #7562 because of this bug.

I also think that this is a diplicate of #8916.

Will reverting fbb44bc51a647862eb05ae3f9d7d49a0be9bed57 (and 4c694093be68d401c60819e5171817c62afef8b2) fix the issue?? If not, why FATE here is changed, is it correct?

​https://github.com/FFmpeg/FFmpeg/commit/fbb44bc51a647862eb05ae3f9d7d49a0be9bed57#diff-084abe3c7cde6e26047d345a498bf59c7c5129158617eb8ce2425edb909367a2