Configuring HLS auto-splitter on remote storage servers

[hbarnetworks]

Not sure if I can bring this up but just incase.

I have been attempting to get edge servers working with the current implementation by just using the proxy_pass / slice module in NGINX. It does work. But since the video file gets served using a php file (remote_control.php) the etag obviously is never the same so caching is a video file is useless. Obviously to bypass this is to just use direct links but that kinda defeats the purpose. Tried multiple ways to let the backend think its possible. But  then I have to code it myself which would kill future updates. So my conclusion is that its not possible using the existing kvs setup.

With HLS you will not need the slice module since its already in chunks. But if the remote_control.php file is still being used, then its still not possible. But just to future proof my implementation. Do you guys have any information on how the implementation would go? Would it still use the remote_control file? Or is it going to run with like an simple encryption key? If its the first then I would need to rethink my strategy and make my own expiration solution (or just get rid of it). if its the latter than I would just need to wait.

 

Thanks in advance!

[Tech Support]

We didn't have any yet detailed plans on this, but obviously we will have to keep remote_control.php as at least the first option. There could be probably some other solutions, for example using some nginx modules for this that will support link expiration, but this will definitely be not the first and not the only option. Because many customers will not be able to use it due to their inability to configure nginx as needed.

Also I think you should be able to use slice module with remote_control.php file. If it needs sending additional headers, you can modify it. This file is never updated with KVS update, and we always keep that in mind when adding new features. Unlike it, remote_cron.php file which is the API for conversion server is always auto-updated with KVS version.

[hbarnetworks]

well there are 2 issues one can possible be resolved through a header. But the other one pretty much cant. The problem is that remote_control.php also gets cached and I cant exclude it either because then it wont cache. This causes it go get a time issue since it also caches the echo time response.

[Tech Support]

Do you mean KVS should also add random parameters to status requests so that they are not cached? This can be done I think.

[hbarnetworks]

On 9/17/2024 at 1:07 PM, Tech Support said:

Do you mean KVS should also add random parameters to status requests so that they are not cached? This can be done I think.

Well maybe I didn't explain it correctly. This is the config I use on NGINX. The problem is that it will never go to the .mp4 location because its served as a PHP file.

If I remove the mp4 location and put it in the php location it will also cache the php file (remote_control.php). Meaning that the main server will grab a cached file and eventually stops working because of the time offset will be wrong after like 5 minutes.

 

    location ~ \.php$ {
       include fastcgi_params;
       fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
       fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
       include snippets/fastcgi-php.conf;
       add_header 'Cache-Control' 'no-store, no-cache, max-age=0';
       add_header X-Cache-Status $upstream_cache_status;
       proxy_pass http://upstream;

        location ~ \.mp4$ {
        slice 4m;

        proxy_cache cache;
        proxy_cache_valid 200 206 3d;

        proxy_cache_key    $scheme$is_args$args$slice_range;
        proxy_set_header   Range $slice_range;
        proxy_http_version 1.1;

        limit_rate 2m;
        limit_rate_after 2m;
        }

Maybe there is a way to just cache the arguments but I have never done that before so maybe someone on this forum has a clue?

[Tech Support]

We moved this into a new topic for better structure.

I'm note sure what is the best way to configure Nginx here, but here is something you should try.

Basically when using remote_control.php KVS would send a bunch of parameters to it:

1. Filename (&file=0/1.mp4)
2. Link generation time (&time=123456789)
3. Security hashes with backward compatibility, so many of them (&cv=XXX, &cv2=YYY, &cv3=ZZZ, ...)

So the whole link will look like this:

https://somedomain.com/remote_control.php?time=1726728042&cv=d5e47585ffcc714ca6f85fb0bc7ffab9&lr=0&cv2=c72ea756d738a3ca4955c60b563494a4&file=%2Fcontents%2Fvideos2%2F1000%2F1237%2F1237.mp4&cv3=c972b61297df2d1f36b6248c493d7e4e&cv4=51a5aea4b78a018756fd68846e9d01f5

If you have a problem with setting up this with PHP-based link, you can probably workaround by forming MP4 link using the file parameter plus some apache rewrite to rewrite this internally to remote_control.php. So you need to form a link like this:

https://somedomain.com/file/contents/videos2/1000/1237/1237.mp4?time=1726728042&cv=d5e47585ffcc714ca6f85fb0bc7ffab9&lr=0&cv2=c72ea756d738a3ca4955c60b563494a4&cv3=c972b61297df2d1f36b6248c493d7e4e&cv4=51a5aea4b78a018756fd68846e9d01f5

Then have a rewrite like this:

RewriteRule ^file/(.*)$ remote_control.php?file=$1 [L,QSA]

So this rewrite will translate the 2nd (/file/....) URL into the first (/remote_control.php?xxx) URL. But for Nginx this will look like some MP4 file URL, which can be cached without knowing there is some PHP script behind it. If this approach will work, you will need to modify /get_file.php on your main project to form a remote URL as #2 instead of remote URL #1.

[hbarnetworks]

Well I made it alot more difficult than it should have been. I just modified the remote_control.php file to use a remote time.php file this way I can ignore the cache on the time. And it seems to function. I will see if this actually works properly over the coming days.

[Focus]

Very interesting, please keep us updated. I might just go ahead and try it out myself as well. Thank you!

[hbarnetworks]

Well it definitely seems to work. I am going to attempt this on a bigger scale with a 1gbit origin and a 10x1gbit cache with multiple servers just to see how it holds up. And I will write a little guide on how to do it. Since in hindsight its pretty easy to setup.

 

The beauty about this is that you can also use multiple upstream in your config to pull from different origin servers this way you cant really have a failure.

[hbarnetworks]

 

it definitely functions. Tested with a 1gbit upstream and 4 servers with 1gbit servers. It eventually reaches a point where the origin isn't doing anything anymore. So based on this caching with the existing configuration is possible.