1. 13 Apr, 2020 18 commits
    • Michael Bradshaw's avatar
      05039c13
    • Michael Bradshaw's avatar
      tests/ref/vsynth: fix fate colr changes · 19a16330
      Michael Bradshaw authored
      Commit 9842fd3a stopped guessing colr
      values.
      Signed-off-by: 's avatarMichael Bradshaw <mjbshaw@google.com>
      19a16330
    • Michael Bradshaw's avatar
      avformat/movenc: write the mdcv atom by default · 4ae8d13e
      Michael Bradshaw authored
      The mdcv atom isn't in ISO/IEC 14496-12:2015 but it is expected to be
      added soon. See:
      http://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/259529.html
      
      The mdcv atom is already parsed in FFmpeg in mov.c.
      Signed-off-by: 's avatarMichael Bradshaw <mjbshaw@google.com>
      4ae8d13e
    • Michael Bradshaw's avatar
      avformat/movenc: remove the write_clli mov flag · 3ebf4497
      Michael Bradshaw authored
      The clli atom is expected to be standardized soon. See
      http://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/259529.html
      
      We now write the clli atom by default.
      Signed-off-by: 's avatarMichael Bradshaw <mjbshaw@google.com>
      3ebf4497
    • Michael Bradshaw's avatar
      9842fd3a
    • Michael Bradshaw's avatar
      avformat/movenc: use enum values directly for colr atom · b1699f4a
      Michael Bradshaw authored
      The switch cases were missing:
      
        - Primaries: bt470m, film, smpte428, and ebu3213.
        - TRCs: gamma22, gamma28, linear, log, log_sqrt, iec61966_2_4, bt1361,
          iec61966_2_1, bt2020_10bit, and bt2020_12bit.
        - Space: rgb, fcc, ycgco, bt2020_cl, smpte2085, chroma-derived-nc,
          chroma-derived-c, and ictcp.
      
      They also annoyingly remapped the following (which are functionally
      equivalent but can be treated differently by clients):
      
        - smpte240m primaries to smpte170m.
        - smpte170m TRC to bt709.
        - bt470bg color space to smpte170m.
      
      The enum values in FFmpeg are the same values as ITU-T H.273 and
      ISO/IEC 23001-8 so we can just use them directly, which is both simpler
      and preserves the user intent.
      Signed-off-by: 's avatarMichael Bradshaw <mjbshaw@google.com>
      b1699f4a
    • Paul B Mahol's avatar
      70f866ad
    • Linjie Fu's avatar
      lavc/vaapi_decode: fix the build failure when hevc_vaapi is disabled · 798ab1d0
      Linjie Fu authored
      Verified with ./configure --enable-vaapi --disable-hwaccel=hevc_vaapi
      
      Failure reported in:
      http://fate.ffmpeg.org/report.cgi?time=20200401135031&slot=x86_64-archlinux-gcc-randomSigned-off-by: 's avatarLinjie Fu <linjie.fu@intel.com>
      798ab1d0
    • Andreas Rheinhardt's avatar
      avformat/matroskaenc: Change signature of mkv_write_track() · 59e3a9ae
      Andreas Rheinhardt authored
      Up until now, mkv_write_track() received the index of the stream whose
      header data it is about to write as parameter; this index has until
      recently been explicitly used to generate both TrackNumber and TrackUID.
      But this is no longer so and as there is no reason why the function
      for writing a single TrackEntry should even know the index of the
      TrackEntry it is about to write, said index is replaced in the list of
      function parameters by the corresponding AVStream and mkv_track.
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      59e3a9ae
    • Andreas Rheinhardt's avatar
      avformat/matroskaenc: Automatically use right TrackNumber in Cues · 38596440
      Andreas Rheinhardt authored
      mkv_cuepoint (the structure used to store the index entries in the
      Matroska muxer) currently contains fields for both the index of the
      packet's stream in the AVFormatContext.streams array and for the
      Matroska TrackNumber; correspondingly, mkv_add_cuepoint() has parameters
      for both. But these two numbers can't be chosen independently, so get
      rid of the TrackNumber.
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      38596440
    • Andreas Rheinhardt's avatar
      avformat/matroskaenc: Ignore AttachedFiles for track limit · 629f08a8
      Andreas Rheinhardt authored
      Attachments are streams in FFmpeg, but they are not tracks in Matroska.
      Yet they were counted when checking a limit for the number of tracks that
      the Matroska muxer imposes. This is unnecessary and has been changed.
      
      Also use unsigned variables for the variables denoting TrackNumbers as
      negative TrackNumbers are impossible.
      
      (The Matroska file format actually has practically no limit on the
      number of tracks and this is purely what our muxer supports. But even if
      this limit were removed/relaxed in the future, it still makes sense to
      use small TrackNumbers as this patch does, because greater numbers need
      more bytes to encode.)
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      629f08a8
    • Andreas Rheinhardt's avatar
      avformat/matroskaenc: Make output more deterministic · ccadd00a
      Andreas Rheinhardt authored
      Using random values for TrackUID and FileUID (as happens when the
      AVFMT_FLAG_BITEXACT flag is not set) has the obvious downside of making
      the output indeterministic. This commit mitigates this by writing the
      potentially random values with a fixed size of eight byte, even if their
      actual values would fit into less than eight bytes. This ensures that
      even in non-bitexact mode, the differences between two files generated
      with the same settings are restricted to a few bytes in the header.
      (Namely the SegmentUID, the TrackUIDs (in Tracks as well as when
      referencing them via TagTrackUID), the FileUIDs (in Attachments as
      well as in TagAttachmentUID) as well as the CRC-32 checksums of the
      Info, Tracks, Attachments and Tags level-1-elements.) Without this
      patch, there might be an offset/a size difference between two such
      files.
      
      The FATE-tests had to be updated because the fixed-sized UIDs are also
      used in bitexact mode.
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      ccadd00a
    • Andreas Rheinhardt's avatar
      avformat/matroskaenc: Remove allocations for Attachments · 358b58cb
      Andreas Rheinhardt authored
      If there are Attachments to write, the Matroska muxer currently
      allocates two objects: An array that contains an entry for each
      AttachedFile containing just the stream index of the corresponding
      stream and the FileUID used for this AttachedFile; and a structure with
      a pointer to said array and a counter for said array. These uids are
      generated via code special to Attachments: It uses an AVLFG in the
      normal and a sha of the attachment data in the bitexact case. (Said sha
      requires an allocation, too.)
      
      But now that an uid is generated for each stream in mkv_init(), there is
      no need any more to use special code for generating the FileUIDs of
      AttachedFiles: One can simply use the uid already generated for the
      corresponding stream. And this makes the whole allocations of the
      structures for AttachedFiles as well as the structures itself superfluous.
      They have been removed.
      
      In case AVFMT_FLAG_BITEXACT is set, the uids will be different from the
      old ones which is the reason why the FATE-test lavf-mkv_attachment
      needed to be updated. The old method had the drawback that two
      AttachedFiles with the same data would have the same FileUID.
      The new one doesn't.
      
      Also notice that the dynamic buffer used to write the Attachments leaks
      if an error happens when writing the buffer. By removing the
      allocations potential sources of errors have been removed.
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      358b58cb
    • Andreas Rheinhardt's avatar
      avformat/matroskaenc: Reuse random seed · 4b18999b
      Andreas Rheinhardt authored
      This commit reuses the random seed generated in mkv_init() (to determine
      the TrackUIDs) for the SegmentUID in order to avoid a potentially
      expensive call to av_get_random_seed().
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      4b18999b
    • 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 14 commits