Re: [Mpg123-devel] One Frame In, one decoded Frame out?

[Thomas O. <tho...@or...>]

Am Mon, 14 Apr 2008 00:05:35 +0100
schrieb Nicholas J Humfrey <nj...@ec...>: 

> Hello,
> 
> Been doing some more work on my libmpg123 plugin for Videolan.  
> VideoLan pre-parses the MPEG Audio and passes exactly one frame of  
> MPEG Audio to the plugin. It then expects to get exactly one frame of  
> decoded audio back again.

Whut? Who is the MPEG decoder here, VLC or libmpg123??
I really tried hard to introduce the "burstyness" actually.
That is, if I understand you correctly.

The magic word here is "gapless". I added code in mpg123 to skip at least the decoder delay and, if possible, the encoder padding.
That results in less samples output for the first and last frames, for example.
And I consider that a _good_ thing, as these samples are not the encoded audio but extra rubbish.
VLC wants the rubbish?
I'm not sure now (it's late and I'm tired) how libmpg123 gives you a bigger than expected burst of samples later... perhaps you could elaborate that with some numbers.
I suspect it's a result of gapless stuff, too.

You can disable the MPG123_GAPLESS runtime option and also set the #define GAPLESS_DELAY to 0 (frame.h) for the library to see how it looks without the ignoring code.
Hm, thinking of which...  I guess the decoder delay ignoring should also be influenced by the runtime config setting.
Currently you cannot prohibit that, only the handling of encoder padding.


Alrighty then,

Thomas.

PS: Anything on IPv6 support, http streaming being a major usage scenario for mpg123, as it seems?