Hi On Fri, Mar 03, 2006 at 01:11:50PM +0200, Oded Shimon wrote:
On Fri, Mar 03, 2006 at 12:30:22AM +0100, Michael Niedermayer wrote:
On Thu, Mar 02, 2006 at 05:16:23PM -0500, Rich Felker wrote:
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, ...)
I could just as well ask - what does the user/developer GAIN from there being an upper bound?
yes you can and should ask, it makes it much harder to generate broken files
yes, if there is no upper bound you can make a broken file, but you can ALWAYS make a broken/inefficient file if you are being deliberately ignorant...
master we have 2 issues, lets call them A and B without fixing A the user can make a broken file without fixing B the user can make a broken file too now fixing A is a bad idea as the user still can ALWAYS make a broken/ inefficient file if he is deliberately ignorant (by using B) now fixing B is a bad idea as the user still can ALWAYS make a broken/ inefficient file if he is deliberately ignorant (by using A) so what do we do, yes we fix neither i like your arguments, they are amusing
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, ...)
To this same sentiment, I ask, what is gained from your new index system? You never replied to my rant.. Yes you did make it optional which makes it
error robustness and easier muxing for muxers which are not based on libnut
somewhat nicer, I am still annoyed by the index_ptr and the additional demuxer complexity for this index system (reallocing the syncpoint cache for each index chunk, reading several chunks...), mostly because I see
you need that for dynamic index building too if theres no index at all, and iam not against adding a syncpoint_count field which would provide you with the number of syncpoints in the whole index
absoloutely no gain. There's a pretty damn good chance that if the index is borked, the entire index is borked. not just a small piece of it. And the file still plays perfectly fine without the index... ("it will make <extreemly rare use case> slightly slower" ...)
its not slightly, and its not rare IMHO [...] -- Michael