Recherche avancée

Sur d’autres sites (5836)

• Insert still frames into H.264 video stream

  7 juillet 2021, par Bassinator

  I'm building an application that receives video packets which are encoded as H.264 from Microsoft Teams - I get one packet for each frame of video. Specifications of the packet contents are given here. For every packet I receive, I write the byte contents of the data[] buffer to a file. This resulting file is a playable H.264 encoded video.

  


  I'm trying to handle the scenario of syncing the audio and video streams from a Teams meeting, and inserting a still frame PNG as a "filler" when nobody has their camera on.

  


  I used the following FFMPEG command to generate n number of seconds of H.264 video from the filler frame :

  


  ffmpeg -loop 1 -i video_filler_frame.png -framerate 30 -c:v libx264 -t 2 -vf scale=1920:1080 C:\Code\temp\out.mp4


  


  This generates an MP4 file (H.264 encoded) - as a test in my code, I tried to read the contents of that generated file as a byte array and append them to the video file.

  


  However, this doesn't appear to work. I'm guessing this is because there is some kind of header or other metadata that prevents us from doing the simple solution of just appending the bytes of the next frame.

  


  My question is, how can I achieve what I am trying to do ? I'd like to splice in n number of frames as I am writing the individual packet contents to the file. In other words, for example, consider the following sequence :

  


  

  • Write packets of video to the file

  


  • My code determines that filler frames are needed at some point in this process

    

    • Insert needed number of filler frames to the file

    


    


  


  • Continue writing packets of video as they come in

  


  


• avcodec/mobiclip : Rewrite code to make it clearer

  18 novembre 2021, par Andreas Rheinhardt

  avcodec/mobiclip : Rewrite code to make it clearer
  In order to know that the earlier code did not use uninitialized
  
  values one needs to know that the lowest four bits of each used
  
  value of pframe_block4x4_coefficients_tab do not vanish identically.
  
  E.g. Coverity did not get this and warned about it in ticket #1466632.
  
  Fix this by slightly rewriting the code.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavcodec/mobiclip.c

• Revision 704028d435 : Experimental rate control change. When the codec in VBR (or cq) mode hits its m

  7 octobre 2013, par Paul Wilkins

  Changed Paths :
   Modify /vp9/encoder/vp9_onyx_if.c

  
  
  Experimental rate control change.

  When the codec in VBR (or cq) mode hits its max q limits and is
  struggling to hit a target bandwidth, the bit target per frame collapses.

  In the first instance normal frames cap out at the maximum allowed
  Q and then the ARF and GFs do the same. This latter behavior is not
  generally desirable as GFs and ARFs are only effective from a quality
  and data rate perspective if they have at lease some level of -Q delta
  compared to the surrounding frames.

  In this patch I define a separate max Q for GFs and ARFs that is
  derived from but somewhat lower than that defined for normal frames.
  In effect there is a minimum Q delta that will always be available for
  GFs and ARFs regardless of the target rate and MAXQ setting.

  This may of course mean that the absolute lowest rate obtainable for
  a given clip is somewhat higher.

  Change-Id : I268868b28401900d0cd87e51e609cd3b784ab54a