Hi On Sun, Feb 12, 2006 at 07:37:55PM +0200, Oded Shimon wrote:
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?
yes, AFAIK 0-byte - skip frames are a feature of AVI only
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?
dunno, but we might even add it into the framecode table so each framecode could have a different "prefix" * no flag needed * fully optional on the muxer side * still as easy for the demuxer as if its in the stream header * theoretically lower overhead / more flexible
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...
yes, startcodes are ok, just think about keyframes, there are several startcodes and headers in a frame or quantization tables or several slices per frame with startcodes infront of them (mpeg1/2 case) [...] -- Michael