[FFmpeg-devel] [PATCH] libavcodec/mpegvideo_parser: set field_order correctly for progressive mpeg2

[Aman Gupta]

On Thu, Dec 7, 2017 at 11:42 AM Michael Niedermayer <michael at niedermayer.cc>
wrote:

> On Wed, Dec 06, 2017 at 02:54:50PM -0800, Aman Gupta wrote:
> > From: Aman Gupta <aman at tmm1.net>
> >
> > ---
> >  libavcodec/mpegvideo_parser.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/mpegvideo_parser.c
> b/libavcodec/mpegvideo_parser.c
> > index de70cd5632..be240b6890 100644
> > --- a/libavcodec/mpegvideo_parser.c
> > +++ b/libavcodec/mpegvideo_parser.c
> > @@ -131,7 +131,7 @@ static void
> mpegvideo_extract_headers(AVCodecParserContext *s,
> >                              }
> >                          }
> >
> > -                        if (!pc->progressive_sequence) {
> > +                        if (!pc->progressive_sequence &&
> !progressive_frame) {
>
> Iam not against this if it results in more correct interlaced detection
> in practice


In my experience, most progressive mpeg2 samples are reported as interlaced
by ffprobe before this change. See for example
https://tmm1.s3.amazonaws.com/720p.ts


> But the spec uses progressive_sequence alone to determine the output
>
>     ISO/IEC 13818-2: 1995 (E) / Recommendation ITU-T H.262 (1995 E)
>
>     If progressive_sequence is 0 the period between two successive fields
> at the output of the decoding
>     process is half of the reciprocal of the frame_rate. See Figure 7-20.
>
> So the commit message seems wrong or inprecisse
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Rewriting code that is poorly written but fully understood is good.
> Rewriting code that one doesnt understand is a sign that one is less smart
> then the original author, trying to rewrite it will not make it better.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>