1

Closed

multicast stream does not display even though multicast packets are recieved

description

Pulling a unicast URL in the sample player works (packets are received, stream is displayed)
Pulling multicast from the same subnet works (packets are received, stream is displayed)
Pulling multicast from outside the client subnet fails. Although multicast packets are received, nothing is displayed and the player hangs at 100% buffered.
A packet sniff confirms the IGMP join and multicast packets being received, but the player fails.
WMP will play the multicast stream
 
This is the case on multiple machines and with Silverlight 2 and 3 beta.

file attachments

Closed Jun 12, 2009 at 11:57 PM by mpoindexter
Resolved in RC-3

comments

mpoindexter wrote May 21, 2009 at 10:30 PM

Does the player buffer or just go straight to 100%? You can see the buffer level at the bottom of the screen.

wrote May 21, 2009 at 10:32 PM

wayne_waterman wrote May 21, 2009 at 11:25 PM

The player does buffer, up to 1 (which given the preceeding numbers and the functional streams I assume means 100%), and multicast packets continue to be received as measured by wireshark.
attached is a screen shot

wrote May 21, 2009 at 11:25 PM

mpoindexter wrote May 22, 2009 at 1:01 AM

Is the file being streamed a live source or a file? If it is a file I suspect this is something we have found in our QA. Basically what happens is that ASF files do not always have buffering information included, so we apply a heuristic to determine the appropriate amount of buffering to do when the ASF doesn't specify. In some cases, due to a bug in the heuristic, we would end up allocating a much too large audio buffer. In this case, the buffer progress will show up as 100% since we report the buffer progress as the progress of the video stream buffer, but we're waiting on the audio to finish buffering. This is already fixed in the code locally, we should be doing another build Monday or Tuesday that should include the fix. If you want to test out the fix sooner, I have attached a new version of Starlight.ASF.dll. Place the file in the folder where you extracted the StarlightPlayer.zip in Bin\Release, overwriting the previous copy.

wrote May 22, 2009 at 1:01 AM

wayne_waterman wrote May 22, 2009 at 8:17 PM

I had tried with both encoder sourced, push broadcast and server side file playlist. The encoder sourced stream never worked. Your explination does explain why, after sending the initial bug comment that I found the file source working. I have 5 items in the playlist, one of which works.
Swapping the Starlight.ASF.dll did not measurably alter the behavior.

mpoindexter wrote May 22, 2009 at 8:37 PM

Interesting. In the next release I will add a way for the debug log to be dumped to the page so we can capture the buffering params that end up being used, and hopefully get some more information. Thanks for all the effort trying to troubleshoot this!

mpoindexter wrote May 22, 2009 at 8:40 PM

If the video file that does not work doesn't contain anything non-public, it would be quite helpful if you could post the video so we can attempt to reproduce the behavior you are seeing locally. If you can't post it, no big deal.

mpoindexter wrote May 26, 2009 at 8:44 PM

A new release has been uploaded that should provide more debug information. You can see the extra debug info by scrolling down on the player page. If you could try with the new build and attach the debug output to this bug if the issue is still occurring that would be quite helpful. Thanks!

wayne_waterman wrote May 26, 2009 at 10:18 PM

Replaced all the Sample Player component on the web head, unreged the MulticastProxyActiveX.dll and re-reged the new one.
Same behavior. debug information attached.
I am also go to try ripping out the audio portion of the files I am working with, see if the behavior remains consistant and if it does post the files for you to look at. I'm afraid the audio component would classify as confidential.

wayne_waterman wrote May 26, 2009 at 10:18 PM

and now with the file attached

wrote May 26, 2009 at 10:18 PM

wayne_waterman wrote May 26, 2009 at 10:53 PM

I'm afraid things get unhappier with encoder source instead of file source.
In both a pull and a push scenario, buffering begins, never gets very high, and within about 60 seconds IE is taking 50% cpu and is unresponsive.
Attached is the debug information for both the pull and the push at a point where I could still copy the inoformation. Would there be an easy way for me to port the debug information to a txt file?

wrote May 26, 2009 at 10:53 PM

wayne_waterman wrote May 26, 2009 at 10:53 PM

and push

wrote May 26, 2009 at 10:53 PM

wrote May 26, 2009 at 11:45 PM

wrote May 26, 2009 at 11:45 PM

mpoindexter wrote May 26, 2009 at 11:52 PM

Excellent, the debug logs have pinpointed an issue. Unfortunately, the Silverlight MediaElement does not allow us to report script events in the stream, so we had not tested with any streams containing script events. We do parse out the script streams (due to early development where we were attempting to report the script events), and actually ended up trying to buffer them as well. I have attached a new version of Starlight.ASF.dll which corrects this behavior, can you give it a whirl and see if that fixes the issue with the VOD files hanging? In addition, if you could upload your wme file you are using for the live sources, I will attempt to replicate the problems you are seeing there as well. We have tested a good bit with live streams, so I think this will be a quick fix.

wrote May 26, 2009 at 11:52 PM

mpoindexter wrote May 27, 2009 at 12:02 AM

Unfortunately, I don't think it will be possible to write the debug information to a file. We're logging the debug info in managed code, and we don't have access to the filesystem due to security restrictions in the Silverlight runtime.

wayne_waterman wrote May 27, 2009 at 7:10 PM

The script issue is the source of the issue. The new Starlight.asf.dll does not correct the issue, but when I remove the script source from the stream everything plays just fine.
The current behavior is that the stream will buffer to 99n% then after a time it will return a "Buffer too large( 5.1709), resetting stream." message which repeats every so often. This is true for both file source multicast and encoder source multicast. Attached is the debug of that behavior.

wrote May 27, 2009 at 7:10 PM

wayne_waterman wrote May 27, 2009 at 7:11 PM

This is the WME used for the encoder source

wrote May 27, 2009 at 7:11 PM

mpoindexter wrote May 27, 2009 at 8:10 PM

I guess the DLL isn't being picked up. The debug log still shows the old behavior. I will do a new full build tomorrow with the fixes. I tested with your WME, and the stream played fine with the fixes in place.

wayne_waterman wrote May 27, 2009 at 10:04 PM

When you were testing with the WME, was the player on the same subnet as the multicast source? It was functional in that condition for myself as well. It is when the multicast stream has to hop a router that things go pear shaped.

mpoindexter wrote May 28, 2009 at 11:04 PM

I have tested using a streaming server on a different subnet that passes through a router, and the stream plays. Release 1.0-RC3 has been uploaded.

mpoindexter wrote Jun 8, 2009 at 6:08 PM

Did the new release have any impact on this?

wayne_waterman wrote Jun 11, 2009 at 4:47 PM

My apologies for the delay. Work got in the way of play. Yes as a matter of fact the new release resolved the issue of streams with scripts and I am now watching a multicast stream over silverlight. Hazahh.
Next step is to have the player actually pass those scripts.

mpoindexter wrote Jun 12, 2009 at 11:57 PM

Excellent, I will close this issue. As far as script events go the problem is that the Silverlight MediaStreamSource interfaces do not allow us to report the script events. I had hoped this would be resolved in Silverlight 3, but looking at the beta docs it seems this restriction is still in place. Bummer.

wrote Jun 12, 2009 at 11:57 PM

wrote Feb 13, 2013 at 10:24 PM

wrote May 16, 2013 at 1:46 AM