Hi Sakari, On Sunday 02 December 2012 22:53:51 Sakari Ailus wrote: > 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? Yes, it's embedded in the compressed stream. > Could this be codec-dependent? Of course, it would be too easy otherwise :-) > > > > > 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. That sounds good to me. > For timestamp types that are hardware-dependent we could have exceptions. -- Regards, Laurent Pinchart -- 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
