[FFmpeg-devel] [PATCH 7/10] GXF Encoder Fixes and HD support (patch broken up)

[Reuben Martin]

Yo, back on Thursday, September 09, 2010 Baptiste Coudurier was all like:
> On 09/08/2010 06:39 PM, Reuben Martin wrote:
> > Yo, back on Wednesday, September 08, 2010 Reuben Martin was all like:
> >>
> >> 07-gxf__set_DAR.patch
> >>
> >> FEATURE: Adds support for storing the video content's display aspect ration in the GXF file. This is particularly important with 16:9 NTSC where it is rather difficult to deduce the display aspect ratio simply from the frame size. Also useful for differentiating beween 1920x1080 and 1440x1080 since the main header on indicates line-height.
> >>
> >>
> >> 07-gxf__set_DAR.patch
> >>
> >>
> >> --- ffmpeg-old/libavformat/gxfenc.c	2010-09-08 17:00:53.716000133 -0500
> >> +++ ffmpeg-new/libavformat/gxfenc.c	2010-09-08 17:02:05.521000116 -0500
> >> @@ -42,6 +42,7 @@
> >>       int p_per_gop;
> >>       int b_per_i_or_p; ///<  number of B frames per I frame or P frame
> >>       int first_gop_closed;
> >> +    int aspect_ratio;
> >>       unsigned order;   ///<  interleaving order
> >>   } GXFStreamContext;
> >>
> >> @@ -187,10 +188,11 @@
> >>           starting_line = 23; // default PAL
> >>
> >>       size = snprintf(buffer, 1024, "Ver 1\nBr %.6f\nIpg 1\nPpi %d\nBpiop %d\n"
> >> -                    "Pix 0\nCf %d\nCg %d\nSl %d\nnl16 %d\nVi 1\nf1 1\n",
> >> +                    "Pix 0\nCf %d\nCg %d\nSl %d\nnl16 %d\nVi 1\nf1 1\nar %d\n",
> >>                       (float)st->codec->bit_rate, sc->p_per_gop, sc->b_per_i_or_p,
> >>                       st->codec->pix_fmt == PIX_FMT_YUV422P ? 2 : 1, sc->first_gop_closed == 1,
> >> -                    starting_line, st->codec->height % 16 == 0 ? (st->codec->height / 16) : ((st->codec->height / 16) + 1 );
> >> +                    starting_line, st->codec->height % 16 == 0 ? (st->codec->height / 16) : ((st->codec->height / 16) + 1 ),
> >> +                    sc->aspect_ratio);
> 
> This contains modifications from a previous patch.

Is this just a comment, or do I need to change it to apply directly to current trunk? That patches are currently set to be applied in-sequence.

Prefer your simplification for calculating st->codec->height.

> 
> > [...]
> >
> >> @@ -673,6 +689,29 @@
> >>                   av_log(s, AV_LOG_ERROR, "video stream must be the first track\n");
> >>                   return -1;
> >>               }
> >> +
> >> +            switch (st->codec->height) {
> >> +                case 512:
> >> +                    sans_vbi_height = 480;
> >> +                    break;
> >> +                case 608:
> >> +                    sans_vbi_height = 576;
> >> +                    break;
> >> +                default:
> >> +                    sans_vbi_height = st->codec->height;
> >> +                    break;
> >> +            }
> 
> if (st->codec->height == 608 || st->codec->height == 512) // VBI
>      sans_vbi_height = st->codec->height - 32;
> else
>      sans_vbi_height = st->codec->height;
> 
> seems simpler to me.

Agreed.

> 
> >> +            av_reduce(&display_aspect_ratio.num,&display_aspect_ratio.den,
> >> +                st->codec->width*st->sample_aspect_ratio.num,
> >> +                sans_vbi_height*st->sample_aspect_ratio.den,
> >> +                1024*1024);
> >> +
>  >
>  > [...]
>  >
> >> +            if (display_aspect_ratio.num == 16&&  display_aspect_ratio.den == 9)
> >> +                sc->aspect_ratio = 1;
> >> +            else
> >> +                sc->aspect_ratio = 0;
> >> +
> 
> This seems a bit harsh to me that is everything > 1.777 should be 
> considered widescreen.
> 
> 

Agreed. Will rework this. There are some cases anamorphic cases with DVCPROHD and AVCI where the encoded width is reduced by 3/4.  So you get things like 960x720 for 720p, 1280x1080 for 1080/59.94i and 1440x1080 for 1080/50i. Should I assume that the user will be smart enough to append the desired aspect ratio to the command line in those cases?