H.264 decoding error log from RTSP stream

Question

I am getting the following H264 error log. This log comes while decoding an RTSP video stream with help of FFMPEG. The picture displayed is blurred after 5/6 seconds. The picture would recover it from time to time. However, it remains blurred for most of the time.

EDIT: Some FFMPEG discussion forums suggested to upgrade FFMPEG version to avoid these logs. I have updated the latest FFMPEG build of June 19, 2015.Still the log remains there and picture is still blurred.

EDIT 2: The RTSP stream is coming from a GANZ camera. This camera is connected through a LAN connection.

[h264 @ 0abb2aa0] Cannot use next picture in error concealment
[h264 @ 0abb2aa0] concealing 1933 DC, 1933 AC, 1933 MV errors in P frame
[h264 @ 098e5c80] RTP: missed 131 packets
[h264 @ 0abb3300] error while decoding MB 66 25, bytestream (-9)
[h264 @ 0abb3300] Cannot use next picture in error concealment
[h264 @ 0abb3300] concealing 1583 DC, 1583 AC, 1583 MV errors in P frame
[h264 @ 098e5c80] RTP: missed 8 packets
[h264 @ 0b113e40] error while decoding MB 54 30, bytestream (-11)
[h264 @ 0b113e40] Cannot use next picture in error concealment
[h264 @ 0b113e40] concealing 1195 DC, 1195 AC, 1195 MV errors in P frame
[h264 @ 098e5c80] RTP: missed 118 packets
[h264 @ 0ac79960] error while decoding MB 13 20, bytestream (-13)
[h264 @ 0ac79960] Cannot use next picture in error concealment
[h264 @ 0ac79960] concealing 2036 DC, 2036 AC, 2036 MV errors in P frame
[h264 @ 098e5c80] RTP: missed 198 packets
[h264 @ 0ad4f500] error while decoding MB 21 9, bytestream (-5)
[h264 @ 0ad4f500] Cannot use next picture in error concealment
[h264 @ 0ad4f500] concealing 2908 DC, 2908 AC, 2908 MV errors in P frame
[h264 @ 098e5c80] RTP: missed 108 packets
[h264 @ 0abb3300] error while decoding MB 1 14, bytestream (-5)
[h264 @ 0abb3300] Cannot use next picture in error concealment
[h264 @ 0abb3300] concealing 2528 DC, 2528 AC, 2528 MV errors in P frame
[h264 @ 098e5c80] RTP: missed 106 packets
[h264 @ 0b1149c0] error while decoding MB 12 5, bytestream (-7)
[h264 @ 0b1149c0] Cannot use next picture in error concealment
[h264 @ 0b1149c0] concealing 3237 DC, 3237 AC, 3237 MV errors in P frame
[h264 @ 098e5c80] RTP: missed -65402 packets
[h264 @ 0b1155a0] error while decoding MB 50 38, bytestream (-7)
[h264 @ 0b1155a0] Cannot use next picture in error concealment
[h264 @ 0b1155a0] concealing 559 DC, 559 AC, 559 MV errors in P frame
[h264 @ 098e5c80] RTP: missed 150 packets
[h264 @ 0af65740] error while decoding MB 48 31, bytestream (-15)
[h264 @ 0af65740] Cannot use next picture in error concealment
[h264 @ 0af65740] concealing 1121 DC, 1121 AC, 1121 MV errors in P frame
[h264 @ 098e5c80] RTP: missed 4 packets
[h264 @ 0ac79960] error while decoding MB 35 38, bytestream (-41)
[h264 @ 0ac79960] Cannot use next picture in error concealment
[h264 @ 0ac79960] concealing 574 DC, 574 AC, 574 MV errors in P frame

I dumped the RTSP stream to an avi file using ffmpeg and there are no errors. C:\Users\Matlab>ffmpeg -i rtsp://192.168.1.67/gnz_media/main 123.avi

There are no H.264 decoding errors. Can anybody help with above decoding errors using ffmpeg api.

Answer 1

This issue is generated by camera so upgrade the camera latest firmware by GANZ technical support.This h.264 video compression does not support by camera.

Answer 2

If you're using UDP, you can expect frames to be dropped - that's part of the UDP design, which favours speed over reliability. Missing packets is a serious problem for the H264 format as a given packet may depend on packets ahead or behind it (using a difference image instead of sending a full new image). So, using UDP will produce a lot of errors including "RTP: missed XXX packets".

Switch to the more reliable but slower TCP by passing rtsp_transport="tcp" option to avformat_open_input. Example:

AVDictionary * opts = NULL;
av_dict_set(&opts, "rtsp_transport", "tcp", 0);
int error = avformat_open_input(&rtsp_format_context, "rtsp://your url here", NULL, &opts);
if (error < 0)
    ; // Connection error. Add your error handling here.

This will stop packets being dropped, which will remove the corruption of the video.