[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...

Reimar Döffinger Reimar.Doeffinger
Mon Jan 5 11:48:34 CET 2009


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?

Greetings,
Reimar D?ffinger




More information about the ffmpeg-cvslog mailing list