Results 1 to 6 of 6

Thread: wowza stops listening for live streams if they drop out

  1. #1
    Join Date
    Mar 2013
    Posts
    6

    Default wowza stops listening for live streams if they drop out

    We have some live streams being sent to a Wowza server, they are encoded using vlc and sent over UDP to the server. The streams work fine, but sometimes we have to restart the vlc process and at that point the Wowza server unpublishes the streams. The wowza server then appears to try to reconnect to the incoming stream but never manages to. Netstat shows that the server never starts listening on the UDP ports for the incoming streams. I have confirmed using tcpdump that the incoming streams restart successfully and the incoming data is being sent to the wowza server after the restart. The restart of vlc takes only a few seconds.

    I've tried this on v3.0.5 and v3.5.2 (I upgraded in the hope that it would fix it ).

    Any ideas anyone?

    This is the log output when the encoder drops:
    2013-03-18 16:43:29 GMT comment server INFO 200 - MediaStreamMap.removeLiveStreamPacketizer[myserver/_definst_/mystream.stream]: Destroy live stream packetizer: smoothstreamingpacketizer - - - 270.757 - - - - - - - - - - - - - - - - - - -- - - - - -
    2013-03-18 16:43:29 GMT comment server INFO 200 - MediaStreamMap.removeLiveStreamPacketizer[myserver/_definst_/mystream.stream]: Destroy live stream packetizer: sanjosestreamingpacketizer - - - 270.76 - - - - - - - - - - - - - - - - - -- - - - - - -
    2013-03-18 16:43:29 GMT comment server INFO 200 - MediaStreamMap.removeLiveStreamPacketizer[myserver/_definst_/mystream.stream]: Destroy live stream packetizer: cupertinostreamingpacketizer - - - 270.76 - - - - - - - - - - - - - - - - - -- - - - - - -
    2013-03-18 16:43:30 GMT comment server INFO 200 - RTPMediaCaster.streamTimeout[26548428:myserver/_definst_:mystream.stream]: timeout:12000 diff:12059 reason:101 - - - 271.302 - - - - - - - - - - - - - - - - - - - - - -- - -
    2013-03-18 16:43:30 GMT comment server INFO 200 - RTPMediaCaster.resetConnection[26548428:myserver/_definst_:mystream.stream]: - - - 271.303 - - - - - - - - - - - - - - - - - - - - - - - - -
    2013-03-18 16:43:30 GMT comment server INFO 200 - RTPMediaCaster.closeRTPSession[26548428:myserver/_definst_:mystream.stream] - - - 271.303 - - - - - - - - - - - - - - - - - - - - - - - - -
    2013-03-18 16:43:30 GMT comment server INFO 200 - RTPUDPTransport.unbind[myserver/_definst_]: /0.0.0.0:5156 sent:0 recv:1855 - - - 271.304 -- - - - - - - - - - - - - - - - - - - - - - - -
    2013-03-18 16:43:30 GMT unpublish stream INFO 200 mystream.stream - _defaultVHost_ myserver _definst_ 268.724 - 80 null 127.0.0.1 rtsp - known 898065551 2463440 0 15 37315664 2463440 0 mystream.stream - - - - - null null - null -
    2013-03-18 16:43:30 GMT destroy stream INFO 200 mystream.stream - _defaultVHost_ myserver _definst_ 268.725 - 80 null 127.0.0.1rtsp - known 898065551 2463440 0 15 0 2463440 0 mystream.stream - - - - - null null - null -


    and then it tries to reconnect over and over:
    2013-03-18 16:44:08 GMT comment server INFO 200 - RTPSessionDescriptionDataProviderBasic.getStreamInfo[myserver/_definst_]: /usr/local/WowzaMediaServer/content/mycontent/mystream.stream - - - 309.664 - - - - - - - - - - - - - - - - - - -- - - - - -
    2013-03-18 16:44:08 GMT create stream INFO 200 - - _defaultVHost_ myserver _definst_ 0.0 - 80 null 127.0.0.1 rtsp - known 761724498 0 0 30 0 0 0 mystream.stream - - - - - null null - null -
    2013-03-18 16:44:08 GMT publish stream INFO 200 mystream.stream - _defaultVHost_ myserver _definst_ 0.0010 - 80 null 127.0.0.1rtsp - known 761724498 0 0 30 0 0 0 mystream.stream - - - - - null null - null -
    2013-03-18 16:44:08 GMT comment server INFO 200 - RTPMediaCaster.Reconnector[23397626:myserver/_definst_:mystream.stream]: done: 5 - - -309.666 - - - - - - - - - - - - - - - - - - - - - - - - -
    2013-03-18 16:44:20 GMT comment server INFO 200 - RTPMediaCaster.streamTimeout[26548428:myserver/_definst_:mystream.stream]: timeout:12000 diff:12061 reason:101 - - - 321.622 - - - - - - - - - - - - - - - - - - - - - -- - -
    2013-03-18 16:44:20 GMT comment server INFO 200 - RTPMediaCaster.resetConnection[26548428:myserver/_definst_:mystream.stream]: - - - 321.622 - - - - - - - - - - - - - - - - - - - - - - - - -
    2013-03-18 16:44:20 GMT comment server INFO 200 - RTPMediaCaster.closeRTPSession[26548428:myserver/_definst_:mystream.stream] - - - 321.623 - - - - - - - - - - - - - - - - - - - - - - - - -
    2013-03-18 16:44:20 GMT unpublish stream INFO 200 mystream.stream - _defaultVHost_ myserver _definst_ 12.464 - 80 null 127.0.0.1 rtsp - known 1855482257 0 0 28 0 0 0 mystream.stream - - - - - null null - null -
    2013-03-18 16:44:20 GMT destroy stream INFO 200 mystream.stream - _defaultVHost_ myserver _definst_ 12.465 - 80 null 127.0.0.1rtsp - known 1855482257 0 0 28 0 0 0 mystream.stream - - - - - null null - null -
    2013-03-18 16:44:20 GMT comment server INFO 200 - RTPMediaCaster.Reconnector[26548428:myserver/_definst_:mystream.stream]: start: 6 - - -321.624 - - - - - - - - - - - - - - - - - - - - - - - - -

  2. #2
    Join Date
    Dec 2007
    Posts
    21,962

    Default

    Wowza should re-connect if the source is reachable again.

    Have you tried reset in StreamManager?

    Can you play the VLC output at that point in another instance of VLC, to verify it?

    I'm not sure if the MediaCaster advanced monitor would help in this case, but you could try it:
    http://www.wowza.com/forums/content....Caster-streams

    Richard

  3. #3
    Join Date
    Mar 2013
    Posts
    6

    Default

    I can't play the source feed as it's a unicast UDP feed, direct to the wowza server. Tcpdump shows the incoming data is arriving at the Wowza server though.

    However, the plot thinkens ... I have discovered that if the streaming server has not streamed to any clients between the last time it was restarted and the time at which the input stream gets dropped, then it will re-bind successfully.
    Here is the log snippet of the successful re-bind:
    GMT comment server INFO 200 - RTPMediaCaster.Reconnector[22459270:myserver/_definst_:mystream.stream]: start: 3 - - -247.857 - - - - - - - - - - - - - - - - - - - - - - - - -
    GMT comment server INFO 200 - RTPSessionDescriptionDataProviderBasic.getStreamInfo[myserver/_definst_]: URI: udp://0.0.0.0:5158 - - -247.956 - - - - - - - - - - - - - - - - - - - - - - - - -
    GMT create stream INFO 200 - - _defaultVHost_ myserver _definst_ 0.0010 - 80 null 127.0.0.1 rtsp - known 949518090 0 0 23 0 0 0 mystream.stream - - - - - null null - null -
    GMT comment server INFO 200 - RTPUDPTransport.bind[myserver/_definst_]: /0.0.0.0:5158 _defaultVHost_ myserver _definst_ 247.96 - 80 null 127.0.0.1 rtsp - known 949518090 0 0 - - - - - - - - - - - - - null -
    GMT publish stream INFO 200 mystream.stream - _defaultVHost_ myserver _definst_ 0.0030 - 80 null 127.0.0.1 rtsp - known 949518090 0 0 23 0 0 0 mystream.stream - - - - - null null - null -

    But if the server HAS streamed out to clients and then the source feed gets dropped then it does NOT re-bind:
    GMT comment server INFO 200 - RTPMediaCaster.Reconnector[25182688:myserver/_definst_:mystream.stream]: start: 3 - - -274.573 - - - - - - - - - - - - - - - - - - - - - - - - -
    GMT comment server INFO 200 - RTPSessionDescriptionDataProviderBasic.getStreamInfo[myserver/_definst_]: /usr/local/WowzaMediaServer/content/mystream.stream - - - 274.674 - - - - - - - - - - - - - - - - - - -- - - - - -
    GMT create stream INFO 200 - - _defaultVHost_ myserver _definst_ 0.0010 - 80 null 127.0.0.1 rtsp - known 1934372233 0 0 24 0 0 0 mystream.stream - - - - - null null - null -
    GMT publish stream INFO 200 mystream.stream - _defaultVHost_ myserver _definst_ 0.0020 - 80 null 127.0.0.1 rtsp - known 1934372233 0 0 24 0 0 0 mystream.stream - - - - - null null - null -

    Note how the "RTPSessionDescriptionDataProviderBasic.getStreamInfo" is different, the successful one has a URI, the unsuccessful one has the filename.

    Also, the server only has to serve any stream to a client for it the stop working, it doesn't have to be the same one that has had it's input dropped.

  4. #4
    Join Date
    Dec 2007
    Posts
    21,962

    Default

    Are you using StreamType "rtp-live" or "live"? If you are using "rtp-live" then change to "live" and use StreamManager to start the stream. Did you enable the advanced monitor? What version are you testing on? Please stick to 3.5.2 and apply the latest patch if you can as well.

    http://www.wowza.com/forums/content....lopment-Builds

    Richard

  5. #5
    Join Date
    Mar 2013
    Posts
    6

    Default

    It's a "live" stream, on v3.5.2. Starting/stopping/reseting the stream via StreamManager doesn't fix the problem. I haven't enabled the advanced monitor yet.

    We have discovered where the problem stems from though. We are using a home-written authentication module which strips out an authentication token from the incoming URL and then passes the stripped URL back to wowza to play, and it appears that there is one line in that module that is causing the problem. We are using setStreamNameAliasProvider to re-write the URL and it is this that is causing the issue. We are doing some more experimenting, but if you have any clues as to why this method would disrupt the bind process, that would be handy .

  6. #6
    Join Date
    Mar 2013
    Posts
    6

    Default

    We sorted this is the end, it was down to us aliasing a .stream file, which itself is an alias and so was messing things up.

Similar Threads

  1. Flash-Player for Listening to Live Audio Broadcast
    By Jaskaran81 in forum General Forum
    Replies: 2
    Last Post: 11-18-2012, 07:11 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
  •