Recherche avancée

Sur d’autres sites (8205)

• Revision 39129 : Amélioration du formulaire de changement de pagination . Si le nombre ...

  1er juillet 2010, par kent1@… — Log

  Amélioration du formulaire de changement de pagination . Si le nombre total d’élément est inférieur à la limite maximale, on affiche que jusqu’au nombre total d’éléments On n’affiche le formulaire que s’il y a effectivement pagination On ajoute ce formulaire de pagination à droite à (...)

• Revision 39129 : Amélioration du formulaire de changement de pagination . Si le nombre ...

  1er juillet 2010, par kent1@… — Log

  Amélioration du formulaire de changement de pagination . Si le nombre total d’élément est inférieur à la limite maximale, on affiche que jusqu’au nombre total d’éléments On n’affiche le formulaire que s’il y a effectivement pagination On ajoute ce formulaire de pagination à droite à (...)

• smart encoding of h264 with ffmpeg library fails

  6 avril 2017, par cuttingJoe

  I try to do smart encoding of a cut out of a h264 video with the help of ffmpeg library.
  The target is to make an efficient cut of an existing video being not forced to begin at an I-frame.
  For the first part of the video I decode the frames from the preceeding I-Frame till the upcoming I-Frame.
  When the intended start of the snippet comes, I encode the frames with AVCodecContext data close to the original video stream. From the second I-Frame onwards I simply copy the packets from the source to the destination stream.
  The resulting video throws errors when played with ffplay at the beginning of the second (the copied) part.
  Playing the same video with MPC-HC the second part is played, but not the first one :-)

  The errors thrown by ffplay are

  [h264 @ 0xa8a70480] top block unavailable for requested intra mode  
  
  [h264 @ 0xa8a70480] error while decoding MB 0 0, bytestream 30156
  
  [h264 @ 0xa8a70480] concealing 8160 DC, 8160 AC, 8160 MV errors in I frame
  
  [h264 @ 0xa8a565a0] reference count overflow121KB sq=    0B f=0/0   
  
  [h264 @ 0xa8a565a0] decode_slice_header error
  
  ...

  So I asume that something on bitstream level doesn’t work.
  I started to dig into topic of extradata of h264, SPS and PPS but didn’t get very far.

  I could post the code and the video, if it helps, but I don’t expect to get the thing solved, but rather some hints, how to go on :

  • Should there be a new header written before the second part ?
  • How can I figure out, what leads to the error messages "top block
    unavailable for requested intra mode" ?
  • What is the best tool to analyze the resulting video (on bitstream
    level ?) ?

  Thanks a lot for help !!

  After some long nights, I came to a solution, which might not be perfect, but it works.
  As tools for analyzing the video I used MediaInfo and the tool isoviewer, which crashes sometimes, if the video is broken, but its of great help anyway.
  The idea is following the comand line approch, what you can find in some forums :

  ffmpeg -i "cut1-26.mp4" -c copy -bsf:v h264_mp4toannexb -f mpegts intermediate1.ts
  
  ffmpeg -i "cut1-26.mp4" -c copy -bsf:v h264_mp4toannexb -f mpegts intermediate2.ts
  
  ffmpeg -i "concat:intermediate1.ts|intermediate2.ts" -c copy -bsf:a aac_adtstoasc out-conc.mp4

  In my code the merging of two video streams looks somehow like that :

  for (int i=1; i/loop over several videos
  
  ...
  
  while (!finalPacketWritten)
  
  {
  
      ...
  
      av_read_frame(i_fmt_ctx, &i_pkt)
  
      do {
  
          if (!finalPktRead) {
  
              ret = av_bsf_send_packet(bsfCtx, &i_pkt);
  
              if (ret < 0)
  
                  return -1;
  
          } else {
  
              ret = av_bsf_send_packet(bsfCtx, NULL); //flush BSF
  
              if (ret < 0)
  
                  return -1;
  
          }
  
          while ((ret = av_bsf_receive_packet(bsfCtx, &o_pkt)) == 0) {
  
              av_interleaved_write_frame(o_fmt_ctx, &o_pkt);
  
              numbPacket++;
  
          }
  
          if ((ret !=0) && finalPktRead) {
  
              finalPacketWritten = 1;
  
          }
  
      } while (finalPktRead && !finalPacketWritten);
  
  }

  The conversion with the bitstreamFilter to AnnexB packets, leads to a structure of the VCL NALUs like that (MP4 container) :

  SEI SPS PPS IDR (first reencoded video part)
  
  NON_IDR
  
  NON_IDR
  
  NON_IDR
  
  ....
  
  SEI SPS PPS IDR (second copied video part with different SPS and PPS data)
  
  NON_IDR
  
  NON_IDR
  
  NON_IDR
  
  ....

  SPS and PPS in avcC NALU is there as well.
  This video plays fine on ffplay, Parole, MPC-HC (windows). On VLC there are artefacts.
  So it looks like most players recognise the new SPS and PPS, when the second part starts and pass the information to the decoder.

  Of course there are other options like

  • reencoding the first part of the video with encoding settings extremely close to the original video and using just one set of SPS and PPS - might this be achievable ?
  • adding a second SPS and PPS information in the header part of the video and the VCL NALUs referencing the matching one.
  • any other idea ?

  Please share your suggestions on it.
  Thanks.