On Wed, Feb 06, 2008 at 01:36:56PM -0500, Rich Felker wrote:
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.
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.
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.
Years and years ago, when talking about AVI and its audio preload feature,
avi audio preload is stupid.
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.
the transmit_ts are a better choice, also if you seriously want device indpendance. It might be possible to specify the minimum needed preload vs bandwidth curve somehow on each syncpoint. This would not add any dependance on the actually used bitrate or buffers. But allow a demuxer (which approximately knows the bandwidth) to choose the ideal preload, or even download the whole file if the bandwidth is too low. It also might be possible to synchronize the clocks based on such preload/bandwidth data.
IIRC info is still allowed to change mid-stream too (or was that removed?)
Removed after your flames IIRC. Its also a point which will cause problems as soon as anyone wants to use info for anything realtime.
-- 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). I stoped counting, the how manyth case is this where your strict info design causes problems? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable