1
I'm using avconv
on a Raspberry Pi to try to fetch a still image from an IP camera with an RTSP stream of H.264 video:
$ avconv -v verbose -i $url -fflags discardcorrupt -t 00:00:01 -r 0.1 -an -vsync 1 -qscale 1 -f image2 images%09d.jpg
I'm having some problems, presumably because the CPU on the Pi is not able to keep up with decoding the video, so sometimes the resulting JPEG is corrupted, for example:
Probably 80% of the time I can get a valid image from the above command, but 20% of the time I get the above image which would throw a wrench into my plans to compile a time-lapse from a live video feed. I added -fflags discardcorrupt
thinking it would help, but it did not seem to do much. I only want to get one single image, so that is why there is the 1-second duration defined and -r
which is set to be less than 1fps.
Anything I can do to ensure that avconv
only ever outputs valid video frame stills?
The output from an invocation of avconv
that resulted in corrupted video frame stills:
avconv version 0.8.4-6:0.8.4-1+rpi1, Copyright (c) 2000-2012 the Libav developers
built on Nov 5 2012 22:22:18 with gcc 4.6.3
configuration: --arch=arm --enable-pthreads --enable-runtime-cpudetect --extra-version='6:0.8.4-1+rpi1' --libdir=/usr/lib/arm-linux-gnueabihf --prefix=/usr --disable-yasm --enable-bzlib --enable-libdc1394 --enable-libdirac --enable-libfreetype --enable-frei0r --enable-gnutls --enable-libgsm --enable-libmp3lame --enable-librtmp --enable-libopencv --enable-libopenjpeg --enable-libpulse --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-vaapi --enable-vdpau --enable-libvorbis --enable-libvpx --enable-zlib --enable-gpl --enable-postproc --enable-swscale --enable-libcdio --enable-x11grab --enable-libx264 --enable-libxvid --shlibdir=/usr/lib/arm-linux-gnueabihf --enable-shared --disable-static
libavutil 51. 22. 1 / 51. 22. 1
libavcodec 53. 35. 0 / 53. 35. 0
libavformat 53. 21. 0 / 53. 21. 0
libavdevice 53. 2. 0 / 53. 2. 0
libavfilter 2. 15. 0 / 2. 15. 0
libswscale 2. 1. 0 / 2. 1. 0
libpostproc 52. 0. 0 / 52. 0. 0
[rtsp @ 0x930680] SDP:
v=0
o=- 1357489248942653 1 IN IP4 192.0.1.123
s=LIVE555 Streaming Media v
i=LIVE555 Streaming Media v
t=0 0
a=tool:LIVE555 Streaming Media v2010.04.09
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:LIVE555 Streaming Media v
a=x-qt-text-inf:LIVE555 Streaming Media v
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:1000
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=64001F;sprop-parameter-sets=J2QAH62IDkOYIOEMKQpEByHMEHCGFIUiA5DmCDhDCkKQwEIYwhxmMhCGAhDGEOMxkIQwEIYwhxmMhCICEZjOI8KfEfiP4j8R8R4ziMREQoEIjEcR4j5PxH8n5PiPEcRkiLQHgLdgKpAAAAMAEAAAAwPGBAAExLAAExLL3vheEQjU,KO48sA==
a=control:track1
m=audio 0 RTP/AVP 97
c=IN IP4 0.0.0.0
b=AS:64
a=rtpmap:97 MPEG4-GENERIC/8000
a=fmtp:97 streamtype=5;profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1588
a=control:track2
[h264 @ 0x9345a0] Missing reference picture
[h264 @ 0x9345a0] decode_slice_header error
[h264 @ 0x9345a0] concealing 2700 DC, 2700 AC, 2700 MV errors
[h264 @ 0x9345a0] concealing 2454 DC, 2454 AC, 2454 MV errors
[rtsp @ 0x930680] Estimating duration from bitrate, this may be inaccurate
Input #0, rtsp, from 'rtsp://192.0.1.123:554':
Metadata:
title : LIVE555 Streaming Media v
comment : LIVE555 Streaming Media v
Duration: N/A, start: 0.000000, bitrate: N/A
Stream #0.0: Video: h264 (High), yuvj420p, 960x720 [PAR 1:1 DAR 4:3], 30 fps, 30 tbr, 90k tbn, 60 tbc
Stream #0.1: Audio: aac, 8000 Hz, mono, s16
[buffer @ 0x9fa5c0] w:960 h:720 pixfmt:yuvj420p
Output #0, image2, to 'images%09d.jpg':
Metadata:
title : LIVE555 Streaming Media v
comment : LIVE555 Streaming Media v
encoder : Lavf53.21.0
Stream #0.0: Video: mjpeg, yuvj420p, 960x720 [PAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 90k tbn, 0.10 tbc
Stream mapping:
Stream #0:0 -> #0:0 (h264 -> mjpeg)
Press ctrl-c to stop encoding
[h264 @ 0x9345a0] Missing reference picture
[h264 @ 0x9345a0] decode_slice_header error
[h264 @ 0x9345a0] concealing 2700 DC, 2700 AC, 2700 MV errors
*** drop! 1 fps= 0 q=1.0 size= -0kB time=10.00 bitrate= -0.0kbits/s
*** drop! 2 fps= 1 q=1.0 size= -0kB time=20.00 bitrate= -0.0kbits/s dup=0 drop=1
Last message repeated 1 times
[h264 @ 0x9345a0] concealing 2454 DC, 2454 AC, 2454 MV errors
*** drop!
error while decoding MB 15 2, bytestream (-17)=20.00 bitrate= -0.0kbits/s dup=0 drop=4
[h264 @ 0x9345a0] concealing 2614 DC, 2614 AC, 2614 MV errors
*** drop!
error while decoding MB 23 29, bytestream (-9)=20.00 bitrate= -0.0kbits/s dup=0 drop=5
[h264 @ 0x9345a0] concealing 986 DC, 986 AC, 986 MV errors
*** drop!
error while decoding MB 5 35, bytestream (-13)=20.00 bitrate= -0.0kbits/s dup=0 drop=6
[h264 @ 0x9345a0] concealing 644 DC, 644 AC, 644 MV errors
*** drop!
error while decoding MB 39 15, bytestream (-37)20.00 bitrate= -0.0kbits/s dup=0 drop=7
[h264 @ 0x9345a0] concealing 1810 DC, 1810 AC, 1810 MV errors
frame= 2 fps= 0 q=1.0 Lsize= -0kB time=20.00 bitrate= -0.0kbits/s dup=0 drop=7
video:75kB audio:0kB global headers:0kB muxing overhead -100.028494%
Thank you @elenril. This seems to be working much better. Out of 114 calls, 12 have corrupted frames (10%). Most resulting JPEGs are ~200KB but the corrupted ones are ~12KB. It seems like these images are differential images that are to be applied on top of the previous frame? Is there a way to filter out such differential frames? My updated command:
avconv -v verbose -fflags discardcorrupt -vf 'select=eq(pict_type\,I)' -i $url -frames 1 -an -vsync 1 -qscale 1 $(date "+%Y%m%dT%H%M%S").jpg
– Weston Ruter – 2013-01-13T22:31:52.873Also, the instances where a differential image results are accompanied by "Missing reference picture" and "decode_slice_header error". – Weston Ruter – 2013-01-13T22:41:06.927
The same -problem again -- -vf is an output option, not an input one. So move it after the input filename, otherwise it will be ignored. If you are unsure whether an option is input or output, look into the manual. Most options have a note in parentheses which says whether they are input or output. – elenril – 2013-01-14T08:20:12.093
OK, thanks… moving
-vf
so it applies to the output does eliminate the periodic “differential” gray frames, but now approximately the same number (10%) of frames come out with the last half of pixels repeating vertically, at different left-to-right scan points in the image. It's like the stream gets interrupted and so it just fills in the rest with repeating data. Perhaps the discard corrupt being applied to the output would do the trick. I'll try.avconv -v verbose -fflags discardcorrupt -i $url -vf 'select=eq(pict_type\,I)' -frames 1 -an -vsync 1 -qscale 1 $timestamp.jpg
– Weston Ruter – 2013-01-14T18:16:47.763Alas, no. Moving
-fflags discardcorrupt
to apply to the output does not prevent truncated image frames from being written out. Latest attempt:avconv -v verbose -i $url -fflags discardcorrupt -vf 'select=eq(pict_type\,I)' -frames 1 -an -vsync 1 -qscale 1 $timestamp.jpg
Any other ideas? – Weston Ruter – 2013-01-14T18:45:07.583I'm going to wager that the corruption I'm experiencing has to do with the video device. – Weston Ruter – 2013-03-31T21:24:38.570