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

[Uoti Urpala]

On Tue, 2010-02-16 at 18:31 +0100, Gwenole Beauchesne wrote:
> On Tue, 16 Feb 2010, Uoti Urpala wrote:
> 
> >> (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.
> 
> You can't express that with -vfm either, can you?

-vfm is meant to identify a whole group of codecs, so it's of course not
the right tool to express those differences. But you CAN express those
semantics with "-vc ffmpeg4vaapi,ffmpeg12," and so on; this wouldn't
work if vaapi/software were options affecting the "same decoder".

BTW somewhat related, I thought that maybe -vc functionality could be
expanded to be a superset of -vfm so you could use something like "-vc
xyz,all_vdpau,all_ffmpeg" where all_ffmpeg would be expanded to all
FFmpeg codecs, basically allowing to get the effects of "-vfm ffmpeg" in
a specific place between trying individually named codecs. 

> I really don't want to duplicate videocodec entries since this is 
> error-prone. see e.g. VDPAU, the fourcc lines now deviate a little. This 
> could be worse when there will be 4 hwaccels to maintain...

I think the best way to address this would be extend codecs.conf syntax
somehow to avoid the duplication.

> OTOH, I quite don't mind duplicating and stick to the current approach 
> which is -vo VO -vc ffmpeg12ACCEL,ffodivxACCEL,

Hmm this seems to contradict what you said just before?

This is basically my preferred approach; but I think it's worth
polishing the details somewhat (allow sharing the codecs.conf fourcc
lines somehow, add syntax for the user to specify "all VDPAU codecs"
without listing them one by one if he doesn't want to differentiate).


> >> (2) This probably would require more changes to vd_ffmpeg.c since new
> >> vd_info and LIBVD_EXTERN(xxx) would be needed + a means to pass the
> >> selected video accelerator to the init function.
> >
> > You could add new -vfm names in simpler ways than adding new
> > vd_info/VD_EXTERN; OTOH maybe showing a different name for the decoder
> > used would actually make sense. The codec has access to the codecs.conf
> > entry used so passing information to init() is not an issue.
> 
> I thought about an "hwaccel" attribute, this would be more appropriate 
> than overriding "out" semantics. But I still don't see how we could test 
> for the currently selected/tested variant.
> 
> e.g.
> videocodec ffmpeg12
> fourcc ...
> hwaccel vaapi
> hwaccel vdpau
> out YV12

I assumed in my suggested approach that those would be separate entries
(either in the text file, or separated by parsing code). As above I
think they should have separate decoder names to identify them anyway.
In any case I think this is such a small detail that there isn't much
point in discussing it at this stage.