LINUX.ORG.RU

История изменений

Исправление no-such-file, (текущая версия) :

конвертацию на лету мы грузим проц, не получится, что на нескольких потоках мы упремся в производительность cpu

Так ты кэширующий прокси перед этим всем поставь. Стрим отдаётся по http(s) т.е. кэшируется как обычно, блоками. Т.к. он зашифрован, то можно использовать в т.ч. сторонние кэши или CDN.

Это должны быть сертификаты полученные от Google/Apple или можно какие-то другие?

Смотря какой режим ты хочешь. Если именно готовый DRM, типа PlayReady, то да, нужно у поставщика регаться и пользоваться его протоколом доставки ключа (а также подтвердить права на контент и т.п.) Но тебе это не надо, просто используй шифрование и сделай свою доставку ключа. В этом заключается велосипедостроительная часть. Самое простое - давать ключ по одноразовому url. Вот тебе мурзилка https://hlsbook.net/how-to-encrypt-hls-video-with-ffmpeg/ Там жирным в манифесте выделена строчка с ключом. Так вот, если на пальцах, тебе нужно не голый url ключа давать, а одноразовый, т.е. Сервер проверяет, что токен ключа в url выдан этом клиенту и тогда отдаёт ключ и токен считается использованным. Как конкретно проверяет зависит от того что тебе надо. Вероятно нужно проверить, что этот пользователь купил это видео и что токен был выдан ему и, например, что прошло не более 1 минуты (если больше, то вероятно плеер не запустился, что-то пошло не так, токен скомпрометирован).

PS: да, ключи должны быть у каждого видоса свои и меняться периодически.

Исходная версия no-such-file, :

конвертацию на лету мы грузим проц, не получится, что на нескольких потоках мы упремся в производительность cpu

Так ты кэширующий прокси перед этим всем поставь. Стрим отдаётся по http(s) т.е. кэшируется как обычно, блоками. Т.к. он зашифрован, то можно использовать в т.ч. сторонние кэши или CDN.

Это должны быть сертификаты полученные от Google/Apple или можно какие-то другие?

Смотря какой режим ты хочешь. Если именно готовый DRM, типа PlayReady, то да, нужно у поставщика регаться и пользоваться его протоколом доставки ключа (а также подтвердить права на контент и т.п.) Но тебе это не надо, просто используй шифрование и сделай свою доставку ключа. В этом заключается велосипедостроительная часть. Самое простое - давать ключ по одноразовому url. Вот тебе мурзилка https://hlsbook.net/how-to-encrypt-hls-video-with-ffmpeg/ Там жирным в манифесте выделена строчка с ключом. Так вот, если на пальцах, тебе нужно не голый url ключа давать, а одноразовый, т.е. Сервер проверяет, что токен ключа в url выдан этом клиенту и тогда отдаёт ключ и токен считается использованным. Как конкретно проверяет зависит от того что тебе надо. Вероятно нужно проверить, что этот пользователь купил это видео и что токен был выдан ему и, например, что прошло не более 1 минуты (если больше, то вероятно плеер не запустился, что-то пошло не так, токен скомпрометирован).