Comments on VOUT IV

[Gildas Bazin]

Hi Sam,

I'm writing this email to the list because any comment would be appreciated.

I had a quick look at your snapshot for the new video output architecture 
(vout IV), and I must say the code is really well structured and easy to 
understand.

One of the goals of vout IV is to spare a memcpy of the video picture when in 
overlay mode. So basically the mpeg decoder will create its pictures in 
buffers that can be directly displayed be the video output plugins.

I just have one question that is really annoying me:

- With DirectX, you can create picture buffers in video memory or in main 
memory. Of course, if you create them directly in video memory, you should 
save some time overall because for a picture to be displayed it has anyway to 
end-up in video memory in some way. The other advantage is that when you will 
send the command to display the picture, you KNOW it will be displayed almost 
instantly (the video hardware only has to do a modifiy the displayed buffer 
pointer on the next screen refresh).
If you only SEND data to video memory, the performance will be good. But as 
soon as you've got a series of read access and write access (like when you 
construct a new picture ( B frame ) from a reference picture ( I or P frame ) 
the performance will not be so great. If you need to do a lot of access to 
some data in video memory, it's supposed to be cheaper to store the data in 
main memory and then do a memcpy into video memory.
So I'm just wondering if we should directly use video memory just to store B 
frames, and the other frames (those which can be referenced) would be kept in 
main memory ?
- I'm not sure but the same comment should be valid for Xvideo too, because X 
is a network oriented protocol. I mean the xvideo picture buffer you created 
could be located at the other end of the network connection, so if you need 
to reference it to build a new picture, you are in big troubles no?

--
Gildas