uvc bulk

[rrrrrrobot]

Operating System

Linux

Board

stm32f746g-disco

Firmware

/device/video_capture commit：433ffe2152ea3763fcd8d5b108f694d2c6cb826d hs mode

What happened ?

ubuntu cannot enable UVC BULK transport Don't support Linux? Windows supports the display of images

How to reproduce ?

run demo hs mode CFG_TUD_VIDEO_STREAMING_EP_BUFSIZE 512

:~$ v4l2-ctl --device=/dev/video0 --set-fmt-video=width=640,height=480,pixelformat=YUYV --stream-mmap --stream-to=file.raw VIDIOC_STREAMON returned -1 (Cannot allocate memory)

Debug Log as txt file (LOG/CFG_TUSB_DEBUG=2)

USBD Setup Received 80 00 00 00 00 00 02 00 Get Status Queue EP 80 with 2 bytes ... USBD Xfer Complete on EP 80 with 2 bytes Queue EP 00 with 0 bytes ... USBD Xfer Complete on EP 00 with 0 bytes

USBD Setup Received 21 01 00 01 01 00 30 00 VIDEO control request Queue EP 00 with 48 bytes ... USBD Xfer Complete on EP 00 with 48 bytes 0000: 01 00 01 01 10 27 00 00 00 00 00 00 00 00 00 00 |.....'..........| 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| VIDEO control complete Queue EP 80 with 0 bytes ... USBD Xfer Complete on EP 80 with 0 bytes

USBD Setup Received A1 82 00 01 01 00 30 00 VIDEO control request Queue EP 80 with 48 bytes ... USBD Xfer Complete on EP 80 with 48 bytes VIDEO control complete Queue EP 00 with 0 bytes ... USBD Xfer Complete on EP 00 with 0 bytes

USBD Setup Received A1 83 00 01 01 00 30 00 VIDEO control request Queue EP 80 with 48 bytes ... USBD Xfer Complete on EP 80 with 48 bytes VIDEO control complete Queue EP 00 with 0 bytes ... USBD Xfer Complete on EP 00 with 0 bytes

USBD Setup Received 21 01 00 01 01 00 30 00 VIDEO control request Queue EP 00 with 48 bytes ... USBD Xfer Complete on EP 00 with 48 bytes 0000: 01 00 01 01 10 27 00 00 00 00 00 00 01 00 00 00 |.....'..........| 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| VIDEO control complete Queue EP 80 with 0 bytes ... USBD Xfer Complete on EP 80 with 0 bytes

USBD Setup Received A1 81 00 01 01 00 30 00 VIDEO control request Queue EP 80 with 48 bytes ... USBD Xfer Complete on EP 80 with 48 bytes VIDEO control complete Queue EP 00 with 0 bytes ... USBD Xfer Complete on EP 00 with 0 bytes

USBD Setup Received 21 01 00 02 01 00 30 00 VIDEO control request Queue EP 00 with 48 bytes ... USBD Xfer Complete on EP 00 with 48 bytes 0000: 01 00 01 01 10 27 00 00 01 00 00 00 01 00 01 00 |.....'..........| 0010: 00 00 00 60 09 00 00 02 00 00 C0 FC 9B 01 03 01 |...`............| 0020: 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| VIDEO control complete Queue EP 80 with 0 bytes ... Queue EP 81 with 2048 bytes ... USBD Xfer Complete on EP 80 with 0 bytes

USBD Setup Received 01 0B 00 00 01 00 00 00 Set Interface VIDEO control request reopen VS 0 CLOSING Endpoint: 0x81 close EP81 Open EP 81 with Size = 512 Allocated 512 bytes at offset 3520 open EP81 Queue EP 80 with 0 bytes ... USBD Xfer Complete on EP 80 with 0 bytes

Screenshots

No response

I have checked existing issues, dicussion and documentation

• [X] I confirm I have checked existing issues, dicussion and documentation.

[rrrrrrobot]

:~$ v4l2-ctl --device=/dev/video0 --set-fmt-video=width=128,height=96,pixelformat=YUYV --stream-mmap --stream-to=file.raw VIDIOC_STREAMON returned -1 (Cannot allocate memory)

[rrrrrrobot]

test_log.txt

[rrrrrrobot]

[Staacks]

Sorry, I did not see that all the details are already in this issue when I asked for them in #1985.

So, I just checked out the latest master branch and built the video_capture example (in isochronous mode at first). Since I don't have an STM32 I tested it on a Pi Pico and ran your command:

    dicon@camelot:~$ v4l2-ctl --device=/dev/video4 --set-fmt-video=width=128,height=96,pixelformat=YUYV --stream-mmap --stream-to=file.raw
    <<<<<< 7.35 fps, dropped buffers: 3
    <<<<<<<<<< 8.65 fps
    <<<<<<<<<< 9.11 fps
    <<<<<<<<<< 9.28 fps
    <<<<<<<<<< 9.43 fps
    <<<<<<<<<< 9.54 fps
    <<<<<<<<<< 9.62 fps
    <<<<<^C

