Recherche avancée

Sur d’autres sites (15960)

• Audio Frame Repetition when combining audio clips in moviepy

  11 septembre 2020, par Omer JR

  Audio frames at very end of a clip get repeated when I concatenate two or more video clips.

  


  I tinkered with

  


  

  1. buffer size (writing with audio_buffsize = 1000 works fine for now)

  


  2. duration ( because I observed that for a clip with 43.15 sec of audio, final video get rounded to 44.0 which adds some glitch / last frame buffer repetition (I guess) = 44.0-43.15.)

  


  


  


  com_vid.write_videofile(FINAL_OUT_VID,
fps=1,
codec="libx264",
audio_bitrate='192k',
audio_fps=44100,
audio_nbytes=2,
audio_codec="aac",
audio_bufsize=1000) # fix issue for audio glitches.

  


  


  writing with audio_buffsize = 1000 works fine for now. But I am not sure whether it will work for every case. I need to write one long clips with many small clips hence need some advice/pointers on how to get cohesive result/clip.

  


  Waveform : this is the case when above code breaks and glitches appear again.

  


  

  


• FFMPEG::got_picture_ptr from avcodec_decode_video2 is updating to 0 for I-Frames of nterlaced video stream

  2 septembre 2016, par mkreddy

  I am new to ffmpeg. I am using ffmpeg in my application which is used to assess the quality. While decoding interlaced video stream the got_picture_ptr in avcodec_decode_video2 for IFrames was set to 0. Where as for progressive video streams everything works perfect.

  While searching for solution I have found that the root cause might be

  1) The current frame is a future P-Frame, hence this cannot be returned (displayed) now. This happens in case of B-frames in the sequence.

  2) The current packet is not a complete decodable frame.

  I have observed that for all the IFrames(Interlaced stream) the execution of decode_postinit in h264.c was returning from below condition.

  if (cur->field_poc[0] == INT_MAX || cur->field_poc[1] == INT_MAX) {<br />
       /* FIXME: if we have two PAFF fields in one packet, we can't start
        * the next thread here. If we have one field per packet, we can.
        * The check in decode_nal_units() is not good enough to find this
        * yet, so we assume the worst for now. */
       // if (setup_finished)
       //    ff_thread_finish_setup(h->avctx);
       return;
   }

  I am not able to understand what might be the problem.

  Will there be any other chance that will update got_picture_ptr to 0 ?(Except the above mentioned)
  How can I know about the frame decodability ? (Which was mentioned in 2nd point)

  Note : I am using GOP structure in my application.

• Revision 8f9d94ec17 : SSSE3 Optimization for Atom processors using new instruction selection and order

  5 décembre 2014, par levytamar82

  Changed Paths :
   Modify /vp9/common/x86/vp9_subpixel_8t_ssse3.asm

  
  
  SSSE3 Optimization for Atom processors using new instruction selection and
  ordering

  The function vp9_filter_block1d16_h8_ssse3 uses the PSHUFB instruction which has
  a 3 cycle latency and slows execution when done in blocks of 5 or more on Atom
  processors.
  By replacing the PSHUFB instructions with other more efficient single cycle
  instructions (PUNPCKLBW + PUNPCHBW + PALIGNR) performance can be improved.
  In the original code, the PSHUBF uses every byte and is consecutively copied.
  This is done more efficiently by PUNPCKLBW and PUNPCHBW, using PALIGNR to
  concatenate the intermediate result and then shift right the next consecutive 16
  bytes for the final result.

  For example :
  filter = 0,1,1,2,2,3,3,4,4,5,5,6,6,7,7,8
  Reg = 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
  REG1 = PUNPCKLBW Reg, Reg = 0,0,1,1,2,2,3,3,4,4,5,5,6,6,7,7
  REG2 = PUNPCHBW Reg, Reg = 8,8,9,9,10,10,11,11,12,12,13,13,14,14,15,15
  PALIGNR REG2, REG1, 1 = 0,1,1,2,2,3,3,4,4,5,5,6,6,7,7,8

  This optimization improved the function performance by 23% and produced a 3%
  user level gain on 1080p content on Atom processors.
  There was no observed performance impact on Core processors (expected).

  Change-Id : I3cec701158993d95ed23ff04516942b5a4a461c0