Hi Sakari, On Friday 29 July 2011 09:44:46 Sakari Ailus wrote: > On Thu, Jul 28, 2011 at 10:36:57PM +0200, Laurent Pinchart wrote: > > On Thursday 28 July 2011 22:28:57 Sakari Ailus wrote: > > > On Thu, Jul 28, 2011 at 01:52:21PM +0200, Laurent Pinchart wrote: > > > > On Tuesday 26 July 2011 20:49:43 Sakari Ailus wrote: > > [snip] > > > > > > > + <table frame="none" pgwide="1" id="v4l2-event-frame-sync"> > > > > > + <title>struct > > > > > <structname>v4l2_event_frame_sync</structname></title> + > > > > > <tgroup cols="3"> > > > > > + &cs-str; > > > > > + <tbody valign="top"> > > > > > + <row> > > > > > + <entry>__u32</entry> > > > > > + <entry><structfield>buffer_sequence</structfield></entry> > > > > > + <entry> > > > > > + The sequence number of the buffer to be handled next or > > > > > + currently handled by the driver. > > > > > > > > What happens if a particular piece of hardware can capture two (or > > > > more) simultaneous streams from the same video source (an unscaled > > > > compressed stream and a scaled down uncompressed stream for > > > > instance) ? Applications don't need to start both streams at the > > > > same time, what buffer sequence number should be reported in that > > > > case ? > > > > > > I think that if the video data comes from the same source, the sequence > > > numbers should definitely be in sync. This would mean that for the > > > second stream the first sequence number wouldn't be zero. > > > > Then we should document this somewhere. Here is probably not the best > > place to document that, but the buffer_sequence documentation should > > still refer to the explanation. > > > > I also find the wording a bit unclear. The "buffer to be handled next" > > could mean the buffer that will be given to an application at the next > > DQBUF call. Maybe we should refer to frame sequence numbers instead of > > buffer sequence numbers. > > What's the difference? I would consider the two the same. If we have multiple simultaneous streams from the same source, I think it would make sense to start thinking about frame sequence numbers instead of buffer sequence numbers. The buffer sequence number would then just store the frame sequence number of the frame stored in the buffer. This would (in my opinion) simplify the spec's understanding. > ..."buffer to be written next to by the hardware"? What about ..."buffer that will store the image" ? -- 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
