Recherche avancée

Sur d’autres sites (8920)

• lavu/tx : implement 32 bit fixed point FFT and MDCT

  9 février 2020, par Lynne

  lavu/tx : implement 32 bit fixed point FFT and MDCT
  Required minimal changes to the code so made sense to implement.
  
  FFT and MDCT tested, the output of both was properly rounded.
  
  Fun fact : the non-power-of-two fixed-point FFT and MDCT are the fastest ever
  
  non-power-of-two fixed-point FFT and MDCT written.
  
  This can replace the power of two integer MDCTs in aac and ac3 if the
  
  MIPS optimizations are ported across.
  
  Unfortunately the ac3 encoder uses a 16-bit fixed point forward transform,
  
  unlike the encoder which uses a 32bit inverse transform, so some modifications
  
  might be required there.
  The 3-point FFT is somewhat less accurate than it otherwise could be,
  
  having minor rounding errors with bigger transforms. However, this
  
  could be improved later, and the way its currently written is the way one
  
  would write assembly for it.
  
  Similar rounding errors can also be found throughout the power of two FFTs
  
  as well, though those are more difficult to correct.
  
  Despite this, the integer transforms are more than accurate enough.
  

  • [DH] doc/APIchanges
  • [DH] libavutil/Makefile
  • [DH] libavutil/tx.c
  • [DH] libavutil/tx.h
  • [DH] libavutil/tx_int32.c
  • [DH] libavutil/tx_priv.h
  • [DH] libavutil/tx_template.c
  • [DH] libavutil/version.h

• ffmpeg implicitly shifts video and audio

  2 mars 2020, par ynn

  I separated a .mkv file with audio and video into two files by the following command.

  ffmpeg -i input.mkv -vn -codec copy out.wav #extract audio
  
  ffmpeg -i input.mkv -an -codec copy out.mkv #extract video

  And I just merge them into one .mkv file :

  ffmpeg -i out.mkv -i out.wav -codec copy final.mkv #this behaves quite strangely

  I thought the initial input input.mkv and the final output final.mkv should be exactly the same, but, in final.mkv, the video and the audio was shifted by about five seconds. Using ffprobe, I found the cause was the video part (out.mkv) was trimmed off by the length (i.e. five seconds) for no reason.

  What’s happening here ? How can I avoid this strange shift ?

  ---

  Detailed Explanation :

  Hereafter I use this sample input called input.mkv. First, extract video and audio from it.

  $ ffmpeg -i input.mkv -vn -codec copy out.wav
  
  $ ffmpeg -i input.mkv -an -codec copy out.mkv

  Next, check the duration of them.

  $ ffprobe -i out.wav 2>&1 | grep Duration
  
    Duration: 00:00:18.88, bitrate: 1536 kb/s
  
  $ ffprobe -i out.mkv 2>&1 | grep Duration
  
    Duration: 00:00:18.87, start: 0.000000, bitrate: 1877 kb/s

  Then combine them.

  $ ffmpeg -i out.mkv -i out.wav -codec copy final.mkv

  Finally, check the duration of streams.

  $ ffprobe -i final.mkv 
  
  Input #0, matroska,webm, from 'final.mkv':
  
    Metadata:
  
      ENCODER         : Lavf58.29.100
  
    Duration: 00:00:18.88, start: 0.000000, bitrate: 3414 kb/s
  
      Stream #0:0: Video: h264 (High), yuv420p(tv, bt709, progressive), 900x586 [SAR 1:1 DAR 450:293], 30.30 fps, 30.30 tbr, 1k tbn, 60 tbc (default)
  
      Metadata:
  
        DURATION        : 00:00:18.866000000
  
      Stream #0:1: Audio: pcm_s16le, 48000 Hz, 2 channels, s16, 1536 kb/s
  
      Metadata:
  
        DURATION        : 00:00:18.880000000

  Strangely, duration of the video stream has been trimmed off from 18.8700 to 18.8660, though the length of the audio stream is not touched at all.

  It seems the longer the video is, the bigger part is trimmed. (In my case of a one hour video, no less than five seconds were trimmed off.)

  ---

  Version Information :

  ~ $ ffmpeg -version
  
  ffmpeg version n4.2.2 Copyright (c) 2000-2019 the FFmpeg developers
  
  built with gcc 9.2.1 (Arch Linux 9.2.1+20200130-2) 20200130
  
  configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-fontconfig --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libdav1d --enable-libdrm --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libiec61883 --enable-libjack --enable-libmfx --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-nvdec --enable-nvenc --enable-omx --enable-shared --enable-version3
  
  libavutil      56. 31.100 / 56. 31.100
  
  libavcodec     58. 54.100 / 58. 54.100
  
  libavformat    58. 29.100 / 58. 29.100
  
  libavdevice    58.  8.100 / 58.  8.100
  
  libavfilter     7. 57.100 /  7. 57.100
  
  libswscale      5.  5.100 /  5.  5.100
  
  libswresample   3.  5.100 /  3.  5.100
  
  libpostproc    55.  5.100 / 55.  5.100

• Extracting thumbnails from a video for creating sprite is really slow on large videos

  22 avril 2020, par Expressingx

  I have to create 'preview' on video progress hover. I'm doing with a sprite image and WebVTT file. Using ffmpeg and imagemagick. However generating thumbnails from a mp4 video is really damn slow (20-30 minutes for 2hrs and 20 min long video). The video is Full HD, H246 encoded, 2GB big. The command used

  



  "ffmpeg.exe -i largevideo.mp4 -f image2 -bt 20M -vf fps=1/5 thumbs-%03d.jpg"


  



  Which means thumb for every 5 secs of the video. Is there a way to make it faster ? Videos in prod can be even bigger.

  



  OS : Win10, ImageMagick is used later to create the sprite from all the thumbnails created with ffmpeg.