1. 03 May, 2020 6 commits
    • Andreas Rheinhardt's avatar
      avformat/matroskaenc: Make sure UIDs of delayed chapters are != 0 · 0aed3002
      Andreas Rheinhardt authored
      This has previously only been checked if the chapters were initially
      available, but not if they were only written in the trailer.
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      0aed3002
    • Andreas Rheinhardt's avatar
      avformat/vorbiscomment: Switch to AVIOContext from bytestream API · 6397b4d6
      Andreas Rheinhardt authored
      Up until now ff_vorbiscomment_write() used the bytestream API to write
      VorbisComments. Therefore the caller had to provide a sufficiently large
      buffer to write the output.
      
      Yet two of the three callers (namely the FLAC and the Matroska muxer)
      actually want the output to be written via an AVIOContext; therefore
      they allocated buffers of the right size just for this purpose (i.e.
      they get freed immediately afterwards). Only the Ogg muxer actually
      wants a buffer. But given that it is easy to wrap a buffer into an
      AVIOContext this commit changes ff_vorbiscomment_write() to use an
      AVIOContext for its output.
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      6397b4d6
    • Andreas Rheinhardt's avatar
      avformat/vorbiscomment: Replace AVDictionary ** by const AVDictionary * · 704d7c9f
      Andreas Rheinhardt authored
      ff_vorbiscomment_write() used an AVDictionary ** parameter for a
      dictionary whose contents ought to be written; yet this can be replaced
      by AVDictionary * since commit 042ca05f;
      and this in turn can be replaced by const AVDictionary * to indicate
      that the dictionary isn't modified; the latter also applies to
      ff_vorbiscomment_length().
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      704d7c9f
    • Andreas Rheinhardt's avatar
      avformat/matroskaenc: Replace impossible condition with assert · ca0a38f2
      Andreas Rheinhardt authored
      If a FLAC track uses an unconventional channel layout, the Matroska
      muxer adds a WAVEFORMATEXTENSIBLE_CHANNEL_MASK VorbisComment to the
      CodecPrivate to preserve this information. And given that FLAC uses
      24bit length fields, the muxer checks if the length is more than this
      and errors out if it is.
      
      Yet this can never happen, because we create the AVDictionary that is
      the source for the VorbisComment. It only contains exactly one entry
      that can't grow infinitely large (in fact, the length of the
      VorbisComment is <= 4 + 33 + 1 + 18 + strlen(LIBAVFORMAT_IDENT)).
      So we can simply assert the size to be < (1 << 24) - 4.
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      ca0a38f2
    • Andreas Rheinhardt's avatar
      avformat/matroskaenc: Write SeekHead when livestreaming · d13feae0
      Andreas Rheinhardt authored
      Commit 6fd300ac added support for WebM
      Chunk livestreaming; in this case, both the header as well as each
      Cluster is written to a file of its own, so that even if the AVIOContext
      seems seekable, the muxer has to behave as if it were not. Yet one of
      the added checks makes no sense: It ensures that no SeekHead is written
      preliminarily (and hence no SeekHead is written at all) if the option
      for livestreaming is set, although one should write the SeekHead in this
      case when writing the Header. E.g. the WebM-DASH specification [1]
      never forbids writing a SeekHead and in some instances (that don't apply
      here) even requires it (if Cues are written after the Clusters).
      
      [1]: https://sites.google.com/a/webmproject.org/wiki/adaptive-streaming/webm-dash-specificationSigned-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      d13feae0
    • Andreas Rheinhardt's avatar
      avformat/matroskaenc: Only write Cluster if it has in fact been opened · 68c7186d
      Andreas Rheinhardt authored
      Since commit 4aa0665f, the dynamic
      buffer destined for the contents of the current Cluster is no longer
      constantly allocated, reallocated and then freed after writing the
      content; instead it is reset and reused when closing a Cluster.
      
      Yet the code in mkv_write_trailer() still checked for whether a Cluster
      is open by checking whether the pointer to the dynamic buffer is NULL or
      not (instead of checking whether the position of the current Cluster is
      -1 or not). If a Cluster was not open, an empty Cluster would be output.
      
      One usually does not run into this issue, because unless there are
      errors, there are only three possibilities to not have an opened Cluster
      at the end of writing a packet:
      The first is if one sent an audio packet to the muxer. It might trigger
      closing and outputting the old Cluster, but because the muxer caches
      audio packets internally, it would not be output immediately and
      therefore no new Cluster would be opened.
      The second is an audio packet that does not contain data (such packets
      are sometimes sent for side-data only, e.g. by the FLAC encoder). The
      only difference to the first scenario is that such packets are not
      cached.
      The third is if one explicitly flushes the muxer by sending a NULL
      packet via av_write_frame().
      
      If one also allows for errors, then there is also another possibility:
      Caching the audio packet may fail in the first scenario.
      
      If one calls av_write_trailer() after the first scenario, the cached
      audio packet will be output when writing the trailer, for which
      a Cluster is opened and everything is fine; because flushing the muxer
      does currently not output the cached audio packet (if one is cached),
      the issue also does not exist if an audio packet has been cached before
      flushing. The issue only exists in one of the other scenarios.
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      68c7186d
  2. 02 May, 2020 19 commits
  3. 01 May, 2020 15 commits