How to set pixelaspect in struct v4l2_cropcap returned by VIDIOC_CROPCAP?

Guys I'm adding v4l2 output device support for VLC/ffmpeg/libav (I'm using v4l2loopback [1] driver for testing) but I have a problem which I can't seem to find a solution.

VLC [2] uses VIDIOC_CROPCAP [3] to detect the pixelaspect ratio of the input it receives from v4l2 device. But I can't seem to find a way to set struct v4l2_cropcap.pixelaspect when I'm outputting data to the device and the result is that VLC assumes pixelaspect is 1:1.

I was hoping that VIDIOC_S_CROP [4] would allow setting pixelaspect but according to docs that is not case. What am I missing?

How to set pixelaspect values returned by VIDIOC_CROPCAP?

[1]: https://github.com/umlaeute/v4l2loopback
[2]: http://git.videolan.org/?p=vlc.git;a=blob;f=modules/access/v4l2/demux.c;hb=HEAD#l248
[3]: http://www.linuxtv.org/downloads/v4l-dvb-apis/vidioc-cropcap.html
[4]: http://www.kernel.org/doc/htmldocs/media/vidioc-g-crop.html

Quoted 11 lines · On Sun September 16 2012 17:32:52 Georgi Chorbadzhiyski wrote:

Guys I'm adding v4l2 output device support for VLC/ffmpeg/libav (I'm using v4l2loopback [1] driver for testing) but I have a problem which I can't seem to find a solution.

VLC [2] uses VIDIOC_CROPCAP [3] to detect the pixelaspect ratio of the input it receives from v4l2 device. But I can't seem to find a way to set struct v4l2_cropcap.pixelaspect when I'm outputting data to the device and the result is that VLC assumes pixelaspect is 1:1.

I was hoping that VIDIOC_S_CROP [4] would allow setting pixelaspect but according to docs that is not case. What am I missing?

The pixelaspect ratio returned by CROPCAP depends on the current video standard of the video receiver or transmitter.

So for video capture the pixelaspect depends on the standard (50 vs 60 Hz) and the horizontal sampling frequency of the video receiver (hardware specific).

For video output the pixelaspect depends also on the standard and on how the transmitter goes from digital to analog pixels (the reverse of what a receiver does).

It is *not* the pixelaspect of the video data itself. For output it is the pixel aspect that the transmitter expects. Any difference between the two will need to be resolved somehow, typically by software or hardware scaling.

Quoted 24 lines · Hans Verkuil

Quoted 23 lines · On Sun September 16 2012 17:32:52 Georgi Chorbadzhiyski wrote:

Quoted 11 lines

Guys I'm adding v4l2 output device support for VLC/ffmpeg/libav (I'm using v4l2loopback [1] driver for testing) but I have a problem which I can't seem to find a solution.

VLC [2] uses VIDIOC_CROPCAP [3] to detect the pixelaspect ratio of the input it receives from v4l2 device. But I can't seem to find a way to set struct v4l2_cropcap.pixelaspect when I'm outputting data to the device and the result is that VLC assumes pixelaspect is 1:1.

I was hoping that VIDIOC_S_CROP [4] would allow setting pixelaspect but according to docs that is not case. What am I missing?

The pixelaspect ratio returned by CROPCAP depends on the current video standard of the video receiver or transmitter.

So for video capture the pixelaspect depends on the standard (50 vs 60 Hz) and the horizontal sampling frequency of the video receiver (hardware specific).

For video output the pixelaspect depends also on the standard and on how the transmitter goes from digital to analog pixels (the reverse of what a receiver does).

Quoted 6 lines

Quoted 3 lines

It is *not* the pixelaspect of the video data itself. For output it is the pixel aspect that the transmitter expects. Any difference between the two will need to be resolved somehow, typically by software or hardware scaling.

Since I'm using virtual output v4l2 loopback device this means I have to set the standard somehow, right?

Yes, just call VIDIOC_S_STD. But the loopback device driver needs to be modified to have cropcap return the aspect ratio belonging to the given standard (or just 1x1 for non-PAL/NTSC resolutions).

I wish personally that this driver was being upstreamed to the kernel. I know that Mauro (subsystem maintainer) isn't too keen on it, but I think we can convince him that it is really a useful driver to have. And if it is part of distros anyway, then we should just accept it (after cleanup, of course).