[Mesa-dev] hardware xvmc video decoding with nouveau

[Younes Manton]

2011/8/8 Christian König <deathsimple at vodafone.de>:
> Am Montag, den 08.08.2011, 15:00 +0200 schrieb Maarten Lankhorst:
>> On 08/08/2011 12:10 PM, Christian König wrote:
>> > Most modern players doesn't do it like this any more, but it still seems
>> > to cause a bunch of problems when seeking or fast forward both with
>> > mplayer and xine.
>> >
>> > So I would suggest we design the interface something like this:
>> As far as I can tell, the hardware decoder I'm using has no problem with that.
>> I just queue all commands and on putsurface I flush them. In fact, with flushing
>> on putsurface it works better than other alternatives, since it can decode future
>> and current surface simultaneously. Each command has to say which surface it's
>> being applied to. :)
> Finally somebody who understands me :D
>
> The problem I'm facing here is that switching the surface a command is
> applied to is causing either a whole bunch of overhead for me (cache
> flushes) or is not possible at all because the hardware wants an command
> buffer always filled with a whole frame.

Incidentally, I think you misunderstood Martin here. The Nvidia
hardware decoder has no problem rendering to multiple surfaces in a
single command buffer, it doesn't need a command buffer per surface
nor does it need to flush when the XvMC user passes in a different
surface to each XvMCRenderSurface call. When the command buffer is
finally flushed it can contain rendering for multiple surfaces without
any issue so it doesn't need to do anything special to support any of
the possible sequences of events that XvMC rendering is capable of.