Comments on VOUT IV
gbazin at netcourrier.com
Wed Aug 8 08:09:57 CEST 2001
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
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?
More information about the vlc-devel