| 2 | |
| 3 | '''Latest status [2012-04-16]:''' |
| 4 | |
| 5 | - the codecs have funny ptime, such as 42 ms. Currently there is no encoding buffering done in the codec, so caller must supply with the exact ptime as reported in default_param. |
| 6 | - some codecs requires very large output buffer. Maybe the codec should provide this encoding buffering anyway. |
| 7 | - decoding already implements buffering, because we don't know if the frame supplied to the codec match the defined ptime (because we don't know how to parse the packet). |
| 8 | - parsing is very rudimentary, it only attempts to split the packet somehow so that it fits the jbuf. |
| 9 | - this is only for file encoding and decoding; RTP is not supported yet. Some of these codecs have their own framing spec, e.g. [http://tools.ietf.org/html/rfc3640 RFC 3640] '''and/or''' [http://tools.ietf.org/html/rfc6416 RFC 6416] for AAC. |
| 10 | |
| 11 | These codecs seem to be working: |
| 12 | - MP2 |
| 13 | - MP3 (ffmpeg needs --enable-libmp3lame) |
| 14 | |
| 15 | These codecs don't: |
| 16 | - AAC: |
| 17 | - decoding fails with "aac channel element 0.0 is not allocated". Probably due to http://lzone.de/aac+decoding+with+ffmpeg+doesn%27t+work |
| 18 | - for encoding, ffmpeg needs --enable-libaacplus |
| 19 | - Vorbis: it only works with 2 channels |
| 20 | |
| 21 | These codecs are untested: |
| 22 | - G.723.1 |
| 23 | - G.726 |