[NUT-devel] Welcome...

[Michael Niedermayer]

Hi

someone needs cola ...
Reply-To: nut-devel-request at mplayerhq.hu 


----- Forwarded message from Michael Niedermayer <michaelni at gmx.at> -----

Date: Sun, 12 Feb 2006 00:42:47 +0100
From: Michael Niedermayer <michaelni at gmx.at>
To: nut-devel-request at mplayerhq.hu
Subject: Re: [NUT-devel] Welcome...
Message-ID: <20060211234247.GT3210 at MichaelsNB>
References: <20060211194141.GQ6600 at crate15>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060211194141.GQ6600 at 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