Le dimanche 19 mars 2017 à 09:55 +0000, Russell King - ARM Linux a écrit : > 2) would it also make sense to allow gstreamer's v4l2src to try > setting > a these parameters, and only fail if it's unable to set it? IOW, > if > I use: > > gst-launch-1.0 v4l2src device=/dev/video10 ! \ > video/x-bayer,format=RGGB,framerate=20/1 ! ... > > where G_PARM says its currently configured for 25fps, but a S_PARM > with 20fps would actually succeed. In current design, v4l2src will "probe" all possible formats, cache this, and use this information for negotiation. So after the caps has been probed, there will be no TRY_FMT or anything like this happening until it's too late. You have spotted a bug though, it should be reading back the parm structure to validate (and probably produce a not-negotiated error here). Recently, specially for the IMX work done by Pengutronix, there was contributions to enhance this probing to support probing capabilities that are not enumerable (e.g. interlacing, colorimetry) using TRY_FMT. There is no TRY_PARM in the API to implement similar fallback. Also, those ended up creating a massive disaster for slow cameras. We now have UVC cameras that takes 6s or more to start. I have no other choice but to rewrite that now. We will negotiate the non-enumerable at the last minute with TRY_FMT (when the subset is at it's smallest). This will by accident add support for this camera interface, but that wasn't the goal. It would still fail with application that enumerates the possible resolutions and framerate and let you select them with a drop- down (like cheese). In general, I can only conclude that making everything that matter enumerable is the only working way to go for generic userspace. Nicolas
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
