LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software
User Name
Password
Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.

Notices


Reply
  Search this Thread
Old 12-15-2018, 02:07 PM   #1
haertig
Senior Member
 
Registered: Nov 2004
Distribution: Debian, Ubuntu, LinuxMint, Slackware, SysrescueCD, Raspbian, Arch
Posts: 2,283

Rep: Reputation: 354Reputation: 354Reputation: 354Reputation: 354
Question: Video streaming with VLC


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:

Code:
cvlc v4l2:///dev/video0 :v4l2-width=320 :v4l2-height=240 --sout '#transcode{vcodec=h264,venc=x264{preset=ultrafast},acodec=none}:rtp{sdp=rtsp://:8554/stream}'
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):

Code:
cvlc rtsp://10.192.0.27:8554/stream
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
Click image for larger version

Name:	pi_top.png
Views:	8
Size:	72.5 KB
ID:	29185   Click image for larger version

Name:	initial.png
Views:	11
Size:	172.4 KB
ID:	29186  
 
Old 12-15-2018, 03:05 PM   #2
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware & Android
Posts: 10,989

Rep: Reputation: 1250Reputation: 1250Reputation: 1250Reputation: 1250Reputation: 1250Reputation: 1250Reputation: 1250Reputation: 1250Reputation: 1250
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!
 
Old 12-15-2018, 05:00 PM   #3
haertig
Senior Member
 
Registered: Nov 2004
Distribution: Debian, Ubuntu, LinuxMint, Slackware, SysrescueCD, Raspbian, Arch
Posts: 2,283

Original Poster
Rep: Reputation: 354Reputation: 354Reputation: 354Reputation: 354
Thanks for the quick reply! I think you hit on many of my bottlenecks in your suggestions.
Quote:
Originally Posted by business_kid View Post
  1. Camera - Maximum framerate? - I don't know, but it is really old and was really cheap. That does not equate to "high framerate".
  2. USB - Are we usb 1/2/3? - The camera is USB 1.3, the single board computer it is plugged into is USB 2
  3. What's the transfer rate from the camera into the box? - I don't know
  4. Is anything encrypted? Travelling over encrypted networks puts an overhead on. - Nothing encrypted so far, but eventually will be when I open it to the internet.
  5. Any other networking lags you haven't mentioned. - The Raspberry Pi3 single board computer is only USB 2 (which is fine with my USB 1 camera!) However, this single board computer SHARES the USB bandwidth with the network bandwidth (at least the WiFi shares, I don't know if the Ethernet shares - doesn't matter since I'm using WiFi, thus it is shared for sure). So I'm kind of taking a double hit there.
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. - This makes sense. That would also help explain the fast motion blur I see with this setup.

My seat of pants type guess is that the webcam is a POS (yes), & the usb is usb-2.0 or worse (yes). Hence the lag. Just doing the sums, a 320x240 picture with 20% overscan should manage ~10FPS on USB-1.0!
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.
 
Old 12-16-2018, 03:49 AM   #4
ondoho
LQ Addict
 
Registered: Dec 2013
Posts: 13,390
Blog Entries: 9

Rep: Reputation: 3654Reputation: 3654Reputation: 3654Reputation: 3654Reputation: 3654Reputation: 3654Reputation: 3654Reputation: 3654Reputation: 3654Reputation: 3654Reputation: 3654
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)
 
Old 12-18-2018, 10:51 PM   #5
haertig
Senior Member
 
Registered: Nov 2004
Distribution: Debian, Ubuntu, LinuxMint, Slackware, SysrescueCD, Raspbian, Arch
Posts: 2,283

Original Poster
Rep: Reputation: 354Reputation: 354Reputation: 354Reputation: 354
Quote:
Originally Posted by ondoho View Post
can't you just push the raw data as provided by the webcam through the network,
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!

Last edited by haertig; 12-18-2018 at 10:53 PM.
 
Old 12-19-2018, 06:15 AM   #6
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware & Android
Posts: 10,989

Rep: Reputation: 1250Reputation: 1250Reputation: 1250Reputation: 1250Reputation: 1250Reputation: 1250Reputation: 1250Reputation: 1250Reputation: 1250
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.
 
Old 12-21-2018, 02:13 AM   #7
ondoho
LQ Addict
 
Registered: Dec 2013
Posts: 13,390
Blog Entries: 9

Rep: Reputation: 3654Reputation: 3654Reputation: 3654Reputation: 3654Reputation: 3654Reputation: 3654Reputation: 3654Reputation: 3654Reputation: 3654Reputation: 3654Reputation: 3654
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Early Inventor Of Streaming Video Wants To Help Fight Off Video Streaming Patent Trolls LXer Syndicated Linux News 0 10-06-2012 05:40 AM
LXer: Early Inventor Of Streaming Video Wants To Help Fight Off Video Streaming Patent Trolls LXer Syndicated Linux News 0 10-06-2012 03:50 AM
[SOLVED] video streaming support with VLC(?) as the streaming server wachi Linux - Embedded & Single-board computer 3 03-28-2011 01:35 PM
Darwin streaming server Video streaming local only ahmed_as8 Linux - Networking 2 05-28-2009 03:52 PM
VLC error: VLC could not open the file "/usr/share/vlc/skins2/text.bmp". brjoon1021 Ubuntu 1 01-14-2009 11:48 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Software

All times are GMT -5. The time now is 12:26 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration