Recherche avancée

Sur d’autres sites (10958)

• Why is ffmpeg faster than this minimal example ?

  23 juillet 2022, par Dave Ceddia

  I'm wanting to read the audio out of a video file as fast as possible, using the libav libraries. It's all working fine, but it seems like it could be faster.

  


  To get a performance baseline, I ran this ffmpeg command and timed it :

  


  time ffmpeg -threads 1 -i file -map 0:a:0 -f null -


  


  On a test file (a 2.5gb 2hr .MOV with pcm_s16be audio) this comes out to about 1.35 seconds on my M1 Macbook Pro.

  


  On the other hand, this minimal C code (based on FFmpeg's "Demuxing and decoding" example) is consistently around 0.3 seconds slower.

  


  #include <libavcodec></libavcodec>avcodec.h>&#xA;#include <libavformat></libavformat>avformat.h>&#xA;&#xA;static int decode_packet(AVCodecContext *dec, const AVPacket *pkt, AVFrame *frame)&#xA;{&#xA;    int ret = 0;&#xA;&#xA;    // submit the packet to the decoder&#xA;    ret = avcodec_send_packet(dec, pkt);&#xA;&#xA;    // get all the available frames from the decoder&#xA;    while (ret >= 0) {&#xA;        ret = avcodec_receive_frame(dec, frame);&#xA;        av_frame_unref(frame);&#xA;    }&#xA;&#xA;    return 0;&#xA;}&#xA;&#xA;int main (int argc, char **argv)&#xA;{&#xA;    int ret = 0;&#xA;    AVFormatContext *fmt_ctx = NULL;&#xA;    AVCodecContext  *dec_ctx = NULL;&#xA;    AVFrame *frame = NULL;&#xA;    AVPacket *pkt = NULL;&#xA;&#xA;    if (argc != 3) {&#xA;        exit(1);&#xA;    }&#xA;&#xA;    int stream_idx = atoi(argv[2]);&#xA;&#xA;    /* open input file, and allocate format context */&#xA;    avformat_open_input(&amp;fmt_ctx, argv[1], NULL, NULL);&#xA;&#xA;    /* get the stream */&#xA;    AVStream *st = fmt_ctx->streams[stream_idx];&#xA;&#xA;    /* find a decoder for the stream */&#xA;    AVCodec *dec = avcodec_find_decoder(st->codecpar->codec_id);&#xA;&#xA;    /* allocate a codec context for the decoder */&#xA;    dec_ctx = avcodec_alloc_context3(dec);&#xA;&#xA;    /* copy codec parameters from input stream to output codec context */&#xA;    avcodec_parameters_to_context(dec_ctx, st->codecpar);&#xA;&#xA;    /* init the decoder */&#xA;    avcodec_open2(dec_ctx, dec, NULL);&#xA;&#xA;    /* allocate frame and packet structs */&#xA;    frame = av_frame_alloc();&#xA;    pkt = av_packet_alloc();&#xA;&#xA;    /* read frames from the specified stream */&#xA;    while (av_read_frame(fmt_ctx, pkt) >= 0) {&#xA;        if (pkt->stream_index == stream_idx)&#xA;            ret = decode_packet(dec_ctx, pkt, frame);&#xA;&#xA;        av_packet_unref(pkt);&#xA;        if (ret &lt; 0)&#xA;            break;&#xA;    }&#xA;&#xA;    /* flush the decoders */&#xA;    decode_packet(dec_ctx, NULL, frame);&#xA;&#xA;    return ret &lt; 0;&#xA;}&#xA;

  


  I tried measuring parts of this program to see if it was spending a lot of time in the setup, but it's not – at least 1.5 seconds of the runtime is the loop where it's reading frames.

  


  So I took some flamegraph recordings (using cargo-flamegraph) and ran each a few times to make sure the timing was consistent. There's probably some overhead since both were consistently higher than running normally, but they still have the 0.3 second delta.

  


  # 1.812 total
time sudo flamegraph ./minimal file 1

# 1.542 total
time sudo flamegraph ffmpeg -threads 1 -i file -map 0:a:0 -f null - 2>&1


  


  Here are the flamegraphs stacked up, scaled so that the faster one is only 85% as wide as the slower one. (click for larger)

  


  

  


  The interesting thing that stands out to me is how long is spent on read in the minimal example vs. ffmpeg :

  


  

  


  The time spent on lseek is also a lot longer in the minimal program – it's plainly visible in that flamegraph, but in the ffmpeg flamegraph, lseek is a single pixel wide.

  


  What's causing this discrepancy ? Is ffmpeg actually doing less work than I think it is here ? Is the minimal code doing something naive ? Is there some buffering or other I/O optimizations that ffmpeg has enabled ?

  


  How can I shave 0.3 seconds off of the minimal example's runtime ?

  


• avcodec/dpx : fix check of minimal data size for unpadded content

  19 octobre 2022, par Jerome Martinez

  avcodec/dpx : fix check of minimal data size for unpadded content
  stride value is not relevant with unpadded content and the total count
  
  of pixels (width x height) must be used instead of the rounding based on
  
  width only then multiplied by height
  unpadded_10bit value computing is moved sooner in the code in order to
  
  be able to use it during computing of minimal content size. Also make sure to
  
  only set it for 10bit.
  Fix 'Overread buffer' error when the content is not lucky enough to have
  
  (enough) padding bytes at the end for not being rejected by the formula
  
  based on the stride value
  Fixes ticket #10259.
  Signed-off-by : Jerome Martinez <jerome@mediaarea.net>
  
  Signed-off-by : Marton Balint <cus@passwd.hu>
  

  • [DH] libavcodec/dpx.c

• Why does libmp3lame add zeros to the start of the MP3 ?

  29 mars 2016, par Phlox Midas

  I have a uncompressed .wav file that I turn into a 96k MP3 file :

  ffmpeg.exe -i song.wav -vn -b:a 96000 -ac 2 -ar 48000 -acodec libmp3lame -y song.mp3

  The input file has 637386 samples. The output has 639360 samples. The extra samples in the MP3 are all zeros at the beginning of the file. This happens in every file I’ve translated and with more codecs than just libmp3lame. Is this an FFMPEG bug or a codec bug ? Why are these added ? Is there a way to stop them from being added ?

  Edit : Simplified example and console output :

  ffmpeg.exe -i song.wav -y song.mp3
  
  
  
  ffmpeg version N-55796-gb74213d Copyright (c) 2000-2013 the FFmpeg developers
  
    built on Aug 26 2013 19:43:51 with gcc 4.7.3 (GCC)
  
    configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libcaca --enable-libfreetype --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib
  
    libavutil      52. 42.100 / 52. 42.100
  
    libavcodec     55. 29.100 / 55. 29.100
  
    libavformat    55. 14.102 / 55. 14.102
  
    libavdevice    55.  3.100 / 55.  3.100
  
    libavfilter     3. 82.102 /  3. 82.102
  
    libswscale      2.  5.100 /  2.  5.100
  
    libswresample   0. 17.103 /  0. 17.103
  
    libpostproc    52.  3.100 / 52.  3.100
  
  Guessed Channel Layout for  Input Stream #0.0 : stereo
  
  Input #0, wav, from 'song.wav':
  
    Duration: 00:00:13.28, bitrate: 1538 kb/s
  
      Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, stereo, s16, 1536 kb/s
  
  Output #0, mp3, to 'song.mp3':
  
    Metadata:
  
      TSSE            : Lavf55.14.102
  
      Stream #0:0: Audio: mp3 (libmp3lame), 48000 Hz, stereo, s16p
  
  Stream mapping:
  
    Stream #0:0 -> #0:0 (pcm_s16le -> libmp3lame)
  
  Press [q] to stop, [?] for help
  
  size=     208kB time=00:00:13.29 bitrate= 128.4kbits/s
  
  video:0kB audio:208kB subtitle:0 global headers:0kB muxing overhead 0.111205%

  Number of samples in wav : 637386

  Number of samples in mp3 : 639984