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