1. 21 Jul, 2019 1 commit
  2. 30 Jun, 2019 1 commit
  3. 16 Jun, 2018 1 commit
  4. 12 Apr, 2018 1 commit
  5. 24 Feb, 2018 1 commit
  6. 14 Feb, 2018 1 commit
  7. 29 Nov, 2017 1 commit
  8. 29 Oct, 2017 2 commits
  9. 22 Oct, 2017 1 commit
  10. 19 Oct, 2017 1 commit
  11. 01 Sep, 2017 2 commits
  12. 30 Aug, 2017 1 commit
  13. 23 Aug, 2017 1 commit
  14. 24 Jun, 2017 2 commits
  15. 19 May, 2017 1 commit
  16. 14 Feb, 2017 1 commit
    • Joel Cunningham's avatar
      HTTP: improve performance by reducing forward seeks · 8c8e5d52
      Joel Cunningham authored
      This commit optimizes HTTP performance by reducing forward seeks, instead
      favoring a read-ahead and discard on the current connection (referred to
      as a short seek) for seeks that are within a TCP window's worth of data.
      This improves performance because with TCP flow control, a window's worth
      of data will be in the local socket buffer already or in-flight from the
      sender once congestion control on the sender is fully utilizing the window.
      
      Note: this approach doesn't attempt to differentiate from a newly opened
      connection which may not be fully utilizing the window due to congestion
      control vs one that is. The receiver can't get at this information, so we
      assume worst case; that full window is in use (we did advertise it after all)
      and that data could be in-flight
      
      The previous behavior of closing the connection, then opening a new
      with a new HTTP range value results in a massive amounts of discarded
      and re-sent data when large TCP windows are used.  This has been observed
      on MacOS/iOS which starts with an initial window of 256KB and grows up to
      1MB depending on the bandwidth-product delay.
      
      When seeking within a window's worth of data and we close the connection,
      then open a new one within the same window's worth of data, we discard
      from the current offset till the end of the window.  Then on the new
      connection the server ends up re-sending the previous data from new
      offset till the end of old window.
      
      Example (assumes full window utilization):
      
      TCP window size: 64KB
      Position: 32KB
      Forward seek position: 40KB
      
            *                      (Next window)
      32KB |--------------| 96KB |---------------| 160KB
              *
        40KB |---------------| 104KB
      
      Re-sent amount: 96KB - 40KB = 56KB
      
      For a real world test example, I have MP4 file of ~25MB, which ffplay
      only reads ~16MB and performs 177 seeks. With current ffmpeg, this results
      in 177 HTTP GETs and ~73MB worth of TCP data communication.  With this
      patch, ffmpeg issues 4 HTTP GETs and 3 seeks for a total of ~22MB of TCP data
      communication.
      
      To support this feature, the short seek logic in avio_seek() has been
      extended to call a function to get the short seek threshold value.  This
      callback has been plumbed to the URLProtocol structure, which now has
      infrastructure in HTTP and TCP to get the underlying receiver window size
      via SO_RCVBUF.  If the underlying URL and protocol don't support returning
      a short seek threshold, the default s->short_seek_threshold is used
      
      This feature has been tested on Windows 7 and MacOS/iOS.  Windows support
      is slightly complicated by the fact that when TCP window auto-tuning is
      enabled, SO_RCVBUF doesn't report the real window size, but it does if
      SO_RCVBUF was manually set (disabling auto-tuning). So we can only use
      this optimization on Windows in the later case
      Signed-off-by: 's avatarJoel Cunningham <joel.cunningham@me.com>
      Signed-off-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      8c8e5d52
  17. 11 Feb, 2017 1 commit
  18. 07 Jan, 2017 1 commit
  19. 08 Dec, 2016 1 commit
  20. 03 Oct, 2016 1 commit
  21. 30 Sep, 2016 2 commits
  22. 04 Aug, 2016 1 commit
  23. 17 Jul, 2016 1 commit
  24. 18 May, 2016 1 commit
    • Martin Storsjö's avatar
      avio: Allow custom IO users to get labels for the output bytestream · db7968bf
      Martin Storsjö authored
      This allows callers with avio write callbacks to get the bytestream
      positions that correspond to keyframes, suitable for live streaming.
      
      In the simplest form, a caller could expect that a header is written
      to the bytestream during the avformat_write_header, and the data
      output to the avio context during e.g. av_write_frame corresponds
      exactly to the current packet passed in.
      
      When combined with av_interleaved_write_frame, and with muxers that
      do buffering (most muxers that do some sort of fragmenting or
      clustering), the mapping from input data to bytestream positions
      is nontrivial.
      
      This allows callers to get directly information about what part
      of the bytestream is what, without having to resort to assumptions
      about the muxer behaviour.
      
      One keyframe/fragment/block can still be split into multiple (if
      they are larger than the aviocontext buffer), which would call
      the callback with e.g. AVIO_DATA_MARKER_SYNC_POINT, followed by
      AVIO_DATA_MARKER_UNKNOWN for the second time it is called with
      the following data.
      Signed-off-by: 's avatarMartin Storsjö <martin@martin.st>
      db7968bf
  25. 24 Mar, 2016 1 commit
    • Martin Storsjö's avatar
      avio: Copy URLContext generic options into child URLContexts · fab8156b
      Martin Storsjö authored
      Since all URLContexts have the same AVOptions, such AVOptions
      will be applied on the outermost context only and removed from the
      dict, while they probably make sense on all contexts.
      
      This makes sure that rw_timeout gets propagated to the innermost
      URLContext (to make sure it gets passed to the tcp protocol, when
      opening a http connection for instance).
      
      Alternatively, such matching options would be kept in the dict
      and only removed after the ffurl_connect call.
      Signed-off-by: 's avatarMartin Storsjö <martin@martin.st>
      fab8156b
  26. 16 Mar, 2016 1 commit
    • Hendrik Leppkes's avatar
      hls: read protocol options through the AVIOContext · 0d4b8a2c
      Hendrik Leppkes authored
      This reverts commit 9f9ed79d.
      
      The hlsopts member was never set anywhere and always NULL, furthermore
      the HLS demuxer needs to retrieve the proper options from the underlying
      http protocol (cookies, user-agent, etc), so a dummy context won't help.
      
      Instead, use the AVIOContext directly to access the options.
      0d4b8a2c
  27. 04 Mar, 2016 1 commit
  28. 29 Feb, 2016 1 commit
  29. 22 Feb, 2016 3 commits
  30. 02 Feb, 2016 1 commit
  31. 29 Jan, 2016 1 commit
  32. 13 Jan, 2016 1 commit
  33. 27 Dec, 2015 1 commit
  34. 16 Nov, 2015 1 commit