Skip to main content
ramazankoc
ramazankoc
Participant
September 27, 2014
Question

HTTP Stream stops after instant encoder connection lost

  • September 27, 2014
  • 3 replies
  • 783 views

Hi,

We use amazon cloud front and Open Broadcaster to livestream also using jwplayer. Some time we experience internet problem on our local system and encoder lost its connection to server but it just took 1 or 2 second. RTMP stream not effecting by this problem and all clients works fine but mobile client (iphone, ipad) stuck last 10 second before connection lost and playing this 10 second every time when i open stream on my tablet.

The only solution that i have find, deleting these folder and restarting server.

mnt/application/livepkgr/streams

mnt/application/livepkgr/events/_definst_/liveevent


I use this FMS url "rtmp://<server-adress>/livepkgr?adbe-live-event=liveeven"t and Play path/stream key is "kamera5"

Url for jw payer is, http://<server-adress>/hls-live/livepkgr/_definst_/kamera5/event.m3u8


Also, I figured out today the .m3u8 file not updating after connection lost with new .ts file, it is always same when i download it every time.


How can i setup the server to play http after instant connection losts?


Thank you.


    This topic has been closed for replies.

    3 replies

    Conor Brennan
    Adobe Employee
    Conor Brennan
    Adobe Employee
    September 30, 2014

    Hi


    Is the encoder configured to use Absolute Time Code (ATC)

    This is necessary for HLS and HDS. It is required for smooth transition between different stream bitrates and in cases of encoder failure and/or restart.

    This could be the root of your issue when the connection between encoder and publishing server is interupted.

    Bit more detail:

    ATC comes as timestamps within the header of Messages Packet format for the RTMP.

    RTMP message packets format has been defined here http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/rtmp/pdf/rtmp_specification_1.0.pdf

    Basically the timestamp field in Type0 chunk must be a absolute time based on some wall clock.

    Timestamp field is interpreted as integral number with least count as 1 millisecond and it should be always increasing.

    This is how the timestamps would look with following events from encoder

    Without ATC

    With ATC

    Publishing start

    Publishing start

    Sending rtmp audio message, timestamp 0 ms

    Sending rtmp audio message, timestamp 12000 ms

    Sending rtmp video message, timestamp 2 ms

    Sending rtmp video message, timestamp 12002 ms

    Sending rtmp audio message, timestamp 4 ms

    Sending rtmp audio message, timestamp 12004 ms

    Sending rtmp video message, timestamp 5 ms

    Sending rtmp video message, timestamp 12005 ms

    Sending rtmp audio message, timestamp 6 ms

    Sending rtmp audio message, timestamp 12006 ms

    Sending rtmp audio message, timestamp 8 ms

    Sending rtmp audio message, timestamp 12008 ms

    Publishing Stop -

    Publishing Stop -

    Wait for 1000 seconds

    Wait for 1000 seconds

    Publishing Start again

    Publishing Start again

    Sending rtmp audio message, timestamp 0 ms

    Sending rtmp audio message, timestamp 13008 ms

    Sending rtmp video message, timestamp 3 ms

    Sending rtmp video message, timestamp 13011 ms

    Sending rtmp audio message, timestamp 4 ms

    Sending rtmp audio message, timestamp 13012 ms

    Sending rtmp video message, timestamp 6 ms

    Sending rtmp video message, timestamp 13014 ms

    Sending rtmp audio message, timestamp 7 ms

    Sending rtmp audio message, timestamp 13015 ms

    Sending rtmp audio message, timestamp 8 ms

    Sending rtmp audio message, timestamp 13016 ms

    So here timestamp is the timestamp defined for Message header of the RTMP protocol. It is integral number of milliseconds. As you notice here, in case of ATC based timestamps, they are based on actual wall clock, always increasing.


    Can you check on the encoder side that ATC is configured ?


    Thanks.



    I
    ilvio.casa
    Participating Frequently
    September 29, 2014

    You can try to create a manifest file and so the jw player point to this new URL.

    ramazankoc
    ramazankocAuthor
    Participant
    September 29, 2014

    Thanks for your replay.

    Should i creat this manifest file for every time stream stopped?

    I
    ilvio.casa
    Participating Frequently
    September 29, 2014

    The manifest contains informations about the stream how encoder type (a/v), bitrate and url (http://<server-adress>/hls-live/livepkgr/_definst_/kamera5/event.m3u8). So you should create or modify a manifest file only when these parameters changes.

    ramazankoc
    ramazankocAuthor
    Participant
    September 29, 2014

    Hi, this problem is very important for us. Can anyone help me?

    Thank you

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices