Recherche avancée

Sur d’autres sites (7195)

• FFMPEG error : "First slice in a frame missing" when decoding H.265 stream

  19 octobre 2023, par Snejk

  I have a problem with decoding IP camera stream (h.265) using ffmpeg libraries.

  


  I use Live555 to receive RTP payload.

  


  mMediaSession->readSource()->getNextFrame(mVideoBuffer.data(),
mVideoBuffer.size(), Stream::Static_PayloadRead, this, Stream::Static_StreamClose, this);


  


  First two bytes (after the start code 0001) has the nal_unit_header. I am retrieving the type, from bits 1-6 ( ( NALU[0] >> 1 ) & 0x3F ). Then I am processing the data depending on the NALu type :

  


  enum NalUnitType  
{  
  NAL_UNIT_CODED_SLICE_TRAIL_N = 0,   // 0  
  NAL_UNIT_CODED_SLICE_TRAIL_R,   // 1    
  NAL_UNIT_CODED_SLICE_TSA_N,     // 2  
  NAL_UNIT_CODED_SLICE_TLA,       // 3    
  NAL_UNIT_CODED_SLICE_STSA_N,    // 4  
  NAL_UNIT_CODED_SLICE_STSA_R,    // 5    
  NAL_UNIT_CODED_SLICE_RADL_N,    // 6  
  NAL_UNIT_CODED_SLICE_DLP,       // 7     
  NAL_UNIT_CODED_SLICE_RASL_N,    // 8  
  NAL_UNIT_CODED_SLICE_TFD,       // 9   
  NAL_UNIT_RESERVED_10,  
...
  NAL_UNIT_CODED_SLICE_BLA,       // 16 
  NAL_UNIT_CODED_SLICE_BLANT,     // 17    
  NAL_UNIT_CODED_SLICE_BLA_N_LP,  // 18  
  NAL_UNIT_CODED_SLICE_IDR,       // 19  // Current name in the spec: IDR_W_DLP  
  NAL_UNIT_CODED_SLICE_IDR_N_LP,  // 20  
  NAL_UNIT_CODED_SLICE_CRA,       // 21  
  NAL_UNIT_RESERVED_22,  
 ...
  NAL_UNIT_VPS,                   // 32  
  NAL_UNIT_SPS,                   // 33  
  NAL_UNIT_PPS,                   // 34  
  NAL_UNIT_ACCESS_UNIT_DELIMITER, // 35  
  NAL_UNIT_EOS,                   // 36  
  NAL_UNIT_EOB,                   // 37  
  NAL_UNIT_FILLER_DATA,           // 38  
  NAL_UNIT_SEI,                   // 39 Prefix SEI  
  NAL_UNIT_SEI_SUFFIX,            // 40 Suffix SEI  
...
  NAL_UNIT_INVALID,  
};  


  


  If buffer doesn't have the start code, I am adding 0x00000001 at the start of the payload data, before sending it to FFmpeg. Camera is sending these NALu (in the same order) :

  


  

  1. HEVC_NAL_VPS,

  


  2. HEVC_NAL_SPS,

  


  3. HEVC_NAL_PPS,

  


  4. HEVC_NAL_IDR_W_RADL,

  


  5. HEVC_NAL_IDR_W_RADL,

  


  6. HEVC_NAL_IDR_W_RADL,

  


  7. HEVC_NAL_TRAIL_R,

  


  8. HEVC_NAL_TRAIL_R
...

  


  


  My solution works partially as I have 1/3 of image decoded. The other 2 HEVC_NAL_IDR_W_RADL slices get FFmpeg error : "First slice in a frame missing". If I lower the stream resolution I have 1/2 image with one additional HEVC_NAL_IDR_W_RADL slice.

  


  Similiar code works with H.264 stream so I know (I hope) that Live555 and FFmpeg code should be fine.

  


  Live555 doesn't reassemble the I frames (http://lists.live555.com/pipermail/live-devel/2016-September/020244.html)

  


  Is there a specific way to reassemble frame send in multiple slices. I have even tried to assemble the frame as it would be Fragmented Unit NAL type 49 (How to depacketize the fragmented frames in RTP data (over UDP) for H265/HEVC ?)

  


  Many Thanks

  


• avformat/sccdec : Don't use uninitialized data, fix crash, simplify logic

  1er octobre 2021, par Andreas Rheinhardt

  avformat/sccdec : Don't use uninitialized data, fix crash, simplify logic
  Up until now, the scc demuxer not only read the line that it intends
  
  to process, but also the next line, in order to be able to calculate
  
  the duration of the current line. This approach leads to unnecessary
  
  complexity and also to bugs : For the last line, the timing of the
  
  next subtitle is not only logically indeterminate, but also
  
  uninitialized and the same applies to the duration of the last packet
  
  derived from it.* Worse yet, in case of e.g. an empty file, it is not
  
  only the duration that is uninitialized, but the whole timing as well
  
  as the line buffer itself.** The latter is used in av_strtok(), which
  
  could lead to crashes. Furthermore, the current code always outputs
  
  at least one packet, even for empty files.
  This commit fixes all of this : It stops using two lines at a time ;
  
  instead only the current line is dealt with and in case there is
  
  a packet after that, the duration of the last packet is fixed up
  
  after having already parsed it ; consequently the duration of the
  
  last packet is left in its default state (meaning "unknown/up until
  
  the next subtitle"). If no further line could be read, processing
  
  is stopped ; in particular, no packet is output for an empty file.
  * : Due to stack reuse it seems to be zero quite often ; for the same
  
  reason Valgrind does not report any errors for a normal input file.
  
  ** : While ff_subtitles_read_line() claims to always zero-terminate
  
  the buffer like snprintf(), it doesn't do so if it didn't read anything.
  
  And even if it did, it would not necessarily help here : The current
  
  code jumps over 12 bytes that it deems to have read even when it
  
  hasn't.
  Reviewed-by : Paul B Mahol <onemda@gmail.com>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavformat/sccdec.c

• avcodec/libx264 : Simplify copying packet data

  7 novembre 2021, par Andreas Rheinhardt

  avcodec/libx264 : Simplify copying packet data
  x264.h : "the payloads of all output NALs are guaranteed to be
  
  sequential in memory." Therefore we can omit the loop.
  Reviewed-by : James Almer <jamrial@gmail.com>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavcodec/libx264.c