https://bugzilla.kernel.org/show_bug.cgi?id=207045 --- Comment #2 from Julian Meyer (jucmeyer@xxxxxxxx) --- I did more research and I found that the problem is that the camera is sending the next UVC payload immediately after finishing the previous one instead of waiting for the next URB. I ran my camera at 640x480@30fps and found the following information: First, the camera reports the max payload size and max frame size as follows: Max Payload Size: 119296 Max Frame Size: 614400 Actual Received Payload Size (sum of all payloads): 614472 This number makes sense because it includes (frame size/payload size =) 6 payload headers of 12 bytes each, so 614472 bytes total. The last URB is truncated because it fits in 37 full 16K URBs + one 8264 byte URB. uvc_video_decode_bulk calls the following functions: 1. uvc_video_decode_start - find header length and decode it 2. uvc_video_decode_meta - decode the rest of the header metadata 3. uvc_video_decode_data - decodes data up to the max payload size and if it overflows, assume the frame is ended 4. uvc_video_decode_end - if this payload was end-of-frame, start the next frame uvc_video_decode_bulk is called from uvc_video_complete which is the completion handler for each URB. This makes it so that each URB must contain one or less payloads because we only process at most one payload per call to the completion handler. In the case of my camera, the driver hits the max payload size and assumes it's finished (the next payload is in the next URB). Then, it tries to parse the header for the next URB assuming it's a new payload even though it's actually in the middle of a payload. This causes FID mismatches and all sorts of other issues. Proposed Fix: When we see a URB that's larger than the maximum payload size, assume it's another payload and start processing the new payload. -- You are receiving this mail because: You are watching the assignee of the bug.
