[I wrote this earlier but had to leave for work so I didn't finish sending. Hope there's nothing newer that renders parts of the message redundant already.] On Wed, Feb 06, 2008 at 08:23:08PM +0100, Michael Niedermayer wrote:
The preload changes depending on buffer fullness thus is not constant over a stream.
Is this your whole point? You could have said that a long time ago and saved us a lot of trouble. I think it's entirely unrealistic that someone concerned with low-latency broadcast would have non-constant preload requirements.
Constant preload is pretty much the same as saying constant sized frames. That is much stricter than CBR. You want to limit nut to that? For this i guess the current design is sufficient.
There are two perspectives on preload. One is asking the question: "For this data, what is the minimum amount I can get away with preloading?" This is a very concrete property of the data to be broadcast, and like you say, it varies. The other perspective is a requirements perspective, e.g. "I want receivers to be able to tune in to my stream and watch it with a maximum preload delay of 0.2 sec." In this case it does not matter whether the minimum preload required (in the former sense) fluctuates between 0.001 sec and 0.2 sec. All that matters is that the maximum minimum preload required is bounded by 0.2.
Or, said differently, if the sender's requirement is that the preload be less than 0.1 second, it should not matter to them whether the receiver is able to get by with only 0.03 seconds of preload when seeking to certain points in the stream. Constraints like these are about worst-case.
well, if the decoder preloads X seconds while needing only 0 seconds then it will need X "seconds" more buffer space. -> this effectively doubles the needed buffer space.
If instead of "how many seconds to preload" you knew some different buffer information, I think the problem would go away. I need to think about it more though and I don't want to give the impression of giving hasty answers since I've been accused of that already. :(
Years and years ago, when talking about AVI and its audio preload feature,
avi audio preload is stupid.
Something we still agree on at least..
-- if so one could hypothetically even intersperse variable preload recommendations but I really doubt the usefulness of doing so.
I guess the spec contains a few rules by now forbidding putting info anywhere except after the stream headers (which at least contain the huge vorbis headers).
Like I just said, repeating the headers frequently is already required if you're doing broadcast... Maybe this makes NUT sufficiently unappealing for broadcast that the whole discussion can be dropped, but for better or worse, I doubt that will happen. Rich