И еще о потоковом видео

[vitus_wagner]

Поигрался с трансляцией посредством vlc

Вот такая командная строка

cvlc v4l2:///dev/video0 :v4l2-standard= :input-slave=alsa://hw:1,0 :live-caching=300 \
 :sout=#transcode{vcodec=VP80,vb=2000,acodec=vorb,ab=128,channels=2,samplerate=44100,scodec=none} \
 :http{dst=:8080/stream.webm}

Картинку показывает и звук передает и даже с более-менее правильным количеством кадров. Но почему-то изображение на экране браузера отстает от моих действий перед экраном почти на минуту. Что для дверного глазка неприемлемо.

И это не на Rasberry Pi, а на десктопе. Впрочем, принципиальной разницы в производительности между Raspberry Pi 4 c 8Гб и десктопом 2013 года выпуска, пожалуй, нет. Ну в два, ну в три раза.

Пробовал файрфокс десктопный, файрфокс мобильный и chromium десктопный.

Как это встраивать в html-5 страничку более-менее понятно. Но может быт все же раздавать надо не по http, а по rtsp? Лучше бы, конечно через WebRTC, но поди найди в документации на VLC умеет он такое или нет.

Comments

[thedeemon]

Интересный симптом. У меня пару раз в Jitsi (в десктопном Firefox'e) случалась тоже задержка порядка минуты. Вот где эти данные так буферизуются?

[kobelsky]

Попробуй OBS, но я тут не особо помощник, только на ютуб лекции транслирую.

[tzirechnoy [lj.rossia.org]]

>надо не по http, а по rtsp?

Скорее по RTP. RTSP потребует дополнительных телодвижэний, и потэнцыально добавит к нему добавит перемотку, которой всё равно у тебя нет.

[tzirechnoy [lj.rossia.org]]

А Слава КПСС WebRTC -- это вроде вообще не протокол. Он там в подложке SDP/RTP кажэтся использует, а в остальном -- это набор интэрфейсов к javascript для отправки микрофонов и камер в SDP/RTP.

а может, это браузер был?

[figador.livejournal.com]

Версия: может, это браузер о вас заботится, кэширует видео, что не было рывков.

Re: а может, это браузер был?

[vitus_wagner]

Может. Но ведь jitsy умудяется как-то его от этого отучить.

Re: а может, это браузер был?

[figador.livejournal.com]

Я не знаю, какой там протокол, но, вероятно, кэширование можно контроллировать http-заголовками.
Кстати, тот низкоуровненвый способ с транслированием видео на порт (mencoder + nc) насколько я помню, приводил к задержке в 10 секунд. Но это было давно и на слабом Asus EEE с процессором Intel Atom.

[stanislavvv]

Мне тут предложили на https://github.com/arut/nginx-rtmp-module посмотреть. Умеет запускать ffmpeg с указанной строкой и транслировать результат.

[vitus_wagner]

Ну вопрос не в том, как транслировать видеопоток по rtp или rtmp, а в том как потом это в браузере принять. Чтобы оно средствами HTML5 корректно отобразилось во всех возможных браузерах.

[rblaze]

Тег video разве не для on-demand? Чтобы загнать в него live, серверу потребутся не вполне тривиальные мозги, динамически засовывать в якобы статический файл живую картинку, да ещё и для нескольких клиентов. Проще всего заглянуть в developer tools у браузера и посмотреть, что там с поступлением данных: вполне возможно, что эту минуту в значительной степени сжирает сервер.

Но вообще DASH и плееры для него придумали не просто так, я бы в его сторону копал.

[vitus_wagner]

Серверу мозги не потребуются. В атрибуте src тэга video указывается URL. Соответственно, что по этой URL сервер отдает, то браузер и покажет. И никаких файлов, ни статических, ни якобы статических там и рядом не стояло.

Другое дело, что браузер URL-схемы rtp: и rtsp: в этом месте почему-то не понимает.

[sur_kg]

> Но почему-то изображение на экране браузера отстает от моих действий перед экраном почти на минуту. Что для дверного глазка неприемлемо.

Я недавно пробовал стриминг с ffmpeg на MediaPlayerClassic. Путем плясок с бубном и тонких настроек сервера и клиента задержку удалось уменьшить до 15 секунд (с 80% вероятностью, что клиент не затупит и не тормознется до 45 секунд).

Пришлось признать, что контейнерно-поточные технологии передачи видео созданы не для реального времени.

Я давно на андроиде игрался с IP Webcam, там был MJPEG, насколько я помню - с минимальной задержкой.

[fk0]

Через эти "контейнеро-поточные" технологии работает же Skype? У них задержка же приемлимая. Но, понятно, нужен протокол обеспечивающий 1) возможность потери пакетов, 2) с небольшим буфером. TCP будет неизбежно портить буферизацией при любом затыке в канале. Либо плеер должен уметь временную синхронизацию брать не из потока, а использовать реальное время (чтоб после затыка быстро-быстро показать или даже сразу откинуть часть кадров). На мой взгляд это чисто технические нюансы которые легко решаются но в мире опенсоура нет мотивации их решать (или даже более, есть мотивация не решать чтоб не конкурировать с коммерческими продуктами).

[sur_kg]

У скайпа своя проприетарная технология, и, подозреваю, что она отличается от mpeg или mkv настолько же, насколько, скажем C++ отличается от Java.

В open source есть, например, Jitsi. Но я его устройством не интересовался, сказать ничего не могу.