I then changed CFG_TUD_VIDEO_STREAMING_BULK to 1 and repeated the test:

    dicon@camelot:~$ v4l2-ctl --device=/dev/video4 --set-fmt-video=width=128,height=96,pixelformat=YUYV --stream-mmap --stream-to=file.raw
    <<<<<<<<<<<< 10.00 fps
    <<<<<<<<<< 10.00 fps
    <<<<<<<<<< 10.00 fps
    <<<<<<<<<< 10.00 fps
    <<<<<<<<<< 10.00 fps
    <<<<<<<<<< 10.00 fps
    <<<<<<<<<< 10.00 fps
    <<<^C

So, on a Pi Pico it works as intended. Not sure if it could be something specific to the STM32 or your Linux version. But in my experience so far, the Linux UVC driver is much more forgiving than the Windows or MacOS one.

However, I also compared my output from lsusb and it is 100% identical except for one difference: My default configuration has wMaxPacketSize set to 64 B, but yours is set to 512 B. It is actually hardcoded to 64 B in the example, but if the STM32 is a high-speed device it makes sense to increase it to 512 B. Could be that there is a problem with the code in High Speed mode. Unfortunately, my Pico Pi is only a Full Speed device, so 64 B is the limit for me.

lsusb output for reference: lsusb_uvc_pi_pico.txt

[rrrrrrobot]

Thank you so much for the split test I pull up the latest code, commit： f1e006d09bd32088ab421d0b519eb89c531eda4e Using full speed wMaxPacketSize set to 64 B (default) git diff： // video streaming endpoint size -#define CFG_TUD_VIDEO_STREAMING_EP_BUFSIZE 256 +#define CFG_TUD_VIDEO_STREAMING_EP_BUFSIZE 64

// use bulk endpoint for streaming interface -#define CFG_TUD_VIDEO_STREAMING_BULK 0 +#define CFG_TUD_VIDEO_STREAMING_BULK 1

make cmd： make BOARD=stm32f746disco DEBUG=1 LOG=1 SPEED=full PORT=0 all

lsusb_bulk_uvc.txt

Run the previous command, the result is still the previous error

My Linux system information： Ubuntu 22.04.2 LTS 64-bit Linux robot 5.19.0-46-generic #47~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Wed Jun 21 15:35:31 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

I have also tested it on different versions of ubuntu on other computers and the results are the same。 At the same time, I also purchased the Pico Pi and did a comparative test after arriving. Same computer system, same code version, but different circuit board, which should be more illustrative。

[Staacks]

Really strange. Your Pi Pico results and comparing those should be interesting.

There is one thing that I am wondering about, though: If I am not mistaken, CFG_TUD_VIDEO_STREAMING_EP_BUFSIZE only has an impact on internal buffering in the examples, because the actual endpoint size is hard-coded for bulk mode in the example: https://github.com/hathach/tinyusb/blob/f1e006d09bd32088ab421d0b519eb89c531eda4e/examples/device/video_capture/src/usb_descriptors.c#L120 and https://github.com/hathach/tinyusb/blob/f1e006d09bd32088ab421d0b519eb89c531eda4e/examples/device/video_capture/src/usb_descriptors.c#L130

Did you change that part of the example for the high speed mode?

[rrrrrrobot]

Sorry, maybe I didn't make it clear. I used stm32f746disco, USB IP is dwc2, and the purchased Pi Pico has not yet reached.

[Staacks]

No, sorry, I understood that. I meant that I am curious if the Pi Pico will work for you. And if it does, what would be the difference to the STM32 in Full Speed mode.

The other thing I was wondering about is that if I read the code correctly, the example should have set a 64B endpoint unless you changed lines 120 and 130. (Still, even if this was a problem, it should also be a problem in Windows.)

[rrrrrrobot]

I didn't change lines 120 and 130, as you can see from my descriptors (lsusb_bulk_uvc.txt), I actually needed to use the high speed mode of DWC2, which is the IP most common in STM32

[Staacks]

Ah, ok. I really wish the Pi Pico could do High Speed...

[rrrrrrobot]

Perhaps there are some compatibility issues with the dwc2 driver

[rrrrrrobot]

As far as the current phenomenon is concerned, speed is not the most important, want to find out why DWC2 bulk mode does not produce images in Linux

[rrrrrrobot]

After stm32f746disco and pico pi tests, the same configuration parameters, the same Linux system, stm32f746disco can not open normally in Linux, pico pi can, it is likely that there is a compatibility problem with the dwc2 IP driver.

[kkitayam]

I actually needed to use the high speed mode of DWC2, which is the IP most common in STM32

Unfortunately, current UVC implementation only supports Full Speed but High Speed.

Packet format of UVC is difference between FS and HS. Current implementation makes packets for FS format. If I had a HS device, I would try to add support for HS.

[rrrrrrobot]

I actually needed to use the high speed mode of DWC2, which is the IP most common in STM32

Unfortunately, current UVC implementation only supports Full Speed but High Speed.

Packet format of UVC is difference between FS and HS. Current implementation makes packets for FS format. If I had a HS device, I would try to add support for HS.

Thank you very much for your support. After two different USB IP tests, it is determined that the stm32 UVC bulk transmission problem has nothing to do with the speed mode. Of course, HS mode is a very useful feature