[NUT-devel] Welcome...

Rich Felker dalias at aerifal.cx
Sun Feb 12 23:35:54 CET 2006


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.




More information about the NUT-devel mailing list