Testing #192
closed
Verify ffmpeg can stream video from /dev/video0
Added by Hammel almost 12 years ago.
Updated over 11 years ago.
Category:
03 - Linux Kernel
Description
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.
- Status changed from New to In Progress
- % Done changed from 0 to 10
Testing this requires getting the 7-10 port USB hub/extender board.
- % 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.
- Priority changed from Urgent to Immediate
- Severity changed from 03 - Medium to 01 - Critical
- Description updated (diff)
- % Done changed from 30 to 40
Updated usbhandler.conf with a Logitech web camera and pushed it upstream. Haven't tested it yet because I need a 10 port usb hub, which is on order.
- % 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.
Changing the gpu_mem didn't help. Adjusting with v4l2-ctl is the next test. This tool is not available in Buildroot. It lives on linuxtv.org. See the README.
- % 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.
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.
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.
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.
- 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.
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:
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.
There is an android library for ffmpeg playback that might be needed to write a custom application:
Another possibility is to use the "livestream" plugin with JWPlayer
- % 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.
- Status changed from In Progress to Closed
- % Done changed from 70 to 100
ffmpeg is streaming video to crtmpserver via piboxd now.
This issue can be closed.
Also available in: Atom
PDF
Updated by Hammel almost 12 years ago