Date: Tue, 13 Nov 2012 14:52:16 +0100 From: Hans Petter Selasky <hselasky@c2i.net> To: SAITOU Toshihide <toshi@ruby.ocn.ne.jp> Cc: freebsd-usb@freebsd.org Subject: Re: isochronous transfer packet is out of sequence Message-ID: <201211131452.16508.hselasky@c2i.net> In-Reply-To: <20121113.222652.71084426.toshi@ruby.ocn.ne.jp> References: <20121112.205208.208974549.toshi@ruby.ocn.ne.jp> <201211121342.47141.hselasky@c2i.net> <20121113.222652.71084426.toshi@ruby.ocn.ne.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 13 November 2012 14:26:52 SAITOU Toshihide wrote:
> In message: <201211121342.47141.hselasky@c2i.net>
>
> Hans Petter Selasky <hselasky@c2i.net> writes:
> > On Monday 12 November 2012 12:52:08 SAITOU Toshihide wrote:
> >> I have tryed the USB isochronous transfer for UVC cam using libusb
> >> interface and I find the packet fragment is out of sequence on the
> >> FreeBSD(1). But I don't find it on the MacBook(2).
> >>
> >> (1) FreeBSD 9.1-RC2, Intel Core i7 3770T
> >> (2) Mac OS X 10.6.8, Intel Core 2 Duo, libusb 1.0.9 (single core)
> >>
> >> Can I prevent this behaviour using libusb interface or is
> >> this an expected behaviour?
> >>
> >> The bellow I issued two libusb_submit_transfer at the beginning.
> >>
> >>
> >> ----- log (1)
> >> 049 4437e06b 0 c 818
> >> 04a 4437e06b 0 c c00
> >> 04b 4437e06b 0 c 818
> >> UVC_STREAM_EOF
> >> total a1400
> >> 04c 4402516b 1 c b9c
> >> 04d 4402516b 1 c 87c
> >> 04e 4402516b 1 c 800
> >> 04f 4402516b 1 c c00
> >> 050 4402516b 1 c 800
> >> 051 4437e06b 0 c c00
> >> 052 4437e06b 0 c 744
> >> 053 4437e06b 0 c c00
> >>
> >>
> >> ----- callback function
> >> static void cb(struct libusb_transfer *xfer)
> >> {
> >>
> >> uint8_t *p;
> >> int plen;
> >> int i;
> >>
> >> p = xfer->buffer;
> >>
> >> for (i = 0; i < xfer->num_iso_packets; i++, p += PKT_LEN)
> >> {
> >>
> >> if (xfer->iso_packet_desc[i].status ==
> >>
> >> LIBUSB_TRANSFER_COMPLETED) {
> >>
> >> plen = xfer->iso_packet_desc[i].actual_length;
> >>
> >> if (plen < 2)
> >>
> >> continue;
> >>
> >> if (p[1] & UVC_STREAM_ERR) // bmHeaderInfo
> >>
> >> continue;
> >>
> >> fprintf(stderr, "%03x ", i);
> >> fprintf(stderr, "%08x ", p[2] | p[3]<<8 |
> >> p[4]<<16
> >> |
> >> | p[5]<<24); // pts fprintf(stderr, "%01x ", p[1] & UVC_STREAM_FID); //
> >>
> >> fid fprintf(stderr, "%01x ", p[0]); // header length fprintf(stderr,
> >> "%x\n", plen); // actual length
> >>
> >> total += plen - p[0];
> >>
> >> if (p[1] & UVC_STREAM_EOF)
> >> {
> >>
> >> fprintf(stderr, "UVC_STREAM_EOF\n", total);
> >> fprintf(stderr, "total %x\n", total);
> >>
> >> if (total < FrameSize)
> >> {
> >>
> >> fprintf(stderr, "insufficient frame data.\n");
> >> write(fd, padding, FrameSize - total); // zero padding
> >>
> >> }
> >>
> >> total = 0;
> >>
> >> }
> >>
> >> write(fd, p + p[0], plen - p[0]); // write payload data
> >>
> >> }
> >>
> >> }
> >>
> >> if (libusb_submit_transfer(xfer) != 0)
> >> {
> >>
> >> fprintf(stderr, "submit transfer failed.\n");
> >>
> >> }
> >>
> >> }
> >
> > Hi,
> >
> > You need to submit two transfers for continued operation.
>
> I may have a misunderstanding but I submit two transfers at start and
> it is resubmited in the callback function, then I see the packet group
> in the wrong place. It seems that the callback function was excuted
> exclusively so the iso packets in the data buffer were out of order,
> just like the packet does not correctly assign to the two transfers.
>
> I can get the video on the MacBook(2). I confirmed using mplayer.
Hi,
Some more checkpoints:
What is the number of ISO-FRAMEs you are submitting? You should not submit too
few and not too many. And the number of frames should be divisible by 8.
Check the timing using the usbdump tool.
--HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201211131452.16508.hselasky>