Декодирование видео в браузере

135 views
Skip to first unread message

Якуш Станислав

unread,
Aug 24, 2013, 11:21:10 AM8/24/13
to stream...@googlegroups.com
Всем привет!

Есть идея насчет доставки видео в live режиме и его декодирования стороне клиента.

Закодированное видео можно доставлять клиенту например с помощью HTTP, WebSockets, EventSource.
Видео должно передаваться небольшими кусками (1-2 мегабайта) которые можно декодировать на фреймы и проиграть.

Сам декодер очевидно должен быть написан на JS. Уже есть несколько POC на эту тему, но серьёзного развития эта тема пока не получила.

Для доставки закодированных кусков можно использовать pub/sub механизм. Клиент делает подписку на канал, ему приходит видео.
Такой способ доставки видео очень хорошо масштабируется. Можно просто добавлять ноды на которые будет подписываться клиент и посылать на канал закодированные куски.

Также есть возможность создавать каналы с одним и тем же видео, но другого качества/размера (для медленного соединения).

Вполне возможно создавать каналы по запросу пользователя, и посылать туда видео которое хочет пользователь с желаемым качеством (Video on Demand).

Всё написанное должно быть применимо и к доставке аудио. HTML5 API кажется позволяет проигрывать не закодированный звук.

Igor Yurchenko

unread,
Aug 24, 2013, 2:52:49 PM8/24/13
to stream...@googlegroups.com
И в чем проблема? Чем мы тут можем тебе помочь?

суббота, 24 августа 2013 г., 23:21:10 UTC+8 пользователь Якуш Станислав написал:

Max Lapshin

unread,
Aug 24, 2013, 3:23:40 PM8/24/13
to stream...@googlegroups.com
Надо всё таки отметить, что человек примерно рассказал о MPEG-DASH, просто слегка коряво =)

И так же надо отметить, что все попытки _декодировать_ видео в браузере бессмысленны, потому что сейчас всё, что может декодировать видео, должно это делать специальным API на специальном чипе. Пробросить API к этому чипу в жаваскрипт — вот задача, которую сейчас решают авторы браузеров.

Всё на мази.

Якуш Станислав

unread,
Aug 24, 2013, 4:04:29 PM8/24/13
to stream...@googlegroups.com
Меня давно интересует такой способ для доставки видео. Поэтому просто хочется обсудить.

К тому же сейчас в разработке ORBX.js от создателя JS. Посмотрим как всё это будет использоваться.

Для ускорения декодирования можно использовать asm.js (не знаю в каком он состоянии).

Также такой способ доставки может быть удобным если источник видео не является файлом, а например веб камера.

Про MPEG-DASH сейчас почитаю.

24 августа 2013 г., 22:23 пользователь Max Lapshin <max.l...@gmail.com> написал:
Надо всё таки отметить, что человек примерно рассказал о MPEG-DASH, просто слегка коряво =)

И так же надо отметить, что все попытки _декодировать_ видео в браузере бессмысленны, потому что сейчас всё, что может декодировать видео, должно это делать специальным API на специальном чипе. Пробросить API к этому чипу в жаваскрипт — вот задача, которую сейчас решают авторы браузеров.

Всё на мази.

--
Вы получили это сообщение, так как подписаны на группу "streaming-ru".
Чтобы отказаться от подписки на эту тему, перейдите на страницу https://groups.google.com/d/topic/streaming-ru/BYXplV4OwfY/unsubscribe.
Чтобы отказаться от подписки на эту группу и все входящие в нее темы, отправьте электронное письмо на адрес streaming-ru...@googlegroups.com.
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

Якуш Станислав

unread,
Aug 24, 2013, 4:28:05 PM8/24/13
to stream...@googlegroups.com
Почитал по MPEG-DASH. Как я понял это несколько другое.

Я вижу следующие недостатки:
1) Необходимость сегментирования и как следствие дублирование исходного видео файла на несколько профилей.
2) Хотя сегментирование может быть полезным с точки зрения оптимизации производительности (не кодировать же каждый раз заново), но возможность настройки энкодера в реальном времени отсутствует.
3) Нужно использовать определённый формат метаданных. В моём случае можно самому решить как управлять видео потоком.

