Frame synchronisation events and support for them in the OMAP 3 ISP driver

Define a frame start event to tell user space when the reception of a frame starts.

Signed-off-by Sakari Ailus <[email protected]>

---
 Documentation/DocBook/media/v4l/vidioc-dqevent.xml |   23

++++++++++++++++++++ .../DocBook/media/v4l/vidioc-subscribe-event.xml |
18 +++++++++++++++ include/linux/videodev2.h |
12 +++++++-- 3 files changed, 50 insertions(+), 3 deletions(-)

(quoted diff) +0 -0

b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml index 5200b68..1d03313 100644

Documentation/DocBook/media/v4l/vidioc-dqevent.xml +7 -0

@@ -88,6 +88,12 @@
 	  </row>
 	  <row>
 	    <entry></entry>
+	    <entry>&v4l2-event-frame-sync;</entry>
+            <entry><structfield>frame</structfield></entry>
+	    <entry>Event data for event V4L2_EVENT_FRAME_SYNC.</entry>
+	  </row>
+	  <row>
+	    <entry></entry>
 	    <entry>__u8</entry>
             <entry><structfield>data</structfield>[64]</entry>
 	    <entry>Event data. Defined by the event type. The union

@@ -220,6 +226,23 @@
       </tgroup>
     </table>
 
+    <table frame="none" pgwide="1" id="v4l2-event-frame-sync">

Documentation/DocBook/media/v4l/vidioc-dqevent.xml +6 -0

+	    </entry>
+	  </row>
+	</tbody>
+      </tgroup>
+    </table>
+
     <table pgwide="1" frame="none" id="changes-flags">
       <title>Changes</title>
       <tgroup cols="3">

(quoted diff) +0 -0

b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml index 275be96..812b63c 100644

Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml +5 -0

@@ -139,6 +139,24 @@
 	    </entry>
 	  </row>
 	  <row>
+	    <entry><constant>V4L2_EVENT_FRAME_SYNC</constant></entry>
+	    <entry>4</entry>
+	    <entry>
+	      <para>Triggered immediately when the reception of a
+	      frame has begun. This event has a

Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml +3 -0

+	    </entry>
+	  </row>
+	  <row>
 	    <entry><constant>V4L2_EVENT_PRIVATE_START</constant></entry>
 	    <entry>0x08000000</entry>
 	    <entry>Base event number for driver-private events.</entry>

include/linux/videodev2.h +9 -3

