1. 13 Apr, 2020 4 commits
    • Andreas Rheinhardt's avatar
      avformat/matroskaenc: Use random TrackUID · 45314ff2
      Andreas Rheinhardt authored
      Up until now, the TrackUID of a Matroska track which is supposed to be
      random was not random at all: It always coincided with the TrackNumber
      which is usually the 1-based index of the corresponding stream in the
      array of AVStreams. This has been changed: It is now set via an AVLFG
      if AVFMT_FLAG_BITEXACT is not set. Otherwise it is set like it is set
      now (the only change happens if an explicit track number has been
      chosen via dash_track_number, because the system used in the normal
      situation is now used, too). In particular, no FATE tests need to be
      updated.
      
      This also fixes a bug in case the dash_track_number option was used:
      In this case the TrackUID was set to the provided number, but the tags
      were written with a TagTrackUID simply based upon the index, so that
      the tags didn't apply to the track they ought to apply to.
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      45314ff2
    • Andreas Rheinhardt's avatar
      avformat/matroskaenc: Don't waste bytes writing durations · bd7dea3f
      Andreas Rheinhardt authored
      Tags in the Matroska file format can be summarized as follows: There is
      a level 1-element called Tags containing one or many Tag elements each
      of which in turn contain a Targets element and one or many SimpleTags.
      Each SimpleTag roughly corresponds to a single key-value pair similar to
      an AVDictionaryEntry. The Targets meanwhile contains information to what
      the metadata contained in the SimpleTags contained in the containing Tag
      applies (i.e. to the file as a whole or to an individual track).
      
      The Matroska muxer writes such metadata. It puts the metadata of every
      stream into a Tag whose Targets makes it point to the corresponding
      track. And if the output is seekable, then it also adds another Tag for
      each track whose Targets corresponds to the track and where it reserves
      space in a SimpleTag to write the duration at the end of the muxing
      process into.
      
      Yet there is no reason to write two Tag elements for a track and a few
      bytes (typically 24 bytes per track) can be saved by adding the duration
      SimpleTag to the other Tag of the same track (if it exists).
      
      FATE has been updated because the output files changed. (Tests that
      write to unseekable output (pipes) needn't be updated (no duration tag
      has ever been written for them) and the same applies to tests without
      further metadata.)
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      bd7dea3f
    • Andreas Rheinhardt's avatar
      avformat/matroskaenc: Ensure that ChapterUID are != 0 · 3c3ad1de
      Andreas Rheinhardt authored
      AVChapters have an int as id field and therefore this value can appear
      <= 0. When remuxing from Matroska, this value actually contains
      the lower 32 bits of the original ChapterUID (which can be 64 bits).
      
      In order to ensure that the ChapterUID is always > 0, they were offset
      as follows (since 07704c61): First max(0, 1LL - chapter[i].id) was computed
      and stored in an uint32_t. And then the IDs were offset using this value.
      
      This has two downsides:
      1. It does not ensure that the UID is actually != 0: Namely if there is
      a chapter with id == INT_MIN, then the offset will be 2^31 + 1 and a
      chapter with id == INT_MAX will become 2^31 - 1 + 2^31 + 1 = 2^32 = 0,
      because the actual calculation was performed in 32 bits.
      2. As soon as a chapter id appears to be negative, a nontrivial offset
      is used, so that not even a ChapterUID that only uses 32 bits is
      preserved.
      
      So change this by treating the id as an unsigned value internally and
      only offset (by 1) if an id vanishes. The actual offsetting then has to
      be performed in 64 bits in order to make sure that no UINT32_MAX wraps
      around.
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      3c3ad1de
    • Gyan Doshi's avatar
      2e2fa2d6
  2. 12 Apr, 2020 8 commits
  3. 11 Apr, 2020 19 commits
  4. 10 Apr, 2020 9 commits