1. 26 Sep, 2016 1 commit
  2. 01 Sep, 2016 1 commit
  3. 19 Aug, 2016 1 commit
  4. 25 Jun, 2016 1 commit
  5. 18 May, 2016 1 commit
  6. 27 Feb, 2016 1 commit
  7. 23 Feb, 2016 1 commit
    • Anton Khirnov's avatar
      lavf: replace AVStream.codec with AVStream.codecpar · 9200514a
      Anton Khirnov authored
      Currently, AVStream contains an embedded AVCodecContext instance, which
      is used by demuxers to export stream parameters to the caller and by
      muxers to receive stream parameters from the caller. It is also used
      internally as the codec context that is passed to parsers.
      
      In addition, it is also widely used by the callers as the decoding (when
      demuxer) or encoding (when muxing) context, though this has been
      officially discouraged since Libav 11.
      
      There are multiple important problems with this approach:
          - the fields in AVCodecContext are in general one of
              * stream parameters
              * codec options
              * codec state
            However, it's not clear which ones are which. It is consequently
            unclear which fields are a demuxer allowed to set or a muxer allowed to
            read. This leads to erratic behaviour depending on whether decoding or
            encoding is being performed or not (and whether it uses the AVStream
            embedded codec context).
          - various synchronization issues arising from the fact that the same
            context is used by several different APIs (muxers/demuxers,
            parsers, bitstream filters and encoders/decoders) simultaneously, with
            there being no clear rules for who can modify what and the different
            processes being typically delayed with respect to each other.
          - avformat_find_stream_info() making it necessary to support opening
            and closing a single codec context multiple times, thus
            complicating the semantics of freeing various allocated objects in the
            codec context.
      
      Those problems are resolved by replacing the AVStream embedded codec
      context with a newly added AVCodecParameters instance, which stores only
      the stream parameters exported by the demuxers or read by the muxers.
      9200514a
  8. 15 Dec, 2015 1 commit
  9. 12 Aug, 2015 1 commit
    • Martin Storsjö's avatar
      movenc: Add a new flag for writing global sidx indexes for dash · 26ac22e5
      Martin Storsjö authored
      The double meaning of the faststart flag (moving a moov atom
      to the start of files, making them streamable, for non-fragmented
      files, vs inserting a global sidx index at the start of files
      for fragmented files) is confusing - see 40ed1cbf for
      explanation of its origins.
      
      Since the second meaning of the flag hasn't been part of any
      libav release yet, just rename it to get rid of the confusion
      without any extra deprecation (which wouldn't get rid of the
      potential confusion, of users adding -movflags faststart
      even for fragmented files, where it isn't needed for making
      them "streamable").
      
      This gets back the old behaviour, where -movflags faststart
      doesn't have any effect for fragmented files.
      Signed-off-by: 's avatarMartin Storsjö <martin@martin.st>
      26ac22e5
  10. 10 Aug, 2015 1 commit
  11. 18 Jul, 2015 1 commit
  12. 19 Mar, 2015 2 commits
  13. 16 Mar, 2015 1 commit
  14. 10 Mar, 2015 2 commits
  15. 05 Mar, 2015 1 commit
  16. 26 Jan, 2015 1 commit
  17. 02 Jan, 2015 2 commits
    • Martin Storsjö's avatar
      movenc: Get rid of a hack for updating the dvc1 atom · b3b0b35d
      Martin Storsjö authored
      Use the more generic approach with the delay_moov flag, instead of
      having a update mechanism specific to this one single atom.
      Signed-off-by: 's avatarMartin Storsjö <martin@martin.st>
      b3b0b35d
    • Martin Storsjö's avatar
      movenc: Add an option for delaying writing the moov with empty_moov · 847bf598
      Martin Storsjö authored
      This delays writing the moov until the first fragment is written,
      or can be flushed by the caller explicitly when wanted. If the first
      sample in all streams is available at this point, we can write
      a proper editlist at this point, allowing streams to start at
      something else than dts=0. For AC3 and DNXHD, a packet is
      needed in order to write the moov header properly.
      
      This isn't added to the normal behaviour for empty_moov, since
      the behaviour that ftyp+moov is written during avformat_write_header
      would be changed. Callers that split the output stream into header+segments
      (either by flushing manually, with the custom_frag flag set, or by
      just differentiating between data written during avformat_write_header
      and the rest) will need to be adjusted to take this option into use.
      
      For handling streams that start at something else than dts=0, an
      alternative would be to use different kinds of heuristics for
      guessing the start dts (using AVCodecContext delay or has_b_frames
      together with the frame rate), but this is not reliable and doesn't
      necessarily work well with stream copy, and wouldn't work for getting
      the right initialization data for AC3 or DNXHD either.
      Signed-off-by: 's avatarMartin Storsjö <martin@martin.st>
      847bf598
  18. 18 Dec, 2014 1 commit
  19. 26 Nov, 2014 1 commit
    • Martin Storsjö's avatar
      movenc: Add a flag for indicating a discontinuous fragment · ee37620b
      Martin Storsjö authored
      This allows creating a later mp4 fragment without sequentially
      writing the earlier ones before (when called from a segmenter).
      
      Normally when writing a fragmented mp4 file sequentially, the
      first timestamps of a fragment are adjusted to match the
      end of the previous fragment, to make sure the timestamp is the
      same, even if it is calculated as the sum of previous fragment
      durations. (And for the first packet in a file, the offset of
      the first packet is written using an edit list.)
      
      When writing an individual mp4 fragment discontinuously like this
      (with potentially writing the earlier fragments separately later),
      there's a risk of getting a gap in the timeline if the duration
      field of the last packet in the previous fragment doesn't match up
      with the start time of the next fragment.
      
      Using this requires setting -avoid_negative_ts make_non_negative
      (or -avoid_negative_ts 0).
      Signed-off-by: 's avatarMartin Storsjö <martin@martin.st>
      ee37620b
  20. 17 Nov, 2014 3 commits
  21. 07 Nov, 2014 1 commit
    • Martin Storsjö's avatar
      movenc: Allow to request not to use edit lists · 1d8a0c1b
      Martin Storsjö authored
      In this case, shift tracks to start from zero instead (potentially
      stretching the first sample in tracks that start later than the
      first one).
      
      Some software does not support edit lists at all, the adobe flash
      player seems to be one of these. This results in AV sync errors when
      edit lists are used to adjust AV sync.
      
      Some players, such as QuickTime, don't respect the duration for
      audio packets, so if an audio track starts later than the video
      track and the first audio sample gets a duration longer than the
      actual amount of data in it, the result will be out of sync.
      
      Based on patches by Michael Niedermayer.
      Signed-off-by: 's avatarMartin Storsjö <martin@martin.st>
      1d8a0c1b
  22. 03 Nov, 2014 1 commit
  23. 29 Oct, 2014 2 commits
  24. 10 Oct, 2014 1 commit
  25. 06 Aug, 2014 1 commit
  26. 05 Aug, 2014 1 commit
  27. 14 Jul, 2014 1 commit
  28. 11 Jul, 2014 1 commit
  29. 18 May, 2014 1 commit
  30. 22 Mar, 2014 1 commit
  31. 16 Mar, 2014 1 commit
  32. 23 Oct, 2013 1 commit
  33. 11 Oct, 2013 1 commit
  34. 17 Sep, 2013 1 commit