Pull to refresh

Comments 4

Видимо из-за хабраэффекта на страницу я так и не попаду (503) :) Спасибо за интересный опыт!
это называеться «Scalable Video». К WebRTC обычно еще преполагаеться SDP — Session Description protocol, в котором и можно указать какие потоки клиент готов принимать…
если клиент сообщяет что готов к 2м потокам, как в вашем случае, подрозумеваеться
что клиент будет скейлить на весь экран сам, если сервер решит переслать меньшую резолюцию. Или же клиент сообщает что готов принимать только одну, в вашем случае 640х480, то сервер пришлет только ее!

Scalable Video родилось что бы сэкономить транскодинг на сервере
это называеться «Scalable Video»

Нет, в статье речь не идет про scalable video, если вы про SVC. Насколько нам известно, WebRTC в данный момент не поддерживает SVC, по крайней мере для кодека H.264.
Ну и SVC имеет слабое отношение к записи стримов и воспроизведению VOD в данном контексте.

WebRTC обычно еще преполагаеться SDP — Session Description protocol, в котором и можно указать какие потоки клиент готов принимать

Да, в SDP, разумеется указываются потоки. В нашем случае указывается 1 видео поток.

если клиент сообщяет что готов к 2м потокам, как в вашем случае

Нет. В нашем случае клиент принимает 1 видеопоток. На графике разрешений показаны высота и ширина этого одного потока во время записи.

подрозумеваеться
что клиент будет скейлить на весь экран сам, если сервер решит переслать меньшую резолюцию

Да, клиент будет скейлить, то, что ему прислали.

Или же клиент сообщает что готов принимать только одну, в вашем случае 640х480, то сервер пришлет только ее!

А вот не факт. В WebRTC, Sender динамически меняет разрешение потока, основываясь на RTCP фидбеках. См. график. Сначала разрешение, при стриминге с iOS приложения, было 640x480, потом упало до 320x240.

Scalable Video родилось что бы сэкономить транскодинг на сервере

Это так, но не актуально для данного конкретного случая.

При этом, в файле записи mp4 мы имеем чудесные фреймы разного размера, точнее сначала последовательность одного размера 640x480, потом другого 320x240, и т.д. Такие фокусы замечательно отыгрывает например VLC

из этого вашего описания я сделал вывод, что один и тот же записаный файл проигрывает-ся offilne с помощью VLC без зеленых областей, а тот же файл переданный по сети да с зелеными…
из этого следует что в файле несколько потоков.
это может быть в 2х вариантах:
1) 2 независимых паралельных H.264 потока, можно посмотреть в МП4 и дампить оба по отдельности в 2 МП4 файла
2) 1 поток no SVC

Насколько нам известно, WebRTC в данный момент не поддерживает SVC, по крайней мере для кодека H.264.


зависит от конкретной имплиментации WebRTC сервера
да, point2point между Chrome броузером нет подежки
но если сервер, то все прекрасно поддерживаеться

Ну и SVC имеет слабое отношение к записи стримов и воспроизведению VOD в данном контексте.


в данном контексте, конечно…
но SVC не ограничен использованием в видео конференциях, это всего лишь набор инструментов кодирования, а как их использовать дело часное

А вот не факт. В WebRTC, Sender динамически меняет разрешение потока, основываясь на RTCP фидбеках. См. график. Сначала разрешение, при стриминге с iOS приложения, было 640x480, потом упало до 320x240.


конечно RTCP играет тут контрольную роль… НО если клиент по SDP не разрешил опускать разрешение то сервер не должен.
правильно составить SDP еще та проблема.
по умолчанию предполагаеться что если клиент готов принять определенный формат, то это максимальный, а значит все что меньше разрешено.
надо отдельно указать что только и только его…

в конечно итоге дело ваше как вы расходуете ресурсы… хотите транскодировать, кстати что ухудшает качество… и вам кажеться так проше, ваше право

Sign up to leave a comment.