On Wed, Feb 13, 2019 at 04:09:10PM -0200, Martin Pieuchot wrote: > On 07/02/19(Thu) 13:52, Raphael Graf wrote: > > [...] > > The new diff below solves this yuy2/yuyv problem by defining them both under > > the same name 'yuy2'. > > That's great. I would just change the comment to explain that it's due > to an incoherency between the names reported by XvListImageFormats(3) and > V4L2 :)
I'll do this when the general idea of the diff gets accepted.. > > > The only change to the manpage is now the addition of yv12 to the list of > > valid encodings. > > Fine, I just missed the point: why do we need to support yv12? The support for yv12 as an input encoding is actually a side effect of the implementation. Webcams (video(4)) do not provide yv12, but is now possible to read and display yv12 encoded files. > > > The trickiest part is the 'choose_enc' function where encodings are chosen > > based on device capabilities. > > The following conversions are now possible: > > yuy2 -> uyvy > > yuy2 -> yv12 > > uyvy -> yuy2 > > uyvy -> yv12 > > > > As my webcam only provides yuy2, I have used input-files for testing: > > $ video -i test.yuy2 > > $ video -i test.uyvy -e uyvy > > $ video -i test.yv12 -e yv12 > > > > These examples work for me with both drivers (modesetting and intel). > > The conversion to yv12 has a small performance impact, of course. Do you > > think > > the performance is acceptable? > > Do you think it is? When is the conversion needed? > Conversion to yv12 is needed when Xv does neither support yuy2 nor uyvy. This is the case when the modesetting driver is in use (see output of xvinfo). I think the performance is acceptable, it is hardly noticable on my laptops.
