Recherche avancée

Sur d’autres sites (9670)

• aarch64 : vp9 : Implement NEON loop filters

  13 novembre 2016, par Martin Storsjö

  aarch64 : vp9 : Implement NEON loop filters
  This work is sponsored by, and copyright, Google.
  These are ported from the ARM version ; thanks to the larger
  
  amount of registers available, we can do the loop filters with
  
  16 pixels at a time. The implementation is fully templated, with
  
  a single macro which can generate versions for both 8 and
  
  16 pixels wide, for both 4, 8 and 16 pixels loop filters
  
  (and the 4/8 mixed versions as well).
  For the 8 pixel wide versions, it is pretty close in speed (the
  
  v_4_8 and v_8_8 filters are the best examples of this ; the h_4_8
  
  and h_8_8 filters seem to get some gain in the load/transpose/store
  
  part). For the 16 pixels wide ones, we get a speedup of around
  
  1.2-1.4x compared to the 32 bit version.
  Examples of runtimes vs the 32 bit version, on a Cortex A53 :
  
                                         ARM AArch64
  
  vp9_loop_filter_h_4_8_neon :          144.0   127.2
  
  vp9_loop_filter_h_8_8_neon :          207.0   182.5
  
  vp9_loop_filter_h_16_8_neon :         415.0   328.7
  
  vp9_loop_filter_h_16_16_neon :        672.0   558.6
  
  vp9_loop_filter_mix2_h_44_16_neon :   302.0   203.5
  
  vp9_loop_filter_mix2_h_48_16_neon :   365.0   305.2
  
  vp9_loop_filter_mix2_h_84_16_neon :   365.0   305.2
  
  vp9_loop_filter_mix2_h_88_16_neon :   376.0   305.2
  
  vp9_loop_filter_mix2_v_44_16_neon :   193.2   128.2
  
  vp9_loop_filter_mix2_v_48_16_neon :   246.7   218.4
  
  vp9_loop_filter_mix2_v_84_16_neon :   248.0   218.5
  
  vp9_loop_filter_mix2_v_88_16_neon :   302.0   218.2
  
  vp9_loop_filter_v_4_8_neon :           89.0    88.7
  
  vp9_loop_filter_v_8_8_neon :          141.0   137.7
  
  vp9_loop_filter_v_16_8_neon :         295.0   272.7
  
  vp9_loop_filter_v_16_16_neon :        546.0   453.7
  The speedup vs C code in checkasm tests is around 2-7x, which is
  
  pretty much the same as for the 32 bit version. Even if these functions
  
  are faster than their 32 bit equivalent, the C version that we compare
  
  to also became around 1.3-1.7x faster than the C version in 32 bit.
  Based on START_TIMER/STOP_TIMER wrapping around a few individual
  
  functions, the speedup vs C code is around 4-5x.
  Examples of runtimes vs C on a Cortex A57 (for a slightly older version
  
  of the patch) :
  
                           A57 gcc-5.3  neon
  
  loop_filter_h_4_8_neon :        256.6  93.4
  
  loop_filter_h_8_8_neon :        307.3 139.1
  
  loop_filter_h_16_8_neon :       340.1 254.1
  
  loop_filter_h_16_16_neon :      827.0 407.9
  
  loop_filter_mix2_h_44_16_neon : 524.5 155.4
  
  loop_filter_mix2_h_48_16_neon : 644.5 173.3
  
  loop_filter_mix2_h_84_16_neon : 630.5 222.0
  
  loop_filter_mix2_h_88_16_neon : 697.3 222.0
  
  loop_filter_mix2_v_44_16_neon : 598.5 100.6
  
  loop_filter_mix2_v_48_16_neon : 651.5 127.0
  
  loop_filter_mix2_v_84_16_neon : 591.5 167.1
  
  loop_filter_mix2_v_88_16_neon : 855.1 166.7
  
  loop_filter_v_4_8_neon :        271.7  65.3
  
  loop_filter_v_8_8_neon :        312.5 106.9
  
  loop_filter_v_16_8_neon :       473.3 206.5
  
  loop_filter_v_16_16_neon :      976.1 327.8
  The speed-up compared to the C functions is 2.5 to 6 and the cortex-a57
  
  is again 30-50% faster than the cortex-a53.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DBH] libavcodec/aarch64/Makefile
  • [DBH] libavcodec/aarch64/vp9dsp_init_aarch64.c
  • [DBH] libavcodec/aarch64/vp9lpf_neon.S

• command line settings for audio equalizer ffmpeg sox

  9 novembre 2016, par user1320370

  I need to add an equalizer effect on some flac files :

  f=4043, 1.65q, g=9.5; f=7024, 1.09q, g=3.7; f=9254, 0.94q, g=-2.5

  I have tried ffmpeg :

  ffmpeg -i solovoce_compress.flac -af equalizer=f=4043:width_type=q:w=1.65:g=9.5, equalizer=f=7024:width_type=q:w=1.09:g=3.7,equalizer=f=9254:width_type=q:w=0.94:g=-2.5 solovoce_equalizzato.flac

  but the result different to what I expect. These values were calculated by izotope ozone (professional audio editor software) and tested.

  I used the equivalent with sox and the result is the same.

  At this point I would like to try ffmpeg ’anequalizer’ filter that shows the graph so I can ’see’ the difference, but the documentation to show the graph is not clear and I have not found anything about it on the web.

  Can someone can please give me an example of how to use ’anequalizer’ with the plot enabled ?

• How do terminal pipes in Python differ from those in Rust ?

  5 octobre 2022, par rust_convert

  To work on learning Rust (in a Tauri project) I am converting a Python 2 program that uses ffmpeg to create a custom video format from a GUI. The video portion converts successfully, but I am unable to get the audio to work. With the debugging I have done for the past few days, it looks like I am not able to read in the audio data in Rust correctly from the terminal pipe - what is working to read in the video data is not working for the audio. I have tried reading in the audio data as a string and then converting it to bytes but then the byte array appears empty. I have been researching the 'Pipe'-ing of data from the rust documentation and python documentation and am unsure how the Rust pipe could be empty or incorrect if it's working for the video.

  


  From this python article and this rust stack overflow exchange, it looks like the python stdout pipe is equivalent to the rust stdin pipe ?

  


  The python code snippet for video and audio conversion :

  


  output=open(self.outputFile, 'wb')
devnull = open(os.devnull, 'wb')

vidcommand = [ FFMPEG_BIN,
            '-i', self.inputFile,
            '-f', 'image2pipe',
            '-r', '%d' % (self.outputFrameRate),
            '-vf', scaleCommand,
            '-vcodec', 'rawvideo',
            '-pix_fmt', 'bgr565be',
            '-f', 'rawvideo', '-']
        
vidPipe = '';
if os.name=='nt' :
    startupinfo = sp.STARTUPINFO()
    startupinfo.dwFlags |= sp.STARTF_USESHOWWINDOW
    vidPipe=sp.Popen(vidcommand, stdin = sp.PIPE, stdout = sp.PIPE, stderr = devnull, bufsize=self.inputVidFrameBytes*10, startupinfo=startupinfo)
else:
    vidPipe=sp.Popen(vidcommand, stdin = sp.PIPE, stdout = sp.PIPE, stderr = devnull, bufsize=self.inputVidFrameBytes*10)

vidFrame = vidPipe.stdout.read(self.inputVidFrameBytes)

audioCommand = [ FFMPEG_BIN,
    '-i', self.inputFile,
    '-f', 's16le',
    '-acodec', 'pcm_s16le',
    '-ar', '%d' % (self.outputAudioSampleRate),
    '-ac', '1',
    '-']

audioPipe=''
if (self.audioEnable.get() == 1):
    if os.name=='nt' :
        startupinfo = sp.STARTUPINFO()
        startupinfo.dwFlags |= sp.STARTF_USESHOWWINDOW
        audioPipe = sp.Popen(audioCommand, stdin = sp.PIPE, stdout=sp.PIPE, stderr = devnull, bufsize=self.audioFrameBytes*10, startupinfo=startupinfo)
    else:
        audioPipe = sp.Popen(audioCommand, stdin = sp.PIPE, stdout=sp.PIPE, stderr = devnull, bufsize=self.audioFrameBytes*10)

    audioFrame = audioPipe.stdout.read(self.audioFrameBytes) 

currentFrame=0;

