[FFmpeg-devel] [PATCH] HWAccel infrastructure (take 5)

[Michael Niedermayer]

On Fri, Feb 20, 2009 at 07:25:53PM +0100, Reimar D?ffinger wrote:
> On Fri, Feb 20, 2009 at 06:33:08PM +0100, Michael Niedermayer wrote:
> > the list you get from lavc really should be best to worst so picking the
> > first you support should work in general.
> 
> Particularly with hardware-decoding, I don't think you will get everyone
> to agree which is "best".

Considering the vast number of people who have more than 1 grafix card in
their system, i dont think this matters


> 
> > 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 ...
> 
> Well, they might have taken a hint for default_get_format and concluded
> that the first one is "the best", where they defined "best" as "most
> widely supported". I could imagine someone falling back to that format

people might do alot that is outside the API, but that is their problem.


> just because they did not want to implement full building/destroying of
> a whole filter chain including format conversion filter insertion for
> testing every format. "See if some format is obviously better, otherwise
> use the first and beat it to work" for me qualifies as sloppy/lazy, but
> not as "not sane".
> But mostly it is a question of how to define "the best" format, and I
> would have disqualified hardware decoders (particularly for MPEG2)
> because they have little error concealment, some errors may cause severe
> system problems (too much code running as root/blocking the display
> device) and simply not handling some streams. None of these are
> properties inherent to the pixfmts though, just the current decoder
> implementations.

what is it that you argue for here?
get_format() gives you the possibility to choose the format you like.
what you make out of the order in which the choices are presented to
you is your decission.
If you want ffmpeg to try harder to present a good choice at fmt[0] a
patch is surely welcome
we have fields specifiying error concealment and detection behavior
they surely could be hints to the list ordering
but that is really of rather low priority ATM, first we should get the
HW API stuff in ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090220/4973777d/attachment.pgp>