[FFmpeg-user] Meaning of ffprobe output

[Carl Eugen Hoyos]

2019-02-02 0:43 GMT+01:00, Ulf Zibis <Ulf.Zibis at gmx.de>:
>
> Am 01.02.19 um 23:25 schrieb Carl Eugen Hoyos:
>> 2019-02-01 23:14 GMT+01:00, Ulf Zibis <Ulf.Zibis at gmx.de>:
>>> So now I understand (hopefully). My main interest was is to know,
>>> if my video is _encoded_ interlaced or not, and I still don't know it :-(
>> Debugging mpegvideo.c shows the video is encoded interlaced.
>> (Which was practically certain as the encoder couldn't know that
>> your content is progressive.)
>
> Do I understand right, that there is no way by ffprobe or some other
> option to know, if a video is _encoded_ interlaced or not?

I suspect there is but I may be wrong.
(It is not really helpful because users use it to decide if they
should de-interlace or not which is a bad idea.)

> You may remember my question and your answer:
> Am 15.01.19 um 12:54 schrieb Carl Eugen Hoyos:
>
>>> Which is the de-interlacing method, libx264 uses by default?
>> x264 is an encoder and knows nothing about de-interlacing,
>> it does not de-interlace.
>
> 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.

Please try to understand that we are only discussing
digital video here, and that all decoders only provide
frames (not fields) and all encoders expect frames
(not fields) - although all frames consist of two fields.
You can ask some encoders to encode the frames
in interlaced or progressive mode.

> 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).
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.
(But the sample video you provided is not interlaced, it
is difficult to encode because of its abysmal quality.)

>>> If it is encoded interlaced, I can understand, that only a pair of
>>> lines can be cropped.
>> This is wrong, the output of the decoder is not different depending
>> on the used encoding method.
>
> 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.

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

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).