[FFmpeg-user] ffprobe bug in 'interlaced_frame'?

[Carl Eugen Hoyos]

Am Mo., 27. Jan. 2020 um 02:42 Uhr schrieb Mark Filipak
<markfilipak.windows+ffmpeg at gmail.com>:

> Right now, if I want the absolute best MKV transcode of a "Making of"

(Not entirely sure if you are aware)
Soft-telecine is vob-specific.

> Special Feature (or Extra Feature or whatever you want to call it) that
> includes real NTSC TV and embedded movie clips, my only alternative is
> to transcode to 60 FPS CFR and suffer an MKV that's about 70% larger
> than it would need to be.

> What I'd prefer is to encode the NTSC TV sections as 30i and encode
> the movie clips as 24p.

Isn't that what happens if you do the following?
$ ffmpeg -i input out.mkv
(You may need to enable interlaced encoding, x264 is smart enough
to only use it for frames that need it)

Or is your problem that the input is cfr and hard-telecined? Maybe
fieldmatch and mpdecimate help (I have never tried but you can
force mpdecimate to only throw away identical frames). But note that
mpdecimate is not supposed to reduce output file size for a modern
codec if you only throw away identical frames, so if your issue is
really file size, it shouldn't matter.

> I think it's possible to mix those two as separate GOPs, but I must
> confess that I'm not sure.

I don't think this is necessary.

> Right now, if I detelecine both sections, of course I get extreme

You cannot detelecine the "TV sections"...

> combing in the NTSC TV sections, and if I hard telecine both sections, I
> get judder in the movie clips.

This is difficult to understand because you (again) change the subject
here (first from soft-telecine that is not supported by FFmpeg to vfr
encoding that is supported except for mov, now to combing artefacts).
If your goal is not to see those artefacts, you either need a deinterlacer
at encoding time or at display time.

Telecine should not cause "judder" (the opposite) but that doesn't
mean you should consider using it, you really shouldn't. Our filter
is mostly meant to easily allow testing the inverse filters.

> Transcoding to 60p works, but the
> resulting MKV is 70% or more larger than the source.

The fact that an output file is larger than an input file is by itself
not related to anything of the above: If you need best quality, it
is actually expected.

If you want the "best" output file, you should not re-encode if
output file size matters (it sadly always does, even for archivists).

Did you tell the encoder that parts of your video are interlaced?
If not, this would be an explanation for large output file size /
bad encoding quality.
(Note that hevc does not support interlaced encoding in the
sense we use it in our discussion.)

Carl Eugen