-----BEGIN PGP SIGNED MESSAGE-----
Anders Lind wrote:
> Hi Kevin
> After some time where I got irritated changing the buffer setting for
> content for sometimes small bit-rates and other times large bit-rates.
> I was changing this setting because I did not want to spend ages for the
> playback to start.
> So instead of figuring the "right" buffer size I was wondering if it
> would be a good idea to change the concept of how to buffer the content
> so it is done automatically so the default setting fits for a 32 kbit/s
> audio stream or a 500 kbit/s video+audio stream.
> Is it correct that the plug-in currently does the following?:
> Buffers x amount of the content
> minimum y percent of the content
> My suggestion is that if it is possible for the plug-in to detect the
> bit-rate of the content then it should load z amounts of bit-rate frames
> before it starts playing. Of course if there is video and audio then it
> should be the sum of the video and audio bit-rates that is afterwards
> multiplied by this factor setting of bit-rate frames.
> In addition if the plug-in detects it should re-buffer within a "short"
> period of time (or just needs to re-buffer) it should then automatically
> add one, two or more frames to the current default setting so it wont
> have to re-buffer in the future.
> The user should then only have to be able to change the "default
> multiple of bit-rate frames to buffer before play" in case the default
> setting somehow does not suffice.
> Changing the behaviour of the plug-in to this would give us three
> 1) We would get faster load times generally.
> 2) We would not have to change the default setting at all or very seldom
> because the content cannot play because of a too small buffer size.
> 3) We will not hear from users that cannot play back content just
> because they did not know that they should increase the size of the
> buffer to play back some e.g. video content.
> I remember we got some posts where the answer to the problems was to
> increase the buffer size.
> I state that we should generally be able to presume that the content
> providers of live content can deliver content with the speed that they
> provide "content in kbit/s". But I may be wrong :-)
> But if the presumption is correct we should be able to assume that the
> amount of bit-rate frames to buffer can be very small like 2 - 4 frames.
> I hope my suggestion makes sense and if so I hope it is possible to
> Best regards
> Anders Lind
Well, we don't really know the data rate until we start playing... Maybe
500KB could be downloaded and then an mplayer -identify -v could be
done and then that parsed and then the buffer size could be adjusted up
or down... Still think there are lots of hard issues here.
Got a patch? ;)
Get my public GnuPG key from
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----