How to Host and Play Videos in 2020?

Question

JavaScript

Good evening!
We recently implemented a project of the festival, on the website of which one could watch full-length films.
In general, everything went well, but now the question of the technologies that were used for this is very acute, because it is very clearly felt that something went wrong, and similar projects are already looming on the horizon.

Having read how "correctly" such an implementation should look, we decided to use Apple's HLS.
Converted all video tracks for different quality using ffmpeg. Split all files into video-audio tracks using mediafilesegmenter, mediasubtitlesegmenter - created playlists using variantplaylistcreator.
We got a cool master.m3u8 playlist file, where all these configs were beautifully described.
And it seems that on the client we get a fully functional system that works fine ... but it wasn’t there.

When users were launched on the project, complaints began to pour in massively, some videos do not load, some catch decode errors (chunk_demuxer_error_append_failed append stream parsing failed), some video freezes at some stages and stops loading on failure. This is despite the fact that on the first day there were no more than 200 simultaneous views online, and the traffic load from the available 3gb / s did not exceed 1/3.
In other words, some kind of crap went.

Since it was necessary to do something urgently, we decided to refuse m3u8 files and switch to the return of whole files right away. In the configs, they simply wrote links to mp4 files, which immediately contained only one audio and video track. And a miracle - all the errors immediately disappeared.
That is, it turns out that the return in one file and the browser decode came out much more efficiently than what we did through HLS. ¯\_( ツ)_/¯

We looked at a bunch of streaming services, most of them gave all their streams in m3u8 format, and people did not experience any problems. Accordingly, a lot of questions arose about how it should be done and what could be the mistake and how to fix it for the future.

1) How to host files on the server? Do I need to split using HLS\DASH? I saw somewhere that these technologies should be used in pairs, since each of them has its own browser support.

2) Should there be any specific settings on the server to effectively serve static media content?

3) Media player. Perhaps the cause of the errors is related to the player that was used on the client? We used https://flowplayer.com/.
Heard about such players as Movie.js Shaka Player, jwplayer - maybe it makes sense to try one of them? The player is not necessarily free, you just want to use technology that can give you maximum coverage. For example, in this project, people came from the TV, but did not work on tizen flowplayer, from the word at all.

4) Encryption\protection of files. As for me, the return of clean mp4 files is not safe from the word at all. It is clear that you can collect the finished file from the playlist with one command from ffmpeg, but in the implementation that came out, you just need to open the dev. tools and get a direct link to a file that you can save to your PC.

Help for the future to do well :)

Answer 1

That is, it turns out that the return in one file and the browser decode came out much more efficiently than what we did through HLS. ¯\_( ツ)_/¯

Of course.
HLS for VoD is used in two cases:
1. If necessary, directly necessary, automatically adjust the video quality without selecting it manually;
2. If you need to encrypt video pieces for each client individually (DRM).
In other cases, there is no particular reason to use HLS / DASH, because. it requires a media source and a javascript player to play in the browser, while normal HTML5 video does not.

We looked at a bunch of streaming services, most of them gave all their streams in m3u8 format, and people did not experience any problems with this. Accordingly, a lot of questions arose about how it should be done and what could be the mistake and how to fix it for the future.

To understand what could be the error, you need to at least get some debug output, or repeat the error.
First, the HLS standard "two": the earlier one allows the use of the MPEG-TS (.ts) container, the later one adds support for .mp4. MPEG-TS is better supported and easier to use and cut.
I once had exactly the same symptoms as you. It turned out that the old DNS A-record remained on the domain, pointing to the non-working IP address of an already non-existent server. And everything, surprisingly, worked, and worked quite stably, but periodically the stream was interrupted with errors.
It's hard to make assumptions without debug data.

1) How to host files on the server? Do I need to split using HLS\DASH? I saw somewhere that these technologies should be used in pairs, since each of them has its own browser support.

Video files do not require any special arrangement on disk. HLS is only supported by mobile browsers (many, but not all), and DASH is not supported by any modern browsers. In any case, you will have to use a javascript player that will independently collect the stream from HLS / DASH and play it through the media source, so there is no fundamental difference. There is absolutely no point in using both HLS and DASH at the same time.

2) Should there be any specific settings on the server to effectively serve static media content?

Not really. Since you have a multi-gigabit link, you can try to configure the network subsystem (if we are talking about Linux), namely, increase TCP buffers, send and receive buffers, the number of conntrack connections (maybe connection errors occur due to the conntrack limit? Did you look into dmesg? ).

3) Media player. Perhaps the cause of the errors is related to the player that was used on the client?

Maybe, definitely. Players contain rather complex code: container parsers and demuxers, work with HLS, media source, compatibility with different browsers.

For example, in this project, people came from the TV, but did not work on tizen flowplayer, from the word at all.

I recommend trying clappr.io - one of the few that works correctly on the outdated Blackberry browser.

4) Encryption\protection of files. As for me, the return of clean mp4 files is not safe from the word at all.

Why do you need to protect your files if you already play them? Maybe you should think about people and viewing convenience, and provide a link that can be opened in a normal video player, or download a movie as a file? I don't understand this stupid trend.