On 14/02/19(Thu) 11:24, Raphael Graf wrote: > 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.
Good, then please update the comment and I'll commit your diff :) Thanks for solving this issue.
