
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

On Sun, Feb 12, 2006 at 12:51:51AM +0100, Michael Niedermayer 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 :)
I'm against this. The reason being that it requires the demuxer to put the packet in writable memory, possibly copying it. Imagine the case of demuxing directly from mmapped buffer, where the codec directly reads the same memory that the demuxer module was using, which is in turn shared with the kernel's filesystem buffers. Such an arrangement offers huge performance benefits for very-high-bitrate streams due to reduced cache thrashing. NUT should not do ugly hacks that preclude such performance optimizations just for the sake of saving a few bytes of overhead. Rich P.S. Yes I know mmap may be slow in default setup due to page faults, but if you either force those page faults to happen in advance or use madvise() the problem goes away.
participants (2)
-
Michael Niedermayer
-
Rich Felker