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

[Hendrik Leppkes]

On Mon, Oct 26, 2015 at 1:12 PM, wm4 <nfxjfg at googlemail.com> wrote:
> 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...

Obviously it doesn't, but I blame the users creating that, not the decoder.