Просмотр видео в Motion

MJPEG считается видеопотоком?

Каким проигрывателем MJPEG можно открыть на сайте?

Неа. Его нужно будет обновлять.

Правильней так:

<img src="http://server/stream.mjpeg?frameno=xxdafsasdfa" alt="MJPEG" id="video">

У меня уже несколько лет самодельное видеонаблюдение так показывает безо всяких id и обновляемых параметров через url.

Хм, надо будет проверить. Я уже давно не возвращался к этой теме.

Что значит обновлять frameno? Как это делать и зачем? И так ведь работает?

Всё и так работает, по крайней мере у меня с mjpeg из motion, не надо ничего обновлять.

Я тоже оба варианта сейчас проверил, оба работают.

Ну, скажем, когда-то я так делал:

<img src="url/makeimage.cgi?someflag=...">

Или как здесь:

$('picture').src = CGI + "?video=yes&" + Math.random();

Естественно, т.к. браузеры текут, приходилось так делать:

img_tmout = setTimeout(refresh_image, 60000); // каждую минуту обновляем, экономим память

Если сейчас действительно firefox может показывать mjpeg без таких извращений, достаточно ему и правда подсунуть адрес CGI-скрипта, да расслабиться.

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

А канал от мжипега не треснет?
Один хрен он его не впрямую вещает — зачем издеваться так?

У меня не трескается, смотрю 640x480 с частотой по кадру в две секунды.

Сейчас проверил. MJPEG поток от motion проксируется nginx бекендом, он соединяется ssh-туннелем с vps в Германии, там проксируется фронтендом на nginx, и с него я забираю поток назад к себе в Москву. Снизу на изображение motion накладывает временную отметку с секундами, и отстает она от сервера не более чем на полсекунды.

А можно как-то останавливать и запускать проигрывание видео?

Если только убирать со страницы тег <img ...> с потоком.

А не проще ли просто листалку скринов на js написать?
И задержка меньше будет и кадров больше.

Современный яваскрипт может всё.

Но ведь mjpeg — это и есть листалка скринов в jpeg, которая уже написана и поддерживается всеми современными браузерами.

Но без него получается быстрее

Теоретически должно получаться быстрее, или есть результаты практического сравнения mjpeg со слайдшоу на js? И что именно получается быстрее?

И еще я далек от мира веб-разработки, поэтому спрошу еще один может быть глупый вопрос. Motion умеет делать скрины, складывать их в файловую систему и сохранять их названия в базу данных. И я не понимаю, как сделать нетребовательную к ресурсам листалку скринов, наделанных motion, чтобы при этом не возникло такой проблемы?

Какие-то жабопроблемы

Практически работает быстрее чем у озвученного варианта с mjpeg.
А именно 800х480 кадры загружаются за 0.2-0.5 секунды, задержка не превышает 0.5 секунды.

А как нужно делать, чтобы такая проблема возникла?
Вебсервер на какюм-нибудь нжинксе или хоть даже simpleHTTP, клиент на JS.

Даже если будет не успевать, надо замутить прекеширование следующего кадра и сбрасывать таймаут. У кого сетка медленная - просто будут смотреть немного «растянуто» во времени.

А именно 800х480 кадры загружаются за 0.2-0.5 секунды, задержка не превышает 0.5 секунды.

У меня с mjpeg такая же задержка, если гонять трафик на 1600км и обратно.

А как нужно делать, чтобы такая проблема возникла?

Ну клиент на JS может только догадываться, что motion уже закончил сохранение нового файла со скрином на сервере. А что случится, если клиент начнет грузить файл, который еще не дописан, или вообще не создан?

Клиент должен отправлять номер кадра который он успешно показал, сервер должен понимать что пора отправить следующий.

И ничего не случится - просто картинка не загрузится, там будет 404.

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

сервер должен понимать что пора отправить следующий.

Он же должен при этом проверить, готов ли уже следующий кадр, чтобы показывать его, а не 404. И мне не понятно, как реализовать такую проверку, если у нас есть только nginx и JS.

Ну я там выше писал что нужно сделать прекеширование следующего кадра. Если покакой-либо причине загрузка кадра не удалась - повторить её через некоторый таймаут. А явно показывать предыдущий успешно загруженный. Код набросать чтоли?

Теперь я понял.

404 случится или будет ждать пока допишет.
JS прекрасно умеет обрабатывать 404.

Пожалуйста прекратите писать глупости на лоре

А так она куда пропадёт?

Не надо придумывать глупости. 404 это статус, который клиенту следует научиться обрабатывать.

Лор, пожалуйста, прекрати заострять внимание на одном глупом сообщении. Кто-то что-то ляпнет - сразу налетают без разбора свой-чужой. Обязательно надо куснуть. Хотя, с другой стороны в этом есть смысл.

А нечего глупости писать.