GNOME Bugzilla – Bug 753562
v4l2src: Implemented timecode metadata
Last modified: 2016-07-26 15:50:33 UTC
The current implementation of v4l2src does not propagate the timecode information on the v4l2_buffer struct. This patch solves this issue by adding this information to the buffer as metadata.
Created attachment 309151 [details] [review] Patch for timecode metadata
Review of attachment 309151 [details] [review]: That's a big patch, with a short description. It should be clear in the patch that you want to add a new public API, and describe need and use of this public API. This is a major change being here as you are asking us to commit to this new API as stable. What I don't like with the approach in this patch is that it assumes that it's fine to consider adding a meta exclusively for one 64 bits timecode. What about the sequence number ? Is there possibly other meta's that are not reachable / accessible ? What does this time code mean, how is it used ? Is this timecode supposed to correlate with some existing GStreamer mechanism (stream position maybe ?) ?
(for maintainers, this is no material for 1.6, will have to wait for 1.8)
As I was not myself well aware of this API, I took the liberty to ask Hans Verkuil about it. He explained that these time code are intended to be used for codes found outside of the overscan area on SD-TV recording (mostly for recorded tapes). This was use for synchronization when reusing these tapes in post-production. In GStreamer, this is called "stream time", and with a rate of 1.0 and base time of 0, this should match the stream position. Doing this, would effectively let GStreamer do what it's designed for, synchronize the streams. I also gathered Hans' opinion: <hverkuil> Well, apparently nobody ever does, because there are no drivers that actually use it. <hverkuil> We've been wondering whether it should just be removed, or marked deprecated or whatever. <hverkuil> I wouldn't add support for it to gstreamer, unless someone has a really good use-case. So here we are, I'd like to know more about why you'd like to use this kernel API.
Hello and thanks for the feedback! In my setup I am using a camera that is taking frames from a moving conveyor. The conveyor has a rotary encoder attached to it, which provides pulses for how many steps the conveyor has done from the last time it was queried. What the v4l2 driver I am working with is doing is it is receiving the pulses that have been recorded since the last buffer dequeue and is storing that information under the userbits array under the v4l2_timecode structure. As for the patch size, the bulk of the patch are copied videodev2 headers that are currently under /sys/v4l2/ext. This is probably not the best solution, I could have pointed the makefile to them under sys instead. If any alternatives can be suggested I would be more than willing to implement a change. However, I am not aware of any other API that v4l2 provides for this kind of case. To be honest, I thought that the reason the timecode userdata existed in the first place was for storing this kind of information.
Thanks for taking the time to report this. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 753592 ***
Also see https://bugzilla.gnome.org/show_bug.cgi?id=766419