24 августа 2013 г., 23:04 пользователь Якуш Станислав <yakush.s...@gmail.com> написал:

Max Lapshin

unread,
Aug 24, 2013, 4:46:19 PM8/24/13
to stream...@googlegroups.com
Станислав, вы очень сильно путаете упаковку и кодирование видео. Это принципиально разные процессы, которые как правило делаются вообще разным софтом.

Пока вы путаете кодирование и транспортировку, вам сложно понимать и с вами сложно общаться.

Кодирование — это чрезвычайно ресурсоемкая процедура по компрессии сырого видео и аудио в некоторые форматы компрессии по нетривиальным алгоритмам, причем, как правило, с потерей исходных данных.

Упаковка в какой-то формат, контейнер и т.п. — это просто перекладывание сжатых данных в каком-то виде с какими-то транспортными заголовками для удобства получающего клиента.


Транспортировку можно осуществлять в тысячи и десятки тысяч одновременных потоков с одного сервера. Кодирование максимум в десятки потоков.

Якуш Станислав

unread,
Aug 24, 2013, 5:10:49 PM8/24/13
to stream...@googlegroups.com
Разницу между кодированием и транспортировкой я понимаю :)

Просто для решения задачи с декодированием видео на стороне браузера возможно нужен свой собственный способ транспортировки. Нужно думать и декодировании и о транспортировке.

> Транспортировку можно осуществлять в тысячи и десятки тысяч одновременных потоков с одного сервера. Кодирование максимум в десятки потоков.

Согласен. Поэтому лучше кодировать заранее и ограничиться несколькими профилями.

Я правда плохо представляю возможность организации live вещания с помощью MPEG-DASH.
Как я понимаю даже если можно генерировать сегмент видео по запросу как будто он уже лежит на FS (хотя на самом деле это видео с web камеры), то это будет не типовое применение для MPEG-DASH?

24 августа 2013 г., 23:46 пользователь Max Lapshin <max.l...@gmail.com> написал:

--

Max Lapshin

unread,
Aug 24, 2013, 5:25:54 PM8/24/13
to stream...@googlegroups.com
Вы не поняли.

Видео на яваскрипте вообще нельзя декодировать. Ни с какими оптимизациями, JIT-компиляцией и чем-либо ещё. На стороне браузера депакетизированное видео должно запихиваться через предоставленный API в видеокарту и проигрываться видеокартой, иначе вы получите второй флеш.


Что вы пишете дальше я, честно говоря, не понимаю.

Якуш Станислав

unread,
Aug 24, 2013, 5:26:13 PM8/24/13
to stream...@googlegroups.com
Ладно, я понял. Для live вещания в MPEG-DASH можно просто сделать сегмент маленьким и добавить его список сегментов в метаданных который потом будет перезагружен клиентом.

MPEG-DASH не очень хорошо подходит для декодирования видео браузером с помощью клиентского JS кода. Т.к. все действия по работе с метаданными выполняет браузер.

Но это всё вопросы транспортировки видео, а не декодирования. Предлагаю обсуждать только декодирование.


25 августа 2013 г., 0:10 пользователь Якуш Станислав <yakush.s...@gmail.com> написал:

Якуш Станислав

unread,
Aug 24, 2013, 5:37:56 PM8/24/13
to stream...@googlegroups.com
Этот API для декодирования не очень нужен если использовать поддерживаемый браузером кодек и контейнер (MPEG-DASH).

Ну это лучше чем флеш. Плагины будут не нужны, только JS библиотеки :)

Roman Timofeev

unread,
Aug 24, 2013, 9:54:47 PM8/24/13
to stream...@googlegroups.com

> Ну это лучше чем флеш. Плагины будут не нужны, только JS библиотеки :)

У вас уже есть работающая с приемлемой скоростью реализация декодера h.264/vp8 на JS?

