[FFmpeg-devel] [PATCH] 5 of 5 Add Speex Encoding

[Justin Ruggles]

Michael Niedermayer wrote:
> On Tue, Jul 07, 2009 at 07:01:13PM -0400, Justin Ruggles wrote:
>> Art Clarke wrote:
>>> On Tue, Jul 7, 2009 at 7:29 AM, Michael Niedermayer <michaelni at gmx.at>wrote:
>>>>> 2) in flvenc.c, either don't enforce the frames-per-packet (assume the
>>>> user
>>>>> knows what they are doing) or just warn people if is not between 1 and 8.
>>>> i think iam in favor of letting the user shoot himself, if that is what he
>>>> asks for, that said thats just a very weak oppinion of mine, i dont mind
>>>> a check ...
>>>>
>>> Any suggestions on the best way to make this configurable in libspeexenc.c?
>>> My default idea is to add (yet another) field at the end of AVCodecContext
>>> named "frames_per_packet", make it settable in libavcodec/options.c, and
>>> then use it in libspeexenc.c (and potentially any other codecs that need
>>> it).  This would be a minor version bump for libavcodec.
>> Here is my idea:
>>
>> add frames_per_packet to AVCodecContext
>>     - min/max_frames_per_packet might be useful too for when it needs
>>       to be variable
>> add num_frames to AVPacket, 0 for incomplete or partial
>> new audio encoding function that outputs to an AVPacket
>>
>> demuxer: set num_frames based on extradata or parsing
>>     parser: parse out full frames if needed and determine num_frames
>> decoder: decode all frames in the packet
>> encoder: encode frame(s) based on user settings and set num_frames
>> muxer: able to determine if num_frames is compatible with the container
> 
> my first thought: overkill
> 
> Is it possible to just split the speex packets at the demuxer/parser and let
> the muxer merge them? or does this multi-packeting apply to several muxers?
> (and yes i do accept the bit padding needed to make them byte aligned)

For Speex, the splitting would be simple in a parser, and merging
possible but maybe slow because it would have to "unalign" the frames
which I think will require using the bitstream writer.  It's worth a try
though.

It might still be worth having a frames_per_packet option for the muxer
so that the user can adjust the overhead/latency trade-off for
muxer/codec combinations that support it.

-Justin