Recherche avancée

Sur d’autres sites (9694)

• h264_mp4toannexb : Don't forget numOfPictureParameterSets

  14 décembre 2019, par Andreas Rheinhardt

  h264_mp4toannexb : Don't forget numOfPictureParameterSets
  The format of an AVCDecoderConfigurationRecord, the out-of-band
  
  extradata of H.264 in mp4, is as follows : First four bytes containing
  
  version, profile and level, one byte for the length size and one byte
  
  each for the number of SPS, followed by the SPS (each with its own size
  
  field), followed by a byte containing the number of PPS followed by the
  
  PPS with their size fields. While the number of SPS/PPS may be zero, the
  
  bytes containing these numbers are mandatory. Yet the byte containing
  
  the number of PPS has been ignored in two places :
  
  1. In the initial check for whether the extradata can contain an
  
  AVCDecoderConfigurationRecord. The minimum size is 7, not 6.
  
  2. No check is made for whether the extradata ended right after the last
  
  byte of the last SPS of the SPS array. Instead the first byte of the
  
  padding is read as if it were part of the extradata and contained the
  
  number of PPS (namely zero, given that the padding is zeroed). No error
  
  or warning was ever raised.
  
  This has been changed. Such truncated extradata is now considered
  
  invalid ; the check for 2. has been incorporated into the general size
  
  check.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavcodec/h264_mp4toannexb_bsf.c

• h264_mp4toannexb : Try to avoid four byte startcodes

  14 décembre 2019, par Andreas Rheinhardt

  h264_mp4toannexb : Try to avoid four byte startcodes
  According to the H.264 specifications, the only NAL units that need to
  
  have four byte startcodes in H.264 Annex B format are SPS/PPS units and
  
  units that start a new access unit. Before af7e953a, the first of these
  
  conditions wasn't upheld as already existing in-band parameter sets
  
  would not automatically be written with a four byte startcode, but only
  
  when they already were at the beginning of their input packets. But it
  
  made four byte startcodes be used too often as every unit that is written
  
  together with a parameter set that is inserted from extradata received a
  
  four byte startcode although a three byte start code would suffice
  
  unless the unit itself were a parameter set.
  FATE has been updated to reflect the changes. Although the patch leaves
  
  the extradata unchanged, the size of the extradata according to the FATE
  
  reports changes. This is due to a quirk in ff_h2645_packet_split which
  
  is used by extract_extradata : If the input is Annex B, the first zero of
  
  a four byte startcode is considered a part of the last unit (if any).
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavcodec/h264_mp4toannexb_bsf.c
  • [DH] tests/ref/fate/h264-bsf-mp4toannexb
  • [DH] tests/ref/fate/h264_mp4toannexb_ticket2991
  • [DH] tests/ref/fate/h264_mp4toannexb_ticket5927
  • [DH] tests/ref/fate/h264_mp4toannexb_ticket5927_2
  • [DH] tests/ref/fate/segment-mp4-to-ts

• avformat/matroskadec : Fix demuxing ProRes

  28 septembre 2019, par Andreas Rheinhardt

  avformat/matroskadec : Fix demuxing ProRes
  The structure of a ProRes frame in mov/mp4 is that of a typical atom :
  
  First a 32 bit BE size field, then a tag detailling the content. Said
  
  size field includes the eight bytes of the atom header.
  This header is actually redundant, as the size of the atom is already
  
  known from the containing atom. It is therefore stripped away when muxed
  
  into Matroska and so the Matroska demuxer has to recreate upon demuxing.
  
  But it did not account for the fact that the size field includes the
  
  size of the header and this can lead to problems when a decoder uses the
  
  in-band size field.
  Fixes ticket #8210.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  
  Signed-off-by : James Almer <jamrial@gmail.com>
  

  • [DH] libavformat/matroskadec.c