[FFmpeg-devel] [PATCH] AVHWAccel infrastructure v2

[Ivan Kalvachev]

On 9/28/09, Gwenole Beauchesne <gbeauchesne at splitted-desktop.com> wrote:
> Le 28 sept. 09 ? 17:56, Ivan Kalvachev a ?crit :
>
>> I see very few of the benefits you declare actually into the code.
>> IMHO, it only makes libavcodec bigger for no real gain at all,
>> adding code that is supposed to reside in the player.
>
> That's the problem. The player shall not have to handle decode
> context... Having the player handle decode context would be as if you
> were to have the player finds itself the right codec to use in SW mode
> or even have it fill in MpegEncContext struct itself... That's not the
> player's job IMHO.

This answer didn't make any sense to me...
Until I looked into the vaapi.c code...
Strange how I have missed the whole deal.

You have broken the basic rule.
NO DIRECT CALLING OF ACCELERATION API from within libavcodec!

This is why now instead of doing everything transparent
you must find various innovative ways to communicate with the decoder.
DISPLAY env have no place in codec,  but you are the one who placed it there.
If all the vaapi junk wasn't in the codec context, then the application wouldn't
had to mess with codec contexts.


Instead of trying to add more bloat to the libavcodecs in order to workaround
design shortcomings, I do recommend you to rework vaapi and make
buffer allocation, rendering and displaying routines external to
libavcodec. The least benefit  would be that libavcodec won't have
vaapi library dependency,
even if it supports vaapi decoding.

I suspect that you find the external way too hackish, but it is
actually the right way.
It keeps lavc as simple as possible, while allowing maximum
flexibility for the calling application.