Recherche avancée

Sur d’autres sites (10640)

• avformat/hlsenc : Use HLS version 2 if rounded durations are enabled

  29 juin 2022, par Lucy

  avformat/hlsenc : Use HLS version 2 if rounded durations are enabled
  This allows for wider compatibility with older devices, such as those
  
  running iOS 3. The only difference between HLS version 2 and version 3 is
  
  that version 3 supports non-integer EXTINF values, and as such, we can
  
  default to version 2 if we're using whole-integer EXTINFs anyways, when
  
  `-hls_flags round_durations` is set.
  As this code seems to otherwise consistently use the lowest compatible
  
  version, this seems to fit in properly with existing behavior.
  Testing confirms with that this patch, HLS output can work all the way back
  
  to iOS 3.
  Reviewed-by : Steven Liu <liuqi05@kuaishou.com>
  
  Signed-off-by : Lucy <lucy@absolucy.moe>
  

  • [DH] doc/muxers.texi
  • [DH] libavformat/hlsenc.c

• Incorrect values for song length (duration) in Mp3tag after ffmpeg FLAC to MP3 conversion

  29 mars 2024, par Clueless

  The problem

  


  As per this post, I use the following command to convert a flac file to mp3 while keeping all metadata :

  


  ffmpeg -i input.flac -ab 320k -map_metadata 0 -id3v2_version 3 output.mp3


  


  When inspecting the converted mp3 file by right-clicking it, going to properties and then details, everything looks in order. The value for "Length" is correct.

  


  

  


  When inspecting the converted mp3 file with Mp3tag, the value for "Length" is different. From my testing, the "Length" value is consistently about 28% of what it is supposed to be.

  


  

  


  Normally, this isn't an issue. Most music players I use, read the correct length value, same as Windows. However, I've recently discovered that Spotify Mobile for some reason ignores the length value that can be seen in the Windows panel and uses the one that can be seen in Mp3tag.

  


  I want to figure out what command I should use so that after the flac file has been converted to mp3, Mp3tag shows the correct length, and there by, Spotify Mobile reads the correct length as well.

  


  What I have tried

  


  1.
After converting the file to Mp3, I've tried reencoding the mp3 file into a... mp3 file using the following command :

  


  ffmpeg -i original.mp3 -c:v copy -c:a mp3 -vn -ar 44100 -ac 2 -b:a 320k copy.mp3


  


  

  


  As can be seen in the image above, this fixes the issue and the length is showing correctly in Mp3tag and in Spotify Mobile.

  


  Issues with this : Reencoding reduces quality and I don't know how to combine the previous flac conversion command and this one into one line.

  


  2.
I tried https://cloudconvert.com/flac-to-mp3 and it worked. The length is displayed correctly in Mp3tag. (What commands did they use on the server ???)

  


  

  


  Issues with this : I don't want to rely on a cloud service for conversion, I have a lot of files to convert and I'd prefer it to be done locally.

  


  Some demo files

  


  Here is a folder with a flac file, a bad mp3 file (wrong length) and a good mp3 file. It looks like if you preview the music in google drive, it also plays the wrong length for the bad mp3 (39s not 2m19s), while vlc, groove player, spotify (desktop not mobile) all play the correct full length (2m19s) for the bad mp3 file.

  


  Folder : here's the link

  


• 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 ?