[NUT-devel] Welcome...

[Michael Niedermayer]

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