Hi Laurent,
Thanks again for your reply.
On 03/04/2014 12:11 PM, Laurent Pinchart wrote:
Hi Mark,
On Friday 28 February 2014 10:34:24 Mark Ryan wrote:
On 02/26/2014 04:40 PM, Laurent Pinchart wrote:
[ ... ]
With the information I've given you, could you try to log more information
in the driver to try and find what goes wrong ? You could for instance
log the content of each header at the beginning of the
uvc_video_decode_start() function.
So maybe I have something here. I ran guvcview and set the format to
MJPEG running at a high resolution. I'm using the kernel 3.11.0-17 that
comes with Ubuntu 13.10. In the usbmon logs I see the following.
[...]
SETUP Host-to-device Class request to Interface
bRequest: SET CUR (01)
wValue: 0200
wIndex: INTF 1 ENTITY 0 (0001)
wLength: 001a
26 data bytes
bmHint 0x01
bFormatIndex 2
bFrameIndex 10
dwFrameInterval 333333
wKeyFrameRate 0
wPFrameRate 0
wCompQuality 0
wCompWindowSize 0
wDelay 32
dwMaxVideoFrameSize 1843200
dwMaxPayloadTransferSize 34816
Note the dwMaxPayloadTransferSize of 34816
[...]
Now I have my first payload
16384 data bytes
0c8d863e 8c007d67 .†>Œ.}g
8e00b304 ffd8ffdb Ž.³.ÿØÿÛ
00430003 02020202 .C......
02030202 02030303 ........
16384 data bytes
fbf5aeff 00c25e12 ûõ®ÿ.Â^.
5d1244d5 353b2437 ].DÕ5;$7
f92d06e6 24c28475 ù-.æ$„u
c740c6b3 8bbb29ad Ç@Ƴ‹»)
16384 data bytes
f1a3cc60 b8200c52 ñ£Ì`¸ .R
0108eac3 1cd4610e ..êÃ.Ôa.
ece45032 40c477a8 ìäP2@Äw¨
e4f35b81 d05001fc äó[ÐP.ü
16384 data bytes
fb3528d1 bc4fcc56 û5(ѼOÌV
fe2d9522 1d04b1e7 þ-•"..±ç
3fa1a9e5 2b9867f6 ?¡©å+˜gö
778e2dd0 7d9b57b5 wŽ-Ð}›Wµ
16384 data bytes
c016baf6 99732c9a À.ºö™s,š
9db39b7b e6b995a4 ³›{湕¤
65751f78 649eb5ed eu.xdžµí
9e2dfdb1 355fd9fa ž-ý±5_Ùú
16384 data bytes
a73d4053 8fad795c §=@Sy\
c9088170 ec1c1e54 É.pì..T
9ce6a59a d89f5742 œæ¥šØŸWB
82cf3297 26d95b18 ‚Ï2—&Ù[.
16384 data bytes
b4d3b21b d4a53595 ´Ó².Ô¥5•
99cac904 2e1bb346 ™ÊÉ...³F
09fe555e 4d2b4b95 .þU^M+K•
be6b488a 0e91b0ca ¾kHŠ.‘°Ê
16384 data bytes
3adb9dbc 6323ad21 :Û¼c#!
8aa85b9d b934d31e Š¨[¹4Ó.
465885f6 a00ad25c FX…ö .Ò\
04fdd44b be43d08a .ýÔK¾CЊ
16384 data bytes
14f1cf4c 0ae43589 .ñÏL.ä5‰
0acdbd0b c8afedc2 .ͽ.ȯíÂ
f15d4339 8bfb5b2b ñ]C9‹û[+
df39e42d 14ecb849 ß9ä-.ì¸I
10466 data bytes
7fffd1fc af99e466 ÿÑü¯™äf
c39cd475 cab500a2 ÃœÔuʵ.¢
ad8ae147 d295ec0c ŠáGÒ•ì.
bd639196 3cfa0ad5 ½c‘–<ú.Õ
14 data bytes
0c8f863e 8c000fd7 .†>Œ..×
9300cb04 ffd9 “.Ë.ÿÙ
The problem seems to be that the payload sent by the camera is much larger
than dwMaxPayloadTransferSize. For this reason the driver assumes that it
has found the end of the frame after processing the third URB. This test is
performed at the bottom of uvc_video_decode_bulk. It then expects URB 4 to
be the start of a new frame, which it isn't, and so it gets out of sync. If
I understand correctly, dwMaxPayloadTransferSize is set by the camera, so
perhaps the camera is at fault here.
Yes, I believe the camera violates the spec.
Interestingly, I checked some wireshark logs I took while using the camera
with the Dell XPS12 booted into Windows and I see the exact same thing. The
dwMaxPayloadTransferSize is set to 34816, but the payloads were much larger,
around 140kb.
What bulk URB size did Windows use ?
As the camera works fine on Windows, I'm guessing Windows is not relying on
the dwMaxPayloadTransferSize to detect the end of a payload. Perhaps it just
uses the FID. Does this sound plausible? If so, I might see if I can
replicate this behaviour locally, to see if it solves the issue.
I don't think it uses the FID, as that requires the presence of a header,
which is only present at the beginning of payloads, and thus require the
driver to be able to detect the payload in the first place.
With the three USB traces I've received so far for your camera it seems that
we could detect the end of a payload by a short URBs. Maybe that's what
Windows does. This would however probably break if the MJPEG data size +
header size happens to be a multiple of 16kB.
Have you looked at the YUYV capture traces ? What's the data pattern there ? I
would expect the last 14 bytes transfer not to be present for YUYV. Does the
camera use a single payload in that case as well ?
I have, and the behaviour seems to differ depending on the frameIndex.
I haven't tested all of the resolutions yet, but here are the two main
patterns I see for YVUV.
- For some resolutions, each frame is split up into multiple payloads,
each of which are equal in size to the dwMaxPayloadTransferSize, apart
perhaps from the last. Each payload consists of a single URB ( I hope
this is the correct terminology ) and has a header. The total size of
the payload equals the dwMaxPayloadFrameSize + (Number of URBs * 12).
- For other resolutions, there is a single payload per frame. The
payload itself is split over multiple URBs. The payload is not
terminated by a URB containing just a header, i.e., a URB of 14 bytes,
as you guessed. The size of the entire payload is equal to the
dwMaxPayloadFrameSize + 12 and is lower than the dwMaxPayloadTransferSize.
I'm going to carry on investigating and will report back here once I
have a complete picture of the camera's behaviour.
--
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
