Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: rtmp dynamic streaming with origin/edge configuration and mediacaster

  1. #1
    Join Date
    Nov 2011
    Posts
    5

    Default rtmp dynamic streaming with origin/edge configuration and mediacaster

    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.
    1. publish the multi-bitrate streams (e.g. 1.stream/2.stream/3.stream) from FMLE 3.2 to the origin.
    2. the client connects to the edge and calls FCSubscribe for all the renditions (1.stream/2.stream/3.stream).
    3. the mediacaster on the edge starts to pull the streams (three streams) from the origin (StreamNameAlias directs the corresponding streams on the origin).
    4. the client calls play a stream (e.g. 3.stream).
    5. the client switches the stream to another rendition (e.g. 1.stream).
    6. the client (user) stops the stream and close the netstream (1.stream).
    7. the edge destroys the stream (1.stream) and closes the session.
    8. 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).
    9. eventually, the mediacaster on the edge continues to pull 3.stream although no client is connected to that stream.
    10. 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).
    11. 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.
    12. 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.
    1. this happens in case of another type of mediacaster (not only liverepeater but also rtp receiving the ts/udp streams)
    2. this does not happen if the stream destroyed is identical to the stream played.
    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.
    4. 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

  2. #2
    Join Date
    Sep 2011
    Posts
    1,919

    Default

    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

  3. #3
    Join Date
    Nov 2011
    Posts
    5

    Default

    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 <OriginURL> 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
    Last edited by catalog; 11-02-2011 at 08:44 AM.

  4. #4
    Join Date
    Sep 2011
    Posts
    1,919

    Default

    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

  5. #5
    Join Date
    Dec 2007
    Posts
    22,013

    Default

    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

  6. #6
    Join Date
    Nov 2011
    Posts
    5

    Default

    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

  7. #7

    Default

    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.
    Not sure what you mean by this. Please explain in more detail.

    Charlie

  8. #8
    Join Date
    Nov 2011
    Posts
    5

    Default

    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 (<OriginURL>, 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

  9. #9
    Join Date
    Dec 2007
    Posts
    22,013

    Default

    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".

    http://www.wowza.com/forums/content....eGroups-module

    The guide says MediaCaster type "rtp", but make it "liverepeater" in this case.

    Richard

  10. #10
    Join Date
    Dec 2007
    Posts
    22,013

    Default

    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

Page 1 of 2 12 LastLast

Similar Threads

  1. RTMP dynamic streaming use nrgp thru Edge/Origin
    By andy_c in forum AddOn: Transcoder
    Replies: 11
    Last Post: 09-03-2013, 07:54 PM
  2. jwplayer values for RTMP feed in an origin/edge configuration
    By m4tt_turner in forum Live Streaming and Encoder Discussion
    Replies: 2
    Last Post: 06-08-2013, 02:27 AM
  3. nDvr + adaptive streaming + origin/edge configuration
    By tktnopbtupeuxpastest in forum AddOn: Wowza nDVR
    Replies: 5
    Last Post: 03-12-2013, 07:58 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •