[MPlayer-dev-eng] [RFC] Split out hwaccel code

[Ivan Kalvachev]

On 3/6/16, Roberto Togni <rxt at rtogni.it> wrote:
> Hi,
>  this is a proposed patch to split the hwaccel code out of vd_ffmpeg,
> and put it into its own driver (vd_ffhw, but better names are welcome).

It's bad idea.

The goal is to have hw acceleration completely transparent.

This means that hw acceleration should be offered by the regular driver.
e.g. mpeg12 should try xvmc, vdpau etc first, then fallback to
software decoding.

That's happening during the query/negotiation for pixel format  (get_format).

> The main purpose of this is to be able to change vd_ffmpeg code without
> the risk of breaking hwaccel (difficult to test if you don't have the
> hardware); at the same time it allows to work on hwaccel in a small and
> clean decoder, without all the special cases needed for the many
> formats supported by vd_ffmpeg.

That would also mean completely loosing the ability to fallback
into software decoding if e.g. h264 profile cannot be handled by hw decoder.

Also, it would mean duplication of critical code.

> This also permit to use hwaccel by passing only "-vfm ffhw -vo vdpau"
> on the commandline, without specifying the codec (now you have to use
> "-vo vdpau -vc xxxvdpau"). If you add -vfm ffhw and the codec is not
> supported by hwaccel, MPlayer will fall back to vd_ffmpeg.

The problem is that you have to init the decoder and feed it a packet,
in order to find out if you can decode it in hardware. This means that
you cannot fail init and fallback to another decoder.

> The current syntax with -vc is also supported, so backward
> compatibility is guaranteed.
>
>
> The code is tested only with h264 and vaapi over vdpau; xvmc and other
> vdpau formats are untested.
>
>
> Hopefully this should accelerate the addition of more hwaccel formats
> (eg. vaapi), and ease the work on buffer management in vd_ffmpeg (today
> dr1 mostly fails).
>
>
> Please comment.