[FFmpeg-devel] [RFC] Monkey's Audio decoder

[Kostya]

On Wed, Sep 12, 2007 at 12:18:57PM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Wed, Sep 12, 2007 at 08:08:26AM +0300, Kostya wrote:
[...]
> > 
> > a) data should be bswap32()d before use
> > b) offset in data should be passed to decoder
> 
> i dont see how either of these would require the dummy packets
> the decoder can bswap the data into an internal buffer (like it does currently
> IIRC) and still correctly return the size of the decoded block
> also it knows the offset of the next block from the end of the previous block
> only the first offset of such a huge frame is unknown but that is passed anyway
 
I'll work on this.
 
> > 
> > While demuxer take care of this, it is hard to make application do so.
> > Alternatives are handling the whole frames or decoding blocks to determine their
> > boundaries (which requires half of decoder code duplication).
> 
> if its possible to split them efficiently (cpu time wise) that should be done
> code duplication can be avoided by properly implementing it ...

That's not possible in given conditions - there are no boundaries between these blocks and determining them would require executing do_entropy_decode() 4608 or 9216 times per block.
 
> > 
> > The only problem with current approach - it makes error happening in decode_audio2()
> > because input frame size is larger than output audio buffer (*frame_size_ptr < buf_size)
> > but I am sure that condition may be dropped without any bad consequences.
> 
> well if you check all audio decoders for buffer overflows ...

I will. 
 
> > 
> > > the problem with your approch is that if the stuff is stream copied then the
> > > file will be full of these dummy packets
> > 
> > I can't imagine this situation - it's another case of codec/container lock in.
> 
> i can imaging people wanting to use it in avi, mkv, ...
> and especially with mkv iam sure its only a matter of time until someone finds
> a completely broken and sick way to do it (aka store the megabyte sized frames
> as is) and without dummy packets ...

So I will stay with those large frames (There is _no_ fast way to split them) but will get rid of those dummy packets. 
 
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> I am the wisest man alive, for I know one thing, and that is that I know
> nothing. -- Socrates



> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel