On Fri, 2 Dec 2016 16:15:10 +0800 Jun Zhao <mypopy...@gmail.com> wrote:
> On 2016/12/1 19:03, wm4 wrote: > > On Wed, 30 Nov 2016 18:25:59 +0100 > > Michael Niedermayer <mich...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
