Заметил непонятную вещь. Подключаюсь по сети к источнику потокового видео, начинаю тянуть поток. Читаю первые 2-3 секунды бегут себе кадры, и тут ВНЕЗАПНО timestamps прыгают на несколько сот секунд и уже дальше бегут как положено. Естественно, вся синхра от этого наперекосяк. Воркараунд сделал, но хочется понять что это такое, в чем дело. Можно было бы подумать что это мой баг, но... Но. Во-первых, видео читается сторонней либой (live555), во вторых абсолютно идентичное поведение я наблюдал на другой платформе читая другим (тоже не моим) кодом поток от камеры совсем другого вендора по совсем другому протоколу Плюс стабильность воспроизведения (инфа 100%). Вопрос - может быть я что-то не знаю про потоковое видео? Про таймстемпинг, и т.д.? PS. Не знал куда тему ткнуть, кинул сюда. Если перенесете - не обижусь
Вполне нормальная ситуёвина. Неизвестно что на пути между сервером и клиентом и как сервер раздаёт. Возможно есть буферизация на пути пакетов или сервер по очереди раздаёт их клиентам и переключение между ними и есть задержка. Чтобы точно сказать, нужно иметь в доступе всю цепочку. Решается есно буферизацией.
У кого есть реальный опыт написания с нуля качественных плееров потокового видео, помогите пожалуйста парой добрых советов. В личку или ICQ 22ноль-1девять3-316.
Постараюсь описать проблему детально. Есть энкодер. Плеет подключается к энкодеру по RTSP и читает видео+аудио поток. Плеер мой, энкодер не мой (я просто разместил объяву). Трафик представляет собой последовательность видео- и аудио-кадров. Каждый кадр имеет timestamp, то есть момент времени, в который он должен быть показан или проигран. Проблема такова. Через несколько секунд после начала чтения потока вдруг происходит скачек timestamp-ов. Скажем 2 секунды гладко, потом ступенька, потом снова гладко. При этом сам контент по времени не скачет. Первое решение которое приходит на ум - корректировать timestamp-ы. То есть считать инкрементально по дельтам, а все дельты бОльшие чем некоторые пороговое значение считать скачком и брать нулевыми. Это работало бы, если бы не... Скачки в timestamp-ах могут возникать и по другим причинам: 1. Лаги в сети, на пути от энкодера до плеера. 2. Загрузка сети внутри компа (скажем чел усиленно качает из торрентов). 3. Загрузка CPU на компе - плееру не хватает процессорного времени. Основная проблема в том, чтобы научиться отличать скачки timestamp-ов, которые делает энкодер от тех, которые происходят по вышеуказанным причинам. Можно было бы забить на timestamps, поскольку известен FPS видео и частота дискретизации аудио, однако т.к. протокол UDP, то нет гарантии что кадры дойдут не потерявшись, поэтому этот способ в лоб не годится. Даже с TCP нет гарантии что энкодер вдруг ни с того ни с сего не пропустить кадр-другой. Возможно нужен какой-то более хитрый критерий. По скольку видео считается realtime-овым, возможно нужно сопоставлять дельту timestamp-ов с дельтой реального времени и пытаться установить факт скачка по вине энкодера на основе этих двух времен. Но пока что такого алгортма придумать и опробовать не удалось. Вот линк на лог плеера. В логе timestamps-ы сессии с ее начала и на несколько десятков секунд. В начале написано какие цифры что значат. 1-2 страницы внизу явно виден скачек по вине энкодера. Задача - научиться отличать его от скачков по прочим причинам. http://www.everfall.com/paste/id.php?i7k9uin2oxot
При этом этот же видеопоток прекрасно играется VLC. Мой плеер делает буфферизацию в одну секунду (как, кажется, и VLC). Больше буфферизовать нельзя - требование кастомера.
Booster Если я правильно понимаю, это не проблема энкодера. Такую же ситуацию я видел на энкодере совсем другого вендора. Да и VLC как-то ведь разруливает эту ситуацию.
_DEN_ Пакеты точно приходят в таком порядке? Если задвинуть подальше такой странный пакет, то это заметно?
Booster Да, сомнений быть не может. Это лог, полученный сразу после приема пакетов библиотекой live555 - думаю ей можно доверять чуть более чем полностью.
Доверять, но проверять, номера кадров в этом логе нет. И почему синхронизация от этого должна нарушиться? Пришёл кадр фиг знает когда отображаемый, следующий пришёл нормальный. Помещай их в очередь и с приходом времени отображения, перебирай.
Booster Ты не понял. Речь не о случайном кадре, а о ступеньке. Случайный кадр это: 2, 4, 7, 9, 112, 11, 14, 16, ... А энкодер дает ступеньку, то есть: 2, 4, 7, 9, 112, 113, 115, 117, 120, ...
А на самом деле кадры идут последовательно или со ступенькой? Неплохо бы посмотреть на лог входящих пакетов. Может буфер переполняется и библа начинает отсеивать.
