On Wed, Feb 06, 2008 at 07:22:14PM +0100, Michael Niedermayer wrote:
On Wed, Feb 06, 2008 at 12:43:21PM -0500, Rich Felker wrote:
On Wed, Feb 06, 2008 at 12:40:53PM -0500, Rich Felker wrote:
Also this would only solve ONE single problem brought up. Your design still leaves the preload time up to pure luck.
If you really need to know a minimum preload time, put it in a protocol header or in the spec for the broadcast constraints.
An info packet field for bitrate information, including minimum preload, would be totally acceptable too if you like.
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. 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. Years and years ago, when talking about AVI and its audio preload feature, I thought we agreed to ignore highly device-dependent buffering details in the interest of making a container that is clean and simple. If there's a need to know the amount of preload required for streaming, a single global value in an info packet should be sufficient. IIRC info is still allowed to change mid-stream too (or was that removed?) -- if so one could hypothetically even intersperse variable preload recommendations but I really doubt the usefulness of doing so. Rich