Recherche avancée

Sur d’autres sites (6261)

• avformat/matroskaenc : Remove inconsistencies wrt seekability handling

  1er mai 2020, par Andreas Rheinhardt

  avformat/matroskaenc : Remove inconsistencies wrt seekability handling
  The Matroska muxer behaves differently in several ways when it thinks
  
  that it is in unseekable/livestreaming mode : It does not add Cue entries
  
  because they won't be written anyway for a livestream and it writes some
  
  elements only preliminarily (with the intention to overwrite them with
  
  an updated version at the end) when non-livestreaming etc.
  There are two ways to set the Matroska muxer into livestreaming mode :
  
  Setting an option or by providing an unseekable AVIOContext. Yet the
  
  actual checks were not consistent :
  If the AVIOContext was unseekable and no AAC extradata was available
  
  when writing the header, writing the header failed ; but if the AVIOContext
  
  was seekable, it didn't, because the muxer expected to get the extradata
  
  via packet side-data. Here the livestreaming option has not been checked,
  
  although one can't use the updated extradata in case it is a livestream.
  If the reserve_index_space option was used, space for writing Cues would
  
  be reserved when writing the header unless the AVIOContext was
  
  unseekable. Yet Cues were only written if the livestreaming option was
  
  not set and the AVIOContext was seekable (when writing the trailer), so
  
  if the AVIOContext was seekable and the livestreaming option set, the
  
  reserved space would never be used at all.
  If the AVIOContext was unseekable and the livestreaming option was not
  
  set, it would be attempted to update the main length field at the end.
  
  After all, it might be possible that the file is so short that it fits
  
  into the AVIOContext's buffer in which case the seek back would work.
  
  Yet this is dangerous : It might be that we are not dealing with a
  
  simple output file, but that our output gets split into chunks and that
  
  each of these chunks is actually seekable. In this case some part of the
  
  last chunk (namely the eight bytes that have the same offset as the
  
  length field had in the header) will be overwritten with what the muxer
  
  wrongly believes to be the filesize.
  
  (The livestreaming option has been added to deal with this scenario,
  
  yet its documentation ("Write files assuming it is a live stream.")
  
  doesn't make this clear at all. At least the segment muxer does not
  
  set the option for live and given that the chances of successfully
  
  seeking when the output is actually unseekable are slim, it is best to
  
  not attempt to update the length field in the unseekable case at all.)
  All these inconsistencies were fixed by treating the output as seekable
  
  if the livestreaming option is not set and if the AVIOContext is
  
  seekable. A macro has been used to enforce consistency and improve code
  
  readability.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavformat/matroskaenc.c

• avformat/matroskaenc : Avoid unnecessary seek

  2 mai 2020, par Andreas Rheinhardt

  avformat/matroskaenc : Avoid unnecessary seek
  The Matroska muxer has a pair of functions designed to write master
  
  elements whose exact length is not known in advance : start_ebml_master()
  
  and end_ebml_master(). The first one of these would write the EBML ID of
  
  the master element that is about to be started, reserve some bytes for
  
  the length field and record the current position as well as how many
  
  bytes were used for the length field. When writing the master's contents
  
  is finished, end_ebml_master() gets the current position (at the end of
  
  the master element), seeks to the length field using the recorded
  
  position, writes the length field and seeks back to the end of the
  
  master element so that one can continue writing other elements.
  But if one wants to modify the content of the master element itself,
  
  then the seek back is superfluous. This is the scenario that presents
  
  itself when writing the trailer : One wants to update several elements
  
  contained in the Segment master element (this is the main/root master
  
  element of a Matroska file) that were already written when writing the
  
  header. The current approach is to seek to the beginning of the file
  
  to update the elements, then seek to the end, call end_ebml_master()
  
  which immediately seeks to the beginning to write the length and seeks
  
  back. The seek to the end (which has only been performed because
  
  end_ebml_master() uses the initial position to determine the length
  
  of the master element) and the seek back are of course superfluous.
  This commit avoids these seeks by no longer using start/end_ebml_master()
  
  to write the segment's length field. Instead, it is now written
  
  manually. The new approach is : Seek to the beginning to write the length
  
  field, then update the elements (in the order they appear in the file)
  
  and seek back to the end.
  This reduces the ordinary amount of seeks of the Matroska muxer to two
  
  (ordinary excludes scenarios where one has big Chapters or Attachments
  
  or where one writes the Cues at the front).
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavformat/matroskaenc.c

• avformat/matroskaenc : Don't segfault when seekability changes

  1er mai 2020, par Andreas Rheinhardt

  avformat/matroskaenc : Don't segfault when seekability changes
  If the Matroska muxer's AVIOContext was unseekable when writing the
  
  header, but is seekable when writing the trailer, the code for writing
  
  the trailer presumes that a dynamic buffer exists and tries to update
  
  its content in order to overwrite data that has already been
  
  preliminarily written when writing the header, yet said buffer doesn't
  
  exist as it has been written finally and not preliminarily when writing
  
  the header (because of the unseekability it was presumed that one won't
  
  be able to update the data anyway).
  This commit adds a check for this and also for a similar situation
  
  involving updating extradata with new data from packet side-data.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavformat/matroskaenc.c