Recherche avancée

Sur d’autres sites (5883)

• intrax8 : Use local destination buffers

  20 février 2016, par Vittorio Giovara

  intrax8 : Use local destination buffers
  These buffers are just a way to store frame pointers and be able to
  
  modify them without touching the original ones.
  The two dependent decoders (WMV2 and VC1) do not need special care for
  
  these fields : the former does not seem to use the dest buffers, while
  
  the latter reinits them every time to the current frame data buffers.
  So only keep a local copy rather than the one from mpegvideo.
  

  • [DBH] libavcodec/intrax8.c
  • [DBH] libavcodec/intrax8.h

• creating simple DVD structure ?

  24 mars 2016, par Rambo Actionha

  I’m trying to make a DVD builder using C# , and I know that DVD’s have a specific structure which I tried to find and I couldn’t see any thing helpful , however , I found some half-completed posts about this structure , which indicate the following :

  • all DVD videos must be in ’.VOB’ format
  • all DVD Videos must be in a folder named "VIDEO_TS" and DVD audios in a folder named "AUDIO_TS" (specifically)
  • "VIDEO_T" and "AUDIO_TS" must be burned to a DVD disk that follows a special filesystem called [UDF][1]

  My question is If I managed to convert my video to suitable ".VOB" format , then I burn it to a disk after adding it to those folders , would it be playable in any DVD player ? I mean is this enough to have a simple DVD disk , and if it wouldn’t .. what would be the simplest DVD structure I can make ( without menus and chapters and other extra stuff ) ? any links related to DVD would be great

• lavc/aacenc_utils : replace powf(x,y) by expf(logf(x), y)

  8 mars 2016, par Ganesh Ajjanagadde

  lavc/aacenc_utils : replace powf(x,y) by expf(logf(x), y)
  This is 2x faster for y not an integer on Haswell+GCC, and should
  
  generally be faster due to the fact that anyway powf essentially does
  
  this under the hood. Made an inline function in lavu/internal.h for this
  
  purpose.
  Note that there are some accuracy differences, that should generally be
  
  negligible. In particular, FATE still passes on this platform.
  Results in 7% speedup in aac encoding with -march=native, Haswell+GCC.
  
  before :
  
  ffmpeg -i sin.flac -acodec aac -y sin_new.aac  6.05s user 0.06s system 104% cpu 5.821 total
  after :
  
  ffmpeg -i sin.flac -acodec aac -y sin_new.aac  5.67s user 0.03s system 105% cpu 5.416 total
  This is also faster than an alternative approach that pulls in powf, gets rid of
  
  the crufty NaN checks and other special cases, exploits knowledge about the intervals, etc.
  
  This of course does not exclude smarter approaches ; just suggests that
  
  there would need to be significant work on this front of lower utility than
  
  searches for hotspots elsewhere.
  Reviewed-by : Reimar Döffinger <Reimar.Doeffinger@gmx.de>
  
  Reviewed-by : Ronald S. Bultje <rsbultje@gmail.com>
  
  Signed-off-by : Ganesh Ajjanagadde <gajjanag@gmail.com>
  

  • [DH] libavcodec/aacenc_utils.h
  • [DH] libavutil/internal.h