[FFmpeg-devel] [PATCH] HWAccel infrastructure (take 5)
Fri Feb 20 18:33:08 CET 2009
On Fri, Feb 20, 2009 at 05:56:41PM +0100, Reimar D?ffinger wrote:
> On Fri, Feb 20, 2009 at 03:07:00PM +0100, Gwenole Beauchesne wrote:
> > Le 20 f?vr. 09 ? 11:45, Ivan Kalvachev a ?crit :
> > >>> avctx->get_format being NULL seems invalid, so no need to check
> > >>> for it
> > >>> also i suspect it would be cleaner to make
> > >>> avcodec_default_get_format()
> > >>> skip hw-accel formats.
> > >>
> > >> Implemented with an ff_is_hwaccel_pix_fmt() function. That's
> > >> intentionally
> > >> internal because users are expected to handle the HW accelerated
> > >> pix_fmt
> > >> specifically anyway. IMO, this is only useful for lavc.
> > >
> > > I think this is wrong.
> > > This makes support for combined (software & hardware) decoders much
> > > harder.
> > >
> > > Application may want to try out the hardware accelerated formats first
> > > then make second pass for fallback non-accelerated.
> > Then application overrides ::get_format(). We are talking about the
> > default get_format() from lavc, it does not have to handle HW
> > accelerated formats.
> I think you misunderstood it, at least the issue I saw is that
> the users supporting hardware acceleration must do two passes:
> one to first search for and try all hardware-accelerated formats and if
> that does not work the next (this can be avoided if you enforce that
> hw-accelerated formats must always come first, but that might break
> anyone who make their own get_format and copied the hard-coded fmt
> from the current default_get_format function).
the list you get from lavc really should be best to worst so picking the
first you support should work in general.
And i really dont see how adding a hw accel format in front can break
any half sane written app. We also could add another new non hw pix_fmt
in front and a app must not choose this unless it supports it ...
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel