[NUT-devel] Welcome...

[Michael Niedermayer]

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

[...]

-- 
Michael