[FFmpeg-devel] [RFC] get rid of h264_vdpau codec
Thu Feb 12 23:26:56 CET 2009
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,
>> 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
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
>> (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.).
More information about the ffmpeg-devel