Recherche avancée

Sur d’autres sites (6171)

• VP8 Codec Optimization Update

  16 juin 2010, par noreply@blogger.com (John Luther) — inside webm

  Since WebM launched in May, the team has been working hard to make the VP8 video codec faster. Our community members have contributed improvements, but there’s more work to be done in some interesting areas related to performance (more on those below).

  
  

  Encoder

  
  The VP8 encoder is ripe for speed optimizations. Scott LaVarnway’s efforts in writing an x86 assembly version of the quantizer will help in this goal significantly as the quantizer is called many times while the encoder makes decisions about how much detail from the image will be transmitted.

  For those of you eager to get involved, one piece of low-hanging fruit is writing a SIMD version of the ARNR temporal filtering code. Also, much of the assembly code only makes use of the SSE2 instruction set, and there surely are newer extensions that could be made use of. There are also redundant code removal and other general cleanup to be done ; (Yaowu Xu has submitted some changes for these).
  
  At a higher level, someone can explore some alternative motion search strategies in the encoder. Eventually the motion search can be decoupled entirely to allow motion fields to be calculated elsewhere (for example, on a graphics processor).
  

  Decoder

  
  Decoder optimizations can bring higher resolutions and smoother playback to less powerful hardware.

  Jeff Muizelaar has submitted some changes which combine the IDCT and summation with the predicted block into a single function, helping us avoid storing the intermediate result, thus reducing memory transfers and avoiding cache pollution. This changes the assembly code in a fundamental way, so we will need to sync the other platforms up or switch them to a generic C implementation and accept the performance regression. Johann Koenig is working on implementing this change for ARM processors, and we’ll merge these changes into the mainline soon.

  In addition, Tim Terriberry is attacking a different method of bounds checking on the "bool decoder." The bool decoder is performance-critical, as it is called several times for each bit in the input stream. The current code handles this check with a simple clamp in the innermost loops and a less-frequent copy into a circular buffer. This can be expensive at higher data rates. Tim’s patch removes the circular buffer, but uses a more complex clamp in the innermost loops. These inner loops have historically been troublesome on embedded platforms.
  
  To contribute in these efforts, I’ve started working on rewriting higher-level parts of the decoder. I believe there is an opportunity to improve performance by paying better attention to data locality and cache layout, and reducing memory bus traffic in general. Another area I plan to explore is improving utilization in the multi-threaded decoder by separating the bitstream decoding from the rest of the image reconstruction, using work units larger than a single macroblock, and not tying functionality to a specific thread. To get involved in these areas, subscribe to the codec-devel mailing list and provide feedback on the code as it’s written.
  

  Embedded Processors

  
  We want to optimize multiple platforms, not just desktops. Fritz Koenig has already started looking at the performance of VP8 on the Intel Atom platform. This platform need some attention as we wrote our current x86 assembly code with an out-of-order processor in mind. Since Atom is an in-order processor (much like the original Pentium), the instruction scheduling of all of the x86 assembly code needs to be reexamined. One option we’re looking at is scheduling the code for the Atom processor and seeing if that impacts the performance on other x86 platforms such as the Via C3 and AMD Geode. This is shaping up to be a lot of work, but doing it would provide us with an opportunity to tighten up our assembly code.
  
  These issues, along with wanting to make better use of the larger register file on x86_64, may reignite every assembly programmer’s (least ?) favorite debate : whether or not to use intrinsics. Yunqing Wang has been experimenting with this a bit, but initial results aren’t promising. If you have experience in dealing with a lot of assembly code across several similar-but-kinda-different platforms, these maintainability issues might be familiar to you. I hope you’ll share your thoughts and experiences on the codec-devel mailing list.
  
  Optimizing codecs is an iterative (some would say never-ending) process, so stay tuned for more posts on the progress we’re making, and by all means, start hacking yourself.
  
  It’s exciting to see that we’re starting to get substantial code contributions from developers outside of Google, and I look forward to more as WebM grows into a strong community effort.
  
  John Koleszar is a software engineer at Google.

  

• FFMPEG on MACOSX is complaining "no matches found"

  15 juin 2022, par Byte Player

  I have a FFMPEG command line function that works perfectly on Windows but on Mac produces the following error :

  


  "no matches found [1:a]adelay=15000:all=1[aud2]"
  
"no matches found [2:a]adelay=5000:all=1[aud3]"

  


  Here is the command (less the full paths which just made it very hard to read). I've verified that the files exist at the paths specified by copying the file path from the command line and going into terminal, typing "open" then pasting in the copied path and pressing enter. In all cases they played.

  


  ffmpeg -loglevel warning -hide_banner -y -i "file1.mp3" -t 5 -i "file2.mp3" -i "file3.mp3" -i "file4.mp3" -ss 25 -t 15 -i "file5.mp3" -ss 15 -t 5 -i "file6.mp3" -filter_complex [1:a]adelay=15000:all=1[aud1];[2:a]adelay=5000:all=1[aud2];[4:a]adelay=25000:all=1[aud4];[5:a]adelay=5000:all=1[aud5];[aud1][aud2][aud4][aud5]amix=inputs=6:duration=longest:dropout_transition=0:normalize=0 "output.mp3"


  


  I know the immediate response (as it should be), is update your FFMPEG but I got the latest build (built on 2022-06-12) and here's what it reports...

  


  ffmpeg version N-107092-g843c4346b1-tessus Copyright (c) 2000-2022 the FFmpeg developers
  built with Apple clang version 11.0.0 (clang-1100.0.33.17)
  configuration: --cc=/usr/bin/clang --prefix=/opt/ffmpeg --extra-version=tessus --enable-avisynth --enable-fontconfig --enable-gpl --enable-libaom --enable-libass --enable-libbluray --enable-libdav1d --enable-libfreetype --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libmysofa --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopus --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvmaf --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-libzimg --enable-libzmq --enable-libzvbi --enable-version3 --pkg-config-flags=--static --disable-ffplay
  libavutil      57. 26.100 / 57. 26.100
  libavcodec     59. 33.100 / 59. 33.100
  libavformat    59. 24.100 / 59. 24.100
  libavdevice    59.  6.100 / 59.  6.100
  libavfilter     8. 40.100 /  8. 40.100
  libswscale      6.  6.100 /  6.  6.100
  libswresample   4.  6.100 /  4.  6.100
  libpostproc    56.  5.100 / 56.  5.100
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...


  


  Any insight or help would be GREATLY appreciated.

  


• ProcessBuilder is not called when trying to start a process

  15 juin 2022, par xnok

  I am trying to understand more about the ffmpeg usage in JavaCV for android studio and for said task I am trying to use ProcessBuilder. I tried writting a simple program to debug the pb.start(); Although, I am not getting a response. What I did was to start a default/empty activity and pasted the following program :

  


  package com.example.myapplication;

import androidx.annotation.RequiresApi;
import androidx.appcompat.app.AppCompatActivity;
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.OutputStream;

import org.bytedeco.javacpp.Loader;

import android.os.Build;
import android.os.Bundle;
import android.util.Log;

public class MainActivity extends AppCompatActivity {
    static final int cols = 192;
    static final int rows = 108;
    static final String ffmpeg = Loader.load(org.bytedeco.ffmpeg.ffmpeg.class);
    static final String rtmp_url = "test.flv";
    static final String[] command = {ffmpeg,
            "-y",
            "-f", "rawvideo",
            "-vcodec", "rawvideo",
            "-pix_fmt", "bgr24",
            "-s", (Integer.toString(cols) + "x" + Integer.toString(rows)),
            "-r", "10",
            "-i", "pipe:",
            "-c:v", "libx264",
            "-pix_fmt", "yuv420p",
            "-preset", "ultrafast",
            "-f", "flv",
            rtmp_url};
    @RequiresApi(api = Build.VERSION_CODES.O)
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        new Thread(t1).start();

    }
    private static Runnable t1 = () -> {
        Log.e("TAG", "void OnCreate called successfully!");
        ProcessBuilder pb = new ProcessBuilder(command).redirectErrorStream(true);
        pb.redirectErrorStream(true);
        try {
            Process process = pb.start();
            BufferedReader reader = new BufferedReader(new InputStreamReader(process.getInputStream()));
            OutputStream writer = process.getOutputStream();
            Log.e("TAG", "Something good happened here");
        } catch (IOException e) {
            e.printStackTrace();
            Log.e("TAG", "Nothing good happened here");
        }
    };


}


  


  My current problem is that I can't seem to start properly the processBuilder process via pb.start() ;

  


  I get the following logs from the logcat panel :

  


  2022-06-14 17:24:46.328 13371-13371/com.example.myapplication E/TAG: void OnCreate called successfully!
2022-06-14 17:24:46.333 13371-13371/com.example.myapplication E/TAG: Nothing good happened here


  


  I'd like to understand why is it skipping the try/catch block and not starting the process ?

  


  EDIT : I made some changes as per @g00se's suggestions and I got the following stack trace from the code above :

  


  2022-06-15 00:32:26.700 29787-29787/? E/USNET: USNET: appName: com.example.myapplication
2022-06-15 00:32:29.328 29787-29828/com.example.myapplication E/TAG: void OnCreate called successfully!
2022-06-15 00:32:29.330 29787-29828/com.example.myapplication E/AndroidRuntime: FATAL EXCEPTION: Thread-4
    Process: com.example.myapplication, PID: 29787
    java.lang.NullPointerException
        at java.lang.ProcessBuilder.start(ProcessBuilder.java:1012)
        at com.example.myapplication.MainActivity.lambda$static$0(MainActivity.java:48)
        at com.example.myapplication.MainActivity$$ExternalSyntheticLambda0.run(Unknown Source:0)
        at java.lang.Thread.run(Thread.java:920)