1. 01 Nov, 2013 1 commit
  2. 14 Aug, 2013 1 commit
    • Martin Storsjö's avatar
      sdp: Add an option for sending RTCP packets to the source of the last packets · b56fc18b
      Martin Storsjö authored
      An SDP description normally only contains the target IP address
      and port for the packets. This means that we don't really have
      any clue where to send the RTCP RR packets - previously they're
      sent to the destination IP written in the SDP (at the same port),
      which rarely is the actual peer. And if the source for the packets
      is on a different port than the destination, it's never correct.
      
      With a new option, we can choose to send the packets to the
      address that the latest packet on each socket arrived from.
      ---
      Some may even argue that this should be the default - perhaps,
      but I'd rather keep it optional at first. Additionally, I'm not
      sure if sending RTCP RR directly back to the source is
      desireable for e.g. multicast.
      Signed-off-by: 's avatarMartin Storsjö <martin@martin.st>
      b56fc18b
  3. 29 Jul, 2013 1 commit
  4. 19 Jul, 2013 1 commit
  5. 18 Jul, 2013 1 commit
    • Ed Torbett's avatar
      avformat/rt*p: Joining a SSM multicast group using an SDP (Issue #2171) · 7203dbde
      Ed Torbett authored
      Passes Source-Specific Multicast parameters read from an sdp file through to the UDP socket code,
      allowing source-specific multicast streams to be correctly received. As an integral part of this
      change, additional checking (currently only enabled in the case of SSM streams, but probably
      useful in similar scenarios) has been added to the RTP protocol handler to distinguish UDP packets
      arriving from multiple sources to the same port and process only the expected packets
      (those transmitted from the expected UDP source address). This resolves an issue identified
      when multiple instances of FFmpeg subscribe to different Source-Specific Multicast streams
      but with each sharing the same destination port.
      Signed-off-by: 's avatarEdward Torbett <ed.torbett@simulation-systems.co.uk>
      Signed-off-by: 's avatarMichael Niedermayer <michaelni@gmx.at>
      7203dbde
  6. 11 Jul, 2013 1 commit
  7. 08 Apr, 2013 1 commit
  8. 15 Jan, 2013 1 commit
    • Martin Storsjö's avatar
      rtsp: Support decryption of SRTP signalled via RFC 4568 (SDES) · 424da308
      Martin Storsjö authored
      This only takes care of decrypting incoming packets; the outgoing
      RTCP packets are not encrypted. This is enough for some use cases,
      and signalling crypto keys for use with outgoing RTCP packets
      doesn't fit as simply into the API. If the SDP demuxer is hooked
      up with custom IO, the return packets can be encrypted e.g. via the
      SRTP protocol.
      
      If the SRTP keys aren't available within the SDP, the decryption
      can be handled externally as well (when using custom IO).
      Signed-off-by: 's avatarMartin Storsjö <martin@martin.st>
      424da308
  9. 08 Jan, 2013 1 commit
    • Martin Storsjö's avatar
      rtpdec: Support sending RTCP feedback packets · 86d9181c
      Martin Storsjö authored
      This sends NACK for missed packets and PLI (picture loss indication)
      if a depacketizer indicates that it needs a new keyframe, according
      to RFC 4585.
      
      This is only enabled if the SDP indicated that feedback is supported
      (via the AVPF or SAVPF profile names).
      
      The feedback packets are throttled to a certain maximum interval
      (currently 250 ms) to make sure the feedback packets don't eat up
      too much bandwidth (which might be counterproductive). The RFC
      specifies a more elaborate feedback packet scheduling.
      
      The feedback packets are currently sent independently from normal
      RTCP RR packets, which is not totally spec compliant, but works
      fine in the environments I've tested it in. (RFC 5506 allows this,
      but requires a SDP attribute for enabling it.)
      Signed-off-by: 's avatarMartin Storsjö <martin@martin.st>
      86d9181c
  10. 03 Jan, 2013 1 commit
    • Martin Storsjö's avatar
      rtsp: Add support for depacketizing RTP data via custom IO · e96406ed
      Martin Storsjö authored
      To use this, set sdpflags=custom_io to the sdp demuxer. During
      the avformat_open_input call, the SDP is read from the AVFormatContext
      AVIOContext (ctx->pb) - after the avformat_open_input call,
      during the av_read_frame() calls, the same ctx->pb is used for reading
      packets (and sending back RTCP RR packets).
      
      Normally, one would use this with a read-only AVIOContext for the
      SDP during the avformat_open_input call, then close that one and
      replace it with a read-write one for the packets after the
      avformat_open_input call has returned.
      
      This allows using the RTP depacketizers as "pure" demuxers, without
      having them tied to the libavformat network IO.
      Signed-off-by: 's avatarMartin Storsjö <martin@martin.st>
      e96406ed
  11. 21 Oct, 2012 1 commit
  12. 18 Oct, 2012 2 commits
  13. 08 Aug, 2012 2 commits
  14. 10 Jul, 2012 3 commits
  15. 08 May, 2012 1 commit
  16. 21 Jan, 2012 1 commit
  17. 20 Jan, 2012 1 commit
  18. 18 Jan, 2012 1 commit
  19. 12 Dec, 2011 1 commit
  20. 02 Nov, 2011 1 commit
  21. 17 Oct, 2011 3 commits
  22. 12 Oct, 2011 1 commit
  23. 18 Jul, 2011 1 commit
  24. 14 Jul, 2011 1 commit
  25. 03 Jul, 2011 1 commit
    • Diego Biurrun's avatar
      RTSP: Doxygen comment cleanup · f75e3da5
      Diego Biurrun authored
      Do not use Doxygen for comments that apply to specific implementation
      details; merge some duplicated Doxygen comment blocks.
      f75e3da5
  26. 10 Jun, 2011 1 commit
  27. 27 May, 2011 1 commit
  28. 11 May, 2011 1 commit
    • Martin Storsjö's avatar
      rtsp: Only do keepalive using GET_PARAMETER if the server supports it · 0b4949b5
      Martin Storsjö authored
      This is more like what VLC does. If the server doesn't mention
      supporting GET_PARAMETER in response to an OPTIONS request,
      VLC doesn't send any keepalive requests at all. After this patch,
      libavformat will still send OPTIONS keepalives if GET_PARAMETER
      isn't explicitly said to be supported.
      
      Some RTSP cameras don't support GET_PARAMETER, and will
      close the connection if this is sent as keepalive request
      (but support OPTIONS just fine, but probably don't need any
      keepalive at all). Some other cameras don't support using
      OPTIONS as keepalive, but require GET_PARAMETER instead.
      Signed-off-by: 's avatarMartin Storsjö <martin@martin.st>
      0b4949b5
  29. 19 Mar, 2011 1 commit
  30. 20 Feb, 2011 2 commits
  31. 30 Jan, 2011 1 commit
  32. 28 Jan, 2011 1 commit
  33. 26 Jan, 2011 1 commit