Recherche avancée

Sur d’autres sites (10684)

• resending a stream causes ffmpeg to crash

  18 août 2020, par Arikael

  we use ffmpeg 3.4.8 to get udp streams from a source.
  
While the streams may be sent 24/7 or just from time to time, ffmpeg should always listen 24/7.
  
Those streams are out of my control.

  


  The streams which are sent from time to time, are not just paused during the time they are not sent, they are not existing.
  
This means while they are always send with on the same address/port and our application sees them as one stream (or one input in ffmpeg terminology) they are technically multiple separate streams sent to the same address.

  


  The problem is when one of those stream stops, ffmpeg keeps listening for the input (which is good) but it crashes as soon as we send the stream again giving the error :

  


  Application provided invalid, non monotonically increasing dts to muxer in stream 4...   
av_interleaved_write_frame(): invalid argument.


  


  Stream 4 contains synchronous klv metadata.

  


  This is to be expected since the new stream will probably have a lower dts than the old stream.

  


  I cant use the reconnect_* flags since we use an udp source

  


  example
  
ffmpeg -i udp://192.168.2.255:1234 -map 0 -c copy -f mpegts udp://192.168.2.255:1235

  


  log (with loglevel verbose)

  


  [mpegts @ 0x1eb8e60] Timestamps are unset in a packet for stream 3. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
[mpegts @ 0x1eb8e60] Application provided invalid, non monotonically increasing dts to muxer in stream 4: 2097600 >= 1732800
av_interleaved_write_frame(): Invalid argument
No more output streams to write to, finishing.
frame=  317 fps= 20 q=-1.0 Lsize=    7252kB time=00:00:23.30 bitrate=2549.1kbits/s speed=1.44x
video:6166kB audio:400kB subtitle:0kB other streams:58kB global headers:0kB muxing overhead: 9.481929%
Input file #0 (udp://192.168.2.255:1234):
  Input stream #0:0 (video): 318 packets read (6334176 bytes);
  Input stream #0:1 (audio): 534 packets read (410112 bytes);
  Input stream #0:2 (data): 0 packets read (0 bytes);
  Input stream #0:3 (data): 56 packets read (9968 bytes);
  Input stream #0:4 (data): 252 packets read (49542 bytes);
  Total: 1160 packets (6803798 bytes) demuxed
Output file #0 (udp://192.168.2.255:1235?broadcast=1):
  Output stream #0:0 (video): 317 packets muxed (6313576 bytes);
  Output stream #0:1 (audio): 534 packets muxed (410112 bytes);
  Output stream #0:2 (data): 0 packets muxed (0 bytes);
  Output stream #0:3 (data): 56 packets muxed (9968 bytes);
  Output stream #0:4 (data): 252 packets muxed (49542 bytes);
  Total: 1159 packets (6783198 bytes) muxed
Conversion failed!


  


  Like mentioned this only happens if the input stream is stopped and started again.

  


  So the question is :
  
Is it somehow possible to give ffmpeg a timeout after which it treats an input as a new stream and/or ignores those dts errors or how can I solve the problem ?

  


  I know I could probably just wait for ffmpeg to fail and then restart it, but maybe there's a cleaner solution.

  


• h264 : prevent theoretical infinite loop in SEI parsing

  30 juillet 2014, par Vittorio Giovara

  h264 : prevent theoretical infinite loop in SEI parsing
  Properly address CVE-2011-3946 and parse bitstream as described in the spec.
  CC : libav-stable@libav.org
  
  Found-by : Mateusz "j00ru" Jurczyk and Gynvael Coldwind
  

  • [DH] libavcodec/h264_sei.c

• imc : add required padding for GetBitContext buffer

  8 juin 2015, par Janne Grunau

  imc : add required padding for GetBitContext buffer
  Fixes stack buffer overflow errors detected by address sanitizer in
  
  fate-imc.
  CC : libav-stable@libav.org
  

  • [DBH] libavcodec/imc.c