[Ffmpeg-devel] Increasing Audio Buffer Size
Tue May 9 21:10:46 CEST 2006
On 9-May-06, at 2:56 PM, Michael Niedermayer wrote:
> On Tue, May 09, 2006 at 01:05:20PM -0400, Cyril Zorin wrote:
>>> heres my thought on how it could be done (comments welcome...)
>>> -int avcodec_decode_audio(AVCodecContext *avctx, int16_t *samples,
>>> +int avcodec_decode_audio(AVCodecContext *avctx, AVFrame *avframe,
>>> optionally the above can be done in a way which doesnt break
>>> be adding a new function and keeping the old ...
>>> the audio decoders decode():
>>> calls avctx.release_buffer(avctx, avframe) if a previous
>>> buffer isnt
>>> needed anymore
>>> calls avctx.get_buffer(avctx, avframe)
>>> audio sample i of channel c is stored in
>>> avframe.data[c][ i*avframe.linesize[c] ] cast to the format
>>> int16_t currently)
>> Would it be correct to say that currently (samples) is an array of
>> interlaced channel data?
>> If many audio decoders already output interlaced
>> channel audio data, then they'd have to be modified to support the
> nonsense, nothing needs to be modified, the new system supports
> interleaved as
> well as non interleaved output, the later makes some sense as it
> might be
> closer to the internal format and it might be easier to filter /
Right now then, without this glorious modification that you're about
to make, how would I specify
that my audio output data is not interleaved?
>> avframe.data[channel][sample_index] storage.
> avframe.data[c][ i*avframe.linesize[c] ] not avframe.data[c][i]
>> In that case, who interlaces
>> the audio data later on?
> if the user needs a format different from what a decoder output ...
> of course the user will need to covert it, lavc might provide some
> to help but its really just a 3 line for loop ...
>> I think it'd be better to take the analogous approach that video
> i do, you just dont seem to understand it
No, it's __you__ who's misunderstanding my point. You can't say
"comments welcome" and
then mouth off to people -- are comments welcome, or not? If you
think you're a genius and
have the liberty to treat people like idiots, then go ahead and
implement it yourself, but don't
pretend to be "open minded" and say shit like "comments welcome."
>> takes, insofar that at a certain point an "Audio Frame" is just a
>> of crap that the decoder can fill in, without organizing it by
>> "channel" or
> for video its organized by color components and lines, so your free
> crap is not analogous
I meant "free form" in that I specify how I'll organize my color
data. Take the mental leap there before
you start calling things "crap", in order to impress... who?
>> Also, if it were up to me, I'd leave the AVFrame struct well alone
>> and make
>> an "AFrame" or otherwise something for "audio frame". I wouldn't
>> want to
>> clutter AVFrame any more.
> thats certainly a possibility, if its better i dont know, what i do
> is it will be more work and possibly more complicated code ...
> we would need AVFrame, AFrame, VFrame later 2 would be "subclasses"
> of AVFrames (= their first fields match the ones from AVFrame)
Subclasses? What for? Shit. If you think that breaking things down
and therefore separating concerns is
making code "complicated", then I think I lost the debate before I
got into it.
Go ahead, stick it in AVFrame.
> In the past you could go to a library and read, borrow or copy any
> Today you'd get arrested for mere telling someone where the library is
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
More information about the ffmpeg-devel