[FFmpeg-devel] [PATCH] HWAccel infrastructure (take 5)
Reimar Döffinger
Reimar.Doeffinger
Fri Feb 20 17:56:41 CET 2009
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[0]
from the current default_get_format function).
To try all the hardware-accelerate formats first you must know which
those are, and with internal ff_is_hwaccel_pix_fmt they might have to
resort to such ugly hacks as in MPlayer that "uselessly" converts to
an internal format, or they implement a variant of
ff_is_hwaccel_pix_fmt() themselves.
More information about the ffmpeg-devel
mailing list