Recherche avancée

Sur d’autres sites (4635)

• ffmpeg RTSP error while decoding MB

  2 mai 2018, par Hugh W

  I’m using ffmpeg to read an h264 RTSP stream from a Cisco 3050 IP camera and reencode it to disk as h264 (there are reasons why I’m not just using -codec:copy).

  The ffmpeg version is as follows :

  ffmpeg version 3.2.6 Copyright (c) 2000-2017 the FFmpeg developers
  
    built with gcc 6.3.0 (Alpine 6.3.0)

  I’ve also tried with ffmpeg 2.8.14-0ubuntu0.16.04.1 and the latest ffmpeg built from source (I used this commit) and see the same behaviour as below.

  The command I’m running is :

  ffmpeg -rtsp_transport udp -i 'rtsp://<user>:<pw>@<ip>:554/StreamingSetting?version=1.0&amp;action=getRTSPStream&amp;ChannelID=1&amp;ChannelName=Channel1' -r 10 -c:v h264 -crf 23 -x264-params keyint=60:min-keyint=60 -an -f ssegment -segment_time 60 -strftime 1 /output/%Y%m%d_%H%M%S.ts -abort_on empty_output
  
  </ip></pw></user>

  I get a variety of errors at a fairly steady rate of at least one per second. Here’s a sample :

  [rtsp @ 0x7f268c5e9220] max delay reached. need to consume packet
  
  [rtsp @ 0x7f268c5e9220] RTP: missed 40 packets
  
  [h264 @ 0x55b1e115d400] left block unavailable for requested intra mode
  
  [h264 @ 0x55b1e115d400] error while decoding MB 0 12, bytestream 114567
  
  [h264 @ 0x55b1e115d400] concealing 3889 DC, 3889 AC, 3889 MV errors in I frame

  The most common one is ’error while decoding MB x x, bytestream x’. This corresponds to severe corruption in the video file when played back.

  I see many references to that error message on stackoverflow and elsewhere, but I’ve yet to find a satisfying explanation or workaround. It comes from this line which appears to correspond to missing data at the end of the stream. ’left block unavailable’ comes from here and also looks like missing data.

  Others have suggested using -rtsp_transport tcp instead (1, 2, 3) which in my case just gives a slightly different mix of errors, and still video corruption :

  [h264 @ 0x557923191b00] left block unavailable for requested intra4x4 mode -1
  
  [h264 @ 0x557923191b00] error while decoding MB 0 28, bytestream 31068
  
  [h264 @ 0x557923191b00] concealing 2609 DC, 2609 AC, 2609 MV errors in I frame
  
  [rtsp @ 0x7f88e817b220] CSeq 5 expected, 0 received.

  Using Wireshark I confirmed that in both UDP and TCP mode, all of the packets are making it from the camera to the PC (sequential RTP sequence numbers without any missing) which makes me think the data is being lost after it arrives at ffmpeg.

  I also see similar behaviour when running the same command against a Panasonic WV-SFV110 camera, but with less frequent errors overall. Switching from UDP to TCP on the Panasonic camera reduces but does not completely eliminate the errors/corruption.

  I also tried a similar command with VLC and got similar errors (cvlc rtsp://<user>:<pw>@<ip>/MediaInput/h264 :sout='#transcode{vcodec=h264}:std{access=file, mux=ts, dst="output.ts"}</ip></pw></user>) — presumably the code hasn’t diverged much since libav forked from ffmpeg.

  The camera is plugged directly into a PoE port on the PC so network congestion can’t be a problem. Given that the PC has enough CPU to keep up encoding the live stream, it seems to me a problem with ffmpeg that it still drops data from the TCP stream.

  Qualitatively, there are several factors which seem to make the problem worse :

  • Higher video resolution
  • Higher system load on the machine running ffmpeg (e.g. transcoding to a low res .avi file produces fewer errors than transcoding to h264 VBR ; using -codec:copy eliminates all errors except a couple while ffmpeg is starting up)
  • Greater motion within the camera view

  What the does the error mean ? And what can I do about it ?

• FFMpeg lib memory leak

  30 mai 2018, par unresolved_external

  I am using lib ffmpeg for video decoding. So in my code I have something like :

  if ((err = av_hwdevice_ctx_create(&m_hw_device_ctx, type,
  
                                              NULL, NULL, 0)) < 0) 
  
      {
  
            printf( "Failed to create specified HW device.\n");
  
            return err;
  
          }
  
  
  
          m_decoder_ctx->hw_device_ctx = av_buffer_ref(m_hw_device_ctx);
  
          if ((ret = avcodec_open2(m_decoder_ctx, decoder, NULL)) < 0)
  
          {
  
              printf("Failed to open codec for video stream\n");
  
              return -1;                
  
          }
  
          if (0 > avcodec_send_packet(m_decoder_ctx, packet)) 
  
          {                
  
              return -1;
  
          }
  
      AVFrame *frame = nullptr;
  
      if (!(frame = av_frame_alloc())) 
  
      {
  
           printf( "Can not alloc frame\n");
  
           return -1;
  
      }
  
  
  
  
  
  
  
      int ret = avcodec_receive_frame(avctx, frame);
  
      if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF) 
  
      {
  
          av_frame_free(&frame);
  
          return 0;
  
      } 
  
      else if (ret < 0) 
  
      {
  
          printf("Error while decoding\n");
  
          av_frame_free(&frame);
  
      }
  
  //here is some application specific manipulation(ommitted for redability)
  
    av_frame_free(&frame);

  And then I free allocated memory like this :

  av_buffer_unref(&m_decoder_ctx->hw_device_ctx);
  
              av_buffer_unref(&m_hw_device_ctx);
  
              m_hw_device_ctx = nullptr;

  But Valgrind constantly reports an error :

  ==1115== 524,288 bytes in 1 blocks are definitely lost in loss record 2,147 of 2,174
  
  ==1115==    at 0x76A67920: ??? (in /usr/lib/x86_64-linux-gnu/libdrm_intel.so.1.0.0)
  
  ==1115==    by 0x76727A07: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so)
  
  ==1115==    by 0x76727B2A: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so)
  
  ==1115==    by 0x766FC2F5: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so)
  
  ==1115==    by 0x7670459C: __vaDriverInit_0_39 (in /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so)
  
  ==1115==    by 0x144A8AE5: ??? (in /usr/lib/x86_64-linux-gnu/libva.so.1.3900.0)
  
  ==1115==    by 0x144A9906: vaInitialize (in /usr/lib/x86_64-linux-gnu/libva.so.1.3900.0)
  
  ==1115==    by 0xD03A55E: ??? (in /usr/local/lib/libavutil.so.56.18.102)
  
  ==1115==    by 0xD03839C: av_hwdevice_ctx_create (in /usr/local/lib/libavutil.so.56.18.102)

  I’ve been trying to troubleshoot it without any success. Also checked a couple of examples - looks like everyone works with that function the same as I do. (e.g. -https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/vaapi_encode.c)
  Compiler flag, which I am using are :

  -O0 -g3 -pthread -fpermissive -lm

  Any ideas - what is wrong with buffer deallocation ?

