Recherche avancée

Sur d’autres sites (6069)

• avformat/matroskaenc : Rename functions to better reflect what they do

  15 avril 2020, par Andreas Rheinhardt

  avformat/matroskaenc : Rename functions to better reflect what they do
  EBML uses variable length integers both for the EBML IDs as well as for
  
  the EBML lengths ; Matroska also uses them for the TrackNumber in
  
  (Simple)Blocks and for the lengths of laces when EBML lacing is used.
  When encoding EBML lengths, certain encodings have a special meaning,
  
  namely that the element has an unknown length. This is not so when
  
  encoding general EBML variable length integers.
  Yet the functions called ebml_num_size() and put_ebml_num() had this
  
  special meaning hardcoded, i.e. they are there to write EBML lengths and
  
  not general EBML numbers. So rename them.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavformat/matroskaenc.c

• avformat/matroskaenc : Improve mimetype search

  3 novembre 2019, par Andreas Rheinhardt

  avformat/matroskaenc : Improve mimetype search
  Use the mime_types of the corresponding AVCodecDescriptor instead of
  
  tables specific to Matroska. The former are generally more encompassing :
  
  They contain every item of the current lists except "text/plain" for
  
  AV_CODEC_ID_TEXT and "binary" for AV_CODEC_ID_BIN_DATA.
  The former has been preserved by special-casing it while the latter is
  
  a hack added in c9212abf so that the demuxer (which uses the same tables)
  
  sets the appropriate CodecID for broken files ("binary" is not a correct
  
  mime type at all) ; using it for the muxer was a mistake. The correct
  
  mime type for AV_CODEC_ID_BIN_DATA is "application/octet-stream" and
  
  this is what one gets from the AVCodecDescriptor.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavformat/matroskaenc.c

• avformat/mux : Don't modify packets we don't own

  13 août 2019, par Andreas Rheinhardt

  avformat/mux : Don't modify packets we don't own
  The documentation of av_write_frame() explicitly states that the function
  
  doesn't take ownership of the packets sent to it ; while av_write_frame()
  
  does not directly unreference the packets after having written them, it
  
  nevertheless modifies the packet in various ways :
  
  1. The timestamps might be modified either by prepare_input_packet() or
  
  compute_muxer_pkt_fields().
  
  2. If a bitstream filter gets applied, it takes ownership of the
  
  reference and the side-data in the packet sent to it.
  
  In case of do_packet_auto_bsf(), the end result is that the returned packet
  
  contains the output of the last bsf in the chain. If an error happens,
  
  a blank packet will be returned ; a packet may also simply not lead to
  
  any output (vp9_superframe).
  
  This also implies that side data needs to be really copied and can't be
  
  shared with the input packet.
  
  The method choosen here minimizes copying of data : When the input isn't
  
  refcounted and no bitstream filter is applied, the packet's data will
  
  not be copied.
  Notice that packets that contain uncoded frames are exempt from this
  
  because these packets are not owned by and returned to the user. This
  
  also moves unreferencing the packets containing uncoded frames to
  
  av_write_frame() in the noninterleaved codepath ; in the interleaved
  
  codepath, these packets are already freed in av_interleaved_write_frame(),
  
  so that unreferencing the packets in write_uncoded_frame_internal() is
  
  no longer needed. It has been removed.
  Reviewed-by : Marton Balint <cus@passwd.hu>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavformat/mux.c