Hi,
Now I am trying to achieve the rtmp dynamic streaming with origin/edge configuration.
I am in trouble as to the behavior of the mediacaster on the edge.
The rough configuration is as follows.
FMLE—>origin(liverepeater-origin)—>edge(liverepeater-edge)—>client
The scenario is as follows.
-
publish the multi-bitrate streams (e.g. 1.stream/2.stream/3.stream) from FMLE 3.2 to the origin.
-
the client connects to the edge and calls FCSubscribe for all the renditions (1.stream/2.stream/3.stream).
-
the mediacaster on the edge starts to pull the streams (three streams) from the origin (StreamNameAlias directs the corresponding streams on the origin).
-
the client calls play a stream (e.g. 3.stream).
-
the client switches the stream to another rendition (e.g. 1.stream).
-
the client (user) stops the stream and close the netstream (1.stream).
-
the edge destroys the stream (1.stream) and closes the session.
-
after a while (one minute or so), mediacaster resets the connections (established at 3 above) only for 1.stream and 2.stream (NOT FOR 3.stream).
-
eventually, the mediacaster on the edge continues to pull 3.stream although no client is connected to that stream.
-
after a few hours, when the client connects to the edge and starts playing (in the same way as 2~4 above), it CAN play the first rendition (e.g. 3.stream).
-
but, when it tries to switch to another rendition (e.g. 1.stream) (in the same way as 5 above), no data is sent from the edge to the client (client is fallen into buffering state and never get back) although all the streams have reached the edge and the edge receives the switch request from the client.
-
this situation (11 above) continues until the application on the edge or the stream (3.stream) is manually reset by JConsole or something.
What I confirmed is as follows.
-
this happens in case of another type of mediacaster (not only liverepeater but also rtp receiving the ts/udp streams)
-
this does not happen if the stream destroyed is identical to the stream played.
-
this does not happen if all the streams are being pulled all the time (by using the StartupStreams.xml or stream manager) regardless of the activities of the client.
-
this happens both in wowza 2.2.3 subscription and 2.2.4.07 development environments.
Is there any way (or workaround) to avoid this behavior of the mediacaster WITHOUT using StartupStreams.xml, stream manager or MediaCaster API?
(for example, all the streams are reset automatically when no client is connected, or the edge keeps pulling all the streams after first FCSubscribe calls even if no client is connected)
Any clue would be appreciated.
Regards
catalog
Hi
This appears to be a bug and I’m sure it will be tested and fixed in due time,
What do your Wowza logs say when this happens??, This may give a clue to solving the problem.
You could try getting rid of : “Stream Alias part” as there may be a conflict of some description.
I would also suggest that try upgrading to wowza 3 as there is a possibility that this may not happen in that environment, but I can’t be sure.
Testing in a Wowza 3 development environment is a safe bet as you have nothing to lose and it could potentially fix this issue.
Jason
For RTMP Dynamic streaming from an edge, it is important for the client to call FCSubscribe(streamName) for each stream in the set. This is built-in to JW Player when using their implementation by adding the Flashvar “rtmp.subscribe=true”
If you have a custom player, you want to do this in the NetConnection NetStatusEvent handler after getting “NetConnection.Connect.Success” notification, before you do NetStream.play2
Richard
There is another approach that might make a difference: instead of FCSubscribe per session, start the smil on the edge in StreamManager with MediaCaster type “liverepeater”.
https://www.wowza.com/docs/how-to-set-up-adaptive-bitrate-streaming-using-mediastreamnamegroups-module
The guide says MediaCaster type “rtp”, but make it “liverepeater” in this case.
Richard
Catalog,
However, we realize that is not an ideal solution because of bandwidth considerations.
Can you package up and send something that we can run and replicate this, including a set of files and your player. Send to support@wowza.com.
Include details of your encoding process for these files. Did you use Expression 4? (we know that works right)
And include a link to this thread for reference.
Richard
Hold on, one more thing to try on your side. Set this Property in the origin Application.xml /Streams /Properties :
<Property>
<Name>sendOriginalTimecodes</Name>
<Value>true</Value>
<Type>Boolean</Type>
</Property>
Richard
Very similar situation here, is there any update on how this finally ended ?
Thank you all
Kind regards
Hi Richard,
Thank you so much for your advice and continued support indeed.
Regarding the MediaStreamNameGroups (smil+StreamManager):
I have already tested it and confirmed that the problem does not occur in this case because all the streams are being pulled (by the edge) all the time and the behavior of the mediacaster (start/shutdown/etc.) is not affected by the activity of the client (play/close/etc.).
(Actually, what I wanted to say by ‘3. this does not happen if all the streams are being pulled all the time (by using the StartupStreams.xml or stream manager) regardless of the activities of the client.’ in my first post is this. sorry for confusing.)
However, what I would like to achieve is the dynamic streaming with origin/edge configuration WITHOUT using the StreamManager/StartupStreams.xml/MediaCasterAPI.
Regarding sendOriginalTimecodes:
Yes, actually Application.xml of my origin always has this property set to true.
But the stream switching does not work (step 11) if an instance of the mediacaster sticks (step 8 and 9) and is left for a few hours.
Can you package up and send something that we can run and replicate this, including a set of files and your player. Send to support@wowza.com.
Thank you so much.
I will send the information (Applicaiton.xml, configuration of FMLE/jwplayer).
Regards
catalog
Hi
Your welcome for the advice and I’m sorry that it didn’t help your further,
I guess its now up to the Wowza support team.
Jason
Hi Jason,
Thank you so much for your advice.
As to the wowza logs,
At the INFO (set in the log4j.properties) level, there is no particular log that shows the error or the unusual event.
At the DEBUG level, I tried to find out something helpful to solve the problem, but I could not (possibly there might be something)…
As to stream name alias,
I tested tag in the Application.xml instead of stream name alias, and I confirmed that the situation is the same.
I wonder/suspect that the root cause of this problem is the behavior of the mediacaster that it does not shutdown/reset an instance in case the stream played is not explicitly closed from the client (step 8 in my scenario above).
My scenario above is 100% reproducible in my environments (and probably other, at least wowza 2, environments), so I wish this would be tested and fixed.
As to wowza 3,
Yes, I will surely test it once I will have a chance (maybe in the near future).
But I still wish wowza 2 would be updated to solve the problem.
Regards
catalog
Hi Richard,
Thank you for the message.
Actually the clients used in my tests implement the FCSubscribe call in the way you mentioned.
I have used two clients, jwplayer 5.7 with the flashvar ‘rtmp.subscribe’=true and the strobe media playback customized so that it calls FCSubscribe for all the streams listed in the f4m manifest before NetStream.play2, and confirmed (by the logs, :8086/connectioncounts) that all the streams reaches the edge.
(Please see the steps 2 and 3 in my scenario above.)
My concern here is rather the behavior of the mediacaster that it does not shutdown/reset an instance in case the stream played is not explicitly closed from the client IN SPITE OF the FCSubscribe call in advance.
Could you please check if this occurs in your environment, and if this is an intended behavior of the mediacaster (I do not think so…).
Your support is appreciated.
Regards
catalog
Hi Charlie,
Thank you for the message.
What I mean by ‘if this occurs in your environment’ is:
Could you please trace the steps 1~7 in my scenario above and check if the steps 8 and then 9 occurs in your environment.
You can do that by using the origin(liverepeater-origin)/edge(liverepeater-edge) applications, the appropriate configuration on the edge to pull the streams from the origin to edge (, stream name alias and the full rtmp url in .stream file should be ok), jwplayer with rtmp.subscrube=true (or other player you like that calls FCSubscribe for all the streams) and the FMLE (any other encoder should be ok if it can publish the multi-bitrate streams to the origin).
What I mean by ‘if this is an intended behavior of the mediacaster’ is:
Could you please confirm that the steps 8 and 9 in my scenario above is intended behavior of the wowza/mediacaster IF 8 and 9 occurs in your environment, or could you please advise me on what might be the root cause of this situation in my environment IF 8 and 9 do not occur in your environment.
If you need any further information regarding my environment/setup/configuraiton/etc., please let me know.
Your support is appreciated.
Regards
catalog
Hi Richard,
Thank you so much for your advice and continued support indeed.
Regarding the MediaStreamNameGroups (smil+StreamManager):
I have already tested it and confirmed that the problem does not occur in this case because all the streams are being pulled (by the edge) all the time and the behavior of the mediacaster (start/shutdown/etc.) is not affected by the activity of the client (play/close/etc.).
(Actually, what I wanted to say by ‘3. this does not happen if all the streams are being pulled all the time (by using the StartupStreams.xml or stream manager) regardless of the activities of the client.’ in my first post is this. sorry for confusing.)
However, what I would like to achieve is the dynamic streaming with origin/edge configuration WITHOUT using the StreamManager/StartupStreams.xml/MediaCasterAPI.
Regarding sendOriginalTimecodes:
Yes, actually Application.xml of my origin always has this property set to true.
But the stream switching does not work (step 11) if an instance of the mediacaster sticks (step 8 and 9) and is left for a few hours.
Can you package up and send something that we can run and replicate this, including a set of files and your player. Send to support@wowza.com.
Thank you so much.
I will send the information (Applicaiton.xml, configuration of FMLE/jwplayer).
Regards
catalog