[FFmpeg-devel] [RFC] get rid of h264_vdpau codec

[Ivan Kalvachev]

On 2/13/09, Gwenole Beauchesne <gbeauchesne at splitted-desktop.com> wrote:
> Hi,
>
> Le 12 f?vr. 09 ? 22:47, Reimar D?ffinger a ?crit :
>
>> On Thu, Feb 12, 2009 at 10:34:28PM +0100, Gwenole Beauchesne wrote:
>>> That's indeed even simpler than my -va hwaccel proposal. However,
>>> your
>>> patch will prefer the non-accelerated codec for VOs that implement
>>> that case. i.e. it probably would be better to add the accelerated
>>> pix_fmt first. But for non-accelerated outputs, the default
>>> get_format() will only get the first pix_fmt[]. In my local tree, I
>>> have added an IS_VDPAU_PIX_FMT() macro to filter out accelerated
>>> pix_fmts in that function.
>>
>> It seems preferable to me to let the application explicitly search the
>> list for the special formats instead of changing the defaul get_format
>> function.
>
> But I think you need to expose some preference/ordering. e.g. MPEG-2
> VLD > IDCT > MoComp. How would you express that? Or could we just say
> that, algorithmically, non-accelerated formats come first, then
> accelerated ones in a particular order?
>
> Oh, just thought the user app could handle that case itself. i.e.
> making it search the pix_fmts array based on his preferences, though,
> in the worst case, that'd be a N x M iterations where N number of
> elements in input pix_fmts and M the number of elements from the
> accelerator preferences.

You can decrease the parsing to 2x if you separate the pix_fmt on
2 groups, pixels and hwaccel data.
One of the ways to do that is to use the PixFmtInfo that describes the
pixel formats.
So get_format() makes one pass and ignores all normal pixels formats
(trying only hwdata).
If it fails then it makes another run and tries normal pixel formats
(ignoring hwdata).

It's likely that there may be simpler solution.

>>> (BTW, you'd also need my patch for vd_ffmpeg as this code will
>>> actually crash for H.264)
>>
>> As said it won't work even remotely for MPlayer as-is, and even the
>> lavc part misses parts in mpegvideo.c
>
> and error_resilience.c. A macro or common variable (e.g. s/
> xvmc_acceleration/whatever_hwaccel/) could help knowing whether we are
> in accelerated mode or not. I'd prefer the latter (less tests: 5 for
> VDPAU + 6 for VA API + at least 3 for DXVA, etc.).

My thoughts exactly.
I'm even sure I've said same thing;)