Hi Laurent, Thanks for the comments. On Tue, Nov 27, 2012 at 05:04:29PM +0100, Laurent Pinchart wrote: > On Thursday 22 November 2012 01:59:00 Sakari Ailus wrote: > > On Wed, Nov 21, 2012 at 11:53:02PM +0100, Hans Verkuil wrote: ,,, > > > What do you think? > > > > Fine for me. Sylwester also brought memory-to-memory devices (and > > memory-to-memory processing whether the device is classified as such in API > > or not) to my attention. For those devices it likely wouldn't matter at all > > what's the system time when the frame is processed since the frame wasn't > > captured at that time anyway. > > > > In those cases it might makes sense to use timestamp that e.g. comes from > > the compressed stream, or pass encoder timestamps that are going to be part > > of the compressed stream. I think MPEG-related use cases were briefly > > mentioned in the timestamp discussion earlier. > > When uncompressing a stream you will get the MPEG embedded timestamp on the > capture side. The timestamp returned to userspace at QBUF time on the output > side will still be unused. I don't really see a use case for returning the > timestamp at which the frame is expected to be processed by the codec, so we > could just make the field reserved for future use in that case. Is the timestamp embedded in the compressed data itself in that case, or where? Could this be codec-dependent? > > > > The driver stores the time at which > > > > + the first data byte was actually sent out in the > > > > + <structfield>timestamp</structfield> field. > > > > > > Same problem as with the capture time: does the timestamp refer to the > > > first or last byte that's sent out? I think all output drivers set it to > > > the time of the last byte (== when the DMA of the frame is finished). > > > > I haven't actually even seen a capture driver that would do otherwise, but > > that could be just me not knowing many enough. :-) Would we actually break > > something if we changed the definition to say that this is the timestamp > > taken when the frame is done? > > For software timestamps we could do that, but for hardware timestamps the > exact timestamping time may vary. Should we then do this for the timestamps that are obtained from the system clock? We also haven't defined other kinds of tiemstamps yet. For timestamp types that are hardware-dependent we could have exceptions. -- Kind regards, Sakari Ailus e-mail: sakari.ailus@xxxxxx XMPP: sailus@xxxxxxxxxxxxxx -- 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
