Re: [FFmpeg-devel] mpegvideo : interlaced_frame with picture_structure == PICT_FRAME
Good explanation, I neglected telecine; wasn't aware of how it worked. Agreed, yadif should handle that, the decoder cannot reverse-telecine by itself without some kind of hinting of the original frames correspondence. Thanks a lot. 2015-01-05 18:35 GMT-05:00 Michael Niedermayer michae...@gmx.at: On Mon, Jan 05, 2015 at 03:17:32PM -0500, Vanista Herion wrote: Some MPEG 2 video will give bad interlacing information in AVFrame. If the parameters are used by a deinterlace filter such as yadif, frames will be processed needlessly and impair the quality. By reviewing the code in mpegvideo.c which sets the interlaced_frame and top_field_first, I noticed that picture_structure is not considered whereas it probably supersedes everything else. The H.262 specification is not very clear on that but in the case of this sample, the stream is definitely progressive, picture_structure is equal to 3 (Frame picture) and top_field_first alternates true and false. The result is that frames come out reported as tff, bff and progressive, cycling at every frame. I propose a simple patch to set interlaced_frame to false when picture_structure is equal to PICT_FRAME. fixed differently, that is by detecting telecined content in yadif [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] mpegvideo : interlaced_frame with picture_structure == PICT_FRAME
On Mon, Jan 05, 2015 at 03:17:32PM -0500, Vanista Herion wrote: Some MPEG 2 video will give bad interlacing information in AVFrame. If the parameters are used by a deinterlace filter such as yadif, frames will be processed needlessly and impair the quality. yes and i hope this will get resolved with idet or some other solution also it might be possible to detect telecined content and do something more sane in that case without the need of idet By reviewing the code in mpegvideo.c which sets the interlaced_frame and top_field_first, I noticed that picture_structure is not considered whereas it probably supersedes everything else. The H.262 specification is not very clear on that but in the case of this sample, the stream is definitely progressive, picture_structure is equal to 3 (Frame picture) and top_field_first alternates true and false. The result is that frames come out reported as tff, bff and progressive, cycling at every frame. I propose a simple patch to set interlaced_frame to false when picture_structure is equal to PICT_FRAME. This is incorrect, and would break detecting actual interlaced frame based MPEG-2 ISO/IEC 13818-2: 1995 (E) 6.1.1.1 Progressive and interlaced sequences This specification deals with coding of both progressive and interlaced sequences. The output of the decoding process, for interlaced sequences, consists of a series of reconstructed fields that are separated in time by a field period. The two fields of a frame may be coded separately (field-pictures). This is s-picture_structure != PICT_FRAME Alternatively the two fields may be coded together as a frame (frame-pictures). Both frame This is s-picture_structure == PICT_FRAME pictures and field pictures may be used in a single video sequence. In progressive sequences each picture in the sequence shall be a frame picture. The sequence, at the output of the decoding process, consists of a series of reconstructed frames that are separated in time by a frame period. also see 6.1.1.8 4:2:0 Format Figure 6-2 – Vertical and temporal positions of samples in an interlaced frame with top_field_first = 1. Figure 6-3 – Vertical and temporal positions of samples in an interlaced frame with top_field_first = 0 Figure 6-4 – Vertical and temporal positions of samples in a progressive frame. 6.3.9 Picture header ... progressive_frame -- If progressive_frame is set to 0 it indicates that the two fields of the frame are interlaced fields in which an interval of time of the field period exists between (corresponding spatial samples) of the two fields. In this case the following restriction applies: • repeat_first_field shall be zero (two field duration). If progressive_frame is set to 1 it indicates that the two fields (of the frame) are actually from the same time instant as one another. In this case a number of restrictions to other parameters and flags in the bitstream apply: • picture_structure shall be “Frame” • frame_pred_frame_dct shall be 1 progressive_frame is used when the video sequence is used as the lower layer of a spatial scalable sequence. Here it affects the up-sampling process used in forming a prediction in the enhancement layer from the lower layer. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] mpegvideo : interlaced_frame with picture_structure == PICT_FRAME
On Mon, Jan 05, 2015 at 03:17:32PM -0500, Vanista Herion wrote: Some MPEG 2 video will give bad interlacing information in AVFrame. If the parameters are used by a deinterlace filter such as yadif, frames will be processed needlessly and impair the quality. By reviewing the code in mpegvideo.c which sets the interlaced_frame and top_field_first, I noticed that picture_structure is not considered whereas it probably supersedes everything else. The H.262 specification is not very clear on that but in the case of this sample, the stream is definitely progressive, picture_structure is equal to 3 (Frame picture) and top_field_first alternates true and false. The result is that frames come out reported as tff, bff and progressive, cycling at every frame. I propose a simple patch to set interlaced_frame to false when picture_structure is equal to PICT_FRAME. fixed differently, that is by detecting telecined content in yadif [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] mpegvideo : interlaced_frame with picture_structure == PICT_FRAME
On Mon, Jan 5, 2015 at 9:17 PM, Vanista Herion vani...@gmail.com wrote: Some MPEG 2 video will give bad interlacing information in AVFrame. If the parameters are used by a deinterlace filter such as yadif, frames will be processed needlessly and impair the quality. By reviewing the code in mpegvideo.c which sets the interlaced_frame and top_field_first, I noticed that picture_structure is not considered whereas it probably supersedes everything else. The H.262 specification is not very clear on that but in the case of this sample, the stream is definitely progressive, picture_structure is equal to 3 (Frame picture) and top_field_first alternates true and false. The result is that frames come out reported as tff, bff and progressive, cycling at every frame. I propose a simple patch to set interlaced_frame to false when picture_structure is equal to PICT_FRAME. interlaced_flag_switch.mpeg https://docs.google.com/file/d/0B72Rmfr6KECZVVE1T3R6dWhMb2s/edit?usp=drive_web The behaviour on that file is correct as far as I can see. The file is not progressive, its telecined. Telecined video is coded partially interlaced (even when the content is not technically interlaced), and when you treat it as pure progressive you will get artifacts. I do not think any changes are required. Someone like kierank can probably explain it better and confirm or deny my statement. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] mpegvideo : interlaced_frame with picture_structure == PICT_FRAME
Some MPEG 2 video will give bad interlacing information in AVFrame. If the parameters are used by a deinterlace filter such as yadif, frames will be processed needlessly and impair the quality. By reviewing the code in mpegvideo.c which sets the interlaced_frame and top_field_first, I noticed that picture_structure is not considered whereas it probably supersedes everything else. The H.262 specification is not very clear on that but in the case of this sample, the stream is definitely progressive, picture_structure is equal to 3 (Frame picture) and top_field_first alternates true and false. The result is that frames come out reported as tff, bff and progressive, cycling at every frame. I propose a simple patch to set interlaced_frame to false when picture_structure is equal to PICT_FRAME. interlaced_flag_switch.mpeg https://docs.google.com/file/d/0B72Rmfr6KECZVVE1T3R6dWhMb2s/edit?usp=drive_web diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c index ce4fa59..2e25e15 100644 --- a/libavcodec/mpegvideo.c +++ b/libavcodec/mpegvideo.c @@ -1832,14 +1832,16 @@ int ff_mpv_frame_start(MpegEncContext *s, AVCodecContext *avctx) s-current_picture_ptr = pic; // FIXME use only the vars from current_pic s-current_picture_ptr-f-top_field_first = s-top_field_first; +s-current_picture_ptr-f-interlaced_frame = !s-progressive_frame + !s-progressive_sequence; if (s-codec_id == AV_CODEC_ID_MPEG1VIDEO || s-codec_id == AV_CODEC_ID_MPEG2VIDEO) { if (s-picture_structure != PICT_FRAME) s-current_picture_ptr-f-top_field_first = (s-picture_structure == PICT_TOP_FIELD) == s-first_field; +else +s-current_picture_ptr-f-interlaced_frame = 0; } -s-current_picture_ptr-f-interlaced_frame = !s-progressive_frame - !s-progressive_sequence; s-current_picture_ptr-field_picture = s-picture_structure != PICT_FRAME; s-current_picture_ptr-f-pict_type = s-pict_type; ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel