nginx 404 handling: hls shenanigans part 2

I posted a few weeks ago with an idea for how to make sure that a video stream stays alive even if the source has disconnected. A few folks pointed out that this is unlikely to work very well, but I figured I'd give it a try anyway.

I have an "infinite colorbars video stream" working now, I think. Does it work for you on your various devices? Video stream is embedded above, source. "Works" means "continues playing looping colorbars for longer than two minutes."

Second problem is, how do I get nginx to redirect to this when an index.m3u8 file goes 404? I tried this and it is not working:

location ~ index\.m3u8$ {
  error_page 404;

Under normal circumstances, nginx is filling up /var/run/hls/live/ with several .ts files and a single index.m3u8 file. When the source disconnects, the .ts files expire one by one, and when none are left, the .m3u8 file and the the enclosing directory, /var/run/hls/live/ also disappear. So maybe that's causing problems with the 404 handler?

Update: I got the 404 handling working. The file /live.m3u8 normally contains a list of the two sub-streams, a full and a downcoded version. But when it would have gone 404, it instead contains the contents of /video404/index.m3u8, which is the looping colorbars. But, it doesn't really work. First, the transition from "video" to "colorbars" is not immediate; one has to click play again, which kind of defeats the purpose. And second, the transition back from colorbars never happens! The colorbars just keep playing on a loop forever (until one hits reload), even after /live.m3u8 no longer has colorbars in it.

So, it was a long shot, and everything sucks.

(And yeah, apparently no browsers except Safari support .m3u8 files natively; it only works if the VIDEO element is wrapped in videojs witchcraft as I do on the webcast page. Here it is by itself.)

Previously, previously, previously.

Tags: , , , ,

  • Previously