0

I'm trying to capture full field of view video from my Raspberry Pi camera (by full field-of-view I mean video that uses the full 2592x1944 set of pixels on the image sensor but that is downsampled to 1920x1440 for output). Been following a great tutorial on this by Lewis Roberts at http://www.lewisroberts.com/2015/05/15/raspberry-pi-mjpeg-at-30fps/

I can stream video just fine across my network with the commands suggested in that post. But I want to write the video to a file for post processing. So I updated the cvlc command as follows:

cvlc –no-audio \
v4l2:///dev/video0 \
–v4l2-width 1920 \
–v4l2-height 1440 \
–v4l2-chroma MJPG \
–v4l2-hflip 1 \
–v4l2-vflip 1 \
–sout=file/ts:filename.mpg

It saves to a file just fine. However, if I open the VLC gui on the RPi, nothing shows up. I can pull the mpg file over to my Windows machine and open it up in VLC. The upper half of the video frames play just fine. However the lower half of the frame seems frozen to the 1st frame captured.

Looking at the ‘Messages’ dialog in VLC – the following warnings show up:

…
avcodec warning: plane 0 not aligned
avcodec warning: disabling direct rendering
core debug: End of video preroll
core debug: Received first picture
hqdn3d debug: Changing coefs to 6.94 6.00 2.56 4.50
avcodec warning: cannot decode one frame (1777 bytes)
core debug: Decoder wait done in 201 ms
avcodec warning: cannot decode one frame (13009 bytes)
avcodec warning: cannot decode one frame (65500 bytes)
…

(it then proceeds to give a long string of not being able to decode one frame…)

I thought the problem might be the data rate – i.e. that the SD card write speeds could not keep up – so I slowed the feed to 5 FPS. However, the result is the same … or even worse! I tested the write speed of the SD card on my raspberry pi using the command:

sync; dd if=/dev/zero of=~/test.tmp bs=500k count=1024

and it comes in at about 10.4 MB/s (‘mega-bytes per second). Looking at task manager, when streaming, the required bandwidth is ~ 11 Mbps (‘mega-bits-per-second’). So the SD card should be about 8x faster than required to keep up with the generated video stream.

Am I doing something wrong with my write-to-file command? Is there another way to write the generated video to a file on the pi (or record to file from another computer) given that the streaming is working fine?

gboy
  • 111
  • 1
  • I would ditch using cvlc and just use uv4l directly; when I started screwing with the camera this is the only way I could get, e.g., a remote stream without noticeable latency (beyond what the network introduces; on a LAN it seems instantaneous). http://raspberrypi.stackexchange.com/a/50344/5538 You can use it to set up /dev/uv4l and then read a file from there, just beware not all formats will work that way, I think. H.264 is definitely fine. – goldilocks Jun 25 '16 at 13:12
  • As noted there I get data rates of ~12 MB/s at full resolution and 30 fps, which is more than the pi's I/O can handle; although you can reconnect as much as you like, the connection only usually works for a few seconds. 960 x 544, 30 fps is fine but still 8 MB/s, which it is capable of maintaining indefinitely (unless you are outside the LAN, in which case the internet itself may cut you off at that rate). – goldilocks Jun 25 '16 at 13:15

1 Answers1

1

I figured out what my problem was. I was using the wrong 'muxer'. When I switched to using the 'ogg' muxer, I was able to write to a file just fine. For the record, the command that is working for me is as follows:

cvlc –no-audio \
v4l2:///dev/video0 \
–v4l2-width 1920 \
–v4l2-height 1440 \
–v4l2-chroma MJPG \
--run-time=10 \
–sout=file/ogg:/tmp/filename.mpg \
vlc:\\quit

Two things I added to this command are:

  1. The '--run-time' specifier to capture just a limited duration of video (10 seconds in this case).
  2. The 'vlc:\quit' command at the end to close out vlc at the end and return control to the command prompt.

One other thing I did before capturing any video was to mount the /tmp folder to the tmpfs. Then, by writing to this folder partition, we write directly to RAM, eliminating the SD Card from the file-write process (just in case that was adding a bottleneck to the process).

gboy
  • 111
  • 1