index fca24cc..056a49e 100644
@@ -2006,6 +2006,7 @@ struct v4l2_streamparm {
 #define V4L2_EVENT_VSYNC			1
 #define V4L2_EVENT_EOS				2
 #define V4L2_EVENT_CTRL				3
+#define V4L2_EVENT_FRAME_SYNC			4
 #define V4L2_EVENT_PRIVATE_START		0x08000000
 
 /* Payload for V4L2_EVENT_VSYNC */

@@ -2032,12 +2033,17 @@ struct v4l2_event_ctrl {
 	__s32 default_value;
 };
 
+struct v4l2_event_frame_sync {
+	__u32 buffer_sequence;
+};
+
 struct v4l2_event {
 	__u32				type;
 	union {
-		struct v4l2_event_vsync vsync;
-		struct v4l2_event_ctrl	ctrl;
-		__u8			data[64];
+		struct v4l2_event_vsync		vsync;
+		struct v4l2_event_ctrl		ctrl;
+		struct v4l2_event_frame_sync	frame_sync;
+		__u8				data[64];
 	} u;
 	__u32				pending;
 	__u32				sequence;

Hi Sakari,

Quoted 2 lines

Define a frame start event to tell user space when the reception of a frame starts.

You might want to rename 'frame start' to 'frame sync' in the subject and commit message as well.

Quoted 38 lines

Signed-off-by Sakari Ailus <[email protected]>

---
 Documentation/DocBook/media/v4l/vidioc-dqevent.xml |   23

++++++++++++++++++++ .../DocBook/media/v4l/vidioc-subscribe-event.xml |
18 +++++++++++++++ include/linux/videodev2.h |
12 +++++++-- 3 files changed, 50 insertions(+), 3 deletions(-)

(quoted diff) +0 -0

b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml index 5200b68..1d03313 100644

Documentation/DocBook/media/v4l/vidioc-dqevent.xml +15 -0

@@ -88,6 +88,12 @@
 	  </row>
 	  <row>
 	    <entry></entry>
+	    <entry>&v4l2-event-frame-sync;</entry>
+            <entry><structfield>frame</structfield></entry>
+	    <entry>Event data for event V4L2_EVENT_FRAME_SYNC.</entry>
+	  </row>
+	  <row>
+	    <entry></entry>
 	    <entry>__u8</entry>
             <entry><structfield>data</structfield>[64]</entry>
 	    <entry>Event data. Defined by the event type. The union

@@ -220,6 +226,23 @@
       </tgroup>
     </table>
 
+    <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>

Documentation/DocBook/media/v4l/vidioc-dqevent.xml line 239

Quoted 2 lines

Documentation/DocBook/media/v4l/vidioc-dqevent.xml +2 -0

+	      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 ?

Quoted 29 lines

Documentation/DocBook/media/v4l/vidioc-dqevent.xml +6 -0

+	    </entry>
+	  </row>
+	</tbody>
+      </tgroup>
+    </table>
+
     <table pgwide="1" frame="none" id="changes-flags">
       <title>Changes</title>
       <tgroup cols="3">

(quoted diff) +0 -0

b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml index 275be96..812b63c 100644

Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml +11 -0

@@ -139,6 +139,24 @@
 	    </entry>
 	  </row>
 	  <row>
+	    <entry><constant>V4L2_EVENT_FRAME_SYNC</constant></entry>
+	    <entry>4</entry>
+	    <entry>
+	      <para>Triggered immediately when the reception of a
+	      frame has begun. This event has a
+	      &v4l2-event-frame-sync; associated with it.</para>
+
+	      <para>A driver will only generate this event when the
+	      hardware can generate it. This might not be the case
+	      e.g. when the hardware has no DMA buffer to write the
+	      image data to. In such cases the

Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml line 156

Quoted 4 lines

Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml +4 -0

+	      <structfield>buffer_sequence</structfield> field in
+	      &v4l2-event-frame-sync; will not be incremented either.
+	      This causes two consecutive buffer sequence numbers to
+	      have n times frame interval in between them.</para>

I don't think that's correct. Don't many drivers still increment the sequence number in that case, to make it possible for applications to detect frame loss ?

Quoted 39 lines

Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml +3 -0

+	    </entry>
+	  </row>
+	  <row>
 	    <entry><constant>V4L2_EVENT_PRIVATE_START</constant></entry>
 	    <entry>0x08000000</entry>
 	    <entry>Base event number for driver-private events.</entry>

include/linux/videodev2.h +9 -3

index fca24cc..056a49e 100644
@@ -2006,6 +2006,7 @@ struct v4l2_streamparm {
 #define V4L2_EVENT_VSYNC			1
 #define V4L2_EVENT_EOS				2
 #define V4L2_EVENT_CTRL				3
+#define V4L2_EVENT_FRAME_SYNC			4
 #define V4L2_EVENT_PRIVATE_START		0x08000000
 
 /* Payload for V4L2_EVENT_VSYNC */

@@ -2032,12 +2033,17 @@ struct v4l2_event_ctrl {
 	__s32 default_value;
 };
 
+struct v4l2_event_frame_sync {
+	__u32 buffer_sequence;
+};
+
 struct v4l2_event {
 	__u32				type;
 	union {
-		struct v4l2_event_vsync vsync;
-		struct v4l2_event_ctrl	ctrl;
-		__u8			data[64];
+		struct v4l2_event_vsync		vsync;
+		struct v4l2_event_ctrl		ctrl;
+		struct v4l2_event_frame_sync	frame_sync;
+		__u8				data[64];
 	} u;
 	__u32				pending;
 	__u32				sequence;

Signature · 3 lines

Regards,

Laurent Pinchart

Quoted 1 line · Laurent Pinchart

On Tuesday 26 July 2011 20:49:43 Sakari Ailus wrote:

Quoted 10 lines

Quoted 10 lines

(quoted diff) +2 -0

+    <table frame="none" pgwide="1" id="v4l2-event-frame-sync">
+      <title>struct

<structname>v4l2_event_frame_sync</structname></title> + <tgroup
cols="3">

Documentation/DocBook/media/v4l/vidioc-dqevent.xml +6 -0

+	&cs-str;
+	<tbody valign="top">
+	  <row>
+	    <entry>__u32</entry>
+	    <entry><structfield>buffer_sequence</structfield></entry>
+	    <entry>

Quoted 8 lines

Documentation/DocBook/media/v4l/vidioc-dqevent.xml line 239

Quoted 2 lines

Documentation/DocBook/media/v4l/vidioc-dqevent.xml +2 -0

+	      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.

Quoted 35 lines

Quoted 35 lines

Documentation/DocBook/media/v4l/vidioc-dqevent.xml +6 -0

+	    </entry>
+	  </row>
+	</tbody>
+      </tgroup>
+    </table>
+
 
     <table pgwide="1" frame="none" id="changes-flags">
 
       <title>Changes</title>
       <tgroup cols="3">

(quoted diff) +0 -0

b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml index 275be96..812b63c 100644

Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml +11 -0

@@ -139,6 +139,24 @@
 
 	    </entry>
 
 	  </row>
 	  <row>
 
+	    <entry><constant>V4L2_EVENT_FRAME_SYNC</constant></entry>
+	    <entry>4</entry>
+	    <entry>
+	      <para>Triggered immediately when the reception of a
+	      frame has begun. This event has a
+	      &v4l2-event-frame-sync; associated with it.</para>
+
+	      <para>A driver will only generate this event when the
+	      hardware can generate it. This might not be the case
+	      e.g. when the hardware has no DMA buffer to write the
+	      image data to. In such cases the

Quoted 8 lines

Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml line 156

Quoted 4 lines

Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml +4 -0

+	      <structfield>buffer_sequence</structfield> field in
+	      &v4l2-event-frame-sync; will not be incremented either.
+	      This causes two consecutive buffer sequence numbers to
+	      have n times frame interval in between them.</para>

I don't think that's correct. Don't many drivers still increment the sequence number in that case, to make it possible for applications to detect frame loss ?

I think I understood once that the OMAP 3 ISP driver didn't do this in all cases but I later learned that this isn't the case. I still would be actually a bit surprised if there was not hardware that could not do this.

Do you think the text is relevant in this context, or should it be removed?

Hi Sakari,

Quoted 2 lines · Laurent Pinchart

Quoted 1 line · On Tuesday 26 July 2011 20:49:43 Sakari Ailus wrote:

[snip]

Quoted 19 lines

Quoted 10 lines

Quoted 10 lines

(quoted diff) +2 -0

+    <table frame="none" pgwide="1" id="v4l2-event-frame-sync">
+      <title>struct

<structname>v4l2_event_frame_sync</structname></title> + <tgroup
cols="3">

Documentation/DocBook/media/v4l/vidioc-dqevent.xml +6 -0

+	&cs-str;
+	<tbody valign="top">
+	  <row>
+	    <entry>__u32</entry>
+	    <entry><structfield>buffer_sequence</structfield></entry>
+	    <entry>

Quoted 8 lines

Documentation/DocBook/media/v4l/vidioc-dqevent.xml line 239

Quoted 2 lines

Documentation/DocBook/media/v4l/vidioc-dqevent.xml +2 -0

+	      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 ?

Quoted 3 lines

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.

Quoted 44 lines

Quoted 43 lines

Quoted 29 lines

Documentation/DocBook/media/v4l/vidioc-dqevent.xml +6 -0

+	    </entry>
+	  </row>
+	</tbody>
+      </tgroup>
+    </table>
+
 
     <table pgwide="1" frame="none" id="changes-flags">
 
       <title>Changes</title>
       <tgroup cols="3">

(quoted diff) +0 -0

b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml index 275be96..812b63c 100644

Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml +5 -0

@@ -139,6 +139,24 @@
 
 	    </entry>
 
 	  </row>
 	  <row>
 
+	    <entry><constant>V4L2_EVENT_FRAME_SYNC</constant></entry>
+	    <entry>4</entry>
+	    <entry>
+	      <para>Triggered immediately when the reception of a
+	      frame has begun. This event has a

Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml line 159

Quoted 10 lines

Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml +10 -0

+	      &v4l2-event-frame-sync; associated with it.</para>
+
+	      <para>A driver will only generate this event when the
+	      hardware can generate it. This might not be the case
+	      e.g. when the hardware has no DMA buffer to write the
+	      image data to. In such cases the
+	      <structfield>buffer_sequence</structfield> field in
+	      &v4l2-event-frame-sync; will not be incremented either.
+	      This causes two consecutive buffer sequence numbers to
+	      have n times frame interval in between them.</para>

I don't think that's correct. Don't many drivers still increment the sequence number in that case, to make it possible for applications to detect frame loss ?

Quoted 5 lines

I think I understood once that the OMAP 3 ISP driver didn't do this in all cases but I later learned that this isn't the case. I still would be actually a bit surprised if there was not hardware that could not do this.

Do you think the text is relevant in this context, or should it be removed?

I think you should just mention that the event *might* not be generated if the hardware needs to be stopped in case of buffer underrun for instance.

Quoted 33 lines · Laurent Pinchart

Quoted 2 lines · On Thursday 28 July 2011 22:28:57 Sakari Ailus wrote:

Quoted 1 line · Laurent Pinchart

On Tuesday 26 July 2011 20:49:43 Sakari Ailus wrote:

[snip]

Quoted 20 lines

Quoted 11 lines

Quoted 11 lines

(quoted diff) +2 -0

+    <table frame="none" pgwide="1" id="v4l2-event-frame-sync">
+      <title>struct

<structname>v4l2_event_frame_sync</structname></title> + <tgroup cols="3">

Documentation/DocBook/media/v4l/vidioc-dqevent.xml +7 -0

+	&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

Quoted 8 lines

Documentation/DocBook/media/v4l/vidioc-dqevent.xml line 239

Quoted 1 line

Documentation/DocBook/media/v4l/vidioc-dqevent.xml +1 -0

+	      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 ?

Quoted 3 lines

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.

Quoted 4 lines

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.

..."buffer to be written next to by the hardware"?

Hi Sakari,

Quoted 39 lines · On Friday 29 July 2011 09:44:46 Sakari Ailus wrote:

Quoted 37 lines · Laurent Pinchart

Quoted 2 lines · On Thursday 28 July 2011 22:28:57 Sakari Ailus wrote:

Quoted 1 line · Laurent Pinchart

On Tuesday 26 July 2011 20:49:43 Sakari Ailus wrote:

[snip]

Quoted 20 lines

Quoted 11 lines

Quoted 11 lines

(quoted diff) +2 -0

+    <table frame="none" pgwide="1" id="v4l2-event-frame-sync">
+      <title>struct

<structname>v4l2_event_frame_sync</structname></title> + <tgroup cols="3">

Documentation/DocBook/media/v4l/vidioc-dqevent.xml +7 -0

+	&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

Quoted 8 lines

Documentation/DocBook/media/v4l/vidioc-dqevent.xml line 239

Quoted 1 line

Documentation/DocBook/media/v4l/vidioc-dqevent.xml +1 -0

+	      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 ?

Quoted 3 lines

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.

Quoted 1 line

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.

Quoted 1 line

..."buffer to be written next to by the hardware"?

What about ..."buffer that will store the image" ?

Quoted 41 lines · Laurent Pinchart

Quoted 40 lines · On Friday 29 July 2011 09:44:46 Sakari Ailus wrote:

Quoted 38 lines · Laurent Pinchart

Quoted 2 lines · On Thursday 28 July 2011 22:28:57 Sakari Ailus wrote:

Quoted 1 line · Laurent Pinchart

On Tuesday 26 July 2011 20:49:43 Sakari Ailus wrote:

[snip]

Quoted 20 lines

Quoted 11 lines

Quoted 11 lines

(quoted diff) +2 -0

+    <table frame="none" pgwide="1" id="v4l2-event-frame-sync">
+      <title>struct

<structname>v4l2_event_frame_sync</structname></title> + <tgroup cols="3">

(quoted diff) +7 -0

+	&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

Quoted 8 lines

Review

Quoted 1 line

(quoted diff) +1 -0

+	      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 ?

Quoted 4 lines

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.

Quoted 7 lines

Quoted 1 line

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.

Another good point from you, I agree with this.

Quoted 3 lines

Quoted 1 line

..."buffer to be written next to by the hardware"?

What about ..."buffer that will store the image" ?

But which image? And if there is no buffer, no image is written to it either.

"frame to be processed or being processed by the hardware"?

Quoted 56 lines · On Friday 29 July 2011 11:54:03 Sakari Ailus wrote:

Quoted 41 lines · Laurent Pinchart

Quoted 40 lines · On Friday 29 July 2011 09:44:46 Sakari Ailus wrote:

Quoted 38 lines · Laurent Pinchart

Quoted 2 lines · On Thursday 28 July 2011 22:28:57 Sakari Ailus wrote:

Quoted 1 line · Laurent Pinchart

On Tuesday 26 July 2011 20:49:43 Sakari Ailus wrote:

[snip]

Quoted 20 lines

Quoted 11 lines

Quoted 11 lines

(quoted diff) +2 -0

+    <table frame="none" pgwide="1" id="v4l2-event-frame-sync">
+      <title>struct

<structname>v4l2_event_frame_sync</structname></title> + <tgroup cols="3">

(quoted diff) +7 -0

+	&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

Quoted 8 lines

Review

Quoted 1 line

(quoted diff) +1 -0

+	      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 ?

Quoted 4 lines

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.

Quoted 7 lines

Quoted 1 line

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.

Another good point from you, I agree with this.

Quoted 3 lines

Quoted 1 line

..."buffer to be written next to by the hardware"?

What about ..."buffer that will store the image" ?

Quoted 4 lines

But which image? And if there is no buffer, no image is written to it either.

"frame to be processed or being processed by the hardware"?

"frame being received" ? This is a *frame* sync event, it should contain the sequence number of the frame that triggered it.