Recherche avancée

Sur d’autres sites (9879)

• 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 ?)

• Issue with openh264enc gstreamer plugin and tcp connections

  20 septembre 2016, par agaldos

  I am trying to stream over TCP encoded video into a EC2 Instance. Using "x264enc" encoder, all works correctly. I get the frames and generate the video correctly.

  The issue comes when I try to use the "openh264enc" encoder.

  If I put in the server "nc -l -p 5555" I can check that data is arriving into the port but when I put the pipeline goes to PREROLLING state and nothing more happens. If I cut the process in the sender, this message appears in the server :

  ubuntu@ip-172-31-87-56:~$ gst-launch-1.0 -e -v tcpserversrc host=ec2-52-29-128-23.eu-central-1.compute.amazonaws.com port=5555 ! h264parse ! mpegtsmux ! filesink location=file.ts
  
  Setting pipeline to PAUSED ...
  
  /GstPipeline:pipeline0/GstTCPServerSrc:tcpserversrc0: current-port = 5555
  
  Pipeline is PREROLLING ...
  
  ERROR: from element /GstPipeline:pipeline0/GstH264Parse:h264parse0: No valid frames found before end of stream
  
  Additional debug info:
  
  gstbaseparse.c(1281): gst_base_parse_sink_event_default (): /GstPipeline:pipeline0/GstH264Parse:h264parse0  
  
  ERROR: pipeline doesn't want to preroll.
  
  Setting pipeline to NULL ...
  
  /GstPipeline:pipeline0/GstTCPServerSrc:tcpserversrc0: current-port = 0
  
  Freeing pipeline ...

  Pipeline used in the EC2 Instance, the server :

  gst-launch-1.0 -e -v tcpserversrc host=ec2-52-29-128-23.eu-central-1.compute.amazonaws.com port=5555 ! h264parse ! mpegtsmux ! filesink location=file.ts

  Sender pipeline with x264enc :

  gst-launch-1.0 -e videotestsrc horizontal-speed=5 ! x264enc ! tcpclientsink port=5555 host=52.29.128.23

  Sender pipeline with openh264enc :

  gst-launch-1.0 -e videotestsrc horizontal-speed=5 ! openh264enc ! tcpclientsink port=5555 host=52.29.128.23

• doc/general : Fix entry for AMQP

  19 mars 2020, par Andriy Gelman

  doc/general : Fix entry for AMQP
  Signed-off-by : Andriy Gelman <andriy.gelman@gmail.com>
  
  Signed-off-by : Marton Balint <cus@passwd.hu>
  

  • [DH] doc/general.texi