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.

Solution

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.

Comments

[llogan]

Please do not ask the same question on multiple Stack Exchange sites.

[Tariq]

Did you face the same problem? How did you update the firmware of your GANZ camera

[Nishant Kashyap]

How can we set the rtsp_transport="tcp" option using the python module python-opencv. To capture the video we add the line cv2.VideoCapture("rtsp://%s:%s@%s/Streaming/Channels/1"), do we need to add some more argument like rtsp_transport='tcp' in the VideoCapture function.

[Phi]

@NishantKashyap I've not used OpenCV, but this blog says just add "?tcp" to the RTSP urls. So connect to rtsp://stream/?tcp instead.

[Nishant Kashyap]

I rather used ffmpeg to fetch the video in mp4 format without any loss in packets and processing in also less, it is easy to play and show on the HTML video player as well. Try this ffmpeg -rtsp_transport tcp -i "rtsp://username:[email protected]" -r 30 -vcodec copy -flags +global_header -map 0 -f mp4 -t 10 -y "video.mp4"

[Joshua Pinter]

Thanks for this answer. However, instead of getting dropped packets, I get completely missing frames of the video. So no "smearing" but instead will loose entire seconds of video. Any advice? Thanks!

[Phi]

@JoshuaPinter I have no extra input on that... but missing frames are either from dropped packets or the camera itself is dropping some, maybe to reach a fixed fps? I would update camera firmware and increase ffmpeg logging level to see if there's missed packets too.

[Joshua Pinter]

@Phi After extensive testing over multiple days, the camera was not at fault but the wifi and streaming ability was to blame. That or the device itself was not capable of processing the data throughput, but less likely. Using TCP would not result in "smearing" or "tearing" of frames, but it would drop the frames altogether (i.e. no partial frames being captured). With UDP, it would retain partial frames as best it could but this would result in "smearing" or "tearing" of those frames. We ended up with UDP because it at least showed partial frames instead of missing entire chunks of the video.