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