I have implemented a frame accurate video player with smooth streaming. When I click a button you can advance one or 5 frames. This works fine on reasonable speed networks, but we noticed unexpected slowness on slower networks. When I used wireshark to track
packet requests from the server, I noticed no matter how small the increment,
when you assign mediaElement.Position a very large sequence (4 Mb) of packets are requested from the server. I think this is a bug. I would expect the buffering pipeline to find that it already had the correct chunk available and not request a ton
of blocks from the server regardless of the current position.
I have experimented with BufferingTime value and have used the caching example to try and solve or analyze the problem.http://msdn.microsoft.com/en-us/library/gg296362%28v=VS.90%29.aspx
The caching example has no mechanism for dealing when the available space is full.
if (((CacheResponse)(((CacheAsyncResult)ar).Result)).Response.Length < isoFileArea.AvailableFreeSpace)
{
...
}
No else statement
When I tried to implement something to clear files from the cache, the behavior became even more unpridictable, so it would be helpfull if there was documentation on how the buffering works in conjunction with the cache. Or an example of exactly how to delete
files relating to the oldest chunks of video data.
Caching worked with respect to avoiding requests to the server if it was a small clip and fit entirely in the cache. It was hard to clear correctly and I could not find the secrets to using the cache to store an amount of data around the current playback
position.
meprospero
3 Posts
BUG: Small increment in SmoothStreamingMediaElement.Position should use buffered data
Nov 20, 2012 04:57 PM|LINK
I have implemented a frame accurate video player with smooth streaming. When I click a button you can advance one or 5 frames. This works fine on reasonable speed networks, but we noticed unexpected slowness on slower networks. When I used wireshark to track packet requests from the server, I noticed no matter how small the increment, when you assign mediaElement.Position a very large sequence (4 Mb) of packets are requested from the server. I think this is a bug. I would expect the buffering pipeline to find that it already had the correct chunk available and not request a ton of blocks from the server regardless of the current position.
I have experimented with BufferingTime value and have used the caching example to try and solve or analyze the problem.http://msdn.microsoft.com/en-us/library/gg296362%28v=VS.90%29.aspx The caching example has no mechanism for dealing when the available space is full.
if (((CacheResponse)(((CacheAsyncResult)ar).Result)).Response.Length < isoFileArea.AvailableFreeSpace)
{
...
}
No else statement
When I tried to implement something to clear files from the cache, the behavior became even more unpridictable, so it would be helpfull if there was documentation on how the buffering works in conjunction with the cache. Or an example of exactly how to delete files relating to the oldest chunks of video data.
Caching worked with respect to avoiding requests to the server if it was a small clip and fit entirely in the cache. It was hard to clear correctly and I could not find the secrets to using the cache to store an amount of data around the current playback position.