[FFmpeg-cvslog] r16431 - in trunk: configure libavcodec/Makefile libavcodec/allcodecs.c libavcodec/avcodec.h libavcodec/h264.c libavcodec/h264_parser.c libavcodec/imgconvert.c libavcodec/mpegvideo.c libavcodec/vdp...

[Måns Rullgård]

Diego Biurrun <diego at biurrun.de> writes:

> On Mon, Jan 05, 2009 at 11:48:34AM +0100, Reimar D?ffinger wrote:
>> On Mon, Jan 05, 2009 at 11:25:02AM +0100, Diego Biurrun wrote:
>> > On Mon, Jan 05, 2009 at 09:02:28AM +0000, Carl Eugen Hoyos wrote:
>> > > Ivan Kalvachev <ikalvachev <at> gmail.com> writes:
>> > > 
>> > > > > + * Codec can export data for HW decoding (VDPAU).
>> > > > > + */
>> > > > > +#define CODEC_CAP_HWACCEL_VDPAU    0x0080
>> > > > 
>> > > > May I request the removal of this new CAP flag, before something
>> > > > starts using it,
>> > > > and advertise the usage of the existing generic CAP_HWACCEL ?
>> > > 
>> > > That would lead to strange behaviour in vd_ffmpeg.c (look at line 256): It would
>> > > act as if XVMC was asked by the user while it was actually VDPAU.
>> > > 
>> > > If you change that code, CODEC_CAP_HWACCEL_VDPAU could be removed.
>> > 
>> > This is backwards.  Bad design decisions in MPlayer should not negatively
>> > influence FFmpeg.  It's preferable to break MPlayer instead of hurting
>> > FFmpeg.
>> 
>> I disagree, IMHO the idea of an hardware-independent
>> hardware-acceleration (as CAP_HWACCEL suggests) is nonsense, and
>> it should have been called CAP_XVMC or some such instead.
>> What is the point of CAP_HWACCEL anyway?
>
> Well, then let us just rename it.  Is there any problem with renaming it?

Hardly, since it is impossible to use with currently installed
headers.  It won't break binary compatibility either.

-- 
M?ns Rullg?rd
mans at mansr.com