I'm no developer, therefore, I don't know what data is available to the mplayerplug-in.
I assume though, that at least some network streams contain information about the total length of the stream (if the stream is finite).
The second input to my feature is the current download rate.
And, finally, the third input is the average audio/video rate of the stream.
If the average audio/video rate is greater than the current download rate, the plugin is able to determine (assuming that the download rate stays the same), how much data needs to be pre-buffered before it's likely that the stream will play until the end without any interruption due lack of data. An absolute safety margin for that buffer due to jitter in download rates could be introduced.
If the average audio/video rate is smaller than the current download rate, the stream can start playing instantly with the smallest possible buffer.
This feature would provide the best responsiveness versus the least annoyance (due to stutters) on finite streams.