while len(vidFrame)==self.inputVidFrameBytes:
    currentFrame+=1
    if(currentFrame%30==0):
        self.progressBarVar.set(100.0*(currentFrame*1.0)/self.totalFrames)
    if (self.videoBitDepth.get() == 16):
        output.write(vidFrame)
    else:
        b16VidFrame=bytearray(vidFrame)
        b8VidFrame=[]
        for p in range(self.outputVidFrameBytes):
            b8VidFrame.append(((b16VidFrame[(p*2)+0]>>0)&0xE0)|((b16VidFrame[(p*2)+0]<<2)&0x1C)|((b16VidFrame[(p*2)+1]>>3)&0x03))
        output.write(bytearray(b8VidFrame))

    vidFrame = vidPipe.stdout.read(self.inputVidFrameBytes) # Read where vidframe is to match up with audio frame and output?
    if (self.audioEnable.get() == 1):


        if len(audioFrame)==self.audioFrameBytes:
            audioData=bytearray(audioFrame) 

            for j in range(int(round(self.audioFrameBytes/2))):
                sample = ((audioData[(j*2)+1]<<8) | audioData[j*2]) + 0x8000
                sample = (sample>>(16-self.outputAudioSampleBitDepth)) & (0x0000FFFF>>(16-self.outputAudioSampleBitDepth))

                audioData[j*2] = sample & 0xFF
                audioData[(j*2)+1] = sample>>8

            output.write(audioData)
            audioFrame = audioPipe.stdout.read(self.audioFrameBytes)

        else:
            emptySamples=[]
            for samples in range(int(round(self.audioFrameBytes/2))):
                emptySamples.append(0x00)
                emptySamples.append(0x00)
            output.write(bytearray(emptySamples))

self.progressBarVar.set(100.0)

vidPipe.terminate()
vidPipe.stdout.close()
vidPipe.wait()

if (self.audioEnable.get() == 1):
    audioPipe.terminate()
    audioPipe.stdout.close()
    audioPipe.wait()

output.close()


  


  The Rust snippet that should accomplish the same goals :

  


  let output_file = OpenOptions::new()
    .create(true)
    .truncate(true)
    .write(true)
    .open(&output_path)
    .unwrap();
let mut writer = BufWriter::with_capacity(
    options.video_frame_bytes.max(options.audio_frame_bytes),
    output_file,
);
let ffmpeg_path = sidecar_path("ffmpeg");
#[cfg(debug_assertions)]
let timer = Instant::now();

let mut video_cmd = Command::new(&ffmpeg_path);
#[rustfmt::skip]
video_cmd.args([
    "-i", options.path,
    "-f", "image2pipe",
    "-r", options.frame_rate,
    "-vf", options.scale,
    "-vcodec", "rawvideo",
    "-pix_fmt", "bgr565be",
    "-f", "rawvideo",
    "-",
])
.stdin(Stdio::null())
.stdout(Stdio::piped())
.stderr(Stdio::null());

// windows creation flag CREATE_NO_WINDOW: stops the process from creating a CMD window
// https://docs.microsoft.com/en-us/windows/win32/procthread/process-creation-flags
#[cfg(windows)]
video_cmd.creation_flags(0x08000000);

let mut video_child = video_cmd.spawn().unwrap();
let mut video_stdout = video_child.stdout.take().unwrap();
let mut video_frame = vec![0; options.video_frame_bytes];

let mut audio_cmd = Command::new(&ffmpeg_path);
#[rustfmt::skip]
audio_cmd.args([
    "-i", options.path,
    "-f", "s16le",
    "-acodec", "pcm_s16le",
    "-ar", options.sample_rate,
    "-ac", "1",
    "-",
])
.stdin(Stdio::null())
.stdout(Stdio::piped())
.stderr(Stdio::null());

#[cfg(windows)]
audio_cmd.creation_flags(0x08000000);

let mut audio_child = audio_cmd.spawn().unwrap();
let mut audio_stdout = audio_child.stdout.take().unwrap();
let mut audio_frame = vec![0; options.audio_frame_bytes];

while video_stdout.read_exact(&mut video_frame).is_ok() {
    writer.write_all(&video_frame).unwrap();

    if audio_stdout.read_to_end(&mut audio_frame).is_ok() {
        if audio_frame.len() == options.audio_frame_bytes {
            for i in 0..options.audio_frame_bytes / 2 {
                let temp_sample = ((u32::from(audio_frame[(i * 2) + 1]) << 8)
                    | u32::from(audio_frame[i * 2]))
                    + 0x8000;
                let sample = (temp_sample >> (16 - 10)) & (0x0000FFFF >> (16 - 10));

                audio_frame[i * 2] = (sample & 0xFF) as u8;
                audio_frame[(i * 2) + 1] = (sample >> 8) as u8;
            }
        } else {
            audio_frame.fill(0x00);
        }
    }
    writer.write_all(&audio_frame).unwrap();
}


video_child.wait().unwrap();
audio_child.wait().unwrap();

#[cfg(debug_assertions)]
{
    let elapsed = timer.elapsed();
    dbg!(elapsed);
}

writer.flush().unwrap();


  


  I have looked at the hex data of the files using HxD - regardless of how I alter the Rust program, I am unable to get data different from what is previewed in the attached image - so the audio pipe is incorrectly interfaced. I included a screenshot of the hex data from the working python program that converts the video and audio correctly.

  


  HxD Python program hex output :

  


  

  


  HxD Rust program hex output :