Recherche avancée

Sur d’autres sites (8310)

• How can I turn libavformat error messages off

  27 octobre 2011, par amrhassan

  By default, libavformat writes error messages to stderr, Like :

  Estimating duration from bitrate, this may be inaccurate

  How can I turn it off ? or better yet, pipe it to my own neat logging function ?

  Edit : Redirecting stderr to somewhere else is not acceptable since I need it for other logging purposes, I just want libavformat to not write to it.

• ffmpeg encoding slowly, not using much CPU

  30 juin 2012, par eblume

  I am using the latest (as of this post) version of ffmpeg on OS X as installed via homebrew (an OS X 3rd-party package manager with a good reputation.) I am trying to encode video that was recorded using Fraps on another machine to reduce the file size while preserving as much quality as is reasonably possible.

  Fraps records video in a .avi container and I believe does absolutely no encoding - instead, it's just a stream of image files. The resulting files are often enormous, obviously. I want to set up a cron job that finds recorded files and encodes them to H.264 with some sort of audio codec (I'm currently using libmp3lame but will revisit it when I get video working right - will probably switch to a lossless audio codec.)

  My problem is that while encoding seems to be working exactly how I want it - very few compression artifacts but about 5% of the original size - the encoding is taking forever. I'm averaging about 1.5 encoded frames per second, and these are 2-3 hours of 30FPS video. On top of that, my CPU is never fully utilized. On my dual-core CPU I am getting a median usage of about 40% of one core, with occasional peaks of 140% to 160%.

  So the question is : How can I speed up encoding ? I'm sure there's got to be some options I'm missing out on.

  Here's the command I use :

  ffmpeg -i INFILE -c copy -c:a libmp3lame -ar 44100 -q:a 5 \
  
                -threads 0 -c:v libx264 OUTFILE

  Thanks !

  EDIT : Actually, it looks like this command isn't compressing that well either - I'll do some digging but it seems that this might be being too generous with the bitrate for H.264. At first I was getting around 2Mb/s but it's gone up to almost 20Mb/s - looks like I'm basically not compressing at all.

• ANSI FATE

  24 août 2010, par Multimedia Mike — FATE Server

  The new FATE server is shaping up well. I think most of the old configurations have been migrated to the new server. I see one new compiler for x86_64– PathScale. It’s not faring particularly well at this point.

  New Tests
  As I write this, I noticed that there are now an even 700 tests, twice as many as the last time I trumpeted such a milestone. (It should be noted that the new FATE system finally breaks down the master regression suite into individual tests.) Thankfully, it’s no longer necessary to wait for me to create or edit tests (anyone with FFmpeg privileges can do this), nor is it necessary to keep up with this blog to know exactly what tests are new. Now, you can simply inspect the file history on tests/fate.mak and tests/fate2.mak (I think these 2 files are going to merge in the near future).

  Vitor, as of r24865 : “Add FATE test for ANSI/ASCII animation and TTY demuxer.” Eh ? What’s this about ? I admit I was completely removed from FFmpeg development for much of June and July so I could have missed a lot. Fortunately, I can check the file history to see which lines were added to make this test happen. And if FATE is exercising the test, you know exactly where the samples will live. Here’s this new decoder in action on the relevant sample :

  
  
  

  The file history fingers Suxen drol/Peter Ross for this handiwork. I might have guessed– the only person who is arguably more enamored with old, weird formats than even I. Now we wait for the day that YouTube has support for this format. I’m sure there are huge archives of these animations out there (and I wager that Trixter and Jason Scott know where).

  
  
  It’s an animation — it just keeps going
  

  Meanwhile, the FATE suite now encompasses a bunch of perceptual audio formats, thanks to the 1-off testing method and a few other techniques. These formats include Bink audio, WMA Pro, WMA voice, Vorbis, ATRAC1, ATRAC3, MS-GSM, AC3, E-AC3, NellyMoser, TrueSpeech, Intel Music Coder, QDM2, RealAudio Cooker, QCELP (just going down the source control log here), and others, no doubt.

  Then there’s this curious tidbit : “Add FATE test for WMV8 DRM”. The test spec is "fate-wmv8-drm: CMD = framecrc -cryptokey 137381538c84c068111902a59c5cf6c340247c39 -i $(SAMPLES)/wmv8/wmv_drm.wmv -an". I would still like to investigate FFmpeg’s cryptographic capabilities, which I suspect are moving in a direction to function as a complete SSL stack one day.

  New Platforms
  As for new platforms, the new FATE system finally allows testing on OS/2 (remember that classic ? It was “the totally cool way to run your computer”). Thanks to Dave Yeo for taking this on.

  Further, a new MIPS-based platform recently appeared on the FATE list. This one reports itself as running on 74kf CPU. Googling for this processor quickly brings up Mans’ post about the Popcorn Hour device. So, congratulations to him for getting the mundane box to serve a higher purpose. Perhaps one day, I’ll be able to do the same for that Belco Alpha-400 netbook.