Mediacache - caching is not useful

Wowza Streaming Engine
1

Looks like mediacache uses the URL sent to the Origin server as one of the keys to determine if there is a cache hit when subsequent requests are made. The URL we send to the origin server, has the content identifier + the users access token. If a different user accesses the same content, the mediacache goes back to the origin server as the URL does not match (the access token of the users are different). Here is how the URL sent to Origin sever looks:

http/uploads/localhost_url/5320ddf00145932dd500008d/bigbuckbunny_750.mp4?signature=d392d5bd0fae5610fdb62d0e9bbfae54e3fa8f558e&access_token=I9TxzhDYUjcMEkfhbUH9H63HYrlcrc%3D9Hh_AVWMad2e1ce010b537837f93b618bd53188fd2318aaa3a543bf50ceca966fx6be883bed054e8cdf69e2351570482fe5bd6b0cd1e9225de87733ba41a4374588b39555398&referer=http://localhost/assets/jwplayer/jwplayer.flash.swf&test_code=abcd

Is there some configuration where I could specify the parts of the URL that must be ignored when doing a match of URL’s?

I would like the entry to look like:

http/uploads/localhost_url/5320ddf00145932dd500008d/bigbuckbunny_750.mp4"

If I cannot do this, mediacache is a just a proxy to my origin server, not really a cache.

Any suggestions?

Thanks.

2

Hi,

I’m not really sure if I fully understand what it is that you want and where the different urls are required.

Is the server that is the Media Cache Source the Origin server that you are referring to? If so, is it this server or the Wowza server that requires the User Access Token?

If so then you will need to configure the Wowza server with it’s own user access token or setup the source server (origin) to allow access directly from the Wowza server.

If you do need to verify the users access token from the player then you will need to do so on the Wowza server before the request is sent to the Media Cache. This way, you would be requesting the same url from the Media Cache for all users.

You can use the Stream Name Aliasing mechanism to intercept the url from the player and then change it to the correct url to send to the Media Cache. There is a simple example available here, https://www.wowza.com/docs/how-to-get-the-streamnamealias-addon. If you need anything custom then the API details are available here, https://www.wowza.com/docs/how-to-use-the-imediastreamnamealiasprovider2-interface. The resolvePlayAlias methods would be used to verify & remap the stream names.

If you simply need to strip off the query string before sending the request to the Media Cache then you should make sure that the stream name in the player is not URLencoded or base64 encoded and that you have these options disabled in your Media Cache configuration.

Roger.

3

Hi,

I understand what you are asking but because it is a caching mechanism, it won’t work as you are thinking. A request is only made to the source when the item is not already cached so you would need to move or mirror the authentication logic to before the caching takes place. This would be true for any caching mechanism. Once an item is cached, the source will never see the request so will not be able to authenticate it anyway.

It’s not a great idea to disable caching as it would result in lots of very small range requests that would probably overload the source very quickly. This is due to the way the MediaReaders work and cannot be changed.

I would do something like the following. Most of the logic is done in the resolvePlayAlias methods I described earlier.

  • Stream url from player with player token comes into Wowza.

  • Authenticate token in resolvePlayAlias. In this method, The stream name from the player is passed in. You have access to the query string and cookies etc. Possibly make a callout to the http server to do the authentication. If the authentication fails, return null. This will send a 404 message back to the player.

  • Once authenticated, re-map the stream name from the player to a common name that will be used by the Media Cache. If the source requires a token then use a token that is unique to the Wowza Server. This way, the source will see the Wowza server as the client and would authenticate it as it would for any other client contacting it directly. A better mechanism would be to have a direct channel from the wowza server to the source so that the wowza server doesn’t need to be authenticated each time.

  • Return this remapped stream name from the resolvePlayAlias method. This will then be the name that Wowza and the Media Cache uses to identify the stream internally.

    If the returned name contains a query string, then this will be stripped off when the stream is created, which I assume is what was happening in your case and why you created a custom random access reader. There are a couple of different methods to make sure that the query string is not stripped off.

  • URL Encode the name before it is returned. Make sure you also url encode the ? and & and any spaces. In the Media Cache Source configuration add or set the following property so that the Media Cache knows to decode the url before sending it to the source.

    <Property>
	<Name>urlDecodeStreamName</Name>
	<Value>true</Value>
</Property>

  • Base64 encode the name before it is returned. This is the better mechanism if urlEncoding causes issues. When applying the base64 encoding, the stream type prefix and the Media Cache source prefix must not be encoded. Only the part of the stream name after the Media Cache Source prefix must be encoded. The name must have a file type prefix to indicate to the Media Reader layer how to handle the stream as it wouldn’t be able to decode the name. eg. mp4:http/[base64 encoded stream path].

    Set the following property in the Media Cache Source properties so that it knows to do a base64 decode on the name.

    <Property>
	<Name>base64DecodeStreamName</Name>
	<Value>true</Value>
</Property>

    Note: you can use either one of the mechanisms but not both together. If both are set to true, only urlDecodeStreamName will be used. urlDecodeStreamName will handle names that are not already encoded however if you have base64DecodeStreamName set, every name must be encoded otherwise it will be decoded to garbage.

    Using either of these two mechanisms should mean that you don’t need a custom RandomAccessReader class.

    Roger.

4

Thank you for your quick reply.

We prefer not to move the user authentication logic from the mediacache source (Origin server). The reason being, the mediacache source is also accessed by other applications using HTTP GET (Range fetches). We would like to keep all authentication logic in one central location. This way access from all applications is authenticated in a consistent way.

Wowza media cache did not work out of the box as it was stripping away the cookies. We wrote a custom module in MediaCacheRandomAccessReader. In the init method we add the cookies back. Once we did this the authentication worked and we were able to stream.

The problem this causes is that the key used for caching now contains an access_token which is specific to a user. This causes the caching functionality to not work across users.

It would be perfect if the custom module we write can set the URL string to use for caching.

It would be good if you could consider the following for a future release:

  1. Pass the incoming URL as is to the mediacache source along with cookies and other headers.

  2. Provide an API to set the exact value of the URL which should be used as a key for caching.

BTW, is there a way to disable caching (by setting TTL to specific values?) but the custom module MediaCacheRandomAccessReader must be invoked so we could add the cookies back in the init method.

Thanks.

5

Thanks Roger. Good suggestions, I will give them a try.