• GoPro : get each frame time stamp

  14 mars 2018, par jlengrand

  I am currently trying to extract each frame time stamp from an MPEG-4 file that has been recorded using a GoPro.

  I want the exact time at which the frame has been captured by the camera, to couple that with computer vision algorithms later on.

  I know that the output framerate is 25 fps.
  I extracted the pts in different ways using ffmpeg and ffprobe, but they all show way too perfect results for me to believe them.

  Each frame/packet has a precise, 0.04 sec interal (or 3600 in pts units) which conveniently enough matches a perfect 25 fps.

  The commands I have used so far are :

  ffmpeg -i 3_96025.MP4  -an -vf showinfo %10d.png 2> res.txt

  I have also tried to use

  ffmpeg -i 3_96025.MP4 **-copyts** -an -vf showinfo %10d.png 2> res.txt

  but the results are exactly the same.

  I also tried ffprobe :

  ffprobe -i 396025.MP4 -show_packets -select_streams v

  Bu the intervals I get are perfect too.

  I am quite sure the gopro cannot sustain 25 fps in such a perfect manner. In addition, I recorded a timer, and I can see that each frame does not exactly match 0.04 seconds interval.
  So is there a way I can actually see the time each frame was captured ?

  Here is a part of the output I get with ffmpeg for reference :

  frame=   42 fps= 26 q=0.0 size=N/A time=00:00:01.36 bitrate=N/A    
  
  n:42 pts:151200 pts_time:1.68 pos:3232584 fmt:yuv420p sar:1/1 s:1280x960 i:P iskey:0 type:B checksum:6A83E942 plane_checksum:[1C859E55 79A4ED3E 28E25DA0]
  
  [Parsed_showinfo_0 @ 0037dea0] n:43 pts:154800 pts_time:1.72 pos:3255334 fmt:yuv420p sar:1/1 s:1280x960 i:P iskey:0 type:B checksum:5736F4C1 plane_checksum:[ACAD00D0 06FFDE34 65FA15BD]
  
  [Parsed_showinfo_0 @ 0037dea0] n:44 pts:158400 pts_time:1.76 pos:3083826 fmt:yuv420p sar:1/1 s:1280x960 i:P iskey:0 type:P checksum:9DD6B636 plane_checksum:[229400B3 7C0B52AF 75D162D4]
  
  [Parsed_showinfo_0 @ 0037dea0] n:45 pts:162000 pts_time:1.8 pos:3531851 fmt:yuv420p sar:1/1 s:1280x960 i:P iskey:0 type:B checksum:2DA4E2B9 plane_checksum:[9C646B9D 16F45382 28B0239A]
  
  [Parsed_showinfo_0 @ 0037dea0] n:46 pts:165600 pts_time:1.84 pos:3556346 fmt:yuv420p sar:1/1 s:1280x960 i:P iskey:0 type:B checksum:B4924AFE plane_checksum:[579EDD8F 94BC5C61 5B7F10FF]
  
  [Parsed_showinfo_0 @ 0037dea0] n:47 pts:169200 pts_time:1.88 pos:3279065 fmt:yuv420p sar:1/1 s:1280x960 i:P iskey:0 type:I checksum:DBB23A0C plane_checksum:[321835C9 57E9C9FB 576B3A39]
  
  [Parsed_showinfo_0 @ 0037dea0] n:48 pts:172800 pts_time:1.92 pos:3655246 fmt:yuv420p sar:1/1 s:1280x960 i:P iskey:0 type:B checksum:9BF3A47A plane_checksum:[4E17440B 3A059191 E394CECF]
  
  [Parsed_showinfo_0 @ 0037dea0] n:49 pts:176400 pts_time:1.96 pos:3677897 fmt:yuv420p sar:1/1 s:1280x960 i:P iskey:0 type:B checksum:2A3167B4 plane_checksum:[78601136 0A6F8334 272ED33B]
  
  [Parsed_showinfo_0 @ 0037dea0] n:50 pts:180000 pts_time:2 pos:3581296 fmt:yuv420p sar:1/1 s:1280x960 i:P iskey:0 type:P checksum:5A8C502E plane_checksum:[65A1FE60 0CEF07C3 F26149FC]
  
  [Parsed_showinfo_0 @ 0037dea0] n:51 pts:183600 pts_time:2.04 pos:3773963 fmt:yuv420p sar:1/1 s:1280x960 i:P iskey:0 type:B checksum:90572E41 plane_checksum:[E9478643 B8BAE0E2 E1A7C6FE]
  
  [Parsed_showinfo_0 @ 0037dea0] n:52 pts:187200 pts_time:2.08 pos:3797473 fmt:yuv420p sar:1/1 s:1280x960 i:P iskey:0 type:B checksum:2F206AB4 plane_checksum:[EB17F6AB 0AD1C78A E032AC61]
  
  [Parsed_showinfo_0 @ 0037dea0] n:53 pts:190800 pts_time:2.12 pos:3700340 fmt:yuv420p sar:1/1 s:1280x960 i:P iskey:0 type:P checksum:9A91E693 plane_checksum:[72309E37 229C34FB 59A71361]
  
  [Parsed_showinfo_0 @ 0037dea0] n:54 pts:194400 pts_time:2.16 pos:3897890 fmt:yuv420p sar:1/1 s:1280x960 i:P iskey:0 type:B checksum:BFCD3D1C plane_checksum:[13787B52 5F33F597 833ECC15]
  
  [Parsed_showinfo_0 @ 0037dea0] n:55 pts:198000 pts_time:2.2 pos:3919440 fmt:yuv420p sar:1/1 s:1280x960 i:P iskey:0 type:B checksum:62C6ED26 plane_checksum:[E4053A80 4752E0B5 E78FD1E2]