[FFmpeg-devel] [PATCH][7/8] Add VA API accelerated H.264 decoding (take 4)
Mon Feb 9 16:15:23 CET 2009
On Mon, Feb 09, 2009 at 03:10:32PM +0100, Gwenole Beauchesne wrote:
> On Mon, 9 Feb 2009, Michael Niedermayer wrote:
>> On Mon, Feb 09, 2009 at 11:39:43AM +0100, Gwenole Beauchesne wrote:
>>> On Fri, 6 Feb 2009, Michael Niedermayer wrote:
>>>> C. as stephen suggested, outputting decoded surfaces
>>> I had a look at it when Jean-Michel Pour? asked for it. However, it
>>> out this could be rather suboptimal. In particular, there are cases where
>>> NV12 readback might be supported but not YV12. Sure, it doesn't cost that
>>> much to convert both, but it still has some cost.
>> i dont understand the problem you describe, If the hardware can only make
>> NV12 available and the user app cannot use that convert is needed anyway
>> and if a common format is supported that could be used ...
>> what am i missing?
> You said "outputting decoded surfaces", this implied a default behaviour
> unlike what I initially suggested (an optional flag). Performing the
> conversion in any case when we usually only want to see the result
> on-screen is not a good use of the underlying resources.
I did not mean to implicate that "outputting decoded surfaces" would mean
having YV12 in main mem. Rather (and maybe iam naive) that there would
be decoded surfaces somewhere and that they would be in some format,
they could very well be in a non standard format in not directly accessable
memory as long as a VO could display them and a converter could somehow
read the data back.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel