I’m writing a driver that will receive video data sent from a device by
isochronous transfers. Each video frame is composed of 153,600 bytes, and
these are sent across a number of packets. There currently isn’t any
start-of-frame or start-of-line information in the data, so I’m wondering
how I should handle packet errors that could occur as part of the transfer.
If I get a packet error, I need to know how many bytes of data were in the
bad packet, so I can still know where in the video frame I am. There is a
packet size field, but I suspect this field isn’t valid if there is an error
in the packet.
Would I need to have start-of-frame and start-of-line indicators in the
data, or is there a better way to do this? I’m hoping I don’t need those
indicators, since that would be extra processing time I’d need to do when
processing the data.
thanks,
Jeff
No frame or line information ? I am not a specialist in video capturing matter,
but I think you cannot rely on the non-real time windows OS’s in general, that they will
be able to catch all frames in time. Apart from corrupted packets, I think you will
have to care about “lost” packets too.
Christiaan
----- Original Message -----
From: “Jeff Helmers”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Friday, May 06, 2005 3:29 PM
Subject: [ntdev] Errors during isochronous USB transfers
> I’m writing a driver that will receive video data sent from a device by
> isochronous transfers. Each video frame is composed of 153,600 bytes, and
> these are sent across a number of packets. There currently isn’t any
> start-of-frame or start-of-line information in the data, so I’m wondering
> how I should handle packet errors that could occur as part of the transfer.
> If I get a packet error, I need to know how many bytes of data were in the
> bad packet, so I can still know where in the video frame I am. There is a
> packet size field, but I suspect this field isn’t valid if there is an error
> in the packet.
>
> Would I need to have start-of-frame and start-of-line indicators in the
> data, or is there a better way to do this? I’m hoping I don’t need those
> indicators, since that would be extra processing time I’d need to do when
> processing the data.
>
> thanks,
> Jeff
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@compaqnet.be
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
If you haven’t got ANY indication of what’s the start and/or end of the
data, how do you know what’s what? Assuming you want this to work reliably,
you will need to have some indication of where the data belongs. I guess
one way would be to have an index into the frame at regular intervals,
including a “marker” to indicate that it’s a correct place. Such as adding
0x12345678, Address, ~address, 0x87654321 at every 1KB of data. If the next
1K block doesn’t have the required tag, you’ve obviously lost some data. If
the address is incorrect compared to the expected, you could fix that up by
skipping the portion of the frame that you didn’t get.
As Christiaan points out, Windows is not a real-time OS, and it’s notorious
for poor real-time response. If you have 100% control over what hardware
goes into the system, you MAY be able to eliminate/replace such hardware
that is causing problems, but if it’s a general produt that will be sold in
any on/off-line shop to any customer, it’s definitely not going to fly
unless you have a way to cope with missing/bad packets. (Obviously being
able to buffer a large amount of data in the hardware and transmit it later
would help here, but windows is quite capable of ignoring your drivers
requests for several milliseconds given the “right” drivers, which at
(153.6* 60)KB/s gives a big window for loosing data.
Best of luck.
–
Mats
“Christiaan
Ghijselinck”
<christiaan.ghijs to> xxxxx@CompaqNet. “Windows System Software Devs
be> Interest List”
Sent by:
bounce-208508-140 cc
xxxxx@lists.osr.com
Subject
Re: [ntdev] Errors during
05/06/2005 03:14 isochronous USB transfers
PM
Please respond to
“Windows System
Software Devs
Interest List”
com>
No frame or line information ? I am not a specialist in video capturing
matter,
but I think you cannot rely on the non-real time windows OS’s in general,
that they will
be able to catch all frames in time. Apart from corrupted packets, I think
you will
have to care about “lost” packets too.
Christiaan
----- Original Message -----
From: “Jeff Helmers”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Friday, May 06, 2005 3:29 PM
Subject: [ntdev] Errors during isochronous USB transfers
> I’m writing a driver that will receive video data sent from a device by
> isochronous transfers. Each video frame is composed of 153,600 bytes,
and
> these are sent across a number of packets. There currently isn’t any
> start-of-frame or start-of-line information in the data, so I’m wondering
> how I should handle packet errors that could occur as part of the
transfer.
> If I get a packet error, I need to know how many bytes of data were in
the
> bad packet, so I can still know where in the video frame I am. There is
a
> packet size field, but I suspect this field isn’t valid if there is an
error
> in the packet.
>
> Would I need to have start-of-frame and start-of-line indicators in the
> data, or is there a better way to do this? I’m hoping I don’t need those
> indicators, since that would be extra processing time I’d need to do when
> processing the data.
>
> thanks,
> Jeff
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
xxxxx@compaqnet.be
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
ForwardSourceID:NT0001276A</christiaan.ghijs>