Recherche avancée

Sur d’autres sites (9108)

• FFMPEG : RTSP stream freezes but FFMPEG keeps recording

  31 juillet 2022, par Kagetsuki

  EDIT : At the time of this writing there is no functionality within FFMPEG that can detect/handle when an RTP/RTSP stream is still active but is no longer delivering valid frames. The only solution I could find was to periodically reset the stream by stopping recording, then reconnecting and starting a new recording which -f segment does NOT do.

  



  ---

  



  I'm recording an RTSP stream from a network camera with FFMPEG, and after some time (usually about an hour and a half to two hours). I'm sure it's specifically a problem with the cameras I'm using and not FFMPEG or my system resources.

  



  What specifically happens is the video freezes but network traffic with the camera continues - it just doesn't seem to send new frames. Because of this behaviour FFMPEG doesn't disconnect/keeps recording because the network connection is still alive. After a few minutes there will always be a single warning in the FFMPEG output :
More than 1000 frames duplicated
But it keeps recording - it's just the same frame over and over.

  



  The command I'm using is :

  



  ffmpeg -stimeout 1000000 -rtsp_transport udp -fflags discardcorrupt -i rtsp://192.168.1.163/live/0/MAIN -vc libx265 -f segment -segment_time 300 -segment_atclocktime 1 -reset_timestamps 1 -strftime 1  "163-%Y-%m-%d_%H-%M-%S-h265.mp4"


  



  Some notes :

  



  

  • stimeout doesn't seem to do anything as the network connection is maintained the camera just seems to stop sending (valid) frames.

  


  • Changing the codec to copy doesn't improve the issue

  


  • Changing the RTSP transport doesn't improve the issue

  


  • I'm aware there is a filter to detect frozen frames, but my FFMPEG does not seem to have it - I'm going to try and build FFMPEG myself now ; but would much prefer a solution that works with bundled FFMPEG > 4.1.3

  


  



  Having FFMPEG fail and exit after > 1000 frames are duplicated would actually be ideal, as then I can just spawn FFMPEG from a script, monitor the process, and restart it when the process ends. Any solution would be great though.

  


• Prevent suspend event when streaming video via HTML video tag

  24 septembre 2014, par jasongullickson

  I seem to be having the opposite problem of most people who are streaming video using the HTML video tag ; I’m saturating the client with data.

  When playing a long video served via ffserver (webm container) everything works great but eventually the browser (Chrome in this case) will begin throwing "suspend" events. After a number of these ( 50-100), a "stalled" event will fire and playback will stop.

  I believe the problem is that once Chrome has buffered a certain amount of video it goes into "suspend" and stops downloading more data. I’ve tested this theory by throttling the speed at which video data is delivered, and if I keep the delivered frame rate close to the playback rate, I can prevent this from happening, but of course deliberately holding back server performance isn’t ideal.

  What I’m looking for is either a way to suppress this "suspend" behavior altogether, or alternatively a way to respond to the event that prevents the eventual "stalled" state.

  Presumably the browser at some point exits the "suspend" state and begins requesting data again, but I haven’t actually observed this occurring. I’m using a chain of mpeg2 -> ffmpeg -> ffserver to stream the video so if the browser is attempting to resume loading data I don’t see the request in my application. I could use a proxy or a sniffer to watch for the traffic but I would expect that maybe there is an ffserver log that can tell me the same thing ? In any event if it’s attempting to resume the download it’s failing, and there’s no indication server-side that there’s a reason for the request to fail (in fact I can pull up the same video feed from ffserver and see it playing correctly).

  So I feel like I’ve isolated this to a client-side playback issue, and one where the browser is voluntarily giving up on loading the data, but I’m not sure how to convince it to "not do that", or at least attempt to resume when it runs the buffer dry.

• Why does subprocess.run() have unexpected behavior in try else block ?

  27 novembre 2023, par Nikita Savenkov

  Trying to make a "to mp4" converter function using ffmpeg that is going to convert a file to mp4, delete the original file, and return True or False for specific conditions.
But I get some unexpected behavior of a subprocess.

  


  Initially I used this construction :

  


  def to_mp4_converter(file):

    input_file = file
    output_file = f"{re.sub(r'\..+$', "", file)}.mp4"

    try:
        subprocess.run(['ffmpeg', '-i', input_file, output_file])
    except subprocess.SubprocessError as e:
        print(f"Subprocess Error: {e}")
        return False
    else:
        try:
            os.remove(path=file)
        except OSError as e:
            print(f"Can't remove {file} file: {e}")
        finally:
            return True


  


  Original file is removed, but output file is half of the expected size and quality of video is low.

  


  But if I place subprocess.run() and os.remove() into separate try else blocks like that :

  


  def to_mp4_converter(file):

    input_file = file
    output_file = f"{re.sub(r'\..+$', "", file)}.mp4"

    try:
        subprocess.run(['ffmpeg', '-i', input_file, output_file])
    except subprocess.SubprocessError as e:
        print(f"Subprocess Error: {e}")
        return False
    else:
        pass

    try:
        os.remove(path=file)
    except OSError as e:
        print(f"Can't remove {file} file: {e}")
    finally:
        return True


  


  Everything works fine.

  


  Isn't subprocess.run() should be a blocking operation, so the else statement in 1st example is unreachable until conversion is done ?