Re: [FFmpeg-user] Meaning of ffprobe output
2019-03-11 19:53 GMT+01:00, Ulf Zibis : > > Am 11.03.19 um 11:58 schrieb Carl Eugen Hoyos: >>> Is native vs. x264 encoder something different? >> The native (FFmpeg-internal) encoders may be a little less >> sophisticated than x264 (and they don't know a special >> adaptive interlaced setting because it didn't exist in earlier >> formats). > Does ffmpeg still use the native encoder when omitting > the -c:v libx264 option? There is no internal h264 encoder, there are encoders for mpeg1video/mpeg2video/h263/mpeg4video etc. Carl Eugen ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Meaning of ffprobe output
Am 11.03.19 um 11:58 schrieb Carl Eugen Hoyos: > So our suspicion after visual inspection was right. Yes, indeed. >> So I buyed the DVD now. Except that it has 3 audio tracks to choose and >> the VHS head switching artefacts are missing, it unfortunately has the >> equal bad quality than my DVD recorder copy, but even has a worst colour >> quality than my copy. The purchased DVD is not a direct telecined copy >> from the 36 mm material (disappointing), it seem to be a capture of the >> in earlier times provided VHS cassette, but with a better adjusted VHS >> player, so the head switching artefacts are missing. > Thank you for the info! > Maybe you should buy a copy of the film? Hey hey, and additionally a telecine machine to have a digital copy. ;-) >> Is native vs. x264 encoder something different? > The native (FFmpeg-internal) encoders may be a little less > sophisticated than x264 (and they don't know a special > adaptive interlaced setting because it didn't exist in earlier > formats). Does ffmpeg still use the native encoder when omitting the -c:v libx264 option? I don't see any difference in the terminal output of ffmpeg or in the results with ffprobe. Or in other words, how can I determine, which encoder was used for transcoding or a given mp4? -Ulf ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Meaning of ffprobe output
2019-02-21 11:31 GMT+01:00, Ulf Zibis : > > Am 21.02.19 um 01:41 schrieb Carl Eugen Hoyos: >> 2019-02-04 23:29 GMT+01:00, Ulf Zibis : >>> Now I've checked the files with mediainfo: >>> - The vob file is stated as interlaced top first. (I know, this does >>> nothing say about the content, only the flag is evaluated.) >> Doesn't FFmpeg also report this? >> (I believe it should.) > This is what I had asked several times, what the meaning of the string > "top first" on the vob input is. It's just the indication of the flag or > something else? I believe you are right, I missed / forgot this. I expect it is not shown for all interlaced encoded (x264) streams though. >>> - The transcoded mp4 is stated as progressive. >> Did you specify that you want x264 to encode using >> algorithms for interlaced input material? >> Should be "-flags +idct" > Aha, this appears to be the long awaited answer to my question what you > mean by "encoded interlaced". The x264 encoder has a special > mode/optimization for interlaced material, which should be enabled > manually, as the encoder can't detect the nature of the input material > automatically. Correct. > So I guess, the interlaced flag is set automatically when > "-flags +idct" is used, but never just copied from the input stream. It shouldn't. >>> I don't know, why libx264 doesn't retain the flag, maybe it evaluates >> Again (afair, I already wrote that at some point): >> x264 neither retains nor drops "the flag", it doesn't know >> about the input content, it cannot "evaluate" its content. > > Hm, as mediainfo shows, the flag "interlaced top first" was dropped when > transcoding from vob to mp4, which seems to be the same what > ffmpeg/ffprobe states by the string "top first". It wasn't dropped: It is a property of the input stream (only). >>> I still must admid, that I don't really understand what is meant by >>> "encoded interlaced", is it the same than "has the interlaced flag set"? >>> I see no reason why ffmpeg "cannot know" this flag. >> Of course it knows this flag but since the flag is completely useless >> (for encoding, it may be needed to decode correctly) it cannot be >> used to determine correct settings for encoding. >> >> Allow me to repeat: Except for the intro, the video you provided >> is not interlaced, it has artefacts that may or may not be easier >> to encode when using interlaced encoding. >> (Because of the given quality, this is mostly a moot discussion: >> Just use a low quantiser or keep the "originals", if you are really >> interested in the movie buy a dvd that will beat the quality of >> your recording by far.) > In the meantime I had the chance to phone with the original producer > Moritz Boerner. The film was recorded with 36 mm celluloid and he had > above 250.000 DM, not 20.000 DM to produce the film. So our suspicion after visual inspection was right. > So I buyed the DVD now. Except that it has 3 audio tracks to choose and > the VHS head switching artefacts are missing, it unfortunately has the > equal bad quality than my DVD recorder copy, but even has a worst colour > quality than my copy. The purchased DVD is not a direct telecined copy > from the 36 mm material (disappointing), it seem to be a capture of the > in earlier times provided VHS cassette, but with a better adjusted VHS > player, so the head switching artefacts are missing. Thank you for the info! Maybe you should buy a copy of the film? >> PS: Rethinking, it may be a good idea to add the flags for >> your x264 encoding, I believe the encoder is smart enough >> to decide when / how to use it. I suspect it won't make a >> difference for the native FFmpeg video encoders though. > > Is native vs. x264 encoder something different? The native (FFmpeg-internal) encoders may be a little less sophisticated than x264 (and they don't know a special adaptive interlaced setting because it didn't exist in earlier formats). Carl Eugen ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Meaning of ffprobe output
Am 21.02.19 um 01:41 schrieb Carl Eugen Hoyos: > 2019-02-04 23:29 GMT+01:00, Ulf Zibis : >> Now I've checked the files with mediainfo: >> - The vob file is stated as interlaced top first. (I know, this does >> nothing say about the content, only the flag is evaluated.) > Doesn't FFmpeg also report this? > (I believe it should.) This is what I had asked several times, what the meaning of the string "top first" on the vob input is. It's just the indication of the flag or something else? >> - The transcoded mp4 is stated as progressive. > Did you specify that you want x264 to encode using > algorithms for interlaced input material? > Should be "-flags +idct" Aha, this appears to be the long awaited answer to my question what you mean by "encoded interlaced". The x264 encoder has a special mode/optimization for interlaced material, which should be enabled manually, as the encoder can't detect the nature of the input material automatically. So I guess, the interlaced flag is set automatically when "-flags +idct" is used, but never just copied from the input stream. >> I don't know, why libx264 doesn't retain the flag, maybe it evaluates > Again (afair, I already wrote that at some point): > x264 neither retains nor drops "the flag", it doesn't know > about the input content, it cannot "evaluate" its content. Hm, as mediainfo shows, the flag "interlaced top first" was dropped when transcoding from vob to mp4, which seems to be the same what ffmpeg/ffprobe states by the string "top first". >> I still must admid, that I don't really understand what is meant by >> "encoded interlaced", is it the same than "has the interlaced flag set"? >> I see no reason why ffmpeg "cannot know" this flag. > Of course it knows this flag but since the flag is completely useless > (for encoding, it may be needed to decode correctly) it cannot be > used to determine correct settings for encoding. > > Allow me to repeat: Except for the intro, the video you provided > is not interlaced, it has artefacts that may or may not be easier > to encode when using interlaced encoding. > (Because of the given quality, this is mostly a moot discussion: > Just use a low quantiser or keep the "originals", if you are really > interested in the movie buy a dvd that will beat the quality of > your recording by far.) In the meantime I had the chance to phone with the original producer Moritz Boerner. The film was recorded with 36 mm celluloid and he had above 250.000 DM, not 20.000 DM to produce the film. So I buyed the DVD now. Except that it has 3 audio tracks to choose and the VHS head switching artefacts are missing, it unfortunately has the equal bad quality than my DVD recorder copy, but even has a worst colour quality than my copy. The purchased DVD is not a direct telecined copy from the 36 mm material (disappointing), it seem to be a capture of the in earlier times provided VHS cassette, but with a better adjusted VHS player, so the head switching artefacts are missing. > PS: Rethinking, it may be a good idea to add the flags for > your x264 encoding, I believe the encoder is smart enough > to decide when / how to use it. I suspect it won't make a > difference for the native FFmpeg video encoders though. Is native vs. x264 encoder something different? -Ulf ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Meaning of ffprobe output
2019-02-04 23:29 GMT+01:00, Ulf Zibis : > > Am 04.02.19 um 01:00 schrieb Carl Eugen Hoyos: >> 2019-02-03 21:16 GMT+01:00, Ulf Zibis : >>> Am 03.02.19 um 21:06 schrieb Carl Zwanzig: It's a shortening of "Top Field First" (TFF). With interlaced video you have a choice of whether the top or bottom field (odd numbered lines/even numbered lines) comes before the other in the digital stream. >>> I know this, but Carl Eugen said, that my video is not interlaced > Now I've checked the files with mediainfo: > - The vob file is stated as interlaced top first. (I know, this does > nothing say about the content, only the flag is evaluated.) Doesn't FFmpeg also report this? (I believe it should.) > - The transcoded mp4 is stated as progressive. Did you specify that you want x264 to encode using algorithms for interlaced input material? Should be "-flags +idct" (As explained before, there is no way for FFmpeg to know if the input it really interlaced or not except for running idet which is not done automatically for performance reasons and which - as you showed - is not always helpful). > I don't know, why libx264 doesn't retain the flag, maybe it evaluates Again (afair, I already wrote that at some point): x264 neither retains nor drops "the flag", it doesn't know about the input content, it cannot "evaluate" its content. > the content and decides to remove it. Carl Eugen stated, that libx264 > makes an interlaced output, if the input is interlaced, so I would > think, it shouldn't change the interlace state, if I understood right. > >> FFmpeg cannot know if the video is interlaced. >> (It was encoded interlaced which is not unusual for mpeg2video) > > I still must admid, that I don't really understand what is meant by > "encoded interlaced", is it the same than "has the interlaced flag set"? > I see no reason why ffmpeg "cannot know" this flag. Of course it knows this flag but since the flag is completely useless (for encoding, it may be needed to decode correctly) it cannot be used to determine correct settings for encoding. Allow me to repeat: Except for the intro, the video you provided is not interlaced, it has artefacts that may or may not be easier to encode when using interlaced encoding. (Because of the given quality, this is mostly a moot discussion: Just use a low quantiser or keep the "originals", if you are really interested in the movie buy a dvd that will beat the quality of your recording by far.) Carl Eugen PS: Rethinking, it may be a good idea to add the flags for your x264 encoding, I believe the encoder is smart enough to decide when / how to use it. I suspect it won't make a difference for the native FFmpeg video encoders though. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Meaning of ffprobe output
Am 04.02.19 um 01:00 schrieb Carl Eugen Hoyos: > 2019-02-03 21:16 GMT+01:00, Ulf Zibis : >> Am 03.02.19 um 21:06 schrieb Carl Zwanzig: >>> It's a shortening of "Top Field First" (TFF). With interlaced video >>> you have a choice of whether the top or bottom field (odd numbered >>> lines/even numbered lines) comes before the other in the digital stream. >> I know this, but Carl Eugen said, that my video is not interlaced Now I've checked the files with mediainfo: - The vob file is stated as interlaced top first. (I know, this does nothing say about the content, only the flag is evaluated.) - The transcoded mp4 is stated as progressive. I don't know, why libx264 doesn't retain the flag, maybe it evaluates the content and decides to remove it. Carl Eugen stated, that libx264 makes an interlaced output, if the input is interlaced, so I would think, it shouldn't change the interlace state, if I understood right. > FFmpeg cannot know if the video is interlaced. > (It was encoded interlaced which is not unusual for mpeg2video) I still must admid, that I don't really understand what is meant by "encoded interlaced", is it the same than "has the interlaced flag set"? I see no reason why ffmpeg "cannot know" this flag. -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".
Re: [FFmpeg-user] Meaning of ffprobe output
2019-02-03 21:16 GMT+01:00, Ulf Zibis : > > Am 03.02.19 um 21:06 schrieb Carl Zwanzig: >> It's a shortening of "Top Field First" (TFF). With interlaced video >> you have a choice of whether the top or bottom field (odd numbered >> lines/even numbered lines) comes before the other in the digital stream. > > I know this, but Carl Eugen said, that my video is not interlaced FFmpeg cannot know if the video is interlaced. (It was encoded interlaced which is not unusual for mpeg2video) Carl Eugen ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
Ulf Zibis wrote: >Does the 'p' in yuv420p mean "progressive"? No, it means "planar". Best regards, Reto ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
Am 03.02.19 um 21:06 schrieb Carl Zwanzig: > It's a shortening of "Top Field First" (TFF). With interlaced video > you have a choice of whether the top or bottom field (odd numbered > lines/even numbered lines) comes before the other in the digital stream. I know this, but Carl Eugen said, that my video is not interlaced, so I'm confused why ffprobe shows this. And if it's just a flag, I'm wondering why it is gone after transcoding to mp4. -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".
Re: [FFmpeg-user] Meaning of ffprobe output
Am 03.02.19 um 16:52 schrieb Ulf Zibis: > Hi Carl Eugen, > > For me it's ok to close that discussion here. You did a lot of effort to > explain me many details, much thanks for that. I can live with the > remaining unclarity. But could you please tell me the meaning of "top first" in ffprobe output of the vob file, which is missing after transcoding to mp4. Does the 'p' in yuv420p mean "progressive"? -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".
Re: [FFmpeg-user] Meaning of ffprobe output
On 2/3/2019 11:58 AM, Ulf Zibis wrote: But could you please tell me the meaning of "top first" in ffprobe output of the vob file, which is missing after transcoding to mp4. It's a shortening of "Top Field First" (TFF). With interlaced video you have a choice of whether the top or bottom field (odd numbered lines/even numbered lines) comes before the other in the digital stream. (I've also found that some software can not work with interlaced content with one or the other (some want TFF, some want BFF, some don't care).) Later, z! ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
Am 03.02.19 um 17:17 schrieb Carl Eugen Hoyos: > They do not look like comb artefacts as caused by interlaced > recording to me. Thanks, here I respect your experience with video material I don't have. But these artefacts must have to do with horizontal motion, as they don't appear in "normal" scenes. >>> Definitely not interlaced (could be de-interlaced, but this doesn't >>> make much difference because of the other visual issues). >> Would you agree, that the original master recording probably >> was an analogue interlaced video tape, maybe early >> Betacam or high quality VHS camera > Wikipedia claims that there was neither Betacam nor VHS-C > in 1982 (I meant "Camcorder" when I wrote "Digital video" > which of course didn't exist), IMDB claims the movie was > released in January 1983. Yes, I've read this Wikpedia article before, but IIRC there also have been full format VHS Camcorders, I remember those monsters in those days. Betacam started in 1982: https://en.wikipedia.org/wiki/Betacam "Catch your Dreams" was produced in late autumn 1982. The first two-piece camera/VCR systems emerged around 1980: https://en.wikipedia.org/wiki/Betamovie > But I agree that the lack of celluloid artefacts does point to > television cameras and recording technology. > (Although I wonder a little if these really were cheaper than > a film camera plus film.) Maybe the author had the chance to lend the camera for nothing for a week. Another fact is, that the film was shown in normal cinemas in the 80ies in Germany. There were no beamers, so the film had to be copied to celluloid. A VHS recording may have been too bad for that, but maybe Betacam was enough. It is indeed difficult to know, if the original master was celluloid or video tape. > Wikipedia also claims that Betacam supported progressive recording. maybe optionally because these cameras anyway had a buffer memory for the special recording technique with 120 % speed. For this technique they had to save 1 line, but I suspect, if they could save a half frame. It is said, a Betacam recording could be played back on a normal Betamax VCR witch worked interlaced. -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".
Re: [FFmpeg-user] Meaning of ffprobe output
2019-02-03 11:58 GMT+01:00, Ulf Zibis : > > Am 01.02.19 um 20:00 schrieb Carl Eugen Hoyos: >>> But for the rest of the video, I'm wondering that I nowhere notice such >>> dropouts. IIRC I read, that the film was produced with a budget of >>> 20.000 DM, which IMHO is not enough for a 76 min. celluloid film. >>> >>> Additionally in the turning camera scene from 2:34 I see comb >>> artifacts, which are typical for interlaced video recordings (see >>> attached extractions). They do not look like comb artefacts as caused by interlaced recording to me. >> Definitely not interlaced (could be de-interlaced, but this doesn't >> make much difference because of the other visual issues). > > Would you agree, that the original master recording probably > was an analogue interlaced video tape, maybe early > Betacam or high quality VHS camera Wikipedia claims that there was neither Betacam nor VHS-C in 1982 (I meant "Camcorder" when I wrote "Digital video" which of course didn't exist), IMDB claims the movie was released in January 1983. But I agree that the lack of celluloid artefacts does point to television cameras and recording technology. (Although I wonder a little if these really were cheaper than a film camera plus film.) Wikipedia also claims that Betacam supported progressive recording. Carl Eugen ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
Am 03.02.19 um 16:47 schrieb Carl Eugen Hoyos: > 2019-02-03 16:31 GMT+01:00, Ulf Zibis : > >> Also I'm missing even few celluloid dropouts in the whole video. > But this does not rule out progressive digital video. There was no digital video in 1982. -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".
Re: [FFmpeg-user] Meaning of ffprobe output
Hi Carl Eugen, Am 03.02.19 um 14:06 schrieb Carl Eugen Hoyos: >>> Second: >>> libx264 does support interlaced encoding (but not field > (It appears as if you didn't read this sentence: It does not > mean "you can feed anything into libx264, it will somehow > deal with it", it means "libx264 does support interlaced > encoding") I read it, but I must admit, that I didn't really understand what field encoding is in comparison to interlaced encoding. For me it's ok to close that discussion here. You did a lot of effort to explain me many details, much thanks for that. I can live with the remaining unclarity. Have a good Sunday, -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".
Re: [FFmpeg-user] Meaning of ffprobe output
2019-02-03 16:31 GMT+01:00, Ulf Zibis : > Also I'm missing even few celluloid dropouts in the whole video. But this does not rule out progressive digital video. Carl Eugen ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
Am 03.02.19 um 13:56 schrieb Carl Eugen Hoyos: >> Otherwise I can't explain the comb artefacts at some >> areas. > I don't really see them, I see many artefacts. I have marked what I interpret as comb artefacts in the attachment. Also I'm missing even few celluloid dropouts in the whole video. -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".
Re: [FFmpeg-user] Meaning of ffprobe output
2019-02-02 21:22 GMT+01:00, Ulf Zibis : > > Am 02.02.19 um 02:18 schrieb Carl Eugen Hoyos: >> Second: >> libx264 does support interlaced encoding (but not field (It appears as if you didn't read this sentence: It does not mean "you can feed anything into libx264, it will somehow deal with it", it means "libx264 does support interlaced encoding") >> 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. libx264 was by far the most advanced encoder until a very short time ago and is still among the best encoders available, of course it supports interlaced encoding, as explicitly stated above. It does not support field-encoding but as said, this - according to the x264 developers - doesn't help anyway. (The H.264 specification identifies two different methods for encoding interlaced video.) Carl Eugen ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
2019-02-02 20:32 GMT+01:00, Ulf Zibis : > > Am 02.02.19 um 19:27 schrieb Ulf Zibis: >> But if I have a interlaced encoded stream with interlaced content, I >> guess only both steps at same time ensure to get a progressive stream >> with good visual quality. > > For this case I see 2 options. Assume we have a 25 fps top first > interlaced encoded stream with interlaced content: > > 1. Use one of the plenty given de-interlace filters, > remove the interlaced flag These two things are less related than what your wording implies (and all SD DVB transmissions where we live show this flag, even for progressive content, so the flag has very little relevance imo). > and result in a 25 fps progressive stream. This implies that every interlaced stream is 50i, this is not the case. > 2. Duplicate each frame and in the duplicate replace the top field with > the top field of the succeeding frame, remove the interlaced flag and > result in a 50 fps progressive stream, where only half of the lines are > changed from frame to frame. > > The 1st method more or less suffers from the known de-interlacing > artefacts. > The 2nd would fully keep the advantages of the old CRT > display method. No, this is not how it works. Carl Eugen ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
2019-02-02 19:27 GMT+01:00, Ulf Zibis : > > Am 02.02.19 um 18:38 schrieb Carl Eugen Hoyos: >> 2019-02-01 23:46 GMT+01:00, Ulf Zibis : >>> Am 30.01.19 um 15:08 schrieb Carl Eugen Hoyos: Without interpolation, this is what all video players do if you disable all de-interlacing. The problem is what kind of "interpolation" you use, this is called de-interlacing, an endless number of algorithms exist. >>> OK, my understandig was, "de-interlacing" means to re-encode from >>> interlaced to progressive _and_ do some interpolation or whatever stuff. >> No, these are two completely independent operations, one of which >> hast nothing to do with de-interlacing. > > Correct. I wanted to say, that I was in error with my former understanding. > > But if I have a interlaced encoded stream with interlaced content, I > guess only both steps at same time ensure to get a progressive stream > with good visual quality. No, this is simply not correct / a misunderstanding. The two "steps" are not related in the way your wording implies. Carl Eugen ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
2019-02-03 11:58 GMT+01:00, Ulf Zibis : > > Am 01.02.19 um 20:00 schrieb Carl Eugen Hoyos: >>> But for the rest of the video, I'm wondering that I nowhere notice such >>> dropouts. IIRC I read, that the film was produced with a budget of >>> 20.000 DM, which IMHO is not enough for a 76 min. celluloid film. >>> >>> Additionally in the turning camera scene from 2:34 I see comb >>> artifacts, which are typical for interlaced video recordings (see >>> attached extractions). >> Definitely not interlaced (could be de-interlaced, but this doesn't >> make much difference because of the other visual issues). > > Would you agree, that the original master recording probably was an > analogue interlaced video tape, maybe early Betacam or high quality > VHS camera, but later processed somehow, what corrupted the > original interlaced content? I cannot rule that out although I find progressive recording more likely. > Otherwise I can't explain the comb artefacts at some > areas. I don't really see them, I see many artefacts. Please lets agree on two things: (In general) you cannot output interlaced video like it worked on CRT TVs until (at least) the eighties. It just doesn't work, no matter if you claim it could work for a fourth time in this thread or not (not even with a CRT computer screen). (Specifically for your file) you may be able to improve quality with denoise filters (and possibly other filters) but this is in no way related to the video being de-interlaced or not. Carl Eugen ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
Am 01.02.19 um 20:00 schrieb Carl Eugen Hoyos: >> But for the rest of the video, I'm wondering that I nowhere notice such >> dropouts. IIRC I read, that the film was produced with a budget of >> 20.000 DM, which IMHO is not enough for a 76 min. celluloid film. >> >> Additionally in the turning camera scene from 2:34 I see comb >> artifacts, which are typical for interlaced video recordings (see >> attached extractions). > Definitely not interlaced (could be de-interlaced, but this doesn't > make much difference because of the other visual issues). Would you agree, that the original master recording probably was an analogue interlaced video tape, maybe early Betacam or high quality VHS camera, but later processed somehow, what corrupted the original interlaced content? Otherwise I can't explain the comb artefacts at some areas. -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".
Re: [FFmpeg-user] Meaning of ffprobe output
Am 11.01.19 um 01:47 schrieb Carl Eugen Hoyos: > 2019-01-11 0:39 GMT+01:00, Ulf Zibis : > >> can anybody explain me the data of ffprobe, I don't find enough hints in >> the docu. E.g.: >> $ ffprobe CYD_copy.vob >> Input #0, mpeg, from 'CYD_copy.vob': >> Duration: 01:16:20.74, start: 0.50, bitrate: 7068 kb/s >> Stream #0:0[0x80]: Audio: ac3, 48000 Hz, stereo, fltp, 256 kb/s >> Stream #0:1[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, bt470bg, >> top first), 704x576 [SAR 12:11 DAR 4:3], 25 fps, 25 tbr, 90k tbn, 50 tbc >> What is: >> tv >> bt470bg > Colour-space related information. From the experience with this thread, I see, I would have better additionally asked ... So I additionally ask, what is the meaning of: - the p in yuv420p - top first -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".
Re: [FFmpeg-user] Meaning of ffprobe output
Hi Moritz, Am 02.02.19 um 22:29 schrieb Moritz Barsnick: > You can always "up-convert" your colorspace before cropping, and > "down-convert" afterwards: > $ ffmpeg [...] -vf format=yuv444p,crop=h=1:...,format=yuv420p [...] > or something like this. Much thank for this hack ... it works! For the record, it's enough to upsample to yuv422p for cropping single horizontal lines. yuv444p would be needed for cropping single vertical columns. - 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".
Re: [FFmpeg-user] Meaning of ffprobe output
On Sat, Feb 02, 2019 at 21:22:03 +0100, Ulf Zibis wrote: > 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. You can always "up-convert" your colorspace before cropping, and "down-convert" afterwards: $ ffmpeg [...] -vf format=yuv444p,crop=h=1:...,format=yuv420p [...] or something like this. (I don't know if it's technically impossible to crop a yuv420p to an uneven number of lines, or just not desired. The color information for that one single line does exist...) Moritz ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
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 ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
Am 02.02.19 um 19:27 schrieb Ulf Zibis:
> But if I have a interlaced encoded stream with interlaced content, I
> guess only both steps at same time ensure to get a progressive stream
> with good visual quality.
For this case I see 2 options. Assume we have a 25 fps top first
interlaced encoded stream with interlaced content:
1. Use one of the plenty given de-interlace filters, remove the
interlaced flag and result in a 25 fps progressive stream.
2. Duplicate each frame and in the duplicate replace the top field with
the top field of the succeeding frame, remove the interlaced flag and
result in a 50 fps progressive stream, where only half of the lines are
changed from frame to frame.
The 1st method more or less suffers from the known de-interlacing
artefacts. The 2nd would fully keep the advantages of the old CRT
display method.
The 2nd method doubles the bit rate of the raw stream, but I believe,
when it comes to compression, the encoder could profit from the
successive lines with same content, so the encoded result may have the
same bit rate by equal quality for both ("de-interlace") methods.
The 2nd method is, what a software player could do with a valid
interlaced encoded stream with interlaced content and then feed the
display controller with such a 50 fps stream for the presentation on a
progressive LCD/LED display.
Is that too sophisticated rocket science?
-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".
Re: [FFmpeg-user] Meaning of ffprobe output
Am 02.02.19 um 18:38 schrieb Carl Eugen Hoyos: > 2019-02-01 23:46 GMT+01:00, Ulf Zibis : >> Am 30.01.19 um 15:08 schrieb Carl Eugen Hoyos: >>> Without interpolation, this is what all video players do if you disable >>> all de-interlacing. >>> The problem is what kind of "interpolation" you use, this is called >>> de-interlacing, an endless number of algorithms exist. >> OK, my understandig was, "de-interlacing" means to re-encode from >> interlaced to progressive _and_ do some interpolation or whatever stuff. > No, these are two completely independent operations, one of which > hast nothing to do with de-interlacing. Correct. I wanted to say, that I was in error with my former understanding. But if I have a interlaced encoded stream with interlaced content, I guess only both steps at same time ensure to get a progressive stream with good visual quality. If I have material, where only one of the steps have been done, to make up leeway the missing step should be a good idea. In my case, where the content seems more or less de-interlaced progressive, it should be good to remove the interlace encoding, but nothing more. This seems to be done automatically when transcoding the interlaced encoded vob stream to a mp4 stream with libx264, as the input stream is marked with "top first", but not the output stream. Please correct me if I'm wrong. -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".
Re: [FFmpeg-user] Meaning of ffprobe output
2019-02-01 23:46 GMT+01:00, Ulf Zibis : > > Am 30.01.19 um 15:08 schrieb Carl Eugen Hoyos: >> Without interpolation, this is what all video players do if you disable >> all de-interlacing. >> The problem is what kind of "interpolation" you use, this is called >> de-interlacing, an endless number of algorithms exist. > > OK, my understandig was, "de-interlacing" means to re-encode from > interlaced to progressive _and_ do some interpolation or whatever stuff. No, these are two completely independent operations, one of which hast nothing to do with de-interlacing. Carl Eugen ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
Sorry for top posting, I can’t figure out how to preserve the formatting while editing from the bottom with this Yahoo Mail mobile editor... “OK, my understandig was, "de-interlacing" means to re-encode from interlaced to progressive _and_ do some interpolation or whatever stuff.” Not entirely but you got the gist of it IMO. My highly ignorant and barely researched understanding: Some de-interlacers alternate fields (e.g. top/bottom) on each frame while discarding the other field and then interpolate the missing lines information for the frame directly from the single half-frame field to eliminate inter-field interpolation motion jitter/judder, but increasing the image and motion noise in the fixed-frame-rate process of alternating fields that don’t time-align or spatially align with each other as they alternate, some ignore the same field (e.g. top) entirely on every frame and then interpolate the missing information from the single field to also eliminate the alternating field judder (while reducing the vertical resolution by half), some create all estimated frames with interpolation between a set of two (or more) fields for less motion blur but also with some loss of motion and image accuracy overall because they algorithmically detect moving objects in the frame and move objects around on the frame in the process of trying to merge the moving objects from the fields without smearing the relatively motionless or disjointedly moving (camera motion) background, some blend the information in the two fields into a single frame without interpolating much but the background motion and merely de-noise the resulting jaggies on detected moving objects with a filter, or maybe I got the interpolation and blending backwards in this case. Dunno... not expert... some do interpolation and/or filtering/blending from prior/successive fields to double the frame rate so there’s an output frame for every input field and the motion plus image is as accurately preserved as possible because it updates with every successive field like a true interlaced display does... then also maybe before de-interlacing there is pull-up or pull-down needed to undo a prior interlaced frame rate conversion between PAL and NTSC... then there’s the added complexity of making sure that your processing gets the order of the fields correct, because everything gets scrambled if you start your first frame with the top field but your source video starts with the bottom field... and if there was prior clumsy editing with inadequate tools too plus maybe an interlaced pull-up or pull-down frame rate conversion you might find the field order of your source reversing in mid-video and needing to re-align your de-interlacer and/or pull-up/pull-down to the fields in your source automagically or manually... I don’t have a clear understanding because I’m not a video expert but if you look it up you can find more info. I probably misunderstood and poorly described lots of details. All I really know for sure is... They don’t all just use variations on fancy math to interpolate a frame from two discrete interlaced fields. The actual method of selecting the input data to be interpolated from varies too depending on whether motion, clarity, judder, processing speed, etc. is more important, and whether the frame rate has already been converted by prior ugly interlaced processing. I only have familiarity from Handbrake, an older version from Ubuntu 12.04 or prior that still had the external processing filters available for pull-down and special effects etc. Some of my source material was European and I tried my best to undo the pre-existing interlaced pull-up scrambling from PAL to NTSC without guidance from an expert or proper tools. My understanding is incomplete as was my tool set and so were my results. YADIF seemed to work the best for me and the pull-down from NTSC to progressive never quite worked right on some sources because of the pre-existing pull-up from PAL to NTSC that I had no filter to undo completely, so there was still residual judder I couldn’t remove. Overall though the output result was smoother and clearer than was the source when played back on a progressive display without de-interlacing. If you need help selecting or tuning a method, you will need to do some reading or you won’t understand what the experts are trying to tell you. I’ve done some of this conversion to store progressive scan on my media server and I probably wouldn’t understand the function better either without more reading. Those who know the FFT math are probably rolling their eyes at my hand-waving attempt to explain math I don’t know. Ask an expert directly for more help understanding if you need more guidance. You can also experiment with the VLC media player de-interlacing menu options to visually compare the result by switching methods on the fly in real time or doing side-by-side playback on two instances of
Re: [FFmpeg-user] Meaning of ffprobe output
2019-02-02 0:43 GMT+01:00, Ulf Zibis : > > Am 01.02.19 um 23:25 schrieb Carl Eugen Hoyos: >> 2019-02-01 23:14 GMT+01:00, Ulf Zibis : >>> 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). ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
Am 01.02.19 um 20:00 schrieb Carl Eugen Hoyos: > Yes, this is correct, yadif is able to nicely remove the interlace > artefacts but I believe it leads to even more distortions in the > rest of the video. This matches to my experience. The best result I got was simply using the atadenoise filter. -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".
Re: [FFmpeg-user] Meaning of ffprobe output
Am 01.02.19 um 23:25 schrieb Carl Eugen Hoyos: > 2019-02-01 23:14 GMT+01:00, Ulf Zibis : >> 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? 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? 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? >> 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? Concerning my example I know, that I can use the fillborders filter, but what to do if I want to do some other work with a single line? -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".
Re: [FFmpeg-user] Meaning of ffprobe output
Am 30.01.19 um 15:08 schrieb Carl Eugen Hoyos: > Without interpolation, this is what all video players do if you disable > all de-interlacing. > The problem is what kind of "interpolation" you use, this is called > de-interlacing, an endless number of algorithms exist. OK, my understandig was, "de-interlacing" means to re-encode from interlaced to progressive _and_ do some interpolation or whatever stuff. -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".
Re: [FFmpeg-user] Meaning of ffprobe output
2019-02-01 23:14 GMT+01:00, Ulf Zibis : > Am 31.01.19 um 13:48 schrieb Carl Eugen Hoyos: >> DVD recorders can only produce interlaced files if the input >> was interlaced, in this specific case, a file with progressive >> content was produced (from progressive original). >> >> (Above of course only applies to the content of the file, >> not the encoding. But when talking about de-interlacing >> and the idet filter, only the content is relevant.) > > 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.) > 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. Carl Eugen ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
Hi, again to my initial question ... Am 31.01.19 um 13:48 schrieb Carl Eugen Hoyos: > DVD recorders can only produce interlaced files if the input > was interlaced, in this specific case, a file with progressive > content was produced (from progressive original). > > (Above of course only applies to the content of the file, > not the encoding. But when talking about de-interlacing > and the idet filter, only the content is relevant.) 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 :-( If it is encoded interlaced, I can understand, that only a pair of lines can be cropped. I tried to crop a single line, but got an error: $ ffmpeg -i CYD_6m_copy.vob -movflags faststart -vf "split[in1][in2];[in1]crop=in_w:1:0:1[top];[in2]crop=in_w:in_h-1:0:1[main];[top][main] vstack" -c:v libx264 -c:a copy CYD_6m_crop+copy-1l_H.264.mp4 ffmpeg version 4.1-static https://johnvansickle.com/ffmpeg/ Copyright (c) 2000-2018 the FFmpeg developers built with gcc 6.3.0 (Debian 6.3.0-18+deb9u1) 20170516 [] Input #0, mpeg, from 'CYD_6m_copy.vob': Duration: 00:06:00.62, start: 0.50, bitrate: 7022 kb/s Stream #0:0[0x80]: Audio: ac3, 48000 Hz, stereo, fltp, 256 kb/s Stream #0:1[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, bt470bg, top first), 704x576 [SAR 12:11 DAR 4:3], 25 fps, 25 tbr, 90k tbn, 50 tbc Stream mapping: Stream #0:1 -> #0:0 (mpeg2video (native) -> h264 (libx264)) Stream #0:0 -> #0:1 (copy) Press [q] to stop, [?] for help [Parsed_crop_1 @ 0x714df40] Invalid too big or non positive size for width '704' or height '0' [Parsed_crop_1 @ 0x714df40] Failed to configure input pad on Parsed_crop_1 Error reinitializing filters! Failed to inject frame into filter network: Invalid argument Error while processing the decoded data for stream #0:1 What does it mean, that ffmpeg (ffprobe as same) says "top first"? Does it mean, that my video is encoded interlaced? If the content of my video is progressive, IHMO it would not harm to re-encode it progressive, so I can crop single lines. How can I do this? -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".
Re: [FFmpeg-user] Meaning of ffprobe output
2019-02-01 19:40 GMT+01:00, Ulf Zibis : > Am 31.01.19 um 00:18 schrieb Carl Eugen Hoyos: >> This masterpiece (make sure you don't miss the imdb comment) >> was most likely made with a film camera that knew nothing about >> interlacing. > > I'm sure this is true at least for the opening credits, as there are > flashing dropouts, typical for celluloid films. So here the > masterpiece has progressive content, was telecined and in the > end copied to VHS with interlaced signal. Yes, this is correct, yadif is able to nicely remove the interlace artefacts but I believe it leads to even more distortions in the rest of the video. > But for the rest of the video, I'm wondering that I nowhere notice such > dropouts. IIRC I read, that the film was produced with a budget of > 20.000 DM, which IMHO is not enough for a 76 min. celluloid film. > Additionally in the turning camera scene from 2:34 I see comb > artifacts, which are typical for interlaced video recordings (see > attached extractions). Definitely not interlaced (could be de-interlaced, but this doesn't make much difference because of the other visual issues). Carl Eugen ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
Hi again, Am 31.01.19 um 00:18 schrieb Carl Eugen Hoyos: > This masterpiece (make sure you don't miss the imdb comment) > was most likely made with a film camera that knew nothing about > interlacing. I'm sure this is true at least for the opening credits, as there are flashing dropouts, typical for celluloid films. So here the masterpiece has progressive content, was telecined and in the end copied to VHS with interlaced signal. But for the rest of the video, I'm wondering that I nowhere notice such dropouts. IIRC I read, that the film was produced with a budget of 20.000 DM, which IMHO is not enough for a 76 min. celluloid film. Additionally in the turning camera scene from 2:34 I see comb artifacts, which are typical for interlaced video recordings (see attached extractions). > The artefacts you see are afaict the result of the VHS drums not > being able to keep 100% synchronization, This I would agree! > Please avoid top-posting here, Carl Eugen Sorry, what you mean by that? -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".
Re: [FFmpeg-user] Meaning of ffprobe output
2019-01-31 6:46 GMT+01:00, Carl Zwanzig : > On 1/30/2019 12:23 PM, Carl Eugen Hoyos wrote: >> this is not about the "signal" that is of >> course interlaced for analog PAL but the content that >> may of may not be interlaced (and the idet filter only >> looks at the content and nothing in FFmpeg is able to >> look at an analog video signal). > > Agreed. I mention it simply because AFAIK DVD > recorders converting from analog will almost always > produce interlaced files. DVD recorders can only produce interlaced files if the input was interlaced, in this specific case, a file with progressive content was produced (from progressive original). (Above of course only applies to the content of the file, not the encoding. But when talking about de-interlacing and the idet filter, only the content is relevant.) Carl Eugen ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
On 1/30/2019 12:23 PM, Carl Eugen Hoyos wrote: this is not about the "signal" that is of course interlaced for analog PAL but the content that may of may not be interlaced (and the idet filter only looks at the content and nothing in FFmpeg is able to look at an analog video signal). Agreed. I mention it simply because AFAIK DVD recorders converting from analog will almost always produce interlaced files. However, more important is that the entire process of converting analog tapes to digital is full of pits and perils, and the conversion artifacts will play hob with any processing (like de-interlacing). The best route, of course, is to capture into a lossless format and process from there. May not help the OP. Later, z! who has some U-Matic tapes to ingest sometime Really Soon Now ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
2019-01-31 0:20 GMT+01:00, Lou Logan : > On Mon, Jan 28, 2019, at 6:58 PM, Carl Eugen Hoyos wrote: >> >> (So apparently the next sentence is wrong and Lou >> does offer release support - but unfortunately only >> to you because he closed ticket #7697 this week >> explaining there is no release support...) > > I don't quite follow your paragraph, but I never > said "I offer release support". I know but that's how Ulf interpreted your message: https://trac.ffmpeg.org/ticket/7623#comment:5 (Sorry: When I answered I didn't bother to check, I simply trusted his interpretation.) Carl Eugen ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
2019-01-31 0:18 GMT+01:00, Carl Eugen Hoyos : > 2019-01-30 23:55 GMT+01:00, Ulf Zibis : > >> here you find the rip from dvd::rip and the result from ffmpeg: >> https://c.1und1.de/@519472591769967166/-XGssZrBRCiT0J4xQUU1LA > > This masterpiece (make sure you don't miss the imdb comment) > was most likely made with a film camera that knew nothing about > interlacing. > The artefacts you see are afaict the result of the VHS drums not more likely: "VHS heads" > being able to keep 100% synchronization, filters that increase the > quality likely exist but this is definitely not my area. > I guess you should search for a specific AviSynth filter. > > Please avoid top-posting here, Carl Eugen ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
On Mon, Jan 28, 2019, at 6:58 PM, Carl Eugen Hoyos wrote: > > (So apparently the next sentence is wrong and Lou > does offer release support - but unfortunately only > to you because he closed ticket #7697 this week > explaining there is no release support...) I don't quite follow your paragraph, but I never said "I offer release support". ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
2019-01-30 23:55 GMT+01:00, Ulf Zibis : > here you find the rip from dvd::rip and the result from ffmpeg: > https://c.1und1.de/@519472591769967166/-XGssZrBRCiT0J4xQUU1LA This masterpiece (make sure you don't miss the imdb comment) was most likely made with a film camera that knew nothing about interlacing. The artefacts you see are afaict the result of the VHS drums not being able to keep 100% synchronization, filters that increase the quality likely exist but this is definitely not my area. I guess you should search for a specific AviSynth filter. Please avoid top-posting here, Carl Eugen ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
Hi, here you find the rip from dvd::rip and the result from ffmpeg: https://c.1und1.de/@519472591769967166/-XGssZrBRCiT0J4xQUU1LA I'm curious, what you find out, Ulf Am 29.01.19 um 21:47 schrieb Carl Eugen Hoyos: > 2019-01-29 20:50 GMT+01:00, Ulf Zibis : >> If you want I could upload a 6 min. chunk with 300 MB. > Just post a link, there are issues with 10G samples > (that could not easily be made smaller). > > Carl Eugen > ___ > 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". ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
2019-01-30 18:27 GMT+01:00, Carl Zwanzig : > On 1/30/2019 6:12 AM, Carl Eugen Hoyos wrote: >> You may have forgotten that while the vertical resolution is kept, >> horizontal resolution is reduced significantly for VHS, likely >> confusing the algorithm for detection of interlaced content. > > Exactly, VHS only has bandwidth of ~3MHz, so a horizontal > resolution of ~240 TV lines (not pixels). There can also be > a -lot- of variable horizontal smearing (plus other artifacts). > AFAIK all VHS players produce an interlaced signal Of course (and what you write is correct to the best of my knowledge) but please note that - at least as far as I am concerned - this is not about the "signal" that is of course interlaced for analog PAL but the content that may of may not be interlaced (and the idet filter only looks at the content and nothing in FFmpeg is able to look at an analog video signal). Carl Eugen ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
On 1/30/2019 6:12 AM, Carl Eugen Hoyos wrote: You may have forgotten that while the vertical resolution is kept, horizontal resolution is reduced significantly for VHS, likely confusing the algorithm for detection of interlaced content. Exactly, VHS only has bandwidth of ~3MHz, so a horizontal resolution of ~240 TV lines (not pixels). There can also be a -lot- of variable horizontal smearing (plus other artifacts). AFAIK all VHS players produce an interlaced signal, composite and optionally S-video; the concept of "progressive scan" does not apply to an analog video signal. There are many pages about capturing analog recordings- going from one lossy format (analog VHS) to another (DVD/mpeg) will not generally yield good results. z! ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
2019-01-29 20:50 GMT+01:00, Ulf Zibis : > My understanding is, that a VHS cassette player always > provides a fully interlaced analogue stream (50 half-frames > per sec. for PAL). You may have forgotten that while the vertical resolution is kept, horizontal resolution is reduced significantly for VHS, likely confusing the algorithm for detection of interlaced content. Carl Eugen ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
2019-01-30 1:26 GMT+01:00, Ulf Zibis :
> In my POV deinterlacing ("classic") is to buffer and optionally somehow
> interpolate the content of the "before half-frame" and add it to the
> current half-frame, so the display content only changes *25 times per
> sec.*. But with the method I outlined, the display content (partly, only
> each 2nd line) would change *50 times per sec.*. The deinterlacing
> then happens in the viewers eye.
Without interpolation, this is what all video players do if you disable
all de-interlacing.
The problem is what kind of "interpolation" you use, this is called
de-interlacing, an endless number of algorithms exist.
Carl Eugen
___
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".
Re: [FFmpeg-user] Meaning of ffprobe output
Hi Carl Eugen, Am 29.01.19 um 22:14 schrieb Carl Eugen Hoyos: > > Are you both sure that the DVD recorder is able to record something > from analog signal that can be de-interlaced? I am curious... Do you ask if it is possible/thinkable, that the resulting DVD contains an already de-interlaced stream *or* that this stream is still interlaced but "can be de-interlaced" later by the reading software? -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".
Re: [FFmpeg-user] Meaning of ffprobe output
Am 29.01.19 um 02:31 schrieb Ulf Zibis:
> Am 29.01.19 um 01:32 schrieb Moritz Barsnick:
>> On Mon, Jan 28, 2019 at 22:52:38 +0100, Ulf Zibis wrote:
LEDs and LCDs would give you headaches if they displayed alternating
lines, as the "afterglow" effect of CRTs, retaining the line's content, is
not present.
>>> If each 2nd line would be empty (black) you may be right, but if the
>>> intermediate lines are filled with the content of the before frame, you
>>> have the "afterglow" effect perfectly simulated also on LCD and LED.
>> Buffering the content of the "before frame" to leave it displayed while
>> the current frame provides every other line is certainly something I
>> would call classic "deinterlacing": You are describing a display which
>> first takes both fields of a frame and combines them to a progressive
>> one.
> Yes, the software video player could transform the 25 fps interlaced
> stream to a 50 fps progressive stream as I described to feed the
> display. Then there would be no visual quality loss as known from
> deinterlacing algorithms like "weave", comparable to the quality of a
> interlaced CRT.
I think, I must correct my statement.
In my POV deinterlacing ("classic") is to buffer and optionally somehow
interpolate the content of the "before half-frame" and add it to the
current half-frame, so the display content only changes *25 times per
sec.*. But with the method I outlined, the display content (partly, only
each 2nd line) would change *50 times per sec.*. The deinterlacing then
happens in the viewers eye.
The from the software player composed stream with 50 fps than feeds the
video controller (graphics card on PC), not the display directly, which
calculates the signal for the real display according to the display's
refresh rate.
I think, this would not be rocket science and it would not wonder me, if
software like VLC really does this.
-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".
Re: [FFmpeg-user] Meaning of ffprobe output
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=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".
Re: [FFmpeg-user] Meaning of ffprobe output
On 1/29/2019 1:16 PM, Eric Wilde wrote: My understanding of at least one VHS protection scheme was to record the video with the horizontal/vertical sync pulses set very low to the threshold for detection. The idea was that, if you made a copy, which was lossy, the copy would not have detectable sync pulses and the picture would appear scrambled. That fits my memory, too. There was also macrovision, which IIRC added extra analog pulses to mess with the recorder's AGC circuits. Been a long time since I've thought about this. I'm not sure how a DVD recorder would detect this, as opposed to a VHS recording that was just of poor quality. But, if you suspect that to be the case, you could certainly confirm it with a scope on the output of the VHS player. Digital capture of any analog tape source, especially VHS, without at least a proc-amp (TBC would be better) in line will give rather-less-than-optimal results. Capturing the composite signal just compounds the problems (as opposed to using Y/C or component). z! ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
At 09:48 PM 1/29/2019 +0100, you wrote:
> 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.
My understanding of at least one VHS protection scheme was to record
the video with the horizontal/vertical sync pulses set very low to the
threshold for detection. The idea was that, if you made a copy, which
was lossy, the copy would not have detectable sync pulses and the
picture would appear scrambled.
I'm not sure how a DVD recorder would detect this, as opposed to a
VHS recording that was just of poor quality. But, if you suspect that
to be the case, you could certainly confirm it with a scope on the
output of the VHS player. For reference, a VHS tape of good quality
should give you typical voltage levels.
Eric
___
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".
Re: [FFmpeg-user] Meaning of ffprobe output
2019-01-29 21:48 GMT+01:00, Moritz Barsnick : > Moin Ulf, > > On Tue, Jan 29, 2019 at 20:50:25 +0100, Ulf Zibis wrote: > >> My understanding is, that a VHS cassette player always provides a fully >> interlaced analogue stream (50 half-frames per sec. for PAL). > > Originally coming from the analog world, I can confirm that this is > true. But depending on what the material actually is, 50 pal half-frames are indistinguishable from progressive video. Are you both sure that the DVD recorder is able to record something from analog signal that can be de-interlaced? I am curious... Carl Eugen ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
Moin Ulf,
On Tue, Jan 29, 2019 at 20:50:25 +0100, Ulf Zibis wrote:
> My understanding is, that a VHS cassette player always provides a fully
> interlaced analogue stream (50 half-frames per sec. for PAL).
Originally coming from the analog world, I can confirm that this is
true.
> With this a DVD recorder has two options, (1) a interlaced vob stream
> or (2) a deinterlaced progressive vob stream. Why should it create a
> mixed stream?
I agree.
> 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.
> It seems to me, a 25 fps interlaced stream has 25 frames per sec., each
> with 2 fields, top and bottom (50 fields per sec. in total) and a 25 fps
> progressive stream has 25 frames per sec., each with 1 field.
> So my video with "TFF: 36759 BFF: 19705 Progressive: 58193
> Undetermined: 27" has 36759*2+19705*2+58193+27 = 171148 fields in
> total, partly half, partly full ones. But idet says: "Repeated Fields:
> Neither:114683 Top: 1 Bottom: 0"
>
> Can you please help me to understand this?
(I hate the concept of interlaced digital video, BTW.)
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.
> 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.
> What is vfr and cfr?
Variable vs. constant frame rate. (Smart phone cameras *tend* to record
VFR, as do some webcams which adapt frame rates to lighting conditions.
Other examples exist.)
Cheers and Gruß,
Moritz
___
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".
Re: [FFmpeg-user] Meaning of ffprobe output
2019-01-29 20:50 GMT+01:00, Ulf Zibis : > If you want I could upload a 6 min. chunk with 300 MB. Just post a link, there are issues with 10G samples (that could not easily be made smaller). Carl Eugen ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
Hi Carl Eugen, thanks again for your patience. Am 29.01.19 um 04:58 schrieb Carl Eugen Hoyos: > > (So apparently the next sentence is wrong and Lou > does offer release support - but unfortunately only > to you because he closed ticket #7697 this week > explaining there is no release support...) OK, but I see 2 differences: The user referred the more old version 3.4.4 compared to 4.1 I use and a segmentation fault is another class of problem than interlace analysis data. > The release version contains more known bugs (and there > are indications that it contains more unknown bugs) and > less features than current git head and there is no release > support on this mailing list. So for each post a new day I have to download and install a new git build with the risk, of slightly different results each day? [Parsed_idet_0 @ 0x6e71900] Single frame detection: TFF: 18738 BFF: 12770 Progressive: 42496 Undetermined: 40680 [Parsed_idet_0 @ 0x6e71900] Multi frame detection: TFF: 36759 BFF: 19705 Progressive: 58193 Undetermined:27 >>> This is not conclusive, possibly mixed progressive - interlaced or >>> interlaced with many scenes without movement. >>> Visual inspection should clarify. Except ~1 min. at the beginning, the whole video has motion. With visual inspection I can not see something, which would give me clarity. If you want I could upload a 6 min. chunk with 300 MB. >> Does that mean, that my vob stream is partly interlaced and partly >> progressive? >> I guess, TFF means top first frame and BFF bottom first frame, right? >> >> This is weird, as the stream comes from a DVD which was recorded from a >> VHS cassette with a hardware DVD recorder. > This basically explains it: Such material is always low-quality, I > wonder if de-interlacing is possible at all (I don't immediately see > how from a theoretical pov, feel free to prove me wrong). My intention is not to transform to a deinterlaced progressive video. as the interlaced one promises better visual quality, but the mixed one makes me worrying to understand basic things. My intention is to have a video which I can view without a DVD hardware, and which is better compressed than with MPEG-2. Optionally I want to give some effort in filtering some VHS artefacts, see my threads "How to filter VHS cassette artifacts", "How to duplicate 1st line", "Calculating offset of shifted line". It appears, that with "crop" I can't extract and process single lines because of interlaced material, so I came to the idea, to intermediately extract the interlaced fields separately, do the filtering and again compose them back to an interlaced stream. With this in mind I opened this thread, because ffprobe from the vob stream says "yuv420p(tv, bt470bg, top first)", where I interpreted "top first" as an indication, that this is a interlaced stream, but the ffprobe from the transcoded mp4 stream does no more say "top first", so I was wondering if the transcode process automatically does deinterlacing. My understanding is, that a VHS cassette player always provides a fully interlaced analogue stream (50 half-frames per sec. for PAL). With this a DVD recorder has two options, (1) a interlaced vob stream or (2) a deinterlaced progressive vob stream. Why should it create a mixed stream? 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. With dvd::rip (mplayer -dumpstream does the same) I was able to work around the corrupted DVD file system and extract the also corrupted vob stream, which is playable, but with broken time line and with some audio errors. Remuxing this with ffmpeg -c copy repaired this, but the result seems to be a mixture of interlaced and progressive frames. I guess, my problem is, that I do not fully understand the ffmpeg data model for video streams. It seems to me, a 25 fps interlaced stream has 25 frames per sec., each with 2 fields, top and bottom (50 fields per sec. in total) and a 25 fps progressive stream has 25 frames per sec., each with 1 field. So my video with "TFF: 36759 BFF: 19705 Progressive: 58193 Undetermined: 27" has 36759*2+19705*2+58193+27 = 171148 fields in total, partly half, partly full ones. But idet says: "Repeated Fields: Neither:114683 Top: 1 Bottom: 0" Can you please help me to understand this? >> 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. > (Please understand that while I completely understand that you > have
Re: [FFmpeg-user] Meaning of ffprobe output
2019-01-29 2:16 GMT+01:00, Ulf Zibis : > Hi Carl Eugen, > > Am 19.01.19 um 14:02 schrieb Carl Eugen Hoyos: >>> $ ffmpeg -i CYD_copy.vob -vf idet -f null - >>> ffmpeg version 4.1-static https://johnvansickle.com/ffmpeg/ Copyright >> Not supported here! >> >>> (c) 2000-2018 the FFmpeg developers >>> built with gcc 6.3.0 (Debian 6.3.0-18+deb9u1) 20170516 >> Not ok! > This recommendation comes from here: > https://trac.ffmpeg.org/ticket/7623#comment:5 (So apparently the next sentence is wrong and Lou does offer release support - but unfortunately only to you because he closed ticket #7697 this week explaining there is no release support...) > So I used the release version 4.1 from here: > https://johnvansickle.com/ffmpeg/ > in the assumption, that it is more stable as the git build. The release version contains more known bugs (and there are indications that it contains more unknown bugs) and less features than current git head and there is no release support on this mailing list. >>> [Parsed_idet_0 @ 0x6e71900] Repeated Fields: Neither:114683 Top: 1 >>> Bottom: 0 I believe this rules out telecined content. >>> [Parsed_idet_0 @ 0x6e71900] Single frame detection: TFF: 18738 BFF: >>> 12770 Progressive: 42496 Undetermined: 40680 >>> [Parsed_idet_0 @ 0x6e71900] Multi frame detection: TFF: 36759 BFF: 19705 >>> Progressive: 58193 Undetermined:27 >> This is not conclusive, possibly mixed progressive - interlaced or >> interlaced with many scenes without movement. >> Visual inspection should clarify. > Does that mean, that my vob stream is partly interlaced and partly > progressive? > I guess, TFF means top first frame and BFF bottom first frame, right? > > This is weird, as the stream comes from a DVD which was recorded from a > VHS cassette with a hardware DVD recorder. This basically explains it: Such material is always low-quality, I wonder if de-interlacing is possible at all (I don't immediately see how from a theoretical pov, feel free to prove me wrong). > 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 76:27.36 length, but the resulting mp4 with > 114502 frames is 76:20.08. (Please understand that while I completely understand that you have different questions, it is not always easy to remember what issues were already discussed: I am sure you can calculate the number of frames from the duration, the vob file is likely vfr, FFmpeg only support writing cfr to mov, the last status line has more information.) > How can I understand all this? (Independently from your actual converted material that I suspect cannot be improved anyway because of its origin: ) Again, visual inspection is necessary if the output of idet is inconclusive, I tested idet with a random interlaced and a (created) telecined stream and the output looked absolutely conclusive. Mixed interlaced, progressive and telecined video is absolutely possible, depending on the actual content. It could also be that your interlaced input was already encoded, I suspect this can break the detection. Carl Eugen ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
Am 29.01.19 um 01:32 schrieb Moritz Barsnick: > On Mon, Jan 28, 2019 at 22:52:38 +0100, Ulf Zibis wrote: >>> LEDs and LCDs would give you headaches if they displayed alternating lines, >>> as the "afterglow" effect of CRTs, retaining the line's content, is not >>> present. >> If each 2nd line would be empty (black) you may be right, but if the >> intermediate lines are filled with the content of the before frame, you >> have the "afterglow" effect perfectly simulated also on LCD and LED. > Buffering the content of the "before frame" to leave it displayed while > the current frame provides every other line is certainly something I > would call classic "deinterlacing": You are describing a display which > first takes both fields of a frame and combines them to a progressive > one. Yes, the software video player could transform the 25 fps interlaced stream to a 50 fps progressive stream as I described to feed the display. Then there would be no visual quality loss as known from deinterlacing algorithms like "weave", comparable to the quality of a interlaced CRT. -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".
Re: [FFmpeg-user] Meaning of ffprobe output
Hi Carl Eugen, Am 19.01.19 um 14:02 schrieb Carl Eugen Hoyos: >> $ ffmpeg -i CYD_copy.vob -vf idet -f null - >> ffmpeg version 4.1-static https://johnvansickle.com/ffmpeg/ Copyright > Not supported here! > >> (c) 2000-2018 the FFmpeg developers >> built with gcc 6.3.0 (Debian 6.3.0-18+deb9u1) 20170516 > Not ok! This recommendation comes from here: https://trac.ffmpeg.org/ticket/7623#comment:5 So I used the release version 4.1 from here: https://johnvansickle.com/ffmpeg/ in the assumption, that it is more stable as the git build. >> [Parsed_idet_0 @ 0x6e71900] Repeated Fields: Neither:114683 Top: 1 >> Bottom: 0 >> [Parsed_idet_0 @ 0x6e71900] Single frame detection: TFF: 18738 BFF: >> 12770 Progressive: 42496 Undetermined: 40680 >> [Parsed_idet_0 @ 0x6e71900] Multi frame detection: TFF: 36759 BFF: 19705 >> Progressive: 58193 Undetermined:27 > This is not conclusive, possibly mixed progressive - interlaced or > interlaced with many scenes without movement. > Visual inspection should clarify. Does that mean, that my vob stream is partly interlaced and partly progressive? I guess, TFF means top first frame and BFF bottom first frame, right? This is weird, as the stream comes from a DVD which was recorded from a VHS cassette with a hardware DVD recorder. 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 76:27.36 length, but the resulting mp4 with 114502 frames is 76:20.08. How can I understand all this? -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".
Re: [FFmpeg-user] Meaning of ffprobe output
On Mon, Jan 28, 2019 at 22:52:38 +0100, Ulf Zibis wrote: > > LEDs and LCDs would give you headaches if they displayed alternating lines, > > as the "afterglow" effect of CRTs, retaining the line's content, is not > > present. > > If each 2nd line would be empty (black) you may be right, but if the > intermediate lines are filled with the content of the before frame, you > have the "afterglow" effect perfectly simulated also on LCD and LED. Buffering the content of the "before frame" to leave it displayed while the current frame provides every other line is certainly something I would call classic "deinterlacing": You are describing a display which first takes both fields of a frame and combines them to a progressive one. Moritz ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
Am 19.01.19 um 23:29 schrieb Carl Eugen Hoyos: > (I don't see this email) What you mean by that? > This deinterlacing method is called "weave", this is not what CRT's > do (as Moritz explained), most people do not like the results. > (Although some do!) This method results in a 25 fps stream, if the original is a 50 half-frame per sec. stream, but what I mean is to send a 50 fps stream where each 2nd line contains a copy of the proceeding half-frame. Each video controller should be able to work with 50 fps streams. -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".
Re: [FFmpeg-user] Meaning of ffprobe output
Am 19.01.19 um 17:30 schrieb Moritz Barsnick: >> Well, but the software player could send 50 frames per second with >> alternately updating only each 2nd top/bottom line. > It could. But if the display is anything else than an old CRT, it will first > deinterlace internally. Why should it do this? There is nothing to deinterlace it the display is fed with 50 full frames per sec., but with only each 2nd line alternately updated with new data. > LEDs and LCDs would give you headaches if they displayed alternating lines, > as the "afterglow" effect of CRTs, retaining the line's content, is not > present. If each 2nd line would be empty (black) you may be right, but if the intermediate lines are filled with the content of the before frame, you have the "afterglow" effect perfectly simulated also on LCD and LED. -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".
Re: [FFmpeg-user] Meaning of ffprobe output
> On Fri, Jan 18, 2019 at 18:19:05 +0100, Ulf Zibis wrote: >> > (It is simply not possible, you can only send frames to your >> > driver / display.) >> Well, but the software player could send 50 frames per second with >> alternately updating only each 2nd top/bottom line. (I don't see this email) This deinterlacing method is called "weave", this is not what CRT's do (as Moritz explained), most people do not like the results. (Although some do!) Carl Eugen ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
On Fri, Jan 18, 2019 at 18:19:05 +0100, Ulf Zibis wrote: > > (It is simply not possible, you can only send frames to your > > driver / display.) > Well, but the software player could send 50 frames per second with > alternately updating only each 2nd top/bottom line. It could. But if the display is anything else than an old CRT, it will first deinterlace internally. LEDs and LCDs would give you headaches if they displayed alternating lines, as the "afterglow" effect of CRTs, retaining the line's content, is not present. Now, whether your deinterlacer or the display's is to be considered better, is up to you. (In my experience, there's a wide variation in the performance of scalers, both HW and SW. I assume the same is valid for deinterlacers.) But encoding/compressing interlaced content gives me a yucky feeling, I would always prefer encoding deinterlaced. Moritz ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
2019-01-18 18:19 GMT+01:00, Ulf Zibis : > $ ffmpeg -i CYD_copy.vob -vf idet -f null - > ffmpeg version 4.1-static https://johnvansickle.com/ffmpeg/ Copyright Not supported here! > (c) 2000-2018 the FFmpeg developers > built with gcc 6.3.0 (Debian 6.3.0-18+deb9u1) 20170516 > [.] Not ok! [...] > [Parsed_idet_0 @ 0x6e71900] Repeated Fields: Neither:114683 Top: 1 > Bottom: 0 > [Parsed_idet_0 @ 0x6e71900] Single frame detection: TFF: 18738 BFF: > 12770 Progressive: 42496 Undetermined: 40680 > [Parsed_idet_0 @ 0x6e71900] Multi frame detection: TFF: 36759 BFF: 19705 > Progressive: 58193 Undetermined:27 This is not conclusive, possibly mixed progressive - interlaced or interlaced with many scenes without movement. Visual inspection should clarify. Carl Eugen ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
Hi, Am 18.01.19 um 16:44 schrieb Carl Eugen Hoyos: > One possibility is to add "-f null -". Thanks! from the original dvd::rip chunks I get: === $ ffmpeg -i "concat:001-C001/CYD-001.vob|001-C002/CYD-001.vob|001-C003/CYD-001.vob|001-C004/CYD-001.vob|001-C005/CYD-001.vob|001-C006/CYD-001.vob|001-C007/CYD-001.vob|001-C008/CYD-001.vob|001-C009/CYD-001.vob|001-C010/CYD-001.vob|001-C011/CYD-001.vob|001-C012/CYD-001.vob|001-C013/CYD-001.vob|001-C014/CYD-001.vob|001-C015/CYD-001.vob|001-C016/CYD-001.vob|001-C017/CYD-001.vob|001-C018/CYD-001.vob|001-C019/CYD-001.vob|001-C020/CYD-001.vob|001-C021/CYD-001.vob|001-C022/CYD-001.vob|001-C023/CYD-001.vob" -vf idet -f null - [.] Input #0, mpeg, from 'concat:001-C001/CYD-001.vob|001-C002/CYD-001.vob|001-C003/CYD-001.vob|001-C004/CYD-001.vob|001-C005/CYD-001.vob|001-C006/CYD-001.vob|001-C007/CYD-001.vob|001-C008/CYD-001.vob|001-C009/CYD-001.vob|001-C010/CYD-001.vob|001-C011/CYD-001.vob|001-C012/CYD-001.vob|001-C013/CYD-001.vob|001-C014/CYD-001.vob|001-C015/CYD-001.vob|001-C016/CYD-001.vob|001-C017/CYD-001.vob|001-C018/CYD-001.vob|001-C019/CYD-001.vob|001-C020/CYD-001.vob|001-C021/CYD-001.vob|001-C022/CYD-001.vob|001-C023/CYD-001.vob': Duration: 00:01:03.16, start: 0.231578, bitrate: 533831 kb/s Stream #0:0[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, bt470bg, top first), 704x576 [SAR 12:11 DAR 4:3], 25 fps, 25 tbr, 90k tbn, 50 tbc Stream #0:1[0x80]: Audio: ac3, 48000 Hz, stereo, fltp, 256 kb/s Stream mapping: Stream #0:0 -> #0:0 (mpeg2video (native) -> wrapped_avframe (native)) Stream #0:1 -> #0:1 (ac3 (native) -> pcm_s16le (native)) Press [q] to stop, [?] for help Output #0, null, to 'pipe:': Metadata: encoder : Lavf58.20.100 Stream #0:0: Video: wrapped_avframe, yuv420p(top coded first (swapped)), 704x576 [SAR 12:11 DAR 4:3], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc Metadata: encoder : Lavc58.35.100 wrapped_avframe Stream #0:1: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s Metadata: encoder : Lavc58.35.100 pcm_s16le frame=120012 fps=200 q=-0.0 Lsize=N/A time=01:20:00.51 bitrate=N/A speed=7.99x video:62819kB audio:900096kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown [Parsed_idet_0 @ 0x6144800] Repeated Fields: Neither:119990 Top: 11 Bottom: 11 [Parsed_idet_0 @ 0x6144800] Single frame detection: TFF: 19273 BFF: 13254 Progressive: 42498 Undetermined: 44987 [Parsed_idet_0 @ 0x6144800] Multi frame detection: TFF: 41292 BFF: 20428 Progressive: 58193 Undetermined: 99 Note, that there are no warnings like: [null @ 0x6afafc0] Application provided invalid, non monotonically increasing dts to muxer in stream 1: 881664 >= 881664 Also note, that there is "yuv420p(top coded first (swapped))" for the output, which seems to be lost in the remuxing copy from: $ ffmpeg -ss 00:03 -t 01:16:20 -i "concat:001-C001/CYD-001.vob|001-C002/CYD-001.vob|001-C003/CYD-001.vob|001-C004/CYD-001.vob|001-C005/CYD-001.vob|001-C006/CYD-001.vob|001-C007/CYD-001.vob|001-C008/CYD-001.vob|001-C009/CYD-001.vob|001-C010/CYD-001.vob|001-C011/CYD-001.vob|001-C012/CYD-001.vob|001-C013/CYD-001.vob|001-C014/CYD-001.vob|001-C015/CYD-001.vob|001-C016/CYD-001.vob|001-C017/CYD-001.vob|001-C018/CYD-001.vob|001-C019/CYD-001.vob|001-C020/CYD-001.vob|001-C021/CYD-001.vob|001-C022/CYD-001.vob|001-C023/CYD-001.vob" -c copy CYD_copy.vob -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".
Re: [FFmpeg-user] Meaning of ffprobe output
Hi, Am 18.01.19 um 16:44 schrieb Carl Eugen Hoyos: >> You may be right. Technically I don't see an obstacle for a software >> player to feed the video display buffer with 50 half-frames per second, >> as most displays refresh rate is at least 50 per sec. > I do though. > (It is simply not possible, you can only send frames to your > driver / display.) Well, but the software player could send 50 frames per second with alternately updating only each 2nd top/bottom line. > One possibility is to add "-f null -". Thanks! for the input vob I get: === $ ffmpeg -i CYD_copy.vob -vf idet -f null - ffmpeg version 4.1-static https://johnvansickle.com/ffmpeg/ Copyright (c) 2000-2018 the FFmpeg developers built with gcc 6.3.0 (Debian 6.3.0-18+deb9u1) 20170516 [.] Input #0, mpeg, from 'CYD_copy.vob': Duration: 01:16:20.74, start: 0.50, bitrate: 7068 kb/s Stream #0:0[0x80]: Audio: ac3, 48000 Hz, stereo, fltp, 256 kb/s Stream #0:1[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, bt470bg, top first), 704x576 [SAR 12:11 DAR 4:3], 25 fps, 25 tbr, 90k tbn, 50 tbc Stream mapping: Stream #0:1 -> #0:0 (mpeg2video (native) -> wrapped_avframe (native)) Stream #0:0 -> #0:1 (ac3 (native) -> pcm_s16le (native)) Press [q] to stop, [?] for help Output #0, null, to 'pipe:': Metadata: encoder : Lavf58.20.100 Stream #0:0: Video: wrapped_avframe, yuv420p, 704x576 [SAR 12:11 DAR 4:3], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc Metadata: encoder : Lavc58.35.100 wrapped_avframe Stream #0:1: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s Metadata: encoder : Lavc58.35.100 pcm_s16le [null @ 0x6afafc0] Application provided invalid, non monotonically increasing dts to muxer in stream 1: 881664 >= 881664 [null @ 0x6afafc0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 463 >= 463 [null @ 0x6afafc0] Application provided invalid, non monotonically increasing dts to muxer in stream 1: 930816 >= 930816 [null @ 0x6afafc0] Application provided invalid, non monotonically increasing dts to muxer in stream 1: 1732608 >= 1731073 [null @ 0x6afafc0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 906 >= 906 [null @ 0x6afafc0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 909 >= 909 [null @ 0x6afafc0] Application provided invalid, non monotonically increasing dts to muxer in stream 1: 1761792 >= 1761792 [null @ 0x6afafc0] Application provided invalid, non monotonically increasing dts to muxer in stream 1: 1855488 >= 1855488 [null @ 0x6afafc0] Application provided invalid, non monotonically increasing dts to muxer in stream 1: 2941440 >= 2941440 [.] [null @ 0x6afafc0] Application provided invalid, non monotonically increasing dts to muxer in stream 1: 218113536 >= 218113536 [null @ 0x6afafc0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 113606 >= 113606 [null @ 0x6afafc0] Application provided invalid, non monotonically increasing dts to muxer in stream 1: 219217920 >= 219217920 [null @ 0x6afafc0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 114181 >= 114181 frame=114684 fps=114 q=-0.0 Lsize=N/A time=01:16:20.72 bitrate=N/A speed=4.53x video:60030kB audio:860178kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown [Parsed_idet_0 @ 0x6e71900] Repeated Fields: Neither:114683 Top: 1 Bottom: 0 [Parsed_idet_0 @ 0x6e71900] Single frame detection: TFF: 18738 BFF: 12770 Progressive: 42496 Undetermined: 40680 [Parsed_idet_0 @ 0x6e71900] Multi frame detection: TFF: 36759 BFF: 19705 Progressive: 58193 Undetermined: 27 for the output mp4 I get: === $ ffmpeg -i CYD_atadenoise_H.264_mp3-q4.mp4 -vf idet -f null - [.] Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'CYD_atadenoise_H.264_mp3-q4.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf57.83.100 Duration: 01:16:20.42, start: 0.00, bitrate: 1403 kb/s Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 704x576 [SAR 12:11 DAR 4:3], 1276 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default) Metadata: handler_name : VideoHandler Stream #0:1(und): Audio: mp3 (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 119 kb/s (default) Metadata: handler_name : SoundHandler Stream mapping: Stream #0:0 -> #0:0 (h264 (native) -> wrapped_avframe (native)) Stream #0:1 -> #0:1 (mp3 (mp3float) -> pcm_s16le (native)) Press [q] to stop, [?] for help Output #0, null, to 'pipe:': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf58.20.100 Stream #0:0(und): Video: wrapped_avframe, yuv420p, 704x576 [SAR 12:11 DAR 4:3], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc (default)
Re: [FFmpeg-user] Meaning of ffprobe output
2019-01-18 15:58 GMT+01:00, Ulf Zibis : > Am 15.01.19 um 12:54 schrieb Carl Eugen Hoyos: >>> tbn >> This is the container timebase, 90k for mpeg streams. > For what stands 90k? For 90,000 milli seconds? It stands for a timebase of 1/9 >>> Is it 1/9 second? >> I suspect timebase is a fraction and has no unit but I may be wrong. > > Timebase without unit? What does it serve for? > If it's 1/9 h, then it would be equal to 1/25 s, which would > perfectly align with the fps 25 of the file. So it's 1/9 sec. [...] >>> i.e. then the video player is able to write 50 half-frames per >>> second to the output display, which provides better quality >>> than 25 merged progressive frames per second. >> Only (old!) CRTs can do this, so I assume this has no >> relevance here. > > You may be right. Technically I don't see an obstacle for a software > player to feed the video display buffer with 50 half-frames per second, > as most displays refresh rate is at least 50 per sec. I do though. (It is simply not possible, you can only send frames to your driver / display.) >> The "idet" filter can do this. > > I have tried that with: > $ ffmpeg -i CYD_atadenoise_H.264_mp3-q4.mp4 -vf idet > and get: > Trailing options were found on the commandline. > At least one output file must be specified. > > Now I'm confused what to do, as I don't want to create another big file. > How is the correct syntax? One possibility is to add "-f null -". Carl Eugen ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
Hi again, Am 15.01.19 um 12:54 schrieb Carl Eugen Hoyos: >> tbn > This is the container timebase, 90k for mpeg streams. For what stands 90k? For 90,000 milli seconds? >>> It stands for a timebase of 1/9 >> Is it 1/9 second? > I suspect timebase is a fraction and has no unit but I may be wrong. Timebase without unit? What does it serve for? If it's 1/9 h, then it would be equal to 1/25 s, which would perfectly align with the fps 25 of the file. >>> which is the timebase for all mpeg streams (and cannot be changed afaik). >> Do you mean MPEG-2 with "mpeg"? > MPEG program and MPEG transport streams are (also) > defined in the MPEG-2 standard (that also defines > several other things). > >> My MPEG-4 stream has 12800 tbn > Command line and complete, uncut console output missing. I here refer to the output in my post from 2019-01-12 22:32 GMT+01:00 >> i.e. then the video player is able to write 50 half-frames per >> second to the output display, which provides better quality >> than 25 merged progressive frames per second. > Only (old!) CRTs can do this, so I assume this has no > relevance here. You may be right. Technically I don't see an obstacle for a software player to feed the video display buffer with 50 half-frames per second, as most displays refresh rate is at least 50 per sec. > The "idet" filter can do this. I have tried that with: $ ffmpeg -i CYD_atadenoise_H.264_mp3-q4.mp4 -vf idet and get: Trailing options were found on the commandline. At least one output file must be specified. Now I'm confused what to do, as I don't want to create another big file. How is the correct syntax? -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".
Re: [FFmpeg-user] Meaning of ffprobe output
2019-01-15 3:13 GMT+01:00, Ulf Zibis : > Am 13.01.19 um 00:25 schrieb Carl Eugen Hoyos: > tbn This is the container timebase, 90k for mpeg streams. >>> For what stands 90k? For 90,000 milli seconds? >> It stands for a timebase of 1/9 > > Is it 1/9 second? I suspect timebase is a fraction and has no unit but I may be wrong. >> which is the timebase >> for all mpeg streams (and cannot be changed afaik). > Do you mean MPEG-2 with "mpeg"? MPEG program and MPEG transport streams are (also) defined in the MPEG-2 standard (that also defines several other things). > My MPEG-4 stream has > > 12800 tbn Command line and complete, uncut console output missing. [...] libx264 does not support PAFF encoding. >>> What is PAFF? >> H.264 field-encoding, another method of h.264 interlaced >> encoding exists, MBAFF (which is supported by libx264). > > So if I want to retain the interlacing from the vob file, I should use > MBAFF. What is the ffmpeg option for this? Probably "-flags +ilme+ildct" > 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'm interested in that, because I imagine, that it would be better > for the quality to retain the interlacing This is correct: If you use progressive encoding for interlaced content, it either costs (a lot of) quality or bitrate. > i.e. then the video player is able to write 50 half-frames per > second to the output display, which provides better quality > than 25 merged progressive frames per second. Only (old!) CRTs can do this, so I assume this has no relevance here. > Does my assumption hold? > But unfortunately I do not know, if my video (DVD-R recorded from a VHS > cassette) originally was telecined from an analogue celluloid film or > was produced directly on video tape (which should be true interlaced). > Any idea, how I can detect this? The "idet" filter can do this. Carl Eugen ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
Hi, Am 13.01.19 um 00:25 schrieb Carl Eugen Hoyos: tbn >>> This is the container timebase, 90k for mpeg streams. >> For what stands 90k? For 90,000 milli seconds? > It stands for a timebase of 1/9 Is it 1/9 second? > which is the timebase > for all mpeg streams (and cannot be changed afaik). Do you mean MPEG-2 with "mpeg"? My MPEG-4 stream has 12800 tbn >> Does 50 tbc mean, that I still have 50 interlaced half-frames per >> second, or why is the codecs timebase 50? > No, it means that the codec timebase is 1/50. > > (The reason that these answers do not really help you > is that the values are not necessarily meant for you, > they typically have more meaning for developers.) > > [...] > >>> libx264 does not support PAFF encoding. >> What is PAFF? > H.264 field-encoding, another method of h.264 interlaced > encoding exists, MBAFF (which is supported by libx264). So if I want to retain the interlacing from the vob file, I should use MBAFF. What is the ffmpeg option for this? Which is the de-interlacing method, libx264 uses by default? I'm interested in that, because I imagine, that it would be better for the quality to retain the interlacing, i.e. then the video player is able to write 50 half-frames per second to the output display, which provides better quality than 25 merged progressive frames per second. Does my assumption hold? But unfortunately I do not know, if my video (DVD-R recorded from a VHS cassette) originally was telecined from an analogue celluloid film or was produced directly on video tape (which should be true interlaced). Any idea, how I can detect this? It was a low budget production in 1982. -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".
Re: [FFmpeg-user] Meaning of ffprobe output
2019-01-12 22:32 GMT+01:00, Ulf Zibis : > Am 11.01.19 um 01:47 schrieb Carl Eugen Hoyos: >> 2019-01-11 0:39 GMT+01:00, Ulf Zibis : >> >>> tbn >> This is the container timebase, 90k for mpeg streams. > > For what stands 90k? For 90,000 milli seconds? It stands for a timebase of 1/9 which is the timebase for all mpeg streams (and cannot be changed afaik). >>> -movflags +faststart -c copy CYD_copy.vob >> Sadly, output option cannot (easily) be checked for correctness. >> Using options that cannot have an effect may reduce your >> chance to get good help here (consider the increased time it >> needs to understand what's going on / what your intentions are). > > The probably wrong '+' was taken from the example in the Wiki: > https://trac.ffmpeg.org/wiki/Encode/H.264#AdditionalInformationTips > Maybe this is an error? > Because VOB also is coded with MPEG, I thought this flag may have a > positive effect. > Anyway, without the flag I get the same ffprobe data. The option "movflags" can only have an effect for mov (and friends) output, not for mpeg streams. [...] > Does 50 tbc mean, that I still have 50 interlaced half-frames per > second, or why is the codecs timebase 50? No, it means that the codec timebase is 1/50. (The reason that these answers do not really help you is that the values are not necessarily meant for you, they typically have more meaning for developers.) [...] >> libx264 does not support PAFF encoding. > > What is PAFF? H.264 field-encoding, another method of h.264 interlaced encoding exists, MBAFF (which is supported by libx264). Carl Eugen ___ 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".
Re: [FFmpeg-user] Meaning of ffprobe output
Thanks Carl Eugen ...
Am 11.01.19 um 01:47 schrieb Carl Eugen Hoyos:
> 2019-01-11 0:39 GMT+01:00, Ulf Zibis :
>
>> tbn
> This is the container timebase, 90k for mpeg streams.
For what stands 90k? For 90,000 milli seconds?
>> -movflags +faststart -c copy CYD_copy.vob
> Sadly, output option cannot (easily) be checked for correctness.
> Using options that cannot have an effect may reduce your
> chance to get good help here (consider the increased time it
> needs to understand what's going on / what your intentions are).
The probably wrong '+' was taken from the example in the Wiki:
https://trac.ffmpeg.org/wiki/Encode/H.264#AdditionalInformationTips
Maybe this is an error?
Because VOB also is coded with MPEG, I thought this flag may have a
positive effect.
Anyway, without the flag I get the same ffprobe data.
*From:*
$ ffprobe CYD_copy.vob
Input #0, mpeg, from 'CYD_copy.vob':
Duration: 01:16:20.74, start: 0.50, bitrate: 7068 kb/s
Stream #0:0[0x80]: Audio: ac3, 48000 Hz, stereo, fltp, 256 kb/s
Stream #0:1[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, bt470bg,
top first), 704x576 [SAR 12:11 DAR 4:3], 25 fps, 25 tbr, 90k tbn, 50 tbc
*I transcoded with:*
$ ffmpeg -i CYD_copy.vob -movflags +faststart -vf atadenoise -c:v
libx264 -c:a libmp3lame -q:a 4 CYD_atadenoise_H.264.mp4
*and get:*
$ ffprobe CYD_atadenoise_H.264.mp4
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'CYD_atadenoise_H.264_mp3-q4.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf57.83.100
Duration: 01:16:20.42, start: 0.00, bitrate: 1403 kb/s
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p,
704x576 [SAR 12:11 DAR 4:3], 1276 kb/s, 25 fps, 25 tbr, 12800 tbn, 50
tbc (default)
Metadata:
handler_name : VideoHandler
Stream #0:1(und): Audio: mp3 (mp4a / 0x6134706D), 48000 Hz, stereo,
fltp, 119 kb/s (default)
Metadata:
handler_name : SoundHandler
Does 50 tbc mean, that I still have 50 interlaced half-frames per
second, or why is the codecs timebase 50?
Thanks for your comments
-Ulf
> Not necessarily related: "-c copy" cannot change anything
> about fields ("half-frames"),
I didn't expect that, the question was about: -c:v libx264
> libx264 does not support PAFF
> encoding.
What is PAFF?
Thanks in advance
-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".
Re: [FFmpeg-user] Meaning of ffprobe output
2019-01-11 0:39 GMT+01:00, Ulf Zibis :
> can anybody explain me the data of ffprobe, I don't find enough hints in
> the docu. E.g.:
> $ ffprobe CYD_copy.vob
> Input #0, mpeg, from 'CYD_copy.vob':
> Duration: 01:16:20.74, start: 0.50, bitrate: 7068 kb/s
> Stream #0:0[0x80]: Audio: ac3, 48000 Hz, stereo, fltp, 256 kb/s
> Stream #0:1[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, bt470bg,
> top first), 704x576 [SAR 12:11 DAR 4:3], 25 fps, 25 tbr, 90k tbn, 50 tbc
> What is:
> tv
> bt470bg
Colour-space related information.
> tbr
The least common multiple of all framerates in the stream, a guess.
> tbn
This is the container timebase, 90k for mpeg streams.
> tbc
This is the codec timebase.
> I'm also wondering, why Stream #0:1 is the video, as it was created by
> $ ffmpeg -ss 00:03 -t 01:16:20 -i
> "concat:001-C001/CYD-001.vob|001-C002/CYD-001.vob|..."
vob has no stream order, "0:1" simply means "second stream
found be FFmpeg".
> -movflags +faststart -c copy CYD_copy.vob
Sadly, output option cannot (easily) be checked for correctness.
Using options that cannot have an effect may reduce your
chance to get good help here (consider the increased time it
needs to understand what's going on / what your intentions are).
Not necessarily related: "-c copy" cannot change anything
about fields ("half-frames"), libx264 does not support PAFF
encoding.
Carl Eugen
___
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".
[FFmpeg-user] Meaning of ffprobe output
Hi, can anybody explain me the data of ffprobe, I don't find enough hints in the docu. E.g.: $ ffprobe CYD_copy.vob Input #0, mpeg, from 'CYD_copy.vob': Duration: 01:16:20.74, start: 0.50, bitrate: 7068 kb/s Stream #0:0[0x80]: Audio: ac3, 48000 Hz, stereo, fltp, 256 kb/s Stream #0:1[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, bt470bg, top first), 704x576 [SAR 12:11 DAR 4:3], 25 fps, 25 tbr, 90k tbn, 50 tbc What is: tv bt470bg tbr tbn tbc I'm also wondering, why Stream #0:1 is the video, as it was created by $ ffmpeg -ss 00:03 -t 01:16:20 -i "concat:001-C001/CYD-001.vob|001-C002/CYD-001.vob|..." -movflags +faststart -c copy CYD_copy.vob from files like $ ffprobe 001-C001/CYD-001.vob Input #0, mpeg, from '/home/ich/Videos/dvdrip-data/CYD/vob/001-C001/CYD-001.vob': Duration: 00:00:20.41, start: 0.231578, bitrate: 74597 kb/s Stream #0:0[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, bt470bg, top first), 704x576 [SAR 12:11 DAR 4:3], 25 fps, 25 tbr, 90k tbn, 50 tbc Stream #0:1[0x80]: Audio: ac3, 48000 Hz, stereo, fltp, 256 kb/s After transcode with $ ffmpeg -i CYD_copy.vob -movflags +faststart -vf atadenoise -c:v libx264 -c:a libmp3lame -q:a 4 CYD_atadenoise_H.264.mp4 I get: $ ffprobe CYD_atadenoise_H.264.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'CYD_atadenoise_H.264_mp3-q4.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf57.83.100 Duration: 01:16:20.42, start: 0.00, bitrate: 1403 kb/s Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 704x576 [SAR 12:11 DAR 4:3], 1276 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default) Metadata: handler_name : VideoHandler Stream #0:1(und): Audio: mp3 (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 119 kb/s (default) Metadata: handler_name : SoundHandler Does 50 tbc mean, that I still have 50 interlaced half-frames per second? Thanks for your comments -Ulf -- Von meinem Seibert gesendet ___ 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".
