>> Sorry for the bit of unrelated question in this thread, but if scaling >> isn't needed as the raw stream is in the right size, why does it make >> any >> difference in this case? It is an uncompressed video stream that has to >> be >> given to the display. Ok, the stream is y8, so each value has to be >> given >> three times to be RGB, but is there anything else that could be >> accelerated in such a case? > > "Accelerated" maybe not (though you lose brightness and contrast > adjustment > as well), but (unless -vo x11 could be modified to support grayscale > directly) > you must convert it to RGB. > Converting to RGB mean reading the Y8 data, writing the RGB data and then > giving the RGB data to the X-Server. > Depending on RGB format, that would mean 5x - 9x the memory bandwidth > requirement - if nothing else that is quite a power waste, even if > your memory is fast enough to handle it (if the video is small enough > it should fit in cache and it wouldn't be a real issue). Ok, thanks! In my case it is already RGB, and I'm assembling the stream live, with white-balance and brightness correction, so in fact I'm using mplayer only as some kind of display interface with bmovl function ;-) It is a power waste to have mplayer convert it to YUV, apply bmovl, and convert back to RGB, but I'm confident that mplayer does this more efficiently than I could do it, so I'm taking the disadvantage of the memory bandwidth (compared to, say, UYVY) for swscale's good conversions. Maybe, when I grow up I'll try to write a Bayer-input for mplayer, that would save lots of conversions for me. :-D Greets, Kiste
