[FFmpeg-devel] [PATCH] libavcodec/qsv.c: Re-design session control and internal allocation
nfxjfg at googlemail.com
Mon Oct 26 13:12:17 CET 2015
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...
More information about the ffmpeg-devel