Recherche avancée

Sur d’autres sites (15134)

• Merge remote-tracking branch ’lukaszmluki/master’

  8 juin 2013, par Michael Niedermayer

  Merge remote-tracking branch ’lukaszmluki/master’
  * lukaszmluki/master :
  
    ftp: add invalid code for RETR operation
  
    ftp: probe seek capability
  
    ftp: fix seeking beyond file size
  
    ftp: abort function optimalization
  
    ftp: explicit return code checks
  
    ftp: fix flush control connection input
  
    ftp: reconnect on tcp read error
  Merged-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] libavformat/ftp.c

• Merge remote-tracking branch ’lukaszmluki/master’

  31 mai 2013, par Michael Niedermayer

  Merge remote-tracking branch ’lukaszmluki/master’
  * lukaszmluki/master :
  
    ftp: enhanced error handling
  
    ftp: reconnect on seek
  
    ftp: move common commands code to function
  
    ftp: enhanced status code handling
  
    ftp: reconnect on read
  
    ftp: move create control connection to function
  
    ftp: credentials moved into FTPContext
  
    ftp: rename function name
  
    ftp: formatting and typos fixes
  Merged-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] libavformat/ftp.c

• FFmpeg + iOS + lossy cellular connections

  9 novembre 2014, par Moss

  I am able to play an RTMP audio + video real-time stream on iOS with FFmpeg. Works fantastic when everything is on a solid WiFi connection.

  When I switch to a cellular connection (great signal strength and LTE/4G), av_read_frame() will intermittently block for an unacceptable amount of time. From what I can tell, it’s not that the cellular data connection just dropped, because I can reconnect immediately and start downloading more packets. In some cases, I’ve clocked 30+ seconds of hang time before it returns the next frame. When the next frame finally comes in, my real-time video stream is permanently delayed by the amount of time that av_read_frame() blocked.

  I attempted a work-around by using the AVIOInterruptCB interrupt callback to abort av_read_frame() if the function takes longer than 1 second to return. Here’s what that code looks like :

  - (void)readPackets {
  
      // Make sure FFmpeg calls our interrupt periodically
  
      _context->interrupt_callback.callback = interrupt_cb;
  
      _context->interrupt_callback.opaque = self;
  
  
  
      dispatch_async(_readPacketQueue, ^(void) {
  
          int err;
  
  
  
          while(true) {
  
              _readFrameTimeStamp = [[NSDate date] timeIntervalSince1970];
  
              err = av_read_frame(_context, &packet);
  
              _readFrameTimeStamp = 0;
  
  
  
              if(err) {
  
                  // Error - Reconnect the entire stream from scratch, taking 5-10 seconds
  
                  // And we know when av_read_frame() was aborted
  
                  // because its error code is -1414092869 ("EXIT")
  
              }
  
              else {
  
                  // Play this audio or video packet
  
              }
  
          }
  
     });
  
  }
  
  
  
  /**
  
   * Interrupt
  
   * @return 1 to abort the current operation
  
   */
  
  static int interrupt_cb(void *decoder) {
  
      if(decoder) {
  
          if(_readFrameTimeStamp != 0) {
  
              if([[NSDate date] timeIntervalSince1970] - _readFrameTimeStamp > 1) {
  
                  // Abort av_read_frame(), it's taking longer than 1 second
  
                  return 1;
  
              }
  
          }
  
      }
  
  }

  This definitely aborts av_read_frame() after 1 second, but unfortunately after I do this, future attempts to call av_read_frame() result in EIO errors (-5), which indicates that the connection has been severed.

  As a result, I am forced to fully reconnect the viewer, which takes 5-10 seconds. (avformat_open_input() takes 3-4 seconds, and then find the stream info again takes 2-3 seconds, and then start reading frames).

  The 5-10 second delay to fully reconnect is much better than waiting more than 10 seconds for av_read_frame() to unblock, and it’s much better than the real-time stream being delayed by a significant amount. But it’s much worse than being able to retry av_read_frame() immediately.

  From a cellular user’s perspective, their video locks up intermittently for 5-10 seconds while we reconnect the stream in the background from scratch, which isn’t a good user experience.

  What strategies are there to better way to manage av_read_frame() on a lossy cellular connection ?
  (Or strategies to improve the reconnect time ?)