Live HLS fragments getting cached by the browser (HTTP Origin mode)

Wowza Streaming Engine
1

Hi

I’m using Wowza4 as HTTP Origin mode in HLS over Cloudfront for live streaming – only wowza tuning was reducing the chunk duration to 2000 ; the cloudfront distribution has a minimum TTL manually set to 2 seconds (and not using origin cache headers).

Having users complaining that their live stream displays “past” video. After investigating, it appears that when restarting the stream, the increment of the m2ts fragment resets (e.g. media_1.ts), and the browser uses the cached fragment, displaying old information, and not the new media_1.ts. However, it apparently does not used a cached chunklist.m3u8.

How could i solve this ? Is the only way changing the stream id every live streaming session ? Is there a way for wowza/cloudfront to randomize the chunk id ?

EDIT: from https://www.wowza.com/docs/how-to-configure-a-wowza-server-as-an-http-caching-origin “Random identifiers must be added to live media chunk and fragment URLs so that each encoder session is unique from a caching perspective.” I created my app configuration through the new manager GUI, by choosing the Live HTTP origin mode, shouldn’t this automatically add the random identifiers (which i don’t see here)?

Wowza version is 4.0.3-ga-1

Relevant Application.xml info:

                
<AppType>LiveHTTPOrigin</AppType>
<StreamType>live</StreamType>
<LiveStreamPacketizers>cupertinostreamingpacketizer, mpegdashstreamingpacketizer</LiveStreamPacketizers>
<HTTPStreamers>cupertinostreaming, mpegdashstreaming</HTTPStreamers>
<Property>
<Name>httpOriginMode</Name><Value>on</Value>
<Name>cupertinoCacheControlPlaylist</Name><Value>max-age=1</Value>
<Name>cupertinoCacheControlMediaChunk</Name><Value>max-age=3600</Value>
2

Hello,

Did you enable the httpRandomizeMediaName property?

In Application.xml, add the property to the <LiveStreamPacketizer>/<Properties> container:

<Property>
    <Name>httpRandomizeMediaName</Name>
    <Value>true</Value>
    <Type>Boolean</Type>
</Property>

Zoran

3

Awesome, it works, thanks.

Out of curiosity, why isn’t that enabled by default in LiveHttpOrigin mode ? Who wants to cache live fragments at all ?

Also, it would be nice if the property was visible in the properties GUI (like ChunkDurationTarget which is in the same configuration section).

4

Great. Thanks for the feedback.

I will forward your suggestion to our product management team to take it into account for a future Wowza release.

Zoran

5

Hi,

The development team is aware of the issue and will address it in an upcoming release.

Roger.

6

We tripped over the same problem. Not only is httpRandomizeMediaName NOT LISTED as an option under Advanced Configuration, it is also set to the WRONG DEFAULT value. In my books this is a critical BUG because it jeopardizes live events in potentially very embarrassing ways. Imaging broadcasting to the general public what was being rehearsed and said on stage just an hours before the show!? Just like Florent said, why on Earth would anyone want to have media chunks designed for HTTP caching to overlap in file name?

Again, this is not a feature request. It’s a bug report!

7

Apparerently, 4 years later, I still have the issue …

8

Hi @Leo Goehrs, thanks for letting me know and I’ll check right now and post an update here.

9

Hi Leo, I see your support ticket and that this is an issue you had with Cloud and Akamai and not Streaming Engine as this post is under. I’m following your ticket conversation with tech support and they are researching it with Akamai. Thanks for your communication with us.