Recherche avancée

Sur d’autres sites (9720)

• Expand (extend) a video to an specific duration

  8 février 2013, par BorrajaX

  Do VLC or FFmpeg (or AVconv) have any feature to force the duration of a video to a certain number of seconds ?

  Let's say I have a... 5 minutes .mp4 video (without audio). Is there a way to have any of the aforementioned tools "expanding" the video to a longer duration ? The video comes from a Power Point slideshow, but it's too short (running too fast, to say so). The idea would be automatically inserting frames so it reaches an specified duration. It looks like something pretty doable (erm... for a total newbie in video encoding/transcoding as I am) : A 5 minutes video, at 30fps means I have 9000 frames... To make it be 10 times longer, get the first "real" frame, copy it ten times, then get the second "real" frame, copy it ten times... and so on.

  I'm using Ubuntu 12.04, but I can install/compile any required software, if needed. So far, I have VLC, AVConv and FFmpeg (FFmpeg in an specific folder, so it won't conflict with AVConv)

  Thank you in advance.

• lavc/opusdsp : simplify R-V V postfilter

  16 décembre 2023, par Rémi Denis-Courmont

  lavc/opusdsp : simplify R-V V postfilter
  This skips the round-trip to scalar register for the sliding 'x'
  
  coefficients, improving performance by about 5%. The trick here is that
  
  the vector slide-up instruction preserves elements in destination vector
  
  until the slide offset.
  The switch from vfslide1up.vf to vslideup.vi also allows the elimination
  
  of data dependencies on consecutive slides. Since the specifications
  
  recommend sticking to power of two offsets, we could slide as follows :
          vslideup.vi v8, v0, 2
  
          vslideup.vi v4, v0, 1
  
          vslideup.vi v12, v8, 1
  
          vslideup.vi v16, v8, 2
  However in the device under test, this seems to make performance slightly
  
  worse, so this is left for (in)validation with future better hardware.
  

  • [DH] libavcodec/riscv/opusdsp_rvv.S

• Thread count option in FFmpeg for FASTEST conversion to h264 ?

  5 septembre 2013, par Saptarshi Biswas

  I need to maximize speed while converting videos using FFmpeg to h264

  • Any input format of source videos
  • User's machine can have any number of cores
  • Power and memory consumption are non-issues

  Of course, there are a whole bunch of options that can be tweaked but this question is particularly about choosing the best -thread <count></count> option. I am trying to find an ideal thread count as a function of

  • no. of cores
  • input video format
  • h264-friendly values maybe ?
  • anything else missed above ?

  I am aware the default -thread 0 follows one-thread-per-core approach which is supposed to be optimal. But I am not sure if this is time or space-optimized. Also, on certain testcases, I've seen more threads (say 4 threads on my dual core test machine) finishes quicker than the default.

  Any other direction, say configure options w.r.t. threads, worth pursuing ?