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 _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".