[FFmpeg-user] Question about macroblocks in soft telecined video

[Mark Filipak]

On 09/06/2020 12:07 PM, Carl Eugen Hoyos wrote:
> Am So., 6. Sept. 2020 um 09:28 Uhr schrieb Mark Filipak
> <markfilipak.windows+ffmpeg at gmail.com>:
> 
> [...]
> 
>> Soft telecined video is actually 23/1.001 frames per second of video
>> even though the metadata tells the decoder to produce 30/1.001 FPS.
> 
> On the FFmpeg user mailing list, "decoder" and "metadata" have
> relatively strict meanings.

Your point is a 'lateral arabesque'. Argue the issues please. Don't bring up something unrelated in 
an attempt to discredit what I wrote.

> Given these meanings, what you write
> is simply wrong.
> (Apart from the fact that telecined content does not necessarily
> have a framerate of 24000/1001, ...

That's an ad homonym attack. I didn't say "telecined". I said "soft telecined". *Soft telecined* 
frames *do* have an FPS of 24/1.001.

>... the whole point is that it can
> have any framerate, in the case of ntsc crts any framerate smaller
> than 30000/1001.)

CRTs? What does the display device have to do with anything? (And NTSC CRTs definitely do have 
30/1.001 Hz frame rate. Solely 30/1.001 Hz frame rate. Otherwise, they're not NTSC.)

>> Of course, the metadata is the key to how the stream 'teaches' the
>> decoder how to telecine.
> 
> But since we don't want to telecine, this is irrelevant: We don't have
> access to an ntsc crt. If you decide to telecine, this cannot be done
> in the (FFmpeg) decoder, you need a (FFmpeg) video filter.

You continue to fail to understand the issue. I'm addressing undecoded video, not decoded video. Why 
am I addressing undecoded video? Because that's what's on a DVD or BD. You don't care about that 
because you (ffmpeg developers) get undecoded frames from the decoder. We (ffmpeg users) need to 
detect what's on discs because that's important.

>> MPV is smart enough to recognize 23/1.001 FPS data and to ignore
>> the metadata and to play at 23/1.001 FPS.
> 
>> Ffmpeg can do the same thing (and thereby eliminate the need to
>> transcode)
> 
> Telecine and transcoding do not depend on each-other so this is
> highly misleading.

They do depend on each other. Users transcode soft telecined video to get 24FPS because they think 
that's what they need to do. Instead, all they need to do is force 24/1.001 -- at least, that's what 
I think, but I'm unsure because ffmpeg is so poorly documented.

>> but the ffmpeg user has to tell ffmpeg to do it.
> 
> No, in general, this is not true.
> (Command line and complete, uncut console output missing.)

I don't know how to respond to that. Console output doesn't have anything to do with adequate 
documentation. The issue isn't a command line mistake. The issue is: How does ffmpeg work?

> A few random remarks:
> You provided some definitions (actually claims) in your email without
> explaining in which domain you believe they are valid. ...

The 'domain' is undecoded video as found on DVDs & BDs.

>... They are not
> valid in the general case (and not valid in most domains).
> I believe you somewhere mention that you want to detect soft-
> telecined content. This is trivial and is not related to macroblocks.

So-called "progressive" video -- I prefer "concurrent" -- is contained in interlaced data structures 
within the macroblocks. Hard telecined video (which may or may not be concurrent depending on 
whether it comes from cinema or from TV) is contained in deinterlaced data within the macroblocks 
that the decoder interlaces to make frames as part of the decoding process. My question has to do 
with whether, for soft telecine, the fields in the chrominance blocks of undecoded macroblocks is 
deinterlaced or interlaced.

> Your definition of our different interpretations of "interlaced" is
> completely backwards and wrong: ...

If you read H.222 and H.262 carefully, you will find that so-called "interlaced" video is not called 
"interlaced". It's called "interlace" (no "d"). It's called "interlace" because interlace is what 
the decoder does. If you read H.222 and H.262 carefully, you will find that the undecoded data is, 
in fact, deinterlaced (in other words: The undecoded data is in fields, not frames).

Interlaced frames is NOT what's found in undecoded video. What's found in undecoded video are 
deinterlaced fields. It is you who have it backwards. And that backwardness is what confused me and 
what confuses others.

>... A digital video stream can be
> encoded (!, not decoded as you imply) using encoding techniques
> meant for interlaced content. The decoder has to detect this and
> comply with it but this has no relevance for a user (it for many years
> was very important for FFmpeg developers). For display, it is
> very important to know if the actual content is interlaced or not.
> Most video players take the first information to decide but this is
> not valid in general (or, using your wording, "sloppy").
> In both views, this is not necessarily related to macroblocks.

It is absolutely intimately related to macroblocks and the data structures they contain.