Thanks. However, the existing code is not really a 'bug', although
your suggested change is (arguably) an improvement.
As you noticed, the current per-transport-packet duration estimation
code has trouble converging on a stable estimate for streams - such
as yours - that are wildly VBR. Your suggested change will probably
help things (although I can also imagine streams for which it might
make things worse by taking longer to converge to the 'correct'
average duration). I am also a bit concerned about the arbitrariness
of the constant "20" that you use.
Nonetheless, I'll add your change to the next release of the library.
(Looking longer-term, a better solution for streaming prerecorded
files (but not live streams) will be to extend the existing "index
file" mechanism to include accurate durations - which could be
computed in advance when generating the index file.)
Ross Finlayson
Live Networks, Inc. (LIVE555.COM)
<http://www.live555.com/>
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
