GNOME Bugzilla – Bug 700285
v4l2: set pixel-aspect-ratio for capture devices only
Last modified: 2013-06-04 15:38:29 UTC
Created attachment 244159 [details] [review] patch I'm not quite sure if this is correct. However without this I have been unable play video files with a different pixel-aspect-ratio on a v4l2sink. The v4l2sink doesn't realy know what aspect ratio is used to show the frames, so I don't think we gain anything from enforcing it.
Is there a way to specify or get the pixel-aspect-ratio of output devices? Otherwise it should really be forced to 1/1, because you won't be able to guarantee that videos are shown with the correct aspect ratio in the end.
For example, is it possible to tell v4l2 that the 100x100 frames should be displayed as 200x100?
Well, there are some ioctls to define a output rectangle. However, I'm not really sure how and when they are supposed to be used, and the implementations are, as far as I can tell not really consistent. There are newer ones, but I'm not sure if there are actually used anywhere. Also, if you consider TV outputs, I'm not sure if assuming that the real pixel aspect ratio is 1/1 makes sense. Anyways, I don't really have a strong opinion either way. I just want to play strange video files with a pixel aspect ration other than 1/1 on embedded hardware, where scaling the video is just not acceptable. If there is any other way to ignore it, then I'm happy with that too.
How do you make sure that the output uses the correct pixel-aspect-ratio in your case, i.e. scales stuff accordingly? I agree that something needs to be done here, just fixing it to 1/1 is not ideal. Just not sure what V4L2 offers us to properly implement that here...
According to VLC people, this information if part of VIDIOC_CROPCAP. I have not looked in depth, so this is left as an excersize, see http://mailman.videolan.org/pipermail/vlc-commits/2012-April/014207.html.
I missed that one. That seems to be the way to go. Maybe In combination with pixel-aspect-ratio/force-aspect-ratio like xvimagesink? That way the application can overwrite it in case the driver does not provide it.
Yes, sounds like the way to go :) Is there something similar for capture devices too or are they always outputting 1/1 pixel-aspect-ratio?
Created attachment 245980 [details] [review] improve pixel aspect ratio handling How about this patch? Is g_param_spec_string correct for a fraction? All elements that have a pixel-aspect-ratio property use it. VIDIOC_CROPCAP is for both capture and output devices. From the documentation of the ioctl: "This ioctl must be implemented for video capture or output devices that support cropping and/or scaling and/or have non-square pixels, and for overlay devices."
commit 74d217c44be6007d83a3e270300f0708b5fe895c Author: Michael Olbrich <m.olbrich@pengutronix.de> Date: Tue Jun 4 08:26:33 2013 +0200 v4l2: improve pixel aspect ratio handling Instead of just assuming a aspect ratio of 1/1 use VIDIOC_CROPCAP to ask the device. This also add a pixel-aspect-ratio property to overwrite the value from the driver and a force-aspect-ratio property to ignore it. https://bugzilla.gnome.org/show_bug.cgi?id=700285