Каков наилучший способ защитить псевдопотоковое видео в формате mp4 (flash, html5, ПК, iOS)?

Я ищу способ разрешить моим клиентам (вошедшим в систему) смотреть видео в формате mp4 на моем веб-сайте.

  • Я не хочу, чтобы они могли скачать видео или, по крайней мере, сделать это очень сложным.
  • Сервер Linux / приложение PHP
  • Я хочу, чтобы мои клиенты могли смотреть видео в веб-браузере на компьютере или на устройстве iOS/Safari (что означает отсутствие флэш-памяти).
  • Мне нужно, чтобы это было бесплатно или действительно дешево (например, не размещать видео в облачной базе за тысячи долларов каждый месяц).

До сих пор я делал следующее:

  • php псевдопотоковая передача FLV-файлов (известная как xmoov). Используя php, я смог выполнить безопасную проверку перед возвратом содержимого потока (переменные сеанса, токен и т. д.). Но это не работает на iOS, поскольку для воспроизведения FLV-видео требуется флэш-память. Это также не так безопасно, потому что простое расширение Firefox, такое как Video Download Helper, может их загрузить.
  • поэтому я закодировал свои видео в mp4, который отлично работает с html5/iOS, но значительно усложняет «безопасный» аспект процесса: кажется очень сложным сделать псевдопоток php. Я не нашел никакого работающего решения, и кажется, что все отказываются от него, потому что это требует слишком много ресурсов (1 процесс php для каждого видео во время потоковой передачи всего содержимого файла).

Поэтому лучшее решение, которое я нашел, - это 2 классических плагина Apache: «H264 Streaming Module» и «Mod Auth Token». Хорошо, это лучше, но это кажется тупиком, потому что для эффективности время ожидания токена аутентификации должно быть очень коротким (менее 5 секунд, чтобы было очень сложно найти запутанный URL-адрес в источнике html и скопировать/вставить его в приложение для загрузки или запуск сценария или ...), но это означает, что клиент должен запустить видео в течение этого периода времени (в iOS нет возможности автозапуска видео). Это также означает, что клиент не может искать в «еще не загруженной» части видео, потому что проигрыватель (я использую JWplayer) делает новый http-вызов URL-адресу, который, очевидно, больше не работает из-за тайм-аут.

Я думал о видеофлеш-плеере, который может генерировать запутанный URL-адрес сам по себе (а не php, выводящий его в источнике html), но он не будет работать на iOS, потому что он основан на флэш-памяти. Если я использую это на компьютерах и html5/auth_token на iOS (на основе пользовательского агента), очень легко подделать пользовательский агент и загрузить видео.

В другом решении, кажется, используется «настоящий» сервер потокового видео, такой как Red5, но почти каждый учебник, который я нашел, посвящен потоковой передаче в реальном времени, телевизору, веб-камере, а не простым файлам mp4, хранящимся на жестком диске. Это также, кажется, не приложение, сделанное для такого типа потребностей.

Так что я открыт для каждого предложения!

заранее спасибо


ios html streaming jwplayer mp4
person spf    schedule 12.11.2012    source источник
comment
Вот почему было изобретено управление цифровыми правами (DRM). У вас есть множество вариантов на стороне браузера, но ни один из них не является бесплатным или дешевым или работает для браузера И iOS из коробки (MS PlayReady / Flash Access). Я бы определенно выбрал поставщика DRM, такого как buydrm.com или wowza.com, который, кажется, хорошо интегрируется с buydrm.com.   -  person Sebastian Annies    schedule 13.11.2012

Ответы (2)


arrow_upward
0
arrow_downward

Я разобрался с файлами FLV с помощью Amazon S3:

http://evolt.org/s3secure

Я работаю над тем, чтобы сделать это для MP4, но я специализируюсь на веб-материалах, а не на видеоматериалах.

person Joel D Canfield    schedule 15.12.2012

arrow_upward
0
arrow_downward

Я нахожусь в такой же ситуации.

Я использую flowplayer, и я отлично получаю FLV для псевдопотока, используя сценарий на стороне сервера (PHP), аналогичный xmoov, со всеми проверками, которые вы упомянули.

У меня есть для вас 1 совет: я использую, ЕСЛИ $start равно 0, токен работает только в течение 3 секунд (поэтому никаких новых запросы могут быть сделаны), но ЕСЛИ $start > 0, то он работает 10 минут или чуть больше.

Таким образом, люди смогут искать другие части видео, но не делать полный запрос. Вы также можете сделать это ограничение $start больше, чем X байт вместо > 0, чтобы убедиться, что умные парни не пропустят вашу проверку.

Теперь, что касается псевдопотока MP4 с использованием того же сценария, у меня все еще проблемы. поскольку значение $start отправляется в секундах (например: ?start=32.125), вместо позиции в байтах я не могу создать псевдопоток видео.

Если вы нашли решение (не более чем mod_h264_streaming), буду рад его услышать.

person Dandy    schedule 15.04.2013