MMS streaming to MS MediaElement display delay issue sovled

[SteveO]

Dear Forum,

Well I have asked for help quite a few times so I thought I should sure post a solution to a problem I believe I have found which may be helpful to others. I have been sending streams from VLC using the Mms protocol to Microsoft Silverlight MediaElement. One key difference between what I was trying to do and what most of the information available on the wed addresses is that I was using VLC to accept a live UDP stream which would then be transcoded and rebroadcast, while most applications it seems are using a fixed file for input. In any event, "live re-streaming" was often successful, but also struggled with a problem of often the MediaElement taking some time to start displaying the stream. It seemed some sort of timeouts were at play as frequently when the signal did play it seemed to do so after a set of times - usually 15, 30, 60, 90 and 120 seconds. I finally was able to isolate out intermittent behaviors giving me two perfect test cases where one always worked and the other always did not. I then saved the sent Mms stream to file to analyze the contents. I also finally found an Asf container viewer program with sufficient detail to allow me to search for differences between the capture of the stream that did and the stream that did not work. This program is "Windows Media ASF View 9 Series " developed by Microsoft and which is freeware. As indicated I compared the contents of these two files and cross-referenced contents with the Asf specification which Microsoft made available in 2010. The problem turned out to be....

The problem turned out to be the values VLC placed in the "Flags" (software) register in the Asf File Properties Object. The first bit in that flag register is the "Broadcast" flag and the second is the "Seekable" flag. Streams that played immediately had a value of 0x01 binary for these flags while for streams that would not play immediately had a value of 0x10 binary. Seems some combination of the encoder parameters, input signal format and input signal starting point would cause differences in how these flags were set. I simply implemented the quick software fix of always setting these flags correctly and acheived consistently correct behavior.

Enjoy!

[Jean-Baptiste Kempf]

Why not provide a VLC patch?

[SteveO]

Can do.... my fix was sort of a hard wire job however - I will take another look and if that is the best I can do I will just comment accordingly...

)

[Jean-Baptiste Kempf]

We are here to help.