[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...
Mon Jan 5 23:55:31 CET 2009
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.
mans at mansr.com
More information about the ffmpeg-cvslog