if the stream recovers when publishing with FMLE but does not recover when publishing with Flash Player, then it seems like there might be a bug in Flash Player. it appears you have opened a bug on this issue with Flash Player already.
does this problem occur with other (previous) versions of Flash Player?
is the stream bad when you try to view it with unicast, over RTMP? or is it only a problem in multicast?
does this problem occur if you publish the stream to FMS over RTMFP unicast instead of RTMP unicast?
Michael,FMLE OK, but flash have this problem, and it seems to be the problem of flash, but the traditional RTMP unicast without the problem, it seems is multicast problems, I really don't know what the reason is, what should I do?
what is the key frame interval on your Flash Player encoder? is it more than a few seconds?
have you changed any of the multicast stream parameters (window duration, relay margin, etc), or left them all default?
if you don't have the bandwidth problem when doing multicast (that is, everything running OK), can a new client join the multicast after it has started and start seeing the stream? or can only clients that were already joined to the group and subscribed to the stream *before* publish see the stream?
does the stream recover if you unpublish and republish, with no other changes on the server, and all subscribers still subscribed?
Happy Thanksgiving Michael，My question how to solve?
the only other diagnostic question i can think to ask is:
1) after things go bad on the multicast, will a new subscriber to the multicast stream start seeing the same bad picture as the other existing subscribers see, and that never recovers (like the existing subscribers)? or does a new subscriber to the multicast start seeing a good picture while existing subscribers see a corrupted picture that never recovers?
2) if you have a unicast subscribe/play of the stream going from before the publisher loses bandwidth, and then the publisher loses bandwidth according to your tests, and then the publisher recovers bandwidth: does the unicast subscribe/play recover to good quality while the multicast stays bad, or do they both go bad and stay bad?
given your tests as described so far, it seems like the most likely explanation that fits is that there's some kind of bug in the FMS multicast publish somehow, that is exercised when the publisher is Flash Player but not when it is FMLE.
1.new subscriber is also bad picture and audio
2.unicast will recover good,multicast is also bad
if this is Flash Player bug,but No relevant personnel confirmed that, if confirmed, and that the next version of repair, but does not seem to have any response, this is I worry about
#1 suggests the problem is in the publish end, not the playback end, and that furthermore the publish is somehow permanently disrupted, rather than perhaps an errant message ending up in the multicast stream that just confuses the playback side (otherwise a new joiner wouldn't have a corrupted stream).
#2 suggests that the problem is with the FMS multicast publish and not with the Flash Player's publish of the stream to the server. since the unicast is good, good data must be coming from the original Flash Player publisher.
i can't think of any good explanation for this behavior, especially when it works OK with FMLE under the same conditions.
here are two more diagnostic tests to try. note that if these make a difference, they are NOT proper solutions, but they might help determine what the real problem is.
3) FMLE might buffer up all stream data during bad network periods, then send it all along to the server when the network gets better. so with FMLE there might not be any dropped frames or time discontinuities, whereas Flash Player might drop frames when its transmission queue gets clogged up. i am pretty sure that setting the NetStream.bufferTime on the Flash Player publishing NetStream to a non-zero value (especially a value larger than the amount of time your test network interruption lasts) should cause no data to be discarded. if you set the FP publisher's NetStream.bufferTime to a large number, does the multicast corruption still persist after a period of bad network?
4) perhaps something funny is happening with the multicast fragment scheduling after an interruption and timeline jump, causing the fragments to almost immediately expire out of the window and so for most of them to not have an opportunity to propagate. what happens if you change the FMS's multicast stream's multicastWindowDuration to be at least 8 seconds longer than the duration of your bad network condition?
one more thing: in the ActionScript code you published before, on the Flash Player side, it looks like you're saying ns.publish("livestream", "live");. what happens if you take out that second "live" parameter and just use ns.publish("livestream")?
I set publisher's NetStream.bufferTime=1000 and multicast stream's multicastWindowDuration=200 also this problem. remove Live
Once it has the problem, FMS 4.0 and 4.5 will video quality variation, audio off and on.
in fms4.5.4,the sound will Don't make any audio.
Michael,This is why, whether flash bugs?
as i said previously, the results of the tests 1 and 2 indicate a bug in FMS. the other tests i suggested might have helped narrow down where the problem was (if they had made any difference). since they made no difference, i still have no idea what could be causing the problem. however, given the other results, it still seems that it is a bug in FMS.
your best course of action, if you have not already done so, is to file a bug report against FMS.
does this problem occur in the most recent version of Adobe Media Server (AMS 5.x?)
if you are using the developer/starter version of FMS/AMS, note that multicast streams will only run for 10 minutes.
Your issue has been received in our database and we will look into it.
The problem how long can I return? I have already finished the project, if the current must use FMLE, does not support FLASH publish, also please tell me. thank you
What you said is not clear. Can you please rephrase?