[FFmpeg-devel] [PATCH] libavcodec/qsv.c: Re-design session control and internal allocation

[wm4]

On Mon, 26 Oct 2015 12:56:31 +0100
Hendrik Leppkes <h.leppkes at gmail.com> wrote:

> >> > I think doing cropping as metadata would also simplify code a lot. For
> >> > example, nobody has to worry about non-mod-2 yuv420 anymore, and how it
> >> > should be handled. It's less tricky, more correct, more efficient.  
> >>
> >> OK. A crop side-data is desired then. I somehow was convinced that it
> >> wouldn't matter for SW. Though, it would actually be really need that  
> >
> > At least this is my opinion. I would like to have such cropping side
> > data, instead of half-broken ad-hoc cropping in the decoder and things
> > like coded_width.
> >
> > I don't know what most others think about this. I suspect most would
> > find such a change too intrusive. At least for hwaccel it's mandatory
> > though. (What we currently do just barely works, and I need hacks in my
> > own code to reconstruct the real surface size.)  
> 
> 99% of all cropping use-cases are extremely simple (only bottom/right)
> and don't require any secret magic in any code.
> I don't mind adding extra cropping metadata, but if you just don't
> care about top/left cropping, simply adjusting width/height is as
> trivial as it gets.
> 
> Adding mandatory new metadata that every user app has to support to
> avoid getting 1920x1088 in the future seems a bit ill-advised.

Well, I've seen you complaining multiple times that non-mod-2 yuv420
does not make any sense...