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

[Kostya]

On Wed, Sep 12, 2007 at 12:18:57PM +0200, Michael Niedermayer wrote:
> Hi
[...]
> 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
> 

Fixed. No more dummy packets, decoder will report consuming of buffer by pieces (while using internal buffer). 
> 
> > 
> > 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 ...

still checking... 
 
> > 
> > > 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 ...

But you should admit that with dummy packets it's even more broken and sick.
 
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ape.patch.bz2
Type: application/x-bzip2
Size: 10394 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070912/73a8f8a8/attachment.bin>