Recherche avancée

Sur d’autres sites (11178)

• FFMPEG : RTSP to HLS restream stops with "No more output streams to write to, finishing."

  1er juin 2022, par Tim W

  I'm trying to do a live restream an RTSP feed from a webcam using ffmpeg, but the stream repeatedly stops with the error :

  



  "No more output streams to write to, finishing."

  



  The problem seems to get worse at higher bitrates (256kbps is mostly reliable) and is pretty random in its occurrence. At 1mbps, sometimes the stream will run for several hours without any trouble, on other occasions the stream will fail every few minutes. I've got a cron job running which restarts the stream automatically when it fails, but I would prefer to avoid the continued interruptions.

  



  I have seen this problem reported in a handful of other forums, so this is not a unique problem, but not one of those reports had a solution attached to it. My ffmpeg command looks like this :

  



  ffmpeg -loglevel verbose -r 25 -rtsp_transport tcp -i rtsp ://user:password@camera.url/live/ch0 -reset_timestamps 1 -movflags frag_keyframe+empty_moov -bufsize 7168k -stimeout 60000 -hls_flags temp_file -hls_time 5 -hls_wrap 180 -acodec copy -vcodec copy streaming.m3u8 > encode.log 2>&1

  



  What gets me is that the error makes no sense, this is a live stream so output is always wanted until I shut off the stream. So having it shut down because output isn't wanted is downright odd. If ffmpeg was complaining because of a problem with input it would make more sense.

  



  I'm running version 3.3.4, which I believe is the latest.

  



  Update 13 Oct 17 :

  



  After extensive testing I've established that "No more outputs" error message generated by FFMPEG is very misleading. The error seems to be generated if the data coming in from RTSP is delayed, eg by other activity on the router the camera is connected via. I've got a large buffer and timeout set which should be sufficient for 60 seconds, but I can still deliberately trigger this error with far shorter interruptions, so clearly the buffer and timeout aren't having the desired effect. This might be fixed by setting a QOS policy on the router and by checking that the TCP packets from the camera have a suitably high priority set, it's possible this isn't the case.

  



  However, I would still like to improve the robustness of the input stream if it is briefly interrupted. Is there any way to persuade FFMPEG to tolerate this or to actually make use of the buffer it seems to be ignoring ? Can FFMPEG be persuaded to simply stop writing output and wait for input to become available rather than bailing out ? Or could I get FFMPEG to duplicate the last complete frame until it's able to get more data ? I can live with the stream stuttering a bit, but I've got to significantly reduce the current behaviour where the stream drops at the slightest hint of a problem.

  



  Further update 13 Oct 2017 :

  



  After more tests, I've found that the problem actually seems to be that HLS is incapable of coping with a discontinuity in the incoming video stream. If I deliberately cut the network connection between the camera and FFMPEG, FFMPEG will wait for the connection to be re-established for quite a long time. If the interruption was long (>10 seconds) the stream will immediately drop with the "No More Outputs" error the instant that the connection is re-established. If the interruption is short, then RTSP will actually start pulling data from the camera again, but the stream will then drop with the same error a few seconds later. So it seems clear that the gap in the input data is causing the HLS encoder to have a fit and give up once the stream is resumed, but the size of the gap has an impact on whether the drop is instant or not.

  


• lavf/tls_gnutls : fix warnings from version check

  26 septembre 2017, par Moritz Barsnick

  lavf/tls_gnutls : fix warnings from version check
  The GnuTLS version is checked through the macro GNUTLS_VERSION_NUMBER,
  
  but this wasn't introduced before 2.7.2. Building with older versions
  
  of GnuTLS (using icc) warns :
  src/libavformat/tls_gnutls.c(38) : warning #193 : zero used for undefined preprocessing identifier "GNUTLS_VERSION_NUMBER"
  
    #if HAVE_THREADS && GNUTLS_VERSION_NUMBER <= 0x020b00
  This adds a fallback to the older, deprecated LIBGNUTLS_VERSION_NUMBER
  
  macro.
  Signed-off-by : Moritz Barsnick <barsnick@gmx.net>
  

  • [DH] libavformat/tls_gnutls.c

• "Non-monotonous DTS" and jerky video when copying streams

  2 décembre 2017, par forthrin

  I’m switching containers from MKV to mp4 for a set of video files. This has worked for all videos before, but now I’m getting weird problems (also when converting from MKV to another MKV !)

  1. I’m getting a million Non-monotonous DTS in output stream messages
  2. With QuickTime on macOS the video is jerking back and forth very fast while playing
  3. With VLC on macOS, the video is skipping a lot of frames

  How can I fix this, without re-encoding the video stream ? (Re-encoding audio would be acceptable.) Somehow it must be possible since the original MKV works perfectly !

  $ ffmpeg -i in.mkv -codec copy out.mp4
  
  ffmpeg version 3.3.4 Copyright (c) 2000-2017 the FFmpeg developers
  
    built with Apple LLVM version 9.0.0 (clang-900.0.37)
  
    configuration: --prefix=/usr/local/Cellar/ffmpeg/3.3.4 --enable-shared --enable-pthreads --enable-gpl --enable-version3 --enable-hardcoded-tables --enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-ffplay --enable-libass --enable-libmp3lame --enable-libx264 --enable-libx265 --enable-libxvid --enable-opencl --enable-videotoolbox --disable-lzma --enable-vda
  
    libavutil      55. 58.100 / 55. 58.100
  
    libavcodec     57. 89.100 / 57. 89.100
  
    libavformat    57. 71.100 / 57. 71.100
  
    libavdevice    57.  6.100 / 57.  6.100
  
    libavfilter     6. 82.100 /  6. 82.100
  
    libavresample   3.  5.  0 /  3.  5.  0
  
    libswscale      4.  6.100 /  4.  6.100
  
    libswresample   2.  7.100 /  2.  7.100
  
    libpostproc    54.  5.100 / 54.  5.100
  
  Input #0, matroska,webm, from 'in.mkv':
  
    Metadata:
  
      ENCODER         : Lavf54.63.104
  
    Duration: 00:37:59.98, start: 0.200000, bitrate: 2536 kb/s
  
      Stream #0:0: Video: h264 (High), yuv420p(progressive), 1280x720 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc
  
      Stream #0:1(eng): Audio: ac3, 48000 Hz, 5.1(side), fltp, 384 kb/s (default)
  
  [mp4 @ 0x7f93c9006c00] track 1: codec frame size is not set
  
  Output #0, mp4, to 'out.mp4':
  
    Metadata:
  
      encoder         : Lavf57.71.100
  
      Stream #0:0: Video: h264 (High) ([33][0][0][0] / 0x0021), yuv420p(progressive), 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 23.98 fps, 23.98 tbr, 16k tbn, 1k tbc
  
      Stream #0:1(eng): Audio: ac3 ([165][0][0][0] / 0x00A5), 48000 Hz, 5.1(side), fltp, 384 kb/s (default)
  
  Stream mapping:
  
    Stream #0:0 -> #0:0 (copy)
  
    Stream #0:1 -> #0:1 (copy)
  
  Press [q] to stop, [?] for help
  
  [mp4 @ 0x7f93c9006c00] Non-monotonous DTS in output stream 0:0; previous: 60720, current: 60064; changing to 60721. This may result in incorrect timestamps in the output file.
  
  [mp4 @ 0x7f93c9006c00] Non-monotonous DTS in output stream 0:0; previous: 63392, current: 62736; changing to 63393. This may result in incorrect timestamps in the output file.
  
  (...repeats a million times...)

  MP4Box :

  $ MP4Box -add in.mkv out.mp4
  
  [MPEG-2 TS] TS Packet 1 is scrambled - not supported
  
  [MPEG-2 TS] TS Packet 3 does not start with sync marker
  
  ...
  
  [MPEG-2 TS] TS Packet 999 does not start with sync marker
  
  [Importer] Unknown input file type
  
  Error importing in.mkv: Corrupted Data in file/stream

  So the file is maybe corrupt ? (Though it plays perfectly to begin with, in VLC at least !) Is there any way I can repair it and convert it to an mp4 file, again without re-encoding the video stream ?