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:

corrupted video frame

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%
Improve this question

1 Answer 1

Reset to default
2

From TFM:

As a general rule, options are applied to the next specified file. Therefore, order is important, and you can have the same option on the command line multiple times. Each occurrence is then applied to the next input or output file. Exceptions from this rule are the global options(e.g. verbosity level), which should be specified first.

Thus -fflags discardcorrupt in your commandline applies to the output file. If you want it to apply to the input file, move it before -i.

I doubt that it will help though, as it seems that the packets are not corrupted, just the stream does not start on a keyframe. A solution to that would be to use the select filter to wait until you get a keyframe: -vf 'select=eq(pict_type\,I)'

Also some random comments on your commandline:

  • -vsync 1 does nothing if you're already specifying -r. -vsync 1 (alias -vsync cfr in newer versions) means that you want CFR output. The framerate is either taken from the input file or is the one specified by -r. So -r automatically implies -vsync 1.
  • If you want just one frame, there is no need to use hacks like -t 00:00:01 -r 0.1. Just say -frames 1.
Improve this answer
6
  • 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
    Jan 13, 2013 at 22:31
  • Also, the instances where a differential image results are accompanied by "Missing reference picture" and "decode_slice_header error".
    – Weston Ruter
    Jan 13, 2013 at 22:41
  • 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
    Jan 14, 2013 at 8:20
  • 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
    Jan 14, 2013 at 18:16
  • Alas, 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
    Jan 14, 2013 at 18:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .