Hi, On 12/29/2012 09:32 PM, Mauro Carvalho Chehab wrote:
Agreed. Adding YUYV support at libv4l should be easy.
Make that easy-ish. There is the easy and the hardway, the easy way is to add an extra conversion step and then convert yuv420 to yuyv, but TBH that is a stupid thing to do, it potentially looses video resolution in the u and v planes and it is just not very cpu effective. So the right thing to do is to go over all the rawXXX -> rgb + rawXXX -> yuv420 converter function pairs, and add a rawXXX -> yuyv function to them for all supported src formats. <snip>
Applications that use libv4l will do whatever behavior libv4l does.
libv4l has 3 different scenarios here: 1) The app is asking for a format libv4l does not support (iow not rgb24 or yuv420), and the video device only supports some proprietary format (ie many gspca webcams), then libv4l will change the requested format to RGB24, do a try_fmt to the device to get closest width/height and returns that. So in this scenario it behaves as Hans V. has suggested. 2) The app is asking for a format libv4l does not support and the device supports one or more standard formats, then libv4l simple passes on the try_fmt to the device, and returns whatever it returns. This is what will happen with most tv-cards, so using libv4l won't help here! 3) The app is asking for a format that libv4l does support, then libv4l negotiates with the device to find the best src format to convert from. libv4l's negotation code will check both the try_fmt return value, as well as that the resulting format is what it asked for. So it does not care either way... Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
