Recherche avancée

Sur d’autres sites (5105)

• Revision 3c092e2474 : Merge changes Ibb308526,I99e330f8 * changes : Prevent CR in screen mode from r

  11 septembre 2015, par Alex Converse

  Merge changes Ibb308526,I99e330f8

  * changes :
  Prevent CR in screen mode from refreshing flat inter blocks forever.
  For screen content consider intra uv when color_sensitivity is set.

• Fallback input for ffmpeg

  22 septembre 2018, par Daniel Cantarin

  I’m doing some transcoding from a third-party remote input stream that I do not control.

  This input stream has errors from time to time, that I would like to mitigate before sending the stream to my transcoding pipeline, avoiding this way some possible problems in the output.

  I have several ideas regarding different problems. But the most basic scenario I would like to set up is as follows : when the stream is down, or it somehow loses some frames, I want to fill that video gap with a secondary input (like a blank screen, for example).

  For this simple task, I would like to use ffmpeg. I know it can mix, let’s say, an input stream with a fullscreen black square static image. However, I have to deal with this other condition : ffmpeg would run in the same infraestructure for the actual transcoding pipeline. That infraestructure must use its computing power for rendering the output. So, whatever ffmpeg command I end up using should use the minimum possible computing power.

  My actual problem : if I use -vcodec copy, in order to use minimum CPU, I can’t alter the original stream. But if I alter the original stream (by mixing it with some other stream), the operation uses CPU.

  My question : Is there a way to use -vcodec copy, but with a fallback input (instead of a mixed one) for when there are video gaps in the primary stream ?

  Thanks in advance.

• lavu/tx : implement 32 bit fixed point FFT and MDCT

  9 février 2020, par Lynne

  lavu/tx : implement 32 bit fixed point FFT and MDCT
  Required minimal changes to the code so made sense to implement.
  
  FFT and MDCT tested, the output of both was properly rounded.
  
  Fun fact : the non-power-of-two fixed-point FFT and MDCT are the fastest ever
  
  non-power-of-two fixed-point FFT and MDCT written.
  
  This can replace the power of two integer MDCTs in aac and ac3 if the
  
  MIPS optimizations are ported across.
  
  Unfortunately the ac3 encoder uses a 16-bit fixed point forward transform,
  
  unlike the encoder which uses a 32bit inverse transform, so some modifications
  
  might be required there.
  The 3-point FFT is somewhat less accurate than it otherwise could be,
  
  having minor rounding errors with bigger transforms. However, this
  
  could be improved later, and the way its currently written is the way one
  
  would write assembly for it.
  
  Similar rounding errors can also be found throughout the power of two FFTs
  
  as well, though those are more difficult to correct.
  
  Despite this, the integer transforms are more than accurate enough.
  

  • [DH] doc/APIchanges
  • [DH] libavutil/Makefile
  • [DH] libavutil/tx.c
  • [DH] libavutil/tx.h
  • [DH] libavutil/tx_int32.c
  • [DH] libavutil/tx_priv.h
  • [DH] libavutil/tx_template.c
  • [DH] libavutil/version.h