Recherche avancée

Sur d’autres sites (5694)

• lavc/flacdsp : optimise RVV vector type for lpc16

  14 mai 2024, par Rémi Denis-Courmont

  lavc/flacdsp : optimise RVV vector type for lpc16
  This calculates the optimal vector type value at run-time based on the
  
  hardware vector length and the FLAC LPC prediction order. In this
  
  particular case, the additional computation is easily amortised over
  
  the loop iterations :
  T-Head C908 :
  
      C     V before  V after
  
   1   48.0    214.7     95.2
  
   2   64.7    214.2     94.7
  
   3   79.7    213.5     94.5
  
   4   96.2    196.5     94.2 #
  
   5  111.0    195.7    118.5
  
   6  127.0    211.2    102.0
  
   7  143.7    194.2    101.5
  
   8  175.7    193.2    101.2 #
  
   9  176.2    224.2    126.0
  
  10  191.5    192.0    125.5
  
  11  224.5    191.2    124.7
  
  12  223.0    190.2    124.2
  
  13  239.2    189.5    123.7
  
  14  253.7    188.7    139.5
  
  15  286.2    188.0    122.7
  
  16  284.0    187.0    122.5 #
  
  17  300.2    186.5    186.5
  
  18  314.0    185.5    185.7
  
  19  329.7    184.7    185.0
  
  20  343.0    184.2    184.2
  
  21  358.7    199.2    183.7
  
  22  371.7    182.7    182.7
  
  23  387.5    181.7    182.0
  
  24  400.7    181.0    181.2
  
  25  431.5    180.2    196.5
  
  26  443.7    195.5    196.0
  
  27  459.0    178.7    196.2
  
  28  470.7    177.7    194.2
  
  29  470.0    177.0    193.5
  
  30  481.2    176.2    176.5
  
  31  496.2    175.5    175.7
  
  32  507.2    174.7    191.0 #
   # Power of two boundary.
  With 128-bit vectors, improvements are expected for the first two
  
  test cases only. For the other two, there is overhead but below noise.
  
  Improvements should be better observable with prediction order of 8
  
  and less, or on hardware with larger vector sizes.
  

  • [DH] libavcodec/riscv/flacdsp_init.c
  • [DH] libavcodec/riscv/flacdsp_rvv.S

• FFMPEG - Struggling to find correct input audio codec parameters on macOS

  20 septembre 2024, par Xavi

  I am trying to read my external stereo microphone with ffmpeg within my Qt Windows+macOs application, but I am struggling to obtain consistent correct input codec parameters on macOs. My findings and suspicions so far :

  


  The code I'm using in macOs is the following, where everything returns a successful return code :

  


   avdevice_register_all();
 
 //macOs only, the same code in windows looks for "dshow" 
 const AVInputFormat *inputFormat = av_find_input_format("avfoundation");
 
 AVFormatContext* inputFormatContext;
 avformat_open_input(&inputFormatContext, inputDevice, inputFormat, NULL);

 avformat_find_stream_info(inputFormatContext, NULL);
 
 //... allocate the codec context for the single input stream and
 // copy the parameters from the stream to the context



  


  In my standalone minimal reproducer this always results on the codec ID of the single stream being AV_CODEC_ID_PCM_F32LE, in both macOS and Windows. When I integrate this code in my Qt application on Windows, I get the same result. However, on macOS, most of the times results in the codec id of the stream being AV_CODEC_ID_PCM_S16LE (via AV_CODEC_ID_FIRST_AUDIO) and sometimes AV_CODEC_ID_PCM_F32LE. Both sample formats are supported by my microphone.

  


  AV_CODEC_ID_PCM_F32LE always results in a correct output. AV_CODEC_ID_PCM_S16LE results on buzzy noisy audio slowed down to 0.5x, and If in this case I decode with AV_CODEC_ID_PCM_F32LE instead of copying the codec parameters from the stream, the output sounds correct again.

  


  I am trying to write generic code, so while enforcing the AV_CODEC_ID_PCM_F32LE codec works, I'd rather understand what is happening.

  


  What am I missing ? Is Qt interacting in some way that I can't think of ? I am compiling and linking my own ffmpeg libraries (6.1.1) and not using Qt's ones.

  


• ffmpeg command exports flac with wrong 'length' metadata, works fine for mp3

  21 juillet 2023, par Martin

  I have some audio recorded in Audacity 3.2.3 that I have exported as an mp3 and a flac. Then I have this file split_by_silence.sh

  


  Which has hardcoded input path values that take an input file, split it by detecting silence, and then finally run an ffmpeg command to split the files. If you save the below code into a file split.sh, you can call it with the command $ ./split_by_silence.sh "value1" "value2"

  


  # ./split_by_silence.sh "full_lowq.flac" %03d_output.flac
