Wowza Logo Wowza Icon
Wowza Video Sign Out
Talk to an Expert Free Trial
Wowza Video Sign Out

Wowza Community

Flash HTTP Streaming - Cache problem with live stream

Wowza Streaming Engine
#1

I’m trying to cache segments for a live flash http stream to save incoming bandwidth but can’t as each client gets a unique URL to the same segment like this:

Client1:

http://server1/live-edge/stream1/media_b125000_w407700900.abst/Seg1-Frag13062

Client2:

http://server1/live-edge/stream1/media_b125000_w345480670.abst/Seg1-Frag13062

Is there anyway I can tweak the settings to not include the _w{client id} in the URL and make the segment cachable as the segment should be identical independent of client?

I’m running Wowza 2.2.3 with:

Origin:

liverepeater-origin-record

cupertinostreamingpacketizer, smoothstreamingpacketizer, sanjosestreamingpacketizer

Edge:

liverepeater-edge

cupertinostreamingrepeater, smoothstreamingrepeater, sanjosestreamingrepeater

rtmp://server1/origin|rtmp://server2/origin

Regards,

Andreas

#2

Andreas,

There is not a good way to cache segments.

Richard

#3

It is the wowza session id. Wowza is not setup to be a caching origin for HTTP.

Charlie

#4

I will contact you off forums with a way to do this.

Charlie

#5

It is the wowza session id. Wowza is not setup to be a caching origin for HTTP.

Charlie

Why? Like andreas pointed out, that’s a great advantage of HTTP Streaming.

One of our customers has many hundred employee behind a single IT infrastructure.

They often want to watch one of our videos at the same time. Our servers can handel this, but the bottleneck is the Internet Connection of the customer. We have to segment the videos at the moment (few minutes seqments) and deliver it with a normal apache server (progressive), so the proxy server of our customer can cache the videos!

I will give a big +1 to the feature of cacheable cupertinostreaming and sanjosestreaming segments.

#6

Andreas,

Wowza is not setup to be an origin server for HLS streams at present. Session ID in playlist is used for logging and other purposes.

Richard

#7

I think it is a possible future feature of Wowza 3, but I don’t think for first release and I don’t have a time frame

Richard

#8

It is a planned feature, on the very short-list, but I still can’t provide a time frame for this.

Richard

#9

I think what you are doing will, at least, mess up logging. HTTP origin capability is an upcoming Wowza feature. I am not able to give a time-frame, but I would not make this effort now

Richard

#10

Lars,

Write to support@wowza.com to explain what you are doing. Include a link to this thread for reference

Richard

#11

Hi Richard,

Can you please elaborate a bit?

What is the _w123456 parameter for?

Wowza segments an incoming live streaming into chunks once and cache for some time and clients downloads these, so why present each client with a different URL to the same chunk?

It’s a big thing being able to leverage on existing HTTP/Proxy infrastructure and that is one of the most important things about HTTP streaming, I believe, so this is very important. I hope others agree with me :slight_smile:

Andreas

#12

It is the wowza session id. Wowza is not setup to be a caching origin for HTTP.

Charlie

Hey charlie (and others).

I’ve been playing with modifiying the session ID, to provide caching for LLNW for a client. I had success setting it to a static value for all connected HTTP clients.

What are the chances that clients could have a chunk collision when SessionID is not unique anymore (two or more chunks, same _bXXXXXXX value)?

Can I control chunking somehow, to limit this from happening?

Hopefully I’m not doing something incredibly stupid and Wowza internals can handle hundreds of clients with identical session ID’s.

Please, strongly correct me if I’m wrong. I can take it :slight_smile:

#13

No problem with messed up log files. The big issue is the double usage of bandwith over LLNW and the load coming towards the Wowza Edge from LLNW.

Messed up log files with a broken session ID are the smaller of two evils. If streaming is not impaired in some way, ofcourse. Will be testing it tomorrow.

Thanks

#14

I still have a problem with setSessionId.

With Cuppertino streaming, I request:

http://luxor:1935/vod/mp4:sample.mp4/playlist.m3u8

#EXTM3U

#EXT-X-VERSION:2

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=572079,CODECS=“avc1.66.30, mp4a.40.2”,RESOLUTION=424x240

playlist.m3u8?wowzasessionid=1113769394

The problem I already have is with the returned session ID in this case.

I am implementing IModuleOnHTTPSession to override the session ID.

String sessionId = httpSession.getSessionId();

String newSessionId = “123456789”;

getLogger().info("sessionId was “+sessionId+”, changing to "+newSessionId);

httpSession.setSessionId(newSessionId);

According to the server, this works perfectly: INFO server comment - sessionId was 1113769394, changing to 123456789

Only problem is, the returned playlist contains the old sessionId. What interface can I implement, to override this session ID before the playlist is sent to the client?

#15

Thanks, got the email. Processing.

#16

Now that Wowza 3 is out… was this issue resolved ?

Are we able to use Wowza as a caching origin for http ?

Reason I am asking is we are trying to use Edgecast and are having issues because of the session id…

#17

He charlie, your priv msg queue is full :slight_smile:

Can you please tell me this secret, too?

© 2007–2024 Wowza Media Systems™, LLC. All rights reserved.   Security & Privacy PolicyLegalSystem Status