Hi, > From: 'Sakari Ailus' [mailto:sakari.ailus@xxxxxx] > Sent: Tuesday, January 22, 2013 7:45 PM > > Hi Kamil, > > On Tue, Jan 22, 2013 at 06:58:09PM +0100, Kamil Debski wrote: > ... > > > OTOH I'm not certain what's the main purpose of such copied > > > timestamps, is it to identify which CAPTURE buffer comes from which > OUTPUT buffer ? > > > > > > > Yes, indeed. This is especially useful when the CAPTURE buffers can > be > > returned in an order different than the order of corresponding OUTPUT > > buffers. > > How about sequence numbers then? Shouldn't that be also copied? > > If you're interested in the order alone, comparing the sequence numbers > is a better way to figure out the order. That does require strict one- > to-one mapping between the output and capture buffers, though, and that > does not help in knowing when it might be a good time to display a > frame, for instance. > The idea behind copying the timestamp was that it can propagate the timestamp from the video stream. If this info is absent application can generate them and still be able to connect OUTPUT and CAPTURE frames. While decoding MPEG4 it is possible to get a compressed frame saying "nothing to do here, move along" (which basically means that the last frame should be repeated). This is where increasing sequence number comes in handy. Even if no timestamp is set the application can detect such empty frames and display the decoded video correctly. Copying sequence numbers was already discussed in January 2012 IIRC. The recommendation was that the device keeps an internal sequence counter and assigns it to both OUTPUT and CAPTURE buffers, so they can be associated. I think that we're diverting from the main topic of this discussion. My patches fix a problem and the only thing that, we cannot agree about is what the default timestamp type should be. Best wishes, -- Kamil Debski Linux Platform Group Samsung Poland R&D Center -- 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
