Recherche avancée

Sur d’autres sites (10046)

• FFmpeg generated video length doesn't match expected length [on hold]

  21 juin 2018, par BentCoder

  I am using command below to generate video out of images. The problem is the length out the video generated. It is always 5 seconds less than expected. If I have 4 images, I expect to see 20 seconds of video but I am getting 15 seconds instead. The very last image img-03.jpg just appears at the end of the video as if it is a cover image. Any idea why and solution ?

  Command

  ffmpeg -y -framerate 1/5 -f image2 \
  
  -i img-%2d.jpg \
  
  -c:v libvpx-vp9 \
  
  -r 25 \
  
  -crf 30 -b:v 0 \
  
  video.webm

  Images

  img-00.jpg
  
  img-01.jpg
  
  img-02.jpg
  
  img-03.jpg

  Output

  ffmpeg version 3.2.10-1~deb9u1~bpo8+1 Copyright (c) 2000-2018 the FFmpeg developers
  
    built with gcc 4.9.2 (Debian 4.9.2-10)
  
    configuration: --prefix=/usr --extra-version='1~deb9u1~bpo8+1' --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --enable-gpl --disable-stripping --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --disable-libebur128 --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-omx --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libopencv --enable-libx264 --enable-shared
  
    libavutil      55. 34.101 / 55. 34.101
  
    libavcodec     57. 64.101 / 57. 64.101
  
    libavformat    57. 56.101 / 57. 56.101
  
    libavdevice    57.  1.100 / 57.  1.100
  
    libavfilter     6. 65.100 /  6. 65.100
  
    libavresample   3.  1.  0 /  3.  1.  0
  
    libswscale      4.  2.100 /  4.  2.100
  
    libswresample   2.  3.100 /  2.  3.100
  
    libpostproc    54.  1.100 / 54.  1.100
  
  Input #0, image2, from 'img-%2d.jpg':
  
    Duration: 00:00:20.00, start: 0.000000, bitrate: N/A
  
      Stream #0:0: Video: mjpeg, yuvj444p(pc, bt470bg/unknown/unknown), 854x480 [SAR 1:1 DAR 427:240], 0.20 fps, 0.20 tbr, 0.20 tbn, 0.20 tbc
  
  [swscaler @ 0x55f2af60e800] deprecated pixel format used, make sure you did set range correctly
  
  [libvpx-vp9 @ 0x55f2af6276a0] v1.3.0
  
  Output #0, webm, to 'video.webm':
  
    Metadata:
  
      encoder         : Lavf57.56.101
  
      Stream #0:0: Video: vp9 (libvpx-vp9), yuv420p, 854x480 [SAR 1:1 DAR 427:240], q=-1--1, 25 fps, 1k tbn, 25 tbc
  
      Metadata:
  
        encoder         : Lavc57.64.101 libvpx-vp9
  
      Side data:
  
        cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1
  
  Stream mapping:
  
    Stream #0:0 -> #0:0 (mjpeg (native) -> vp9 (libvpx-vp9))
  
  Press [q] to stop, [?] for help
  
  Input stream #0:0 frame changed from size:854x480 fmt:yuvj444p to size:854x480 fmt:yuvj420p
  
  [swscaler @ 0x55f2af602b60] deprecated pixel format used, make sure you did set range correctly
  
  frame=    4 fps=0.0 q=0.0 Lsize=     214kB time=00:00:15.00 bitrate= 117.0kbits/s speed=  16x    
  
  video:214kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.234810%

• Anomalie #3351 (Fermé) : Le header ’link’ est affiché dans la page généré au lieu d’être envoyé pa...

  23 novembre 2014, par marcimat ☺☮☯♫

  Bon, en fait c’était déjà résolu par spip:r21816
  Bizarrement tout n’était pas à jour dans mon test.
  Super.
  Merci :)

• armv6 : Accelerate ff_fft_calc for general case (nbits != 4)

  16 juillet 2014, par Ben Avison

  armv6 : Accelerate ff_fft_calc for general case (nbits != 4)
  The previous implementation targeted DTS Coherent Acoustics, which only
  
  requires nbits == 4 (fft16()). This case was (and still is) linked directly
  
  rather than being indirected through ff_fft_calc_vfp(), but now the full
  
  range from radix-4 up to radix-65536 is available. This benefits other codecs
  
  such as AAC and AC3.
  The implementaion is based upon the C version, with each routine larger than
  
  radix-16 calling a hierarchy of smaller FFT functions, then performing a
  
  post-processing pass. This pass benefits a lot from loop unrolling to
  
  counter the long pipelines in the VFP. A relaxed calling standard also
  
  reduces the overhead of the call hierarchy, and avoiding the excessive
  
  inlining performed by GCC probably helps with I-cache utilisation too.
  I benchmarked the result by measuring the number of gperftools samples that
  
  hit anywhere in the AAC decoder (starting from aac_decode_frame()) or
  
  specifically in the FFT routines (fft4() to fft512() and pass()) for the
  
  same sample AAC stream :
                Before          After
  
                Mean   StdDev   Mean   StdDev  Confidence  Change
  
  Audio decode  2245.5 53.1     1599.6 43.8    100.0%      +40.4%
  
  FFT routines  940.6  22.0     348.1  20.8    100.0%      +170.2%
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DBH] libavcodec/arm/fft_init_arm.c
  • [DBH] libavcodec/arm/fft_vfp.S