Re: [RFC] Timestamps and V4L2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 09/22/2012 10:28 PM, Daniel Glöckner wrote:
> On Sat, Sep 22, 2012 at 07:12:52PM +0200, Sylwester Nawrocki wrote:
>> If we ever need the clock selection API I would vote for an IOCTL.
>> The controls API is a bad choice for something such fundamental as
>> type of clock for buffer timestamping IMHO. Let's stop making the
>> controls API a dumping ground for almost everything in V4L2! ;)
> 
>> Perhaps VIDIOC_QUERYBUF and VIDIOC_DQBUF should be reporting
>> timestamps type only for the time they are being called. Not per buffer,
>> per device. And applications would be checking the flags any time they
>> want to find out what is the buffer timestamp type. Or every time if it
>> don't have full control over the device (S/G_PRIORITY).
> 
> I'm all for adding an IOCTL, but if we think about adding a
> VIDIOC_S_TIMESTAMP_TYPE in the future, we might as well add a
> VIDIOC_G_TIMESTAMP_TYPE right now. Old drivers will return ENOSYS,
> so the application knows it will have to guess the type (or take own
> timestamps).

Hmm, would it make sense to design a single ioctl that would allow
getting and setting the clock type, e.g. VIDIOC_CLOCK/TIMESTAMP_TYPE ?

> I can't imagine anything useful coming from an app that has to process
> timestamps that change their source every now and then and I seriously
> doubt anyone will go to such an extent that they check the timestamp
> type on every buffer. If they don't set their priority high enough to
> prevent others from changing the timestamp type, they also run the
> risk of someone else changing the image format. It should be enough to
> forbid changing the timestamp type while I/O is in progress, as it is
> done for VIDIOC_S_FMT.

I agree, but mem-to-mem devices can have multiple logically independent,
"concurrent" streams active. If the clock type is per device it might 
not be that straightforward...


Regards,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux