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

[Michael Niedermayer]

Hi

On Friday 23 April 2004 03:46, D Richard Felker III wrote:
> 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
i doubt it, its hardly possible with these numbers, but i dont have that nut 
file anymore so i cant check it easily

>
> > 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?
yes, see the attched debug output, i can also upload the source mp3 if u want

[...]
-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debug.bz2
Type: application/x-bzip2
Size: 1113 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20040423/341902e9/attachment.bin>