0

I have a c930e camera:

$ v4l2-ctl --list-devices
Logitech Webcam C930e (usb-0000:00:1d.0-1.3):
    /dev/video0

I checked the capabilities like so:

$ ffmpeg -f v4l2 -list_formats all -i /dev/video0
[video4linux2,v4l2 @ 0x56094badd800] Raw       :     yuyv422 :           YUYV 4:2:2 : 640x480 160x120 176x144 320x180 320x240 352x288 424x240 480x270 640x360 800x448 800x600 848x480 960x540 1024x576 1280x720 1600x896 1920x1080 2304x1296 2304x1536
[video4linux2,v4l2 @ 0x56094badd800] Compressed:       mjpeg :          Motion-JPEG : 640x480 160x120 176x144 320x180 320x240 352x288 424x240 480x270 640x360 800x448 800x600 848x480 960x540 1024x576 1280x720 1600x896 1920x1080

So it supports 1920x1080 in mjpeg. That's what I want to stream...

Just in case, make sure v4l2 supports the formats:

$ v4l2-ctl --list-formats
ioctl: VIDIOC_ENUM_FMT
    Index       : 0
    Type        : Video Capture
    Pixel Format: 'YUYV'
    Name        : YUYV 4:2:2

    Index       : 1
    Type        : Video Capture
    Pixel Format: 'MJPG' (compressed)
    Name        : Motion-JPEG

I also checked the input format with ffprobe to see the frame rate like so:

$ ffprobe /dev/video0 -input_format mjpeg
  libavutil      55. 78.100 / 55. 78.100
  libavcodec     57.107.100 / 57.107.100
  libavformat    57. 83.100 / 57. 83.100
  libavdevice    57. 10.100 / 57. 10.100
  libavfilter     6.107.100 /  6.107.100
  libavresample   3.  7.  0 /  3.  7.  0
  libswscale      4.  8.100 /  4.  8.100
  libswresample   2.  9.100 /  2.  9.100
  libpostproc    54.  7.100 / 54.  7.100
Input #0, video4linux2,v4l2, from '/dev/video0':
  Duration: N/A, start: 79986.526080, bitrate: N/A
    Stream #0:0: Video: mjpeg, yuvj422p(pc, bt470bg/unknown/unknown), 1920x1080, 30 fps, 30 tbr, 1000k tbn, 1000k tbc

That tells us 30 fps in 1920x1080 in the mjpeg format.

However, once I started the streaming server and then ffmpeg to actually stream the data, I get this message:

$ ffmpeg -f video4linux2 -s 1920x1080 -r 5 -re -i /dev/video0 -input_format mjpeg -an -vcodec libx264 -bf 5 http://localhost:8090/wall.ffm
Input #0, video4linux2,v4l2, from '/dev/video0':
  Duration: N/A, start: 78055.235551, bitrate: 165888 kb/s
    Stream #0:0: Video: rawvideo (YUY2 / 0x32595559), yuyv422, 1920x1080, 165888 kb/s, 5 fps, 5 tbr, 1000k tbn, 1000k tbc
[tcp @ 0x555677149fc0] Connection to tcp://localhost:8090 failed (Connection refused), trying next address
[tcp @ 0x555677147da0] Connection to tcp://localhost:8090 failed (Connection refused), trying next address
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> mpeg1video (native))
Press [q] to stop, [?] for help
Output #0, ffm, to 'http://localhost:8090/wall.ffm':
  Metadata:
    creation_time   : now
    encoder         : Lavf57.83.100
    Stream #0:0: Video: mpeg1video, yuv420p, 1920x1080, q=2-31, 15000 kb/s, 5 fps, 1000k tbn, 30 tbc
    Metadata:
      encoder         : Lavc57.107.100 mpeg1video
    Side data:
      cpb: bitrate max/min/avg: 30000000/0/15000000 buffer size: 1572864000 vbv_delay: -1

which shows 5 fps.

When I change the -r to anything higher than 5, I get errors and it goes back to 5 fps anyway (its more like a megaton of errors on the screen):

Past duration 2.999992 too large

The duration amount is between 3 and 5 too large.

Where could be the problem?

As far as I know USB-2 can transfer 480mbps, which is way more than the 5mbps and also less than what the network interface can support (100mbps). So the data should flow at full speed, no frame dropped on my local network, shouldn't it?

P.S. I have a raspberry Pi 3 B+

Improve this question
2
  • 2
    I think the issue is that your expectations of what a Pi is capable of are too high. The Pi is being asked to capture a large image and stream it. The Pi has limited memory and depending on the model a single or multiple core processor. The Pi likely can not keep pace with what you are asking it to do. .Just because the camera is capable of a higher frame rate doesn't mean the system is. The system can only run as fast as the slowest component. As for the theoretical maximum, you are already close to it if increasing the frame rate causes errors
    – Steve Robillard
    Jul 21, 2020 at 5:52
  • @SteveRobillard Well, it doesn't seem that bad. 4K doesn't work, but I can do 1080p on the video board, I don't see why transferring the camera data would be that slow...
    – Alexis Wilke
    Jul 21, 2020 at 6:05

1 Answer 1

Reset to default
2

Maybe the problem is that you are using x264 to encode the stream. The x264 is a software H264 encoder, and the pi is not fast enough for realtime software H264 encoding. You can try with the pi's hardware encoder too with the h264_v4l2m2m ffmpeg codec.

This camera contains a H264 encoder too. I managed to get H264 stream from it at 30fps and send over HTTP as MP4 (H264) with a very little overhead. My solution uses the UVC H264 extension unit to configure the camera's encoder.

If you are interested, the code is on github: fmp4streamer (Use the MJPGH264 capture format in the configuration file for this camera)

Improve this answer
2
  • Am I right to assume that this is your own project? In that case you should disclose this clearly in your answer.
    – Dmitry Grigoryev
    Feb 21, 2022 at 8:31
  • 1
    Yes, it is. Thanks for the alignment.
    – soyer
    Feb 21, 2022 at 11:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.