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.
 

Reply via email to