[NUT-devel] CVS: main/DOCS/tech mpcf.txt,1.117,1.118

[Rich Felker]

On Thu, Mar 02, 2006 at 05:16:23PM -0500, Rich Felker wrote:
> > are you drunk? if all frames are 5megs then max_distance==5mb will give
> > you exactly the same file as any smaller max_distance, now if max_distance is
> 
> It's not about size or overhead, but usefulness. Distance between
> syncpoints being > max_distance should be a special case, not the
> general case. The demuxer implementation in principle has to do more
> to check for validity in this case. Maybe all that can be eliminated
> and it's not such a big deal, but I'm still against putting particular

To clarify: if it turns out that there's no demuxer issues with
max_distance being significantly smaller than all frames, I'm sorry
for making an issue out of this. If that's the case maybe we can make
a rule that max_distance cannot be larger than some fixed upper limit,
but IMO we should still leave it vlc-coded in case there's a need to
support larger max_distance in NUT 2.0 or something (way in the
future).

> > my proposed header compression, which has negligible complexity would reduce
> > the overhead by ~1% and was rejected based on nonexistant kernel and demuxer
> > architectures
> 
> Scratch kernel; the kernel architecture for it already exists. It's in
> POSIX and called posix_madvise. There is no demuxer to do zerocopy
> demuxing, but in the case where decoded frames fit in L2 cache easily,
> but the compressed frame is very large (i.e. high quality, high
> bitrate files -- the very ones where performance is a problem)
> zerocopy will make a significant improvement to performance.
> Sacrificing this to remove 1% codec overhead in crappy codecs is not a
> good tradeoff IMO. It would be easier to just make "MN custom MPEG4"
> codec that doesn't have the wasted bytes to begin with...

One other thing with this that I forgot to mention: it would be
possible to support zerocopy for non-"header-compressed" files even if
header compression were supported. My reason for not wanting to have
this option was that it forces any demuxer with zerocopy support to
also have a duplicate demuxing system for the other case. If this can
be shown not to be a problem (i.e. a trivial way to support both
without significant additional code or slowdown) I'm not entirely
opposed to the idea.

Rich