[NUT-devel] Welcome...

[Oded Shimon]

On Sun, Feb 12, 2006 at 12:52:34PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Sun, Feb 12, 2006 at 07:45:54AM +0200, Oded Shimon wrote:
> [...]
> > > > Anything else? These are truely the last issues I'm aware of, as far as I'm 
> > > > concerned we can (finally) finalize spec... If anybody has anything, say it 
> > > > now...
> > > 
> > > something crazy :)
> > > ive already suggested it long ago and its probably a stupid idea but it might
> > > mean big reduction of overhead and iam very curious how much space we could 
> > > save with it ...
> > > 
> > > give each stream 2 byte sequences in the stream header 
> > > (like codec_specific_data), one for keyframes one for non-key frames, then
> > > for each frame, put the correspong byte sequence before the frame before
> > > outputing it from the demuxer :)
> > 
> > It's weird.. It's the codec's job, not the container... Do we put it before 
> > ALL frames in the stream or add another stream flag (or nut flag?).
> > 
> > Anyway, I suspect your savings will be about as much as your loss by adding 
> > checksums to syncpoints... I don't really consider it reduction in 
> > overhead, more like compression of data... I'm assuming you're refferring 
> > to silly mp3 and mpeg-4 startcodes?...
> 
> yep, 4byte per frame for mpeg4 at least and 2 byte per mp3 frame
> at 30fps 44100khz thats ~1.6kbit/sec or 1.3 mb for a 2 hour movie
> 
> for syncpoints its 4byte per 16384byte which for a 650mb movie
> is ~166kbyte
> 
> the checksum per syncpoint overhead also is per filesize so lower
> bitrate lower overhead for the checksums, while the startcode overhead
> wont decrease, for example: for a 1hour 128kbit stereo mp3 in nut
> the syncpoint checksums need 14kbyte while the startcodes need 275kbyte

Heh, wow, you're right. For a simple high bitrate file:

before: TOTAL: 726098576 bytes data, 917174 bytes overhead, 0.13% overhead
after:  TOTAL: 726098576 bytes data, 187977 bytes overhead, 0.03% overhead

And for the 620 low bitrate file:

before: TOTAL: 623128520 bytes data,  1988245 bytes overhead, 0.32% overhead
after:  TOTAL: 623128520 bytes data, -1168114 bytes overhead, -0.19% overhead

(negative overhead! hehe)

I should note, the low bitrate file failed for me at first because some 
frames were zero bytes (stupid mencoder). This is not an issue because NUT 
is pts aware, and zero byte frames should never occur unless they really 
mean something to the decoder (like, black frame). Instead, they should be 
compensated by higher pts. Right?

Anyway, the only thing I'm kind of worried about is how to put this in 
spec. Just have 2 fixed codes in the stream header, for keyframes and for 
non keyframes?... Also, do ALL frames get it, or can it be flagged off?

BTW, is it considered a violation of NUT spec to put mpeg-4 startcodes 
inside nut frames, as spec says cannot have containers inside the NUT 
container? (ogg-in-avi)

I guess MPEG-4 spec specifies the startcodes as literal parts of the frames 
for decoder, so ok...

- ods15