[FFmpeg-user] Meaning of ffprobe output

[Ulf Zibis]

Am 02.02.19 um 02:18 schrieb Carl Eugen Hoyos:
>> I meant, if libx264 does a re-encoding from interlaced
>> encoding to progressive encoding?
> libx264 does not encode "from interlaced encoding"
> because it cannot know if the source was encoded
> interlaced or progressive.

With "interlaced encoded" I mean, that it includes some kind of flag in
the stream which tells the video player how to interpret the frame
content and deal with it accordingly. I was in assumption, that also an
encoder would dignify such flag.

Isn't there such flag?

>> That would mean, if I have an interlaced encoded vob
>> stream I get a progressive encoded mp4 stream and
>> the advantage of a better visual result of an interlacing
>> display is lost with libx264. Am I right?
> First:
> There is no "interlacing display", in our context this does
> not exist (anymore).

If not CRT I meant a compound of software, video controller and display,
where the 2nd field is actually painted on screen with a delay of half
of the frame interval.

> Second:
> libx264 does support interlaced encoding (but not field
> encoding because it does not help encoding efficiency).
>
> Apart from that, it does severely hurt compressibility
> if you don't set interlaced encoding for interlaced content.
... what only is available for _some_ encoders as you have stated, and
libx264 seems not to have that.

>> So what is the technical reason, that I can't crop a single line for
>> further processing?
> This is a property (or a bug) of yuv420p and our crop filter
> and not related to interlacing.

Ooh, that was a long ride to find the answer for my primary question,
and good that we have ruled out, that it is not related to interlacing.
Very much thanks for your patience.
Does that mean, it makes *sense to file a bug* to have single line
processing with crop in the future? I would burn for that.

> This is apart from the fact that the h.264 standard requires even
> resolutions iirc.

Yes I know that. After the splitting, cropping, modifying and again
merging single lines the resulting frame size should be even.

> Carl Eugen
>
> PS: The hevc and the j2k decoder sometimes provide "fields"
> (instead of frames) but this is completely unrelated: Because the
> standards (luckily) do not support interlaced encoding, some
> smart asses decided to send the two fields of an interlaced
> frame as independent frames to the encoders and expect the
> playback systems to reconstruct the original video.
> This does not work with FFmpeg (out of the box).

Very interesting method. This is what I would have asked for if my vob
stream certainly would have been proofed as interlaced.

-Ulf