Recherche avancée

Sur d’autres sites (12928)

• x86/tx_float : remove vgatherdpd usage

  20 mai 2022, par Lynne

  x86/tx_float : remove vgatherdpd usage
  Its performance loss ranges from either being just as fast as individual loads
  
  (Skylake), a few percent slower (Alderlake), 8% slower (Zen 3), to completely
  
  disasterous (older/other CPUs).
  Sadly, gathers never panned out fast on x86, even with the benefit of time and
  
  implementation experience.
  This also saves a register, as there's no need to fill out an additional
  
  register mask.
  Zen 3 (16384-point transform) :
  
  Before : 1561050 decicycles in           av_tx (fft),  131072 runs,      0 skips
  
  After :  1449621 decicycles in           av_tx (fft),  131072 runs,      0 skips
  Alderlake :
  
  2% slower on big transforms (65536), to 1% (131072), to a few percent for smaller
  
  sizes.
  

  • [DH] libavutil/x86/tx_float.asm
  • [DH] libavutil/x86/tx_float_init.c

• rtmp audio out of sync, http works fine

  21 janvier 2014, par marca

  We have encoded and distributed videos for some years now, using FFMPEG to produce h.264/mp4 files that have been working great for us. We have been using HTML mode and fall-backed to flash for browsers that does not support it natively using flowplayer.

  We use cloudfront to serve our files from a s3 bucket and have been using http progressive streaming.

  Recently we started distribute the files in flashmode over rtmp instead, using a cloudfront streaming distribution pointing to the same amazon s3 bucket.

  All good for some weeks, until yesterday when we notice a couple of files with audio sync issues in rtmp mode.
  The same file have no sync problems in flash with direct url to file.

  What can be the case ?

  Not working when streamed via RTMP, but file work with http streaming/progressive.
  You see the sync issue 15 sec's into the video.
  rtmp ://s2xe2avk54qztf.cloudfront.net:1935/cfx/st/mp4:95fvOY255bdPspO3z6tEvGi3Em7/default.mp4
  http://media.shootitlive.com/95fvOY255bdPspO3z6tEvGi3Em7/default.mp4

  Another file that have no sync issue at all.
  rtmp ://s2xe2avk54qztf.cloudfront.net:1935/cfx/st/mp4:P4EuH2TZxfV6BvpupP6dxrrs7gD/default.mp4
  http://media.shootitlive.com/P4EuH2TZxfV6BvpupP6dxrrs7gD/default.mp4

  Both files have the same format for video and audio and have been encoded the exact same way with ffmpeg. It's not player related as we see the audio sync issue on several players and when playing stream in VLC.

• AWS Lambda execution time for FFMPEG transcoding

  4 janvier 2023, par FlamingMoe

  I'm using AWS Lambda for converting files from WEBM to MP4

  


  I'm using ffmpeg version 4.3.1-static https://johnvansickle.com/ffmpeg/ (I have done the following tests also with the ffmpeg in serverless AWS ffmpeg layer (that includes de 4.1.3), but results are even worse (about 25% slower)

  


  I'm using Node 10x as container.

  


  WEBM size   Time to convert.  Memory Lambda.  Memory used (as shown in log)

80Mb             ~44s              3008            410
40Mb             ~44s              3008            375

80Mb             ~70s              1024            321
40Mb             ~70s              1024            279


  


  All videos are 80s length. So as far as I can see, it does not matter the size of the WEBM, if the length of the video is the same, it takes the same to convert. So ffmpeg takes more time if the video length is higher, not if the file size is higher ... curious ;-)

  


  But in the other hand, I'm confused with Lambda memory. I know memory and CPU comes together in Lambda ... the more memory you choose, the more CPU is assigned.

  


  But...

  


  

  1. Why ffmpeg just take about 300/400Mb if it has more to run ?

  


  2. How can I tell ffmpeg to use more memory ?

  


  3. Is there any option to accelerate the process in Lambda ?

  


  


  Btw, In all tests, all ffmpeg are the same, and

  


  cpu-used paramenter)

  


  

  • I added to ffmpeg parameters cpu-used=100, and it does not matter at all if I put cpu-used=5 ... times are the same, so I guess that parameter is useless (i don't know why)

  


  


  threads parameter)

  


  

  • Also I did some tests with "threads" parameters, but it's useless also.

  


  


  I know it's not a good comparison, but same files takes about 5 seconds to be converted in a simple dedicated server (8 vCores and 8GB RAM in OVH Centos VPS).

  


  Btw, Amazon Elastic Transcoder is not an option :
a) it's extremely more expensive
b) it has just his profiles to convert, and my ffmpeg commands are very complex (watermarks, effects, etc ...)