Recherche avancée

Sur d’autres sites (9311)

• lavc/arm : fix lack of precision in ff_ps_stereo_interpolate_neon

  22 juin 2017, par Clément Bœsch

  lavc/arm : fix lack of precision in ff_ps_stereo_interpolate_neon
  The code originally pre-multiply by 2 the steps, causing the running sum
  
  of the h factors to drift away due to the lack of precision. It quickly
  
  causes an inaccuracy > 0.01.
  I tried diverse approaches such as multiply by 2.0 (instead of adding
  
  the value itself) without success.
  I'm unable to bench the impact of this change, feel free to compare.
  This commit fixes the incoming aacpsdsp tests.
  Following is an alternative simplified function (matching the incoming
  
  AArch64 code) that may be used :
  function ff_ps_stereo_interpolate_neon, export=1
  
          vld1.32         q0, [r2]
  
          vld1.32         q1, [r3]
  
          ldr             r12, [sp]
  
          vmov.f32        q8, q0
  
          vmov.f32        q9, q1
  
          vzip.32         q8, q0
  
          vzip.32         q9, q1
  
  1 :
  
          vld1.32         d4, [r0,:64]
  
          vld1.32         d6, [r1,:64]
  
          vadd.f32        q8, q8, q9
  
          vadd.f32        q0, q0, q1
  
          vmov.f32        d5, d4
  
          vmov.f32        d7, d6
  
          vmul.f32        q2, q2, q8
  
          vmla.f32        q2, q3, q0
  
          vst1.32         d4, [r0,:64] !
  
          vst1.32         d5, [r1,:64] !
  
          subs            r12, r12, #1
  
          bgt             1b
  
          bx              lr
  
  endfunc
  

  • [DH] libavcodec/arm/aacpsdsp_neon.S

• Converting AAC stream to DASH MP4 with high fragment length precision

  5 mars 2017, par vdudouyt

  For my HTML5 project I need to create a fragmented MP4 file with a single audio stream (no video), each fragment of which has a duration of exactly 0.1 second.

  Accordingly to ffmpeg docs, you can accomplish that by passing a value in microseconds with ’-frag_duration’ - which I found to be working and playable with HTML5 MediaSource API :

  $ ffmpeg -y -i input.aac -c:a libfdk_aac -b:a 64k -level:v 13 -r 25 -strict experimental -movflags empty_moov+default_base_moof -frag_duration 100000 output.mp4

  As we have a 210 second audio split up by 0.1s fragments, I expect that in output.mp4 we’d have 2100 fragments, hence 2100 moof atoms. But, upon inspecting it I’ve figured out that we only have 1811 moof atoms - which means that some (or maybe even all) fragments are bigger than expected :

  $ python ~/git/mp4viewer/src/showboxes.py output.mp4 |grep moof|wc -l
  
  1811

  Could anybody tell me what’s wrong, and how could I accomplish what I want ?

  Right now my assumption is that during an encoding I have AAC frame length which is not a multiple of 0.1s, hence ffmpeg has no chance to produce the fragments that are strictly equal to 0.1s but I’m not sure. If somebody can confirm that - and let me know a way to explicitly set AAC frame_size in FFMPEG (I couldn’t find anything like that in the docs), or completely disprove this - it would be also highly appreciated.

• how to limit precision of motion vectors in hevc using ffmpeg libx265 ?

  22 juillet 2020, par n-93

  For an experiment on HEVC video coding, I wanted to test how the precision of motion vectors impacts the rate of the compressed file.
By examining the options present in FFmpeg libx65 it seems that they are mostly concerned with changing the algorithms used for motion estimation to limit their complexity. Is there a way to limit the precision used to represent motion vectors ?
Thank you