1. 06 Oct, 2020 1 commit
  2. 30 Sep, 2020 1 commit
  3. 28 Sep, 2020 5 commits
  4. 24 Sep, 2020 1 commit
    • Nicolas Dufresne's avatar
      rtpbin: Remove the rtpjitterbuffer with the stream · 345f74b0
      Nicolas Dufresne authored
      Since !348, the jitterbuffer was only removed with the session. This restores
      the original behaviour and removes the jitterbuffer when the stream is
      removed. This avoid accumulating jitterbuffer objects into the bin when a
      session is reused.
      
      Part-of: <!735>
      345f74b0
  5. 23 Sep, 2020 1 commit
    • Nicolas Dufresne's avatar
      rtpbin: Cleanup dead code · ecc110ca
      Nicolas Dufresne authored
      The rtpjitterbuffer is now part of the session elements, we no longer need
      to do the ref_sink dance when signalling it. It is already owned by the bin
      when signalled. Also, the code that handles generic session elements already
      handle the ref_sink() calls since:
      
      03dc2295
      
      Part-of: <!735>
      ecc110ca
  6. 21 Sep, 2020 8 commits
    • Matthew Waters's avatar
      rtph26*depay: drop FU's without a corresponding start bit · ea61714c
      Matthew Waters authored
      If we have not received a FU with a start bit set, any subsequent FU
      data is not useful at all and would result in an invalid stream.
      
      This case is constructed from multiple requirements in
      RFC 3984 Section 5.8 and RFC 7798 Section 4.4.3.  Following are excerpts
      from RFC 3984 but RFC 7798 contains similar language.
      
      The FU in a single FU case is forbidden:
      
         A fragmented NAL unit MUST NOT be transmitted in one FU; i.e., the
         Start bit and End bit MUST NOT both be set to one in the same FU
         header.
      
      and dropping is possible:
      
         If a fragmentation unit is lost, the receiver SHOULD discard all
         following fragmentation units in transmission order corresponding to
         the same fragmented NAL unit.
      
      The jump in seqnum case is supported by this from the specification
      instead of implementing the forbidden_zero_bit mangling:
      
         If a fragmentation unit is lost, the receiver SHOULD discard all
         following fragmentation units in transmission order corresponding to
         the same fragmented NAL unit.
      
         A receiver in an endpoint or in a MANE MAY aggregate the first n-1
         fragments of a NAL unit to an (incomplete) NAL unit, even if fragment
         n of that NAL unit is not received.  In this case, the
         forbidden_zero_bit of the NAL unit MUST be set to one to indicate a
         syntax violation.
      
      Part-of: <!730>
      ea61714c
    • Seungha Yang's avatar
      imagefreeze: Response caps query from srcpad · 027940a4
      Seungha Yang authored
      ... and chain up to default query handler for unhandled query types.
      Unhandled query shouldn't be returned with FALSE if there's no special needs.
      
      Part-of: <!731>
      027940a4
    • Matthew Waters's avatar
      qtmux: make documentation happy · e64227f5
      Matthew Waters authored
      introduce a base qtmux class that we can install documentation snippets
      on instead of duplicating across alll the isomp4 elements
      
      Part-of: <!643>
      e64227f5
    • Matthew Waters's avatar
      isomp4/mux: add a fragment mode for initial moov with data · 52b63de1
      Matthew Waters authored
      Used by some proprietary software for their fragmented files.
      
      Adds some support for multi-stream fragmented files
      
      Flow is as follows.
      1. The first 'fragment' is written as a self-contained fragmented
         mdat+moov complete with an edit list and durations, tags, etc.
      2. Subsequent fragments are written with a mdat+moof and each stream is
         interleaved as data arrives (currently ignoring the interleave-*
         properties).  data-offsets in both the traf and the trun ensure
         data is read from the correct place on demuxing.  Data/chunk offsets
         are also kept for writing out the final moov.
      3. On finalisation, the initial moov is invalidated to a hoov and the
         size of the first mdat is extended to cover the entire file contents.
         Then a moov is written as regularly would in moov-at-end mode (the
         default).
      
      This results in a file that is playable throughout while leaving a
      finalised file on completion for players that do not understand
      fragmented mp4.
      
      Part-of: <!643>
      52b63de1
    • Matthew Waters's avatar
      97e932d5
    • Matthew Waters's avatar
      qtdemux: bail out when encountering an atom with a size of 0 · 37f0119f
      Matthew Waters authored
      A size 0 atom means the atom extends to the end of the file.  No further
      valid atoms will ever follow.  Avoids a subsequent scan for an atom from
      one byte earlier after encountering a size 0 atom.
      
      Part-of: <!643>
      37f0119f
    • Matthew Waters's avatar
      qtdemux: fix subsequent moof parsing after moov with valid samples · 868149ca
      Matthew Waters authored
      reset the moof_offset back to its original value like is done in the
      error case just before.
      
      Fixes subsequent parsing of a moof following a moov that contains valid
      samples in a non-streaming fragmented mp4.
      
      Part-of: <!643>
      868149ca
    • Matthew Waters's avatar
      qtdemux: extend edit list when fragmented · 2b9c4656
      Matthew Waters authored
      When we are fragmented, the edit list may only refer to the portion of
      the media that is in the moov.  Extend the edit list stop time when we
      if there is only one qt segment and we are reading a fragmented file.
      
      Fixes playback of some fragmented mp4 files generated by proprietary
      programs.
      
      Part-of: <!643>
      2b9c4656
  7. 18 Sep, 2020 3 commits
  8. 16 Sep, 2020 2 commits
    • StefanBruens's avatar
      qtdemux: Add support for AAX encrypted audio streams · ee3ea2a9
      StefanBruens authored
      This is modelled after the DASH Common Encryption scheme, but is somewhat
      simpler as more parts are fixed, i.e. just one encryption scheme.
      
      The output caps are fixed to 'application/x-aavd'. All information
      required for decryption are part of the 'adrm' atom, which is passed
      on as a property. The property is attached to the buffer.
      
      Part-of: <!577>
      ee3ea2a9
    • StefanBruens's avatar
      qtdemux: Add 'aavd' and related fourcc codes for AAX encrypted audio · 6e68873d
      StefanBruens authored
      The 'aavd' box is contained in the 'stsd' sample description. The 'aavd'
      box follows the layout of an 'mp4a' entry, i.e. it contains a single
      standard 'esds' extension box, and the two proprietary 'adrm' and 'aabd'
      extension boxes.
      
      Part-of: <!577>
      6e68873d
  9. 14 Sep, 2020 1 commit
  10. 13 Sep, 2020 1 commit
  11. 11 Sep, 2020 1 commit
  12. 10 Sep, 2020 4 commits
  13. 09 Sep, 2020 5 commits
  14. 08 Sep, 2020 6 commits