[FFmpeg-devel] [PATCH] lavc/vaapi_h26[45]: add crop info support in vaapi_h26[4, 5]

[wm4]

On Fri, 2 Dec 2016 16:15:10 +0800
Jun Zhao <mypopydev at gmail.com> wrote:

> On 2016/12/1 19:03, wm4 wrote:
> > On Wed, 30 Nov 2016 18:25:59 +0100
> > Michael Niedermayer <michael at niedermayer.cc> wrote:
> >   
> >>>> AVFrame had a pan_scan parameter to store one or more croping
> >>>> rectangles.
> >>>> That is now available as side data
> >>>>
> >>>> I remember the intend that this could be used for multiple rectangles
> >>>> of different sizes for example for storing recommanded display
> >>>> rectangles for a 4:3 and a 16:9 display device, but it seems only a
> >>>> single size per frame is supported in the API
> >>>>
> >>>> [...]    
> >>>
> >>> This one is very "special" - I don't know if I'd want to further its
> >>> existence. What's it used for at all?    
> >>
> >> I only know whats written in the specs, i dont remember having
> >> investigated what real world files do with it, and my knowledge of the
> >> specs is many years old so the spec would be a better place than my
> >> memory of it for further research ...  
> > 
> > If we're going to have a crop rectangle, lots of code (including many
> > video filters) will need to be able to interpret them. Considering
> > this, the pan scan side data is prohibitively complex. Maybe it
> > accurately reflects some standard (mpeg1/2 apparently?), but I'd say
> > it's not simple enough for general use.
> > _  
> 
> I don't think software dec/enc/filter have the crop issue, so I guess
> we just need a general solution for HWAccel dec/enc/hwcontext_xxx_filter.

For software filters, there is the issue that cropping left/right can
make the plane pointers unaligned (e.g. crop 1 pixel -> the pointer is
not aligned to 16 bytes anymore). Which can cause performance issues.
Also, cropping subsampled yuv by non-mod-2 width/height (as jpg
decoding requires it) is really messy.