2019-02-02 0:43 GMT+01:00, Ulf Zibis <ulf.zi...@gmx.de>: > > Am 01.02.19 um 23:25 schrieb Carl Eugen Hoyos: >> 2019-02-01 23:14 GMT+01:00, Ulf Zibis <ulf.zi...@gmx.de>: >>> So now I understand (hopefully). My main interest was is to know, >>> if my video is _encoded_ interlaced or not, and I still don't know it :-( >> Debugging mpegvideo.c shows the video is encoded interlaced. >> (Which was practically certain as the encoder couldn't know that >> your content is progressive.) > > Do I understand right, that there is no way by ffprobe or some other > option to know, if a video is _encoded_ interlaced or not?
I suspect there is but I may be wrong. (It is not really helpful because users use it to decide if they should de-interlace or not which is a bad idea.) > You may remember my question and your answer: > Am 15.01.19 um 12:54 schrieb Carl Eugen Hoyos: > >>> Which is the de-interlacing method, libx264 uses by default? >> x264 is an encoder and knows nothing about de-interlacing, >> it does not de-interlace. > > I meant, if libx264 does a re-encoding from interlaced > encoding to progressive encoding? libx264 does not encode "from interlaced encoding" because it cannot know if the source was encoded interlaced or progressive. Please try to understand that we are only discussing digital video here, and that all decoders only provide frames (not fields) and all encoders expect frames (not fields) - although all frames consist of two fields. You can ask some encoders to encode the frames in interlaced or progressive mode. > That would mean, if I have an interlaced encoded vob > stream I get a progressive encoded mp4 stream and > the advantage of a better visual result of an interlacing > display is lost with libx264. Am I right? First: There is no "interlacing display", in our context this does not exist (anymore). Second: libx264 does support interlaced encoding (but not field encoding because it does not help encoding efficiency). Apart from that, it does severely hurt compressibility if you don't set interlaced encoding for interlaced content. (But the sample video you provided is not interlaced, it is difficult to encode because of its abysmal quality.) >>> If it is encoded interlaced, I can understand, that only a pair of >>> lines can be cropped. >> This is wrong, the output of the decoder is not different depending >> on the used encoding method. > > So what is the technical reason, that I can't crop a single line for > further processing? This is a property (or a bug) of yuv420p and our crop filter and not related to interlacing. This is apart from the fact that the h.264 standard requires even resolutions iirc. Carl Eugen PS: The hevc and the j2k decoder sometimes provide "fields" (instead of frames) but this is completely unrelated: Because the standards (luckily) do not support interlaced encoding, some smart asses decided to send the two fields of an interlaced frame as independent frames to the encoders and expect the playback systems to reconstruct the original video. This does not work with FFmpeg (out of the box). _______________________________________________ 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".