#IN=$1
#OUT=$2

OUT="%03d_output.flac"
IN="/mnt/e/martinradio/rips/vinyl/WIP/Dogs On Fire (1983, Vinyl)/dog on fire.flac"
OUTPUT_LOCATION="/mnt/e/martinradio/rips/vinyl/WIP/Dogs On Fire (1983, Vinyl)/"

true ${SD_PARAMS:="-18dB"};
true ${MIN_FRAGMENT_DURATION:="20"};
export MIN_FRAGMENT_DURATION
if [ -z "$OUT" ]; then
    echo "Usage: split_by_silence.sh full.mp3 output_template_%03d.mp3"
    echo "Depends on FFmpeg, Bash, Awk, Perl 5. Not tested on Mac or Windows."
    echo ""
    echo "Environment variables (with their current values):"
    echo "    SD_PARAMS=$SD_PARAMS       Parameters for FFmpeg's silencedetect filter: noise tolerance and minimal silence duration"
    echo "    MIN_FRAGMENT_DURATION=$MIN_FRAGMENT_DURATION    Minimal fragment duration"
    exit 1
fi
#
# get comma separated list of split points (use ffmpeg to determine points where audio is at SD_PARAMS [-18db] )
#

echo "_______________________"
echo "Determining split points..." >& 2
SPLITS=$(
    ffmpeg -v warning -i "$IN" -af silencedetect="$SD_PARAMS",ametadata=mode=print:file=-:key=lavfi.silence_start -vn -sn  -f s16le  -y /dev/null \
    | grep lavfi.silence_start= \
    | cut -f 2-2 -d= \
    | perl -ne '
        our $prev;
        INIT { $prev = 0.0; }
        chomp;
        if (($_ - $prev) >= $ENV{MIN_FRAGMENT_DURATION}) {
            print "$_,";
            $prev = $_;
        }
    ' \
    | sed 's!,$!!'
)
echo "SPLITS= $SPLITS"

#
# Add 5 seconds to each of the comma separated numbers
#
# Convert the comma-separated string into an array
arr=($(echo $SPLITS | tr ',' '\n'))
# Initialize a new array to store the results
new_arr=()
# Iterate through each element and add 5 seconds of padding
for i in "${arr[@]}"; do
  result=$(echo "$i + 5" | bc -l)
  new_arr+=("$result")
done
# Convert the array back into a comma-separated string
NEW_SPLITS=$(IFS=,; echo "${new_arr[*]}")
# Print the result
echo "NEW_SPLITS= $NEW_SPLITS"
SPLITS=$NEW_SPLITS

#
# Print how many tracks should be exported
#
res="${SPLITS//[^,]}"
CHARCOUNT="${#res}"
num=$((CHARCOUNT + 2))
echo "Exporting $num tracks"
echo "_______________________"

#
# Split audio into individual tracks
#
current_directory=$(pwd)

cd "$OUTPUT_LOCATION"

echo "Running ffmpeg command: "

ffmpeg -i "$IN" -c copy -map 0 -f segment -segment_times "$SPLITS" "$OUT"
#ffmpeg -i "full_lowq.flac" -c copy -map 0 -f segment -segment_times "302.825,552.017" "%03d_output.flac"


echo "Done."

cd $current_directory

echo "running flac command"
# check flac file intrgrity


  


  If I call this code for my flac file :

  


  OUT="%03d_output.flac"
IN="/mnt/e/martinradio/rips/vinyl/WIP/Dogs On Fire (1983, Vinyl)/dog on fire.flac"


  


  The outputted files have an incorrect metadata for the length. They all report as having the same length, but if i import any of them into audacity, the file has a correct length.

  


  

  


  but if i run this for my mp3 file, we can see the correct length metadata :

  


  OUT="%03d_output.mp3"
IN="/mnt/e/martinradio/rips/vinyl/WIP/Dogs On Fire (1983, Vinyl)/dogs on fire.mp3"


  


  

  


  So there is something with my ffmpeg command that causes it to export flac files with wrong 'length' metadata

  


  ffmpeg -i "$IN" -c copy -map 0 -f segment -segment_times "$SPLITS" "$OUT"



  


  I've tried with the flac example to change -c copy to -c:a flac, but that just gives every output flac file a length of 00:00:00

  


  is it a problem with my ffmpeg command ? Or my files ? https://file.io/tIFsa1l70076
it works for mp3 files just fine, why does it have this issue with flac ?