Live streaming (San Jose): playlist*.abst looping

Wowza Streaming Engine
1

Dear all,

I have recently encountered a strange problem.

We are publishing three streams (800, 512 and 256kbps), encoded in MP4 (Baseline 3.0, 4 seconds between each key frame)+MP3.

We play these streams by a SMIL file, located in our “contents” folder on the server:

<smil>
  <head> </head>
  <body>
    <switch>
      <video system-bitrate="800000" src="mp4:livestream-3"></video>
      <video system-bitrate="512000" src="mp4:livestream-2"></video>
      <video system-bitrate="256000" src="mp4:livestream-1"></video>
    </switch>
  </body>
</smil>

The player has a very high available bandwidth and the playback usually starts with the highest bitrate. However, when we throttle down the bandwidth for the player, the video hangs and the player starts looping over the “playlist*.abst” file. The video starts again when I reload the page.

I modified the live/Application.xml file as follows:

  • no transcoders have been enabled

  • Root/Application/Streams/StreamType is “live”

  • Root/Application/Streams/LiveStreamPacketizers contains “cupertinostreamingpacketizer,sanjosestreamingpacketizer”

  • Root/Application/HTTPStreamers is “cupertinostreaming,sanjosestreaming”

  • Root/Application/LiveStreamPacketizer contains the following setup:

  • sanjoseChunkDurationTarget: 4000

  • sanjoseMaxChunkCount: 4

  • sanjosePlaylistChunkCount: 4

  • cupertinoChunkDurationTarget: 4000

  • cupertinoMaxChunkCount: 4

  • cupertinoPlaylistChunkCount: 4

    Looking at the Firebug Net Console I can see the following behaviour:

    The server is a Wowza 3.1.1 on a Linux (Ubuntu) 64-bit machine.

    The player is the standard OSMF Flash Media Playback (based on OSMF 2.0, opened by the Flash Player plugin v. 11.2 on a Firefox 12 browser): http://www.osmf.org/configurator/fmp/#

    Thank you in advance for your advices,

    Leonardo Scattola

2

Try with OSMF 1.6. I never got version 2.0 to work (it usually starts looping right away, even before downloading first fragment).

3

Can you play each stream in the set individually?

For comparison, have you tried the SmoothStreaming example?

For testing, try making two streams only in FMLE, and make them both very low total bitrate.

Have you considered using Wowza Transcoder instead of multiple streams from FMLE?

Richard

4

Also, you never want the max chunk count set that low. It is leading to 404 error. I would suggest a value of 10 for sanjose (and cupertino).

btw, the looping is a know problem with OSMF.

Richard

5

Leanardo,

Is there any reason you can’t do Flash RTMP? If not, take a look at JW Player RTMP Dynamic plugin:

http://www.longtailvideo.com/support/jw-player/jw-player-for-flash-v5/16012/setting-up-rtmp-dynamic-streaming

And take a look at this technique for generating the .rss needed by JW Player in Wowza

https://www.wowza.com/docs/how-to-use-jw-player-with-adaptive-bitrate-streaming-from-wowza-streaming-engine

Richard

6

Leonardo,

What about Smooth streaming, the other HTTP streaming to the desktop?

Have you looked at this article?

https://www.wowza.com/docs/how-to-configure-adobe-hds-packetization-sanjosestreaming

Richard

7

Right, the sanjoseMaxChunkCount, 404… are you sure you reloaded the application so that your change is in affect?

Can you try 2 second key frame frequency?

Richard

8

Zip up the conf and logs folders and send to support@wowza.com to open a support ticket.

Include all current encoder/encoding details.

Include a link that we can try.

Richard

9

As I understand, Best Effort Fetch in OSMF 2.0 does something like that (attempt to download a fragment which is not in a fragment list, but should be) - http://sourceforge.net/apps/mediawiki/osmf.adobe/index.php?title=Best-Effort_Fetch . Unfortunately I can’t test because Wowza does not work with OSMF 2.0 at all - it begins looping immediately after starting the stream, not even one fragment gets downloaded.

10

Actually OSMF 2.0 problem (initial looping) has been just fixed by Wowza devs and should be in next build. As for recovery from ‘falling out of window’ I added a simple hack that detects that and returns first available fragment (skipping several seconds of content). It is not perfect - after skip audio and video appears frozen for several seconds. My knowledge of OSMF is minimal and I don’t know how to make it flush the buffer and start playing from new time stamp. I reported this bug to adobe ( http://bugs.adobe.com/jira/browse/FM-1573 ), hopefully they will fix it properly.

11

Hi

The recommended KeyFrame time is between 1-3 seconds and 2 seconds seems to work best for most people.

So the stream works fine now that you have removed the 256 kbps stream?

That does seem odd, what happens if you publish a stream with such a low bitrate that no one will ever watch it… (because a higher bitrate will always be accessible even with low speed internet connection)

That will mean that the lowest never gets triggered, thus stopping this odd behavior. (worth a try if nothing else)

Jason

12

Try with OSMF 1.6. I never got version 2.0 to work (it usually starts looping right away, even before downloading first fragment).

We tried with OSMF 1.6.1 pre with the very same behaviour.

Another interesting element: the problem seems to happen always with the lowest bitrate stream; if we publish the two upper bitrates only (800 and 512) the lower one triggers the loop.

13

Sorry, I didn’t express myself correctly.

I was saying that the lowest bitrate always triggers the loading loop; if we have two streams only, the lowest one shows the incorrect behaviour.

You are suggesting that we define a “last stream” with a very small bitrate? It makes sense, although it seems to me that we would exploit a “system fault” instead of correcting it.

14

Unfortunately, adding a very low bitrate stream on the SMIL without actually publishing it does not work (the “manifest.f4m” GET returns a 404 error).

Richard? Anybody from Wowza?

15

Another thing: every now and then, when the user switches stream due to bandwidth fluctuations, the player receives a 404 error for the next fragment; please check the image below.

The player obviously quits immediately.

What may we check?

16

Richard,

thank you for your advices.

We tried with different versions of OSMF and all of them render the very same result. Do you know any other alternative technology for a Flash-based player?

Thank you,

Leonardo

17

Richard, all,

same behaviour with the server-side transcoding.

Regards,

Leonardo

18

Richard,

Unfortunately we’re committed to doing HTTP live streaming for this event.

Thank you,

Leonardo

19

Richard,

We cannot switch the current player technology to Smooth Streaming; we are forced to use our Flash-based player.

As for the parameters settings we are now using the default ones:

sanjoseChunkDurationTarget

10000

Integer

sanjoseMaxChunkCount

10

Integer

sanjosePlaylistChunkCount

4

Integer

sanjoseRepeaterChunkCount

4

Integer

We changed the key frame interval accordingly (one every 5 seconds), but the problem still occurs.

Thank you,

Leonardo

20

We restarted the server, so I guess the new settings are in effect.

We tried also with the following settings:

  • sanjoseChunkDurationTarget to 8000, key frame interval to 2 and 4 secs

  • sanjoseChunkDurationTarget to 4000, key frame interval to 2 and 4 secs

and the problem still occurs.

Thank you,

Leonardo