1. 04 Dec, 2017 3 commits
  2. 23 Nov, 2017 1 commit
  3. 28 Sep, 2017 1 commit
  4. 18 Aug, 2017 1 commit
  5. 16 May, 2017 1 commit
  6. 27 Apr, 2017 3 commits
  7. 26 Apr, 2017 2 commits
  8. 15 Apr, 2017 1 commit
  9. 14 Apr, 2017 1 commit
  10. 24 Feb, 2017 3 commits
  11. 19 Feb, 2017 1 commit
    • Rostislav Pehlivanov's avatar
      opus_pvq: fix PVQ search for K < 5 and low Ns · 67fa02ed
      Rostislav Pehlivanov authored
      If the PVQ search picked a place to increment/decrement on the y[]
      vector which had no pulse then it would cause a desync since it would
      change the sum in the wrong direction. Fix this by not considering
      places without pulses as viable.
      
      This makes the PVQ search slightly worse at K < 5 which isn't all that
      common. Still, this is a workaround to prevent making broken files until
      I can think of a better way of fixing it.
      
      Also add an assertion, which can be removed or moved to assert1/2 once
      the PVQ search is stable.
      Signed-off-by: 's avatarRostislav Pehlivanov <atomnuker@gmail.com>
      67fa02ed
  12. 15 Feb, 2017 1 commit
  13. 14 Feb, 2017 3 commits
    • Rostislav Pehlivanov's avatar
      opus: add a native Opus encoder · 5f47c85e
      Rostislav Pehlivanov authored
      This marks the first time anyone has written an Opus encoder without
      using any libopus code. The aim of the encoder is to prove how far
      the format can go by writing the craziest encoder for it.
      
      Right now the encoder's basic, it only supports CBR encoding, however
      internally every single feature the CELT layer has is implemented
      (except the pitch pre-filter which needs to work well with the rest of
      whatever gets implemented). Psychoacoustic and rate control systems are
      under development.
      
      The encoder takes in frames of 120 samples and depending on the value of
      opus_delay the plan is to use the extra buffered frames as lookahead.
      Right now the encoder will pick the nearest largest legal frame size and
      won't use the lookahead, but that'll change once there's a
      psychoacoustic system.
      
      Even though its a pretty basic encoder its already outperforming
      any other native encoder FFmpeg has by a huge amount.
      
      The PVQ search algorithm is faster and more accurate than libopus's
      algorithm so the encoder's performance is close to that of libopus
      at zero complexity (libopus has more SIMD).
      The algorithm might be ported to libopus or other codecs using PVQ in
      the future.
      
      The encoder still has a few minor bugs, like desyncs at ultra low
      bitrates (below 9kbps with 20ms frames).
      Signed-off-by: 's avatarRostislav Pehlivanov <atomnuker@gmail.com>
      5f47c85e
    • Rostislav Pehlivanov's avatar
      opus_celt: rename structures to better names and reorganize them · 07b78340
      Rostislav Pehlivanov authored
      This is meant to be applied on top of my previous patch which
      split PVQ into celt_pvq.c and made opus_celt.h
      
      Essentially nothing has been changed other than renaming CeltFrame
      to CeltBlock (CeltFrame had absolutely nothing at all to do with
      a frame) and CeltContext to CeltFrame.
      3 variables have been put in CeltFrame as they make more sense
      there rather than being passed around as arguments.
      The coefficients have been moved to the CeltBlock structure
      (why the hell were they in CeltContext and not in CeltFrame??).
      
      Now the encoder would be able to use the exact context the decoder
      uses (plus a couple of extra fields in there).
      
      FATE passes, no slowdowns, etc.
      Signed-off-by: 's avatarRostislav Pehlivanov <atomnuker@gmail.com>
      07b78340
    • Rostislav Pehlivanov's avatar
      opus_celt: move quantization and band decoding to opus_pvq.c · e538108c
      Rostislav Pehlivanov authored
      A huge amount can be reused by the encoder, as the only thing
      which needs to be done would be to add a 10 line celt_icwrsi,
      a wrapper around it (celt_alg_quant) and templating the
      ff_celt_decode_band to replace entropy decoding functions
      with entropy encoding.
      
      There is no performance loss but in fact a performance gain of
      around 6% which is caused by the compiler being able to optimize
      the decoding more efficiently.
      Signed-off-by: 's avatarRostislav Pehlivanov <atomnuker@gmail.com>
      e538108c