1. 01 May, 2020 18 commits
    • Limin Wang's avatar
      e7626e4e
    • Limin Wang's avatar
      6da653e5
    • Limin Wang's avatar
    • Limin Wang's avatar
      1726eefe
    • Andreas Rheinhardt's avatar
      avformat/matroskadec: Cosmetics · 39fb1e96
      Andreas Rheinhardt authored
      Reindentation as well as marking several variables used for demuxing
      RealAudio as const to clearly see that they don't change during
      demuxing.
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      39fb1e96
    • Andreas Rheinhardt's avatar
      avformat/matroskadec: Support ContentCompression for all codecs · 979b5b89
      Andreas Rheinhardt authored
      The Matroska demuxer has three functions for creating packets out of
      the data read: One for certain RealAudio codecs (ATRAC3, cook, sipr,
      RealAudio 28.8), one for WebVTT (actually, the WebM flavour of it) and
      one for all the others. Only the last function supported Matroska's
      ContentCompression (e.g. it reversed zlib compression or added the
      removed headers to the packets). But in Matroska, all tracks are allowed
      to be compressed. This commit adds support for this.
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      979b5b89
    • Andreas Rheinhardt's avatar
      avformat/matroskadec: Cache whether a track needs to be decoded · 96012d17
      Andreas Rheinhardt authored
      There is no need to recheck this for every frame.
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      96012d17
    • Andreas Rheinhardt's avatar
      avformat/matroskadec: Improve forward compability · b577968c
      Andreas Rheinhardt authored
      Matroska is built around the principle that a reader does not need to
      understand everything in a file in order to be able to make use of it;
      it just needs to ignore the data it doesn't know about.
      
      Our demuxer typically follows this principle, but there is one important
      instance where it does not: A Block belonging to a TrackEntry with no
      associated stream is treated as invalid data (i.e. the demuxer will try
      to resync to the next level 1 element because it takes this as a sign
      that it has lost sync). Given that we do not create streams if we don't
      know or don't support the type of the TrackEntry, this impairs this
      demuxer's forward compability.
      
      Furthermore, ignoring Blocks belonging to a TrackEntry without
      corresponding stream can (in future commits) also be used to ignore
      TrackEntries with obviously bogus entries without affecting the other
      TrackEntries (by not creating a stream for said TrackEntry).
      
      Finally, given that matroska_find_track_by_num() already emits its own
      error message in case there is no TrackEntry with a given TrackNumber,
      the error message (with level AV_LOG_INFO) for this can be removed.
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      b577968c
    • Andreas Rheinhardt's avatar
      avformat/matroskadec: Don't discard valid packets · e471faf9
      Andreas Rheinhardt authored
      A Block (meaning both a Block in a BlockGroup as well as a SimpleBlock)
      must have at least three bytes after the field containing the encoded
      TrackNumber. So if there are <= 3 bytes, the Matroska demuxer would
      skip this block, believing it to be an empty, but valid Block.
      
      This might discard valid nonempty Blocks, namely if the track uses header
      stripping. And certain definitely spec-incompliant Blocks don't raise
      errors: Those with two or less bytes left after the encoded TrackNumber
      and those with three bytes left, but with flags indicating that the Block
      uses lacing as then there has to be further data describing the lacing.
      
      Furthermore, zero-sized packets were still possible because only the
      size of the last entry of a lace was checked.
      
      This commit fixes this. All spec-compliant Blocks that contain data
      (even if side data only) are now returned to the caller; spec-compliant
      Blocks that don't contain anything are not returned.
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      e471faf9
    • Andreas Rheinhardt's avatar
      avformat/matroskadec: Simplify checks for cook and ATRAC3 · 4b1c19a0
      Andreas Rheinhardt authored
      Some conditions which don't change and which can therefore be checked
      in read_header() were instead rechecked upon parsing each block. This
      has been changed.
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      4b1c19a0
    • Andreas Rheinhardt's avatar
      avformat/matroskadec: Don't output uninitialized data for RealAudio 28.8 · bdaa98dd
      Andreas Rheinhardt authored
      The Matroska demuxer splits every sequence of h Matroska Blocks into
      h * w / cfs packets of size cfs; here h (sub_packet_h), w (frame_size)
      and cfs (coded_framesize) are parameters from the track's CodecPrivate.
      
      It does this by splitting the Block's data in h/2 pieces of size cfs each
      and putting them into a buffer at offset m * 2 * w + n * cfs where
      m (range 0..(h/2 - 1)) indicates the index of the current piece in the
      current Block and n (range 0..(h - 1)) is the index of the current Block
      in the current sequence of Blocks. The data in this buffer is then used
      for the output packets.
      
      The problem is that there is currently no check to actually guarantee
      that no uninitialized data will be output. One instance where this is
      trivially so is if h == 1; another is if cfs * h is so small that the
      input pieces do not cover everything that is output. In order to
      preclude this, rmdec.c checks for h * cfs == 2 * w and h >= 2. The
      former requirement certainly makes much sense, as it means that for
      every given m the input pieces (corresponding to the h different values
      of n) form a nonoverlapping partition of the two adjacent frames of size w
      corresponding to m. But precluding h == 1 is not enough, other odd
      values can cause problems, too. That is because the assumption behind
      the code is that h frames of size w contain data to be output, although
      the real number is h/2 * 2. E.g. for h = 3, cfs = 2 and w = 3 the
      current code would output four (== h * w / cfs) packets. although only
      data for three (== h/2 * h) packets has been read.
      
      (Notice that if h * cfs == 2 * w, h being even is equivalent to
      cfs dividing w; the latter condition also seems very reasonable:
      It means that the subframes are a partition of the frames.)
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      bdaa98dd
    • Andreas Rheinhardt's avatar
      avformat/matroskadec: Fix buffer overflow when demuxing RealAudio 28.8 · 4f5c6c1b
      Andreas Rheinhardt authored
      RealAudio 28.8 (like other RealAudio codecs) uses a special demuxing
      mode in which the data of the existing Matroska Blocks is not simply
      forwarded as-is. Instead data from several Blocks is recombined
      together to output several packets. The parameters governing this
      process are parsed from the CodecPrivate: Coded framesize (cfs), frame
      size (w) and sub_packet_h (h).
      
      During demuxing, h/2 pieces of data of size cfs each are read from every
      Matroska (Simple)Block and put at offset m * 2 * w + n * cfs of a buffer
      of size h * w, where m ranges from 0 to h/2 - 1 for each Block while n
      is initially zero and incremented after a Block has been parsed until it
      is h, at which poin the assembled packets are output and n reset.
      
      The highest offset is given by (h/2 - 1) * 2 * w + (h - 1) * cfs + cfs
      while the destination buffer's size is given by h * w. For even h, this
      leads to a buffer overflow (and potential segfault) if h * cfs > 2 * w;
      for odd h, the condition is h * cfs > 3 * w.
      
      This commit adds a check to rule this out.
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      4f5c6c1b
    • Andreas Rheinhardt's avatar
      avformat/matroskadec: Fix demuxing RealAudio 28.8 · c91e3690
      Andreas Rheinhardt authored
      RealAudio 28.8 does not need or use sub_packet_size for its demuxing
      and this field is therefore commonly set to zero. But since 18ca491b
      the Real Audio specific demuxing is no longer applied if sub_packet_size
      is zero because the codepath for cook and ATRAC3 divide by it; this made
      these files undecodable.
      
      Furthermore, since 569d18aa (merged in 2c8d876d) sub_packet_size being
      zero is used as an indicator for invalid data, so that a file containing
      such a track was completely skipped.
      
      This commit fixes this by not checking sub_packet_size for RealAudio
      28.8 at all.
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      c91e3690
    • Andreas Rheinhardt's avatar
      avformat/matroskadec: Simplify check for RealAudio · c6f60b90
      Andreas Rheinhardt authored
      They need a special parsing mode and in order to find out whether this
      mode is in use, several checks have to be performed. They can all be
      combined into one: If the buffer that is only used to assemble their
      packets has been allocated, use the RealAudio parsing mode.
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      c6f60b90
    • Andreas Rheinhardt's avatar
      avformat/matroskadec: Reject sipr flavor > 3 · 8287c201
      Andreas Rheinhardt authored
      Only flavors 0..3 seem to exist. E.g. rmdec.c treats any flavor > 3
      as invalid data. Furthermore, we do not know how big the packets to
      create ought to be given that for sipr these values are not read from
      the bitstream, but from a table.
      
      Furthermore, flavor is only used for sipr, so only check it for sipr;
      rmdec.c does the same. (The old check for flavor being < 0 was
      always wrong given that flavor is an int that is read via avio_rb16(),
      so it has been removed completely.)
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      8287c201
    • Limin Wang's avatar
    • Limin Wang's avatar
    • Lynne's avatar
      fate/oggopus-demux: fix fate failure · 4fd0559b
      Lynne authored
      Failure was due to the extra comment printed by libavcodec/utils.c since
      side data is used to signal the skipped samples.
      4fd0559b
  2. 30 Apr, 2020 18 commits
  3. 29 Apr, 2020 4 commits