Recherche avancée

Sur d’autres sites (8125)

• Performant AV1 encoding, does it exist ?

  29 novembre 2022, par V O

  I'm developing a VoD application as a white label product that runs in a SaaS context using K8s. To enable streaming, I take the input video and re-convert it into HLS segments in multiple version and codecs to reach maximum compatibility.

  


  Yesterday I started implementing AV1 as codec, as it will in near future detach h264 as it's more efficient with the same level of compatibility across all the available browsers.
That was the point where things started to get strange, as I want to have this codec instead of h264 ^^.

  


  If you take a look at the following doc pages from ffmpeg : https://trac.ffmpeg.org/wiki/Encode/AV1

  


  You will notice that there are 3 main encoders available to handle encoding to av1. These are : libaom, SVT-AV1 and rav1e. No matter which one of these I try, the performance is slow, even slower than with HEVC. Recently I came along a news article about Netflix and that they are upgrading their library to AV1. If I take a look at the numbers of media elements Netflix offers, the amount is just huge, and I really don't understand how they did it. From what I know, SVT-AV1 is developed by Netflix in cooperation with Intel, So I assume they somehow rely on hardware encoding using an Intel CPU extension.

  


  Does somebody maybe know more and how they did it ? I really can't imagine that they just do CPU only encoding. A movie would take days to get encoded.

  


  Thanks in advance

  


• avisynth : Fix a "AVISynth" vs. "AviSynth" struct name typo

  29 juillet 2013, par Diego Biurrun

  avisynth : Fix a "AVISynth" vs. "AviSynth" struct name typo
  Also fix some similar typos in comments and documentation.
  

  • [DBH] doc/general.texi
  • [DBH] libavfilter/vf_gradfun.c
  • [DBH] libavformat/avisynth.c

• swscale/output : fix bilinear yuv2rgb chroma interpolation

  17 décembre 2024, par Niklas Haas

  swscale/output : fix bilinear yuv2rgb chroma interpolation
  These functions were divided into two special cases ; one assuming that
  
  uvalpha == 0, and the other assuming that uvalpha == 2048. This worked fine
  
  for simple 2x chroma upscaling but broke for e.g. yuv410p, non-centered chroma,
  
  or other special cases that involved non-aligned chroma filters.
  Fix it by instead dividing this check into two cases, a uvalpha==0 fast path
  
  and a uvalpha>0 general path. Instead of (A+B)/2 the general path now multiplies
  
  in the true uvalpha weight.
  I tried preserving the old fast path for the case of uvalpha == 2048, but this
  
  was significantly slower in practise versus having just one general path.
  
  However, we still need a uvalpha == 0 path for the unscaled case.
  Fixes : ticket #5083
  
  Signed-off-by : Niklas Haas <git@haasn.dev>
  
  Sponsored-by : Sovereign Tech Fund
  

  • [DH] libswscale/output.c