I have a question on video streaming using VLC. My goal is to run a webcam on a single board computer and view it's output on a different computer on my LAN. I want to do this using a low power single board computer (ultimately a Pi Zero W probably) and I don't want to write video or large quantities of temp files to the microSD card holding the file system on the single board computer (so it doesn't wear out prematurely). So the quick solutions you see on the web that say "apt-get install motion" are not appropriate. "motion" works, ... if you are willing to put up with a framerate of about 0.5 and hammer your microSD card to death in short order.

My concept prove-in and testing video setup is a Raspberry Pi3 running Raspbian Stretch Lite. Connected to my LAN via WiFi. I attached an old, cheap USB 1.3 webcam. I installed VLC. I run the following command on the Pi3 to stream the webcam:

I run the following command on my Linux desktop (different computer) to view the video stream (the Pi3's IP is 10.192.0.27, the choice of port 8554 is arbitrary):

Basically, this works, and does not overtax the meager CPU capabilities of the Pi3 (see the 'top' screenshot below). Note that "preset=ultrafast" forces the encoder to "profile=baseline", which keeps the CPU utilization lower. I can up the video resolution to 640x480 and the Pi3 can still keep up (CPU use triples though). If I remove "preset=ultrafast" then the encoder switches to "profile=high" which is too much for the poor little Pi3 to handle.

OK, by "Basically, this works", I mean that from the time I fire up VLC on the viewing computer until the first image appears is about 5 seconds. And that initial image is unusable (see screenshot below) for about 8 seconds, until it finally clears up and the video looks good. I haven't looked to find out the framerate I am getting, but it is adequate for my use (there is blurring of fast motion and dropped frames, but the video does not appear to stall or freeze). Additionally, there is about a 1-1/2 second lag between motion seen by the webcam being updated on the viewing computer screen. This lag never goes away and is present for the entire viewing session.

None of these problems affect my intended usage - I can accept the initial startup corrupted video that lasts for a few seconds, and the lag is fine (I'm just watching my front yard). 320x240 while small, is adequate.

My question is: Are there better VLC settings I can choose on the Pi3 that would result in better performance? This exercise is purely about learning VLC on the low-horsepower Pi3 at the moment. I am looking to eventually move this to a Pi Zero W (less computing power), use a Pi camera board rather than a USB webcam, and also make it available over the internet using HTTP rather than RTSP. Given these planned changes, performance will become a bigger concern.

p.s. - I did note, that when I gave this my first try using HTTP rather than RTSP, the viewing computer web browser (Chromium) tried to download a file rather than stream the video. That's a bridge I will investigate and cross when I get to it, but if anyone knows what's up with that, a hint now might save me some time later. Thanks!

Attached Thumbnails

   

To me (No expert in streaming), your cvlc invocations look well thought out, but you don't know the bottleneck(s). May I suggest

1. Camera - Maximum framerate?
2. USB - Are we usb 1/2/3?
3. What's the transfer rate from the camera into the box?
4. Is anything encrypted? Travelling over encrypted networks puts an overhead on.
5. Any other networking lags you haven't mentioned.

The taking seconds to come up I think I can explain. I had one of those video cards once. I souped it up as directed by devs, and it wouldn't lip synch a fullscreen video. It could only write a fraction of the screen every time. That's what's happening to you. It's taking you a lot of writes to get one full picture.

My seat of pants type guess is that the webcam is a POS, & the usb is usb-2.0 or worse. Hence the lag. Just doing the sums, a 320x240 picture with 20% overscan should manage ~10FPS on USB-1.0!

Thanks for the quick reply! I think you hit on many of my bottlenecks in your suggestions.
Based on your very good speculations here, I'm thinking that my performance might paradoxically be better once I switch to my final target platform: a Pi Zero W with the Pi camera board. Even though the Pi Zero has less CPU horsepower (and less memory) than the Pi3 I am currently using, CPU and memory do not appear to be my bottlenecks, at least not when I'm using the low-end video transcoder settings that I am. My bottleneck would seem to be I/O. The Pi camera board interfaces directly to I/O pins on the single board computer, thus it would probably be a faster interface than USB. I guess I'll find that out when I try it - it will depend in part on the quality of the Pi's software interface to the camera. Plus, the shared nature of USB/network on the Pi should not come into play with the more direct camera connection. Things would probably improve even more if I used an Ethernet connection rather than WiFi, but unfortunately that won't be happening because the physical location of the device is not near an Ethernet jack in my house. Another way to improve performance might be to continue with a USB webcam, but buy a good one that does it's own h264 encoding in hardware. Thus the single board computer would be freed from that task. But since this is more or less a "play" application for me, I don't really want to spend the money to get a really good webcam. I just don't need that. It would also be worthwhile to investigate other single board computer platforms that don't have the I/O limitations of the Raspberry Pi platform. Possibly an Odroid XU4.

can't you just push the raw data as provided by the webcam through the network, and treat it as video only at the destination?
(i would assume that the webcam already compresses its output on-chip - but i know woefully little about webcams - if it was really raw video data, it might be too much)
that way you wouldn't need any media software at all on the pi zero.
tbh, even vlc seems a bit heavy.
if it needs to be treated as video/media, i'd at least try to use ffmpeg instead.

(sorry if you touched on these subjects already; i admit i did not read all of your topic)

I don't know how to "push the raw data through the network" other than using something like vlc as a middleman. You mentioned ffmpeg ... I didn't realize that you could stream directly from that, but I did some Googling and indeed you can. So I will investigate using that in place of vlc and do some testing of performance differences to see which works better.

When I first started this project, I tried using vlc to stream the webcam data without transcoding. But because I don't know what the webcam sends out natively, I just tried guessing. I tried h264 (I knew that wouldn't work since this is such an old webcam). I also guessed at mpeg-2 and mjpeg. I could never get any of these to display video at the receiving end. So either none of these was the correct format, or I was doing something else wrong. Only if I transcoded the initial video could I make things work. I tried transcoding using mjpeg and h264, the mjpeg was much lower quality but did not save on resources over h264, so I just stuck with h264. Also, I could not make mpeg-2 transcoding work (a missing codec?) Honestly, I didn't try very hard, and just switched back to h264 since the pi was able to handle h264 without straining (at lower settings).

Thanks!

Maybe you should research ondoho's suggestion. This is your project. As someone said: "Research is what I'm doing when I don't know what I'm doing."

We can declare solution #1 a failure, your webcam underspecified, etc. The one place you seem to have spare capacity is network bandwith. Yes, install more codecs if you have to. DEFINITELY read more.

The ~10FPS I quoted earlier was based on 360x240 with 20% overscan (very heavy - I don't think there's any overscan) transferring FULL pictures @1.0MB/S. You're getting about 2 FPS and it's taking 5 seconds to come up +8 seconds to be usable, say 15 seconds to be complete To me, that sounds like you're getting about 1/30 of an image in each frame, 1/15th or 6.66% of an image in a second. Something is drastically, drastically wrong. Somebody could come in, steal stuff, and go home and your camera wouldn't notice :-o.

You can probably buy what you want for a few €/$/£/¥ from Aliexpress, Ebay, or any large mail order outfit. If you're proceeding to reinvent the wheel, Change that %£@&€! webcam for starters.

i'm not sure what the specs of a pi zero are.
but i'm guessing that any sort of transcoding-on-the-fly will bring it to its knees.