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

[Gwenole Beauchesne]

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.

>> (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.).

Regards,
Gwenole.