Recherche avancée

Sur d’autres sites (9437)

• lavc/h264dec : Improve "Increasing reorder buffer" message loglevel.

  23 août 2016, par Carl Eugen Hoyos

  lavc/h264dec : Improve "Increasing reorder buffer" message loglevel.
  Do not show the message for the first frame by default, show a
  
  warning if increasing is necessary in the middle of the stream.
  

  • [DH] libavcodec/h264dec.c

• Moviepy Making a CompositeVideoClip of two concatenate_videoclips

  16 avril 2018, par Max Better

  Working with the Moviepy lib and I’ve been beating my head off a wall with this last step for a while.

  GifClips = concatenate_videoclips(TheGIFs, method='compose')
  
  TextClips = concatenate_videoclips(TheTexts, method='compose')

  I’ve written both of these to separate files and they look fine. But I’m having a problem getting them to combine properly.

  I’m trying :

  FinishedClips = CompositeVideoClip([GifClips, TextClips], size=(1920,1080))

  It has the audio from TextClips and shows the GifClips but the text isn’t visible. It did show when written alone without the composite.

  It does work if I combine GifClips with a single TextClip but this doesn’t work when I need text clips to run one after another.

  I could run a CompositeVideoClip with every single TextClip and a part of the GifClips and then concatenate them all together but that doesn’t seem like the neatest way of doing this. My guess is there’s a fairly obvious argument here somewhere but looking through the docs and examples I’m struggling so far.

  Any suggestions on how I could get the TextClips clip to show up properly in a composite would be much appreciated.

• avfilter/af_afade : improve accuracy and speed of gain computation

  25 novembre 2015, par Ganesh Ajjanagadde

  avfilter/af_afade : improve accuracy and speed of gain computation
  Gain computation for various curves was being done in a needlessly
  
  inaccurate fashion. Of course these are all subjective curves, but when
  
  a curve is advertised to the user, it should be matched as closely as
  
  possible within the limitations of libm. In particular, the constants
  
  kept here were pretty inaccurate for double precision.
  Speed improvements are mainly due to the avoidance of pow, the most
  
  notorious of the libm functions in terms of performance. To be fair, it
  
  is the GNU libm that is among the worst, but it is not really GNU libm’s fault
  
  since others simply yield a higher error as measured in ULP.
  "Magic" constants are also accordingly documented, since they take at
  
  least a minute of thought for a casual reader.
  Reviewed-by : Paul B Mahol <onemda@gmail.com>
  
  Signed-off-by : Ganesh Ajjanagadde <gajjanagadde@gmail.com>
  

  • [DH] libavfilter/af_afade.c