The container is very efficiently seek-able over the network, in fact. But your implementation must be sufficiently intelligent.
Here are some benchmarks from the opusfile library, On a 25 hour long variable bitrate audio recording performing 1000 jumps to exact sample positions with no caching:
Total seek operations: 1873 (1.873 per exact seek, 4 maximum).
So an average of less than two operations, and in the worst case 4-- meaning even with a 100ms RTT a worse case seek will not cause a noticeable delay. (and obviously, if it cached, it would be much better).
I am not an expert on streaming media and have just begun my research, but it seems to me that your quoted benchmark is assuming many seeks will be done on the stream. But there are cases where the user wants to only skip once or twice into a song as they are sampling the music for the first time, which is my use case. For that case, the lack of an index is afaics horrific because there will be the latency of some roundtrips required to optimally locate the seek position (by a bisection sampling method) and wasted bandwidth as well.
There are
many complaints about the lack of an index found on Google search. In particular I note the "Random Access" section of a
list of complaints about the Ogg container design.
And this requires no indexes which require the file be written in multiple passes or that it only be seekable when it's "finished"-- a live stream is seekable while it's being recorded.
You apparently assume your container is only going to be used for live streams.
So you are saying Ogg is not designed as an optimal archive format. You could have instead made the index optional.
I think the seeking performance, given a good seeking implementation, is pretty good, and it's often more efficient than other less flexible containers even when they have indexes-- because to keep their indexes reasonably sized they're not high resolution-- and getting them requires seeking to the end or a rewrite of the file. To the extent that an average near 2 is less good than 1 might be with a perfect index, that is a cost for the streaming functionality, and I think a reasonable one.
Hey the resolution could be a configurable parameter so programmers can decide the tradeoff that is ideal for their application. Since when should you decide for them.
I didn't design the container, but if I did-- I might have only added an additional back-reference or two at each page; I wouldn't change how seeking works.
Seems you are excluding use cases.
I am getting the idea now after several times interacting with you, that you are clearly better at math than I am but I am better designer than you. You seem to pigeon-hole often. Perhaps it is the heads-down quality that is required to have the patience to learn all that math?
I recognize your intellect and attention to detail, but you seem to also be inflexible which is not the trait of the best software designers I've known in my life. I am guessing that
maybe you are strongly German cultured and need everything neatly ordered in your own space. Note I have some German ancestry (and it shows sometimes in my perfectionism at times), but I also am a mix breed of French, Celtic, and Cherokee native. I think this makes me more creative/flexible than you. Not that I often think about comparing ourselves, just at
times like this where you disrespect others (and then somehow expect they would respect you
).
Perhaps you were not intending to disrespect me in this case, but I think the past track record (see link above) is what leads to this tension which is ready to blow at any time. Also I holding you to a higher standard w.r.t. to this crap that you seem to be foisting with Segregated Witness, because you hold everyone else to such a higher standard and even threatening them of being scammers without sufficient proof (again see my link above). Perhaps I should realize this is just the German trait and brush it off my shoulder. I think the less we interact the better. Thanks for the reply and I wish your orderly orderness didn't rub me the wrong way. Sorry I am about as compatible with a German as I am with shooting myself in the head. I love freedom which means stop stomping on others. I am a sheepdog which means I will fight those who I perceive are oppressing freedom of expression. Hey I understand what it is like to deal with trolls and in that case I would support the swift action since trolls only aim to disrupt, but I wasn't trolling you.
Tim hasn't really had anything to do with Rust-- I had some infinitesimally small influence on the language (lobbied successfully for overflow of ordinary signed types to be defined as an error). Rust has some nice properties for cryptocurrency infrastructure: in particular it has no overhead, deterministic operation, with high levels of safety enforced at compile time. These things matter for decentralized cryptocurrency, since speed is also a security consideration.
I know I read something about Rust and one of your two names mentioned, but I forgot the specifics and couldn't locate it again readily with a Google search (at least not on Tim's name).
Okay I could understand the incomplete typing of Rust (as compared to say for example Haskell or Scala) would not be the priority when wanting to get as close as possible to the metal while having some higher level functionality not provided by C.
Any way, as I said, the specifics of my former criticisms have been mostly forgotten by myself. I would need to refresh my memory. I think the flaw was w.r.t. to declaring the invariants for class members in the class methods if I am not mistaken (but that is very vague so I might be recollecting incorrectly).