Verify ffmpeg can stream video from /dev/video0
|Status:||Closed||Start date:||07 Jul 2013|
|Category:||03 - Linux Kernel|
|Target version:||1.0 - Atreides|
|Severity:||01 - Critical|
If I plug in a web camera, will v4l automatically create /dev/video0? If not, how do I get it to do so (probably through an mdev script).
Once /dev/video0 is there, will ffmpeg stream from there to an avi file?
May want to cross compile an opkg for gucview for testing purposes.
RM #192: Comment updates, plus added older version of TP wifi adapter and a Logitech webcam.
#2 Updated by Hammel almost 5 years ago
- % Done changed from 10 to 30
Webcams require uvcvideo. My webcam is supported by this driver. uvcvideo is already in the PiBox kernel config. So all that's needed is to add an entry to usbhandler.conf for the webcam to load uvcvideo. That's been done, but it's not tested on the target yet.
Once this is running I should be able to test ffmpeg reading from /dev/video0 using information from the ffmpeg wiki.
#6 Updated by Hammel almost 5 years ago
- % Done changed from 40 to 50
Initial test with webcam:
- webcam recognized on boot up and drivers correctly loaded.
- video recording worked with this command line (spaces required):
ffmpeg -f video4linux2 -r 25 -s 640x480 -i /dev/video0 out.avi
- Video transferred back to build host to view. It's blocky and a little jumpy. Probably because gpu_mem (see RM #215) is not configured for video.
Tweaking will be required. I may also need to limit the video size to something smaller, like 320x280.
#8 Updated by Hammel almost 5 years ago
- % Done changed from 50 to 60
Doh! v4lutils are included in the multimedia/XBMC package I added to PiBox, but I didn't enable the v4lutil sub package (though most of the rest of the XBMC components are enabled). Enabling the package and rebuilding worked fine. v4l2-ctl is now in the target rootfs.
Change to buildroot config pushed upstream.
Now I can try fiddling with the webcam to get a better picture at 640x480. Right now the picture is decent at 320x200 but that seems a bit small.
#9 Updated by Hammel almost 5 years ago
v4l2-ctl doesn't seem to do much to help the quality. Playing with ffmpeg helped a little. This line seems best so far:
ffmpeg -f video4linux2 -r 25 -qscale 2 -intra -s 320x240 -i /dev/video0 cam.avi
This at least has the most steady image and you can see the overhead fan spinning nearly continuously. However, all tests so far always encounter a period of freeze up in the recording. I'm not sure why yet.
My version of ffmpeg is a bit old: 0.8.2. I could try building from git.
#10 Updated by Hammel almost 5 years ago
Updated ffmpeg in buildroot to 2.0.1 (latest stable) by applying patches to package since 2013.02 release and then patching version and updating "armvfp" option to "vfp". Build completed successfully and new rootfs built. Still need to test it on the target.
If the test succeeds I'll need to supply a patch to the Buildroot mailing list to bump to 2.0.1. Patch is in src/buildroot/patches/2013.02/0044-ffmpeg-bump-to-2.0.1.patch in my sandbox.
#11 Updated by Hammel almost 5 years ago
The 2.0.1 build works but doesn't seem to show up in the rootfs. The ffmeg on the target always shows the old version. This is probably due to some kind of library update issue. The only way to be sure is to clean out my buildroot build from my sandbox and redo it from scratch. That'll take awhile to complete.
#12 Updated by Hammel almost 5 years ago
- Priority changed from Immediate to Low
Rebuild failed because the gstffmpegutils didn't like the newer ffmpeg.
Instead of spinning my wheels on this right now, I'm going to just live with the stutter and work toward a working (if not ideal) version of the complete system, then come back later and try to improve on performance. Eventually I have to upgrade the toolchain and Buildroot anyway, so I'll deal with this after I deal with those.
Moving Priority to low and moving on.
#13 Updated by Hammel almost 5 years ago
One possible way to improve performance is to stream directly from ffmpeg to a remote device. This would work fine in a travel trailer where the webcam is being used by an Android app in the tow vehicle to see behind the trailer.There are multiple discussions on how to do this:
- http://ffmpeg.gusari.org/viewtopic.php?f=12&t=920 (stream direct from ffmpeg to display host w/ffplay)
- http://ffmpeg.org/pipermail/ffmpeg-user/2013-January/012510.html (recipe to stream direct to Android)
- http://www.ciufek.net/ - Low latency streaming with ffmpeg - android source code examples
Essentially you point ffmpeg to a udp port on the target system and then point a player to read from that port on that host. Apparently you read it with RTSP, but I'm still not clear on that. I should be able to test this from PiBox to a desktop using VLC, I think. ffserver may also need to be involved.Here's an extended write up on use of ffmpeg/ffserver including streaming.
- https://groups.google.com/forum/#!topic/c-rtmp-server/AiFBwh_cdgc (use "livestream" plugin)
#14 Updated by Hammel almost 5 years ago
- % Done changed from 60 to 70
I've cross compiled ffmpeg with x264 based on a modified version of the lumux instructions (see attached cross.sh). A sanity test on pibox shows the binary works. I've not had a chance to test if streaming with it works any better.
The test to stream should be based on the gusari description of a direct stream from ffmpeg on pibox to ffplay or vlc on the build host. If that performs better than my current method then I'll look at the direct to android examples.
If direct streaming proves better than what I'm doing with crtmpserver then I'll create a cross-build package for ffmpeg.