[MPlayer-dev-eng] Bogus numbers for NUT overhead

[D Richard Felker III]

On Fri, Apr 23, 2004 at 02:38:28AM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Friday 23 April 2004 01:41, D Richard Felker III wrote:
> > While trying to figure out how to improve the nut design, I've been
> > doing overhead calculation on paper, and discovered that most of
> > Michael's numbers are totally bogus. It's IMPOSSIBLE for any container
> > to have less than ~0.25% overhead for 128kbit mp3, because the packet
> > size is 418 bytes, meaning that even a 1byte header gives ~0.25%
> > overhead! But Michael's original "NUT preview" email on ffmpeg-devel
> >
> > reported:
> > > -rw-r--r--    1 michael  michael   4592134 2004-04-01 19:57 test3.nut
> > > -rw-r--r--    1 michael  michael   4582922 2004-04-01 19:57 test3.mp3
> >
> > So either his muxer was dropping some frames, or it's packing multiple
> > frames together (which is illegal). Other reports since then have
> > repored similarly incredible results. So what's up?
> never underestimate NUT

:))))

> ok, there was a bug in that early version, where various things wherent reset 
> at type != 0 packets at least, maybe more, i noticed these when i implemented 
> seeking ...
> and the stream was 160kbit not 128, the mp3 packet size was 522/523 and with 
> packet size prediction the type 0 headers should have been 1 byte each, so 
> the overhead must be above 1*100%/522.5= 0.19138... %
> and 
> 4592134 - 4582922 = 9212
> 9212*100% / 4582922 = 0.201%

What about the type 1/2 frames? Were there any type2 frames except at
the beginning of the file? :P

> thats pretty close, maybe there where further bugs, current nut with the same 
> mp3 now gives
> -rw-r--r--    1 michael  michael   4594557 2004-04-23 02:26 test3.nut
> -rw-r--r--    1 michael  michael   4582922 2004-04-23 02:05 test3.mp3
> 4594557 - 4582922 = 11635
> 11635*100% / 4582922 = 0.2538...%

Hmm, wonder why there's so much difference.

> a simple 'ffmpeg -i test3.nut -acodec copy test3-out.mp3' gives a binary 
> identical mp3 so there are certainly no droped frames

OK. Still, are you positive that it's not packing multiple frames
together?

Rich