tff interlaced encode from progressive not working

[daren]

Summary of the bug:
tff interlaced encodes of wrongly (progressive) encoded interlaced footage used to work. It now seems to always wrongly encode as bff but label (mediainfo) it as tff no matter if -top 0 or -top 1 is supplied.

How to reproduce:

% ffmpeg -i input -c:v libx264 -flags +ilme+ildct -top 1 output
ffmpeg version n4.4
built with GCC 11.1.0 (Arch Linux repository)

Tried a few ffmpeg-static versions out, it breaks at 4.4-static and works up to 4.2.2-static (4.3.x branches were missing)
It broke fairly recently though, couple weeks/months ago, guessing with ffmpeg 4.4.

Attached a file that works with

ffmpeg -i progressive_interlaced_footage.mkv -pix_fmt yuv420p -c:v libx264 -flags +ilme+ildct -top 1 interlaced.mkv

on 4.2.2-static and lower versions but not with n4.4/4.4-static.

[daren]

progressive encode of interlaced footage

[jeeb]

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

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

[daren]

I tried it just now, it sets the field order for mediainfo to read, but it's still botched for playback.

Attaching another script test_ffmpeg_interlace.sh for reproduction.

ffmpeg 4.4 produces all output with choppy (wrong field order) deinterlaced playback with vlc and mpv while 4.2.2-static deinterlaces properly .

[jeeb]

That's interesting since while I have found the issue (auto-detection after override was handled and not the other way around in ffmpeg.c), the "top" option when specified for an output does not do anything else than set that value to either "bb" (0) or "tt" (1).

So if those two do not work... then there's something else at play as well.

[daren]

ffmpeg-static released a couple more versions up to the latest one, can somewhat backtrack where this went buggy.

It happened between releases 4.3.2 and 4.4 and is still an issue with 5.0, if someone could try reproduce this with commits that could be the culprit here.

Attaching another script that quickly tries to reproduce this with all the ffmpeg-static versions available.

[elenril]

Should have been fixed 2 years ago in 4c694093be68d401c60819e5171817c62afef8b2, cannot reproduce the bug in my tests.
Please reopen and comment if it's still broken for you.

[daren]

No, still the case in ffmpeg 6.0 even, just checked.

I'll bisect between tags 4.3.2 and 4.4 and find the culprit commit that botched this.

[daren]

I bisected between 4.3.6 and 4.4 and this commit broke it:
​https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=fbb44bc51a647862eb05ae3f9d7d49a0be9bed57

[elenril]

Okay, I see the problem in the handling of the -top option. The thing is also that it is badly named, underdocumented, and entirely redundant with the setfield filter - transcoding your video with -vf setfield=tff produces correctly-looking output. I'm thinking the option should be removed and everyone should switch to using the filter.

[daren]

That seems to do the trick and controls whether it's tff or bff, didn't read about it earlier.

If the -top option is that undocumented and unused as barely anyone complained about it not working properly for over 2 years, might as well deprecate and/or remove it.

[elenril]

Should be fixed in 43a0004b5c23dd8258cfe723a5c4e9fd9ee8f5ef.