11

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.

Tariq
  • 2,274
  • 4
  • 24
  • 40
  • 1
    Please do not ask the [same question](http://superuser.com/questions/930955/h-264-decoding-error-log-from-rtsp-stream) on multiple Stack Exchange sites. – llogan Jun 22 '15 at 16:23
  • @tariq: can you do the following: `ffplay << RTSP STREAM >>` and post the output here? `ffplay` is part of the ffmpeg toolkit, not sure how it works on Windows though... – EladG Jun 23 '15 at 06:56
  • Are you just decoding or reencoding the stream? It just looks like ffmpeg too busy encoding, so it just skips incoming packets, which causing errors. Try to use smaller resolution. – Dmitri Sosnik Jun 23 '15 at 23:19
  • I am not encoding the video stream. I receive an RTSP stream, decode it and then display using OpenCV. – Tariq Jun 24 '15 at 08:18
  • 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; Can anybody help me understand why it is showing this behaviour (Giving log errors in c program and no errors at all when dumping the RTSP stream to avi file using ffmpeg.exe command)? – Tariq Jun 24 '15 at 15:41
  • full command line and console output please? (preferably as a gist) are you using zeranoe builds? – rogerdpack Jun 25 '15 at 18:18
  • Below is gist link. I hope this will help you to solve the problem; https://gist.github.com/tesmai4/70e42bf0f12b9dd69995 – Tariq Jun 25 '15 at 18:27
  • Following is the output of ffplay rtsp://192.168.1.67/gnz_media/main The output does not fit in one comment[please see the link to gist]. https://gist.github.com/anonymous/059c4db6e860675890ce – Tariq Jun 27 '15 at 11:55
  • @Tariq So, play is fine, but could you show your ffmpeg command line? – Dmitri Sosnik Jun 29 '15 at 07:03
  • @Tariq Sorry, gist link from Jun 25 shows only errors, it doesn't have ffmpeg command line. And gist link with ffplay looks normal – Dmitri Sosnik Jun 30 '15 at 02:58
  • @Dimitri; Please see the update gist for ffmpeg command; https://gist.github.com/anonymous/31180346db4ebe1f280b – Tariq Jun 30 '15 at 06:31
  • @Tariq - You are reencoding your stream (h264 (native) -> h264 (libx264)), it's quite expensive, and depending on resolution and/or framerate just can't be done in realtime, so rtp drops packets, try just copy video over and reencode it later, something like: ffmpeg -i rtsp://192.168.1.67/gnz_media/second -c:v copy 987.mp4 – Dmitri Sosnik Jun 30 '15 at 09:20
  • Thanks for your comment Dimitri. I need to do it in C using FFMPEG. Any suggestion for that will be really helpful? – Tariq Jun 30 '15 at 09:38
  • @Tariq I haven't used ffmpeg libraries for ages, don't remember details atm, but basically you don't need to configure any decoders or encoders, just read packet and save it to a new container. Just check ffmpeg source code to figure out how they would handle "-c:v copy" option – Dmitri Sosnik Jun 30 '15 at 09:45
  • Decoding with ffmpeg; I don't need to configure any encoder/decoder? Share some sample, if possible – Tariq Jun 30 '15 at 14:55
  • I get my stream as h264 encoded and need decode it. How can I avoide the conversion from g your stream (h264 (native) -> h264 (libx264))? I can try any other decoding like g your stream (h264 (native) -> h264 (mpeg)) as long as computation time is reduced and packets are not dropeed – Tariq Jun 30 '15 at 14:59
  • @Tariq It depends on what you want to do with that data, if you have to analyze image - just decode it and work with it, but make sure that you can handle 25/30/whatever fps. Or just dump video in a file and process it later. – Dmitri Sosnik Jun 30 '15 at 23:42
  • @Dmitri; Thanks for your answer. I am decoding and analysing RTSP stream in real time. I don't have the option to save to file and decode/process it later. I have to process the stream as it is received. any comment on how to avoid h264 (native) -> h264 (libx264)) conversion? How can I ensure to maintain 25fps during stream processing? – Tariq Jul 01 '15 at 06:22
  • @Tariq did you solve it ?!! – Muhammed Refaat Sep 03 '15 at 09:35
  • @Refaat; not yet. Still working on it – Tariq Sep 03 '15 at 13:14
  • How is it now? Did you solve? – Zen Dec 16 '16 at 13:05

2 Answers2

10

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.

Phi
  • 467
  • 5
  • 16
  • 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. – Nishant Kashyap Jun 26 '18 at 20:48
  • @NishantKashyap I've not used OpenCV, but [this blog](http://workingwithcomputervision.blogspot.com/2012/07/weve-finally-got-it-going-ill-get-onto.html) says just add "?tcp" to the RTSP urls. So connect to `rtsp://stream/?tcp` instead. – Phi Jun 28 '18 at 14:14
  • 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:password@xxx.xx.xx.xx" -r 30 -vcodec copy -flags +global_header -map 0 -f mp4 -t 10 -y "video.mp4"` – Nishant Kashyap Jun 29 '18 at 15:33
  • 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! – Joshua Pinter Feb 13 '19 at 20:28
  • @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. – Phi Feb 16 '19 at 19:19
  • 2
    @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. – Joshua Pinter Feb 22 '19 at 16:22
-4

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.

himanshu
  • 1