[FFmpeg-user] Meaning of ffprobe output

[Ulf Zibis]

Moin Moritz,

Am 29.01.19 um 21:48 schrieb Moritz Barsnick:
>> My explanation is, that the original VHS was marked with copy
>> protection, so the DVD recorder by legal reasons has to sustain the
>> copy protection by creating an intentionally corrupted DVD file
>> system (which is not readable from a computer) and additionally a
>> corrupted vob stream, which is detected and forbidden to copy by
>> legal DVD copy software.
> This seems far fetched ("weit hergeholt"), at least in terms of
> creating mixed progressive/interlaced content. Broken file systems and
> streams: Yes, often.
I agree! But this is the only explanation I could imagine. This is what
I was taught in a german forum about the copy protection:
https://thinkpad-forum.de/threads/216464-Mein-geliebtes-T500-war-pl%C3%B6tzlich-mausetot?p=2168728&viewfull=1#post2168728
As you can see, this DVD was able to crash my laptop ... weird!
Here another german discussion about this DVD:
https://forum.ubuntuusers.de/topic/konvertiertes-video-am-ende-ohne-ton-geeignete/

> (I hate the concept of interlaced digital video, BTW.)
Well yes, but the concept allows the impression of fluent motion on
horizontal camera panning as with a 50 fps stream.

> AFAIU, idet does an *interpretation* of the input, somewhat like the
> visual inspection. In certain cases, it will see no obvious signs of
> interlacing, and count the frames as progressive. So, in summary, you
> have a statistical analysis. Unless your DVD recorder is really doing
> funky magic, your recording should be interlaced.
>
>>>> Also I do not understand, that after the transcoding to mp4 the numbers
>>>> are different. I interpret this, that the transcoding process does some
>>>> deinterlacing, but you say, the encoder does not. The vob with 114684
>>>> frames at 25 fps results in 1:16:27.36 length, but the resulting mp4 with
>>>> 114502 frames is 1:16:20.08.
> BTW, this difference is marginal, and probably due to the lossy nature
> of re-encoding biasing idet's results.

Yes, it's marginal, I just mentioned it to be complete. I guess the
cause are the corrupted time stamps in the vob, which you can see in the
former post from 18.01.19, 18:19 MEZ as couples of this massages:
[null @ 0x6afafc0] Application provided invalid, non monotonically
increasing dts to muxer in stream 1: 881664 >= 881664
With "ffmpeg -c copy" from the ripped vob I got similar messages.

I could imagine, that this corrupted timing data is the cause of idet's
weird interpretation.
So I'm still wondering, how I reliable could determine, if the stream is
interlaced. I think this is an important property, which should be in
the default output of ffprobe.

>> I need concentration on the subject and additionally time to
>> translate my thoughts from german to english.
> For a few of us, you could reiterate in German. That will not help the
> community at all, though.

Unfortunately this is true.

... and again: Can anybody teach me a little about the ffmpeg data model
in relation to frame vs. field?

Cheers and 'nabend

Ulf