Якуш Станислав

unread,
Aug 25, 2013, 2:50:10 AM8/25/13
to stream...@googlegroups.com
> У вас уже есть работающая с приемлемой скоростью реализация декодера h.264/vp8 на JS?

Есть только POC на эту тему (Broadway) + возможно ORBX.js появится.

http://habrahabr.ru/post/131632/
http://www.opennet.ru/opennews/art.shtml?num=36879


25 августа 2013 г., 4:54 пользователь Roman Timofeev <crypt...@gmail.com> написал:

> Ну это лучше чем флеш. Плагины будут не нужны, только JS библиотеки :)
У вас уже есть работающая с приемлемой скоростью реализация декодера h.264/vp8 на JS?

--

Max Lapshin

unread,
Aug 25, 2013, 3:25:05 AM8/25/13
to stream...@googlegroups.com
Какой смысл в этой безумной инициативе, если сейчас на всех клиентах, включая десктопы, декодирование видео переводится на спец чип?

Якуш Станислав

unread,
Aug 25, 2013, 3:55:38 AM8/25/13
to stream...@googlegroups.com
Если у браузера будет специальный API для декодирования видео то это конечно будет очень хорошо. Но сейчас такого API нету, а желание вручную управлять декодированием есть.

К тому же если у браузера будет свой API для декодирования то он скорее всего будет ограничен поддержкой нескольких кодеков. Возможно кому-то понадобится поддерживать декодирование своего собственного/не поддерживаемого браузером кодека.


25 августа 2013 г., 10:25 пользователь Max Lapshin <max.l...@gmail.com> написал:
Какой смысл в этой безумной инициативе, если сейчас на всех клиентах, включая десктопы, декодирование видео переводится на спец чип?

--

Max Lapshin

unread,
Aug 25, 2013, 4:29:03 AM8/25/13
to stream...@googlegroups.com
Станислав, вы просто не читаете что я пишу.

Anatoly Shipitsin

unread,
Aug 25, 2013, 10:38:21 PM8/25/13
to stream...@googlegroups.com



2013/8/25 Якуш Станислав <yakush.s...@gmail.com>

Если у браузера будет специальный API для декодирования видео то это конечно будет очень хорошо. Но сейчас такого API нету, а желание вручную управлять декодированием есть.

Да ладно? Зайдите на youtube вот сюда http://www.youtube.com/html5 и ответьте мне на вопрос а как это у нас youtube видео показывает свое, без флеша?
 
К тому же если у браузера будет свой API для декодирования то он скорее всего будет ограничен поддержкой нескольких кодеков. Возможно кому-то понадобится поддерживать декодирование своего собственного/не поддерживаемого браузером кодека.

Я вам даже больше скажу в стандарт пытаются пропихнуть два разных кодека h.264 и WebM пока получается плохо. По этой причине тому же google приходится кодировать и держать два экземпляра видео кодированного в  h.264 и WebM. Про DRM для видео в вебе уже говорят. Вы иногда новости читайте :)

Roman Timofeev

unread,
Aug 26, 2013, 6:53:10 AM8/26/13
to stream...@googlegroups.com
> Я вам даже больше скажу в стандарт пытаются пропихнуть два разных кодека
> h.264 и WebM пока получается плохо.

строго говоря, webm - это не кодек :)
кодек - это vp8(и его продолжение vp9).


все эти приседания с видеодекодерами на JS - феерический идиотизм.
да, на машинах подключенных к розетке это может иметь какой-то смысл,
но на мобильных батарейка кончится раньше первого фильма.
но даже если мы получим приемлемую скорость(в 2-3 раза медленее сишной
реализации) остаётся проблема распараллеливания JS-движка.

Гораздо лучше было бы иметь API, используя которое можно узнать о
поддерживаемых кодеках/контейнерах/разрешениях и наличия аппаратной
акселерации для них.
В сочетании с Web Cryptography API можно было бы подумать о реализации DRM.
Reply all
Reply to author
Forward
0 new messages