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. The solution I've found is that I use a separate queue for each surface and flush each queue each time a surface is either used as a reference surface or with putsurface. On the down side that means to either: A) use a hashtable where I can find the buffer for a surface (which will slow things down a little bit) B) or implement my own video buffer with additionally to the video data holds a reference to the command buffer which should be used (also ugly, because with vdpau you just doesn't knows whether a video buffer is used with hardware decoding or software decoding, but maybe that is just another state tracker dependent thing that needs to be hidden from the driver) C) or (and that's the way I think we should follow) enables the state tracker to supply an additional "hint" to the decoder which command buffer should be used. As long as it is not problem for you to switch the surface on the fly you can just ignore the "hint". > > 3. We pass the render target and the buffer to begin/render/end. > > This enables slice level decoder to start their decoding earlier, while > > it still keeps the burden of figuring out where a frame start/ends to > > the XvMC state tracker. > The nouveau hardware acceleration really doesn't need more than > the current patch by ymanton, and the XvMC api doesn't expose this > kind of information, so I don't really think it makes sense to add that. Yeah that's what I'm talking about, the purpose of a state tracker is to hide all the interface details from the driver (and not the other way around), and since XvMC is the only interface which doesn't have a distinct begin/end frame call (compared to vdpau,vaapi and DXVA), and that it is needed by at least some implementations -> it's the job of the state tracker to work around that. > > So do you have time to work on this a bit more or should I take a break > > from the h264 implementation and try to do it right this time? Since I > > think I now knew what you guys need it should be possible for me to > > change the interface to something everybody is happy with. > > > I'm happy with the current api for nouveau for XvMC (minus bug above). Are you sure? Try what's happening when you just jump back and for in a video with mplayer. Assuming your command buffer is somehow limited in size you will soon get a buffer overrun, because what mplayer does is the following: XvMCRenderSurface(slice 0); XvMCRenderSurface(slice 1); .... XvMCRenderSurface(slice n); *oh crap the use has just jumped to another key frame* (There is no putsurface for the first set of slices) XvMCRenderSurface(slice 0); XvMCRenderSurface(slice 1); .... XvMCRenderSurface(slice n); XvMCPutSurface(...); To solve this I first tried to increase the command buffer size, but that's not only a waste memory it also doesn't really solves the problem, because nobody limits mplayer to just call XvMCRenderSurface over and over again. > For vdpau, I wonder if it makes more sense to have each driver have its own > library, > for example vdpau_g3dvl.so and vdpau_nouveau.so, if/when it comes to adding > nouveau > acceleration. If you look at the vdpau wrapper, it's using dri2 to query for > the driver name > to use. This would allow setting the right binary to use for each driver. Hui? There should be already separate vdpau_*.so for each build target, at least the r600g driver is called libvdpau_r600.so and softpipe is called libvdpau_softpipe.so. If you add an vdpau-nouveau target you just need to set LIBBASENAME in the makefile. Regards, Christian. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev