Google
  Web www.spinics.net

maximum resolution: how to extend ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


>> 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



[Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Free Online Dating]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Devices]

Add to Google Powered by Linux