[MPlayer-dev-eng] [PATCH] Add -va for video acceleration

[compn]

On Tue, 16 Feb 2010 19:07:32 +0200, Uoti Urpala wrote:
>On Tue, 2010-02-16 at 17:14 +0100, Gwenole Beauchesne wrote:
>> On Tue, 16 Feb 2010, Uoti Urpala wrote:
>> 
>> > On Tue, 2010-02-16 at 16:33 +0100, Gwenole Beauchesne wrote:
>> >> On Tue, 16 Feb 2010, Uoti Urpala wrote:
>> >>> I think the existing -vfm option would suit this use too (preferring
>> >>> codecs using a particular kind of hardware decoding).
>> >>
>> >> How? They all depend on FFmpeg. Or do you want to split them all as -vfm
>> >> ffmpeg,ffmpeg_vaapi,ffmpeg_crystalhd? It's not really user-friendly.
>> >
>> > Either add support for having one codec in multiple categories for the
>> > -vfm option, or just split the 'ffmpeg' one into 'ffmpeg' (FFmpeg
>> > software decoders) and 'vdpau', 'vaapi' etc - I can't at least
>> > immediately think of any important problems with that.
>> 
>> I think the problems with this approach are:
>
>You seem to assume a particular clumsy implementation and then identify
>problems in that; as far as I can tell the problems you're talking about
>are not intrinsic to my approach itself.
>
>> (1) We will tend to duplicate videocodec entries since this would require 
>> different "driver" lines, isn't it? So far, my current approach works by 
>> just adding e.g. out VAAPI_MPEG2 to an existing videocodec entry. It's 
>> preferable to add a single line rather than copying the whole entry x N 
>> accelerators (N can be 4 very easily).
>
>I think it's preferable to distinguish various accelerated versions on
>the video codec level. If you don't then you need to duplicate all the
>codec preferred/forced/fallback functionality to implement selecting the
>actual hardware decoder used within the "same" codec. Also things like
>"use VAAPI for mpeg4 but software for mpeg2 because my hardware has
>problems with that" becomes hard to express on the command line if you
>try to separate hardware decoding mode from other codec selection.

i agree. i cant think of any other way to let user decide which codec
needs accel and which doesnt. altho its not very user friendly (and a
bit of a pain when you have to add the same new fourcc to 16 codecs).

having said that, with the duplication, you could still apply something
to make it easier for users who dont need that level of customizability
to enable hwaccel.

what would ovveride what in this example? -vc coreavc, -va crystalhd.
would coreavc get picked first, and then crystalhd takes over if
coreavc fails?

actually, i dont know what gets overridden in a -vc coreavc -vfm ffmpeg
either.

-compn