1. 05 Jan, 2015 8 commits
  2. 04 Jan, 2015 2 commits
  3. 03 Jan, 2015 24 commits
  4. 02 Jan, 2015 6 commits
    • Martin Storsjö's avatar
      sidxindex: Remove parsing that isn't necessary any longer · 470c9db1
      Martin Storsjö authored
      When we don't adjust the Period start time, we don't need to
      parse the earliest_presentation_time from the sidx boxes either.
      Signed-off-by: 's avatarMartin Storsjö <martin@martin.st>
      470c9db1
    • Martin Storsjö's avatar
      sidxindex: Don't adjust the Period start time depending on the track start time · 5cf6bda6
      Martin Storsjö authored
      This was only necessary to get playback to start with dash.js 1.2.0,
      it has been fixed in the git version.
      
      The previous behaviour was incorrect - the Period's start time
      is irrespective of the actual first timestamp of the contents
      within the period. The Period start time only says when, within the
      global timeline, this particular piece should start to be played
      back.
      Signed-off-by: 's avatarMartin Storsjö <martin@martin.st>
      5cf6bda6
    • Martin Storsjö's avatar
      dashenc: Use pts for MPD timeline timestamps · 7a1a63e3
      Martin Storsjö authored
      This should be more correct. This also should give more sensible
      switching between video streams with different amount of b-frame
      delay.
      
      The current dash.js release (1.2.0) fails to start playback of
      such files from the start (if the start pts is > 0), but this has
      been fixed in the current git version of dash.js.
      
      Also enable the use of edit lists, so that streams in many cases
      start at pts=0.
      Signed-off-by: 's avatarMartin Storsjö <martin@martin.st>
      7a1a63e3
    • Martin Storsjö's avatar
      dashenc: Use delay_moov · c5e7ea13
      Martin Storsjö authored
      Signed-off-by: 's avatarMartin Storsjö <martin@martin.st>
      c5e7ea13
    • 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