Hi On Thu, Mar 02, 2006 at 05:16:23PM -0500, Rich Felker wrote: [...]
sorry but i wont continue these disscussions, expect me to fork if this continues, proposals should be judged on their effects (like overhead, complexity, error robustness, amount of memory or computations or delay , ...) but not on philosophical ones, nonexisting codecs, nonexisting demuxer architectures, nonexisiting kernels and so on
Michael, please have some patience. When you spring a bunch of new things on us all the sudden, there will be resistence, just like when our roles were reversed with the per-stream back_ptr/pts stuff. Forking and ignoring the concerns of the other people involved is possible but it does much less to improve the overall design. At that time I was adamantly against calling a vote (even though I probably could have 'won' the vote, as you said) or doing other things to polarize the situation. This has always been about making NUT as good as possible, not about people's personal egos, and where my ideas have turned out to be bad I've abandoned them. I hope we can reasonably discuss the remaining issues you've raised and reach a consensus on what the best design is rather than flaming and forking and such.
you ask someone else to stop flaming? ;)
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...
this reminds me of my little mpeg1 experiment, replacing the entropy coder with an ac coder gave ~10% lower bitrate ...
so either 0.0003815% is significnat that my header compression will go into the spec or arbirary sized max_distance leaves it, choose, but stop to change the rules for each thing depening upon if you like it or not
My objection to upper bound on max_distance had nothing to do with size. I'm sorry I wasn't clear.
and what is the terrible thing which will/could happen if there where an upper limit? i mean from the user or developer perspecitve (complexity, speed, overhead, ...) not the idealist/philosopher perspective (its wrong, bad design, this is like <infamous container> does it, it will make <extreemly rare use case> slightly slower, ...) [...] -- Michael