Kostya's Boring Codec World

I think I ought to tell about the idea that fellow FFmpeg participant Robert Swain (I still wait for him to complete AMR-NB decoder) tries to champion. I mean encoding profiles.

The idea is quite simple – allow users use convenient presets instead of command line black magic, so simple commands like

ffmpeg -i input.vob -preset dvdrip -preset hq_mp3 output.avi
ffmpeg -i input.avi -preset flash_youtube output.flv
ffmpeg -i input.vob -preset ipod_vid output.mp4

can be used without bothering about bitrate/flags/gop size/whatever.

I also think this will be useful. It will be easier to change options meaning without making additional complications (we still get questions from users that do not know recent ffmpeg expects bitrate to be specified in bits, not in kilobits as before). Just don’t make frontend for it named ffclippy, okay?

After some discussions on IRC I’ve participated I’d like to present here for future discussion.

1. Audio API should reflect video API as much as possible. Now decoder outputs 16-bit native-endian audio into raw buffer.
2. Introduce audio formats. I’d like to be able to decode old 8-bit codec into bytes, newer 24-bit audio into 32-bit ints, floats for other codecs if they need it, etc.
3. Planar format for multichannel codecs. It will simplify downmixing and channel reordering. (This is not my idea but it is worth mentioning)
4. Swscaler-like structure for format handling and negotiations between audio filters.
5. Block-based audio processing. Each audio should be operated as a multiple of blocks with fixed number of samples (like video is operated by frames and rarely by slices). Why not always by single block? Because some formats throw chunks with multiple blocks to decode (Monkey Audio, Musepack SV8) and some have too small blocks that cause too much overhead to process them by one at time (most speech codecs and (AD)PCM). This is just a bit stricter than current scheme.

Now, who wants to implement this?