Hi someone needs cola ... Reply-To: nut-devel-request@mplayerhq.hu ----- Forwarded message from Michael Niedermayer <michaelni@gmx.at> ----- Date: Sun, 12 Feb 2006 00:42:47 +0100 From: Michael Niedermayer <michaelni@gmx.at> To: nut-devel-request@mplayerhq.hu Subject: Re: [NUT-devel] Welcome... Message-ID: <20060211234247.GT3210@MichaelsNB> References: <20060211194141.GQ6600@crate15> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060211194141.GQ6600@crate15> User-Agent: Mutt/1.5.10i Status: RO Hi On Sat, Feb 11, 2006 at 09:41:41PM +0200, Oded Shimon wrote:
hut... hut... is this thing on? OK, mailing list is working :)
For all your anonymous enjoyment, you can get latest libnut and nututuils from: svn checkout svn://213.144.138.186/nut/trunk
Make sure to read README...
You'll also see all commits in this ml..
On to buisness... Spec:
1. Split index The only big problem I see is deciding where to split it, and I doubt if even libnut will support this. It's also weird in regards to index_ptr. I vote against this... If it's local storage, you probably have a big damage chunk, not a single byte one...
you dont need a single byte error for this to be usefull, if you loose 10kb in one chunk of a 100kb index you really want to be able to recover as much of the 90kb as you can ...
2. Frame repetition Well, is there anything to really do about this? I can't think of any way a flag would be useful to the demuxer or player, you can just repeat the frame as is, maybe let the codec layer deal with it.
well, i dont care strongly about that, if you are against it fine then repeated frame == (keyframe && binary identical to last), it means 1 compare pass more for the demuxer if it wants to discard them (like when storing a network stream on reliable media)
3. convert_ts overflow Uhhh... 120 years otta be enough for everybody.
agree, we can fix that in 100 years ... [...]
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 :) [...] -- Michael ----- End forwarded message ----- -- Michael