Появилась такая проблема... я никогда не занимался видео, но тут поставили такую задачу у нас на предприятии купили камеры для видео-наблюдения, с ними шли штатный клиент и сервер. Клиент не подходит нашему руководству и мне поручено написать специальный клиент, со всеми его функциями проблем не возникает но проблема в том что я не могу нормально воспроизводить поток, нашёл либу для работы с этим МП4 (HikPlayM4.dll) там есть всё для проигрывания из потока, когда проигрываю поток читая его из файла всё нормально. Но когда из сети проигрывается определённый кусок, а затем задержка (стоит последняя картинка фрагмента) и следующий фрагмент но пропущенные 2 секунды выпадают ... я так полагаю это из-за неравномерности прихода потоков из сети, все приходящие пакеты я сразу кидаю в функцию ввода в поток к чему я это всё ... как хотя бы примерно мне организовать такой приём данных и их воспроизведение, какой-то буфер выделять и в него всё закидывать а потом оттуда читать? Направьте на путь истинный те кто этим занимается, я в видео полный профан и в алгоритмах работы с ним тоже... P.S. Возможно муторно пояснил, ну вы спросите если чего недодал
А как обстоят дела с видео, если использовать родной клиент системы видеонаблюдения, пауз нет? И по какому протоколу передается поток с сервера в ваше приложение? Они предоставляют свое API, идут "сырые" данные по UDP (TCP), возможно еще как-то?..
TheRawGod В родном клиенте дела обстоят нормально, видео идёт гладко. Протокол у них какой-то свой c идентификатором NetFlag2(внутри TCP). Разобрался с его структурой экспериментальным путём,(не полностью) так как нигде не нашёл информации. Видео идёт по TCP, пакетами каждый из которых предваряется 166-и байтовым заголовком, внутри чистый видео поток. До этого я написал инструмент который без просмотра пишет эти пришедшие данные в файл mp4, в файл всё записывается как положено этих проблем нет т.е. проблема именно в realtime воспроизведении. Проблема не столько в паузах как в том что после этих пауз выпадают куски видео равные по времени паузе, хотя в функцию ввода в поток я посылаю все данные не пропуская. забыл упомянуть, структура этого 166 байтного заголовка который прицеплен к видеоданным мне не ясна .... может в этом проблема ... но если я имею видео данные не знаю зачем мне может понадобиться этот заголовок ... собственно затем и пришёл чтобы спросить как может осуществляться эта передача
Я немного занимался передачей видео по сети. Вопрос о дополнительном заголовке логичный, у меня тоже возник. В моем случае я получал mpeg4 поверх RTP. И несмотря на то, что видеопоток в чистом виде полностью и без изменений передается в полях полезной нагрузки RTP-пакетов, все-равно существуют доп. заголовки, которые дублируют некоторую часть служебной информаци из потока. Вероятно есть абсолютно правильно объяснение, но я точно могу сказать, что как минимум это нужно для следующего. Проследим пусть следования видео данных: raw сэмплы -> мпег4 семплы -> видеопоток -> сеть .......... сеть -> [надо это дело декодировать]. Часто для декодирования используется, скажем, DirectShow. Внутри него все данные передаются семплами. Так вот выходит, что при преобразовании в поток, информация о границах семплов теряется! Т.е. она конечно есть, внутри битстрима (видеопотока), но формат мпег4 стрима очень непрятный. Парсить кучу данных, чтобы просто скормить DirectShow фильтру (а там надо минимум данных: деление на сэмплы, размеры, key-не-key фрейм, таймстемп, вроде все), который все-равно отдаст данные декодеру, который, опять же, все распарсит очень нехорошо с точки зрения производительности. А не забывайте - процессорного времени мпег4 декодироване занимает критично много. Для этого протоколы передачи видео несут некую доп. информацию, известную еще до передачи, пусть она и так есть спрятаная в битстриме, но для подготовки к декодированию, корректной фрагментации при передаче (так бить, чтоб в случае потерь минимум фреймов попортилось) она очень важна. Вот зачем могут быть нужны эти заголовки в вашем случе. Пусть протокол там свой, но природа передаваемы данных ведь та же. Так что могу поспорить, что в этих заголовках вы, при желании, найдете и таймстемпы фреймов и их размеры и еще чего-нибудь подобного Это к слову о заголовках. Теперь о самой проблеме. Инетересно, как организовано декодирование видео с помощью упомянутой вами HikPlayM4.dll. Если ею используется PULL-модель получения данных, то workaround для проблемы очевиден: просто буферизируйте данные. Размер буфера выберите эксперементально. Если поможет - значит виноваты разработчики библиотеки, т.к. выходит что при задержке данных все ломается, а это ненормально. Если используется PUSH модель, то... А как быстро вы посылаете данные в случае записанного файла? Кусками какой величины? Или вы отдаете указатель на весь буфер сразу? Так же проблема могла бы быть объяснима в случае выпадания key-фреймов. Тогда грамотный декодер при наличии информации о потере кей-фрейма (которая по идее вполне может быть взята из вами упомянутого заголовка) просто ждет следующий кей фрейм, т.к. иначе пользователь увидит "испорченную" картинку. Но тот факт, что используется TCP по идее этот вариант отбрасывает. Тем не менее, если сервер позволяет регулировать такой параметр, как скажем частота прихода I-фреймов / число P-фреймов между I-фреймами / GOP size / GOV size и т.п., попробуйте позадавать им граничные значения и посмотреть на поведение вашей программы. Изменяется ли длина пауз? Также, не задокументирован ли так называемый profile и level, посылаемого сервером mpeg4 стрима? Что-нить вроде "advanced simple profile (AS profile), level 2" не встречается в описании типа потока? Это могло бы помочь сопоставить характер воспроизведения проблемы со структурой передаваемых данных и установить возможную связь между ними. По идее, если ответим на вышеупомянутые вопросы картина должны вырисоваться выразительная. Кстати, а что использует родное клиентское приложение для декодирования mpeg4? Какой кодек, на чем основанный? Ведь можно просто попробовать переиспользовать его.
TheRawGod да надо посмотреть на эти заголовки ... возможно там и таймстэмп ... а вариант с буферизацией приходил мне в голову, но повторюсь я в этом новичок и решил для начала проконсультироваться ... также созрела ещё идейка, всё это попробую завтра на работе это сделать нет никакой возможности... но я уверен что и с HikPlayM4.dll я смогу добиться нужного эффекта там сжатие в H.264 происходит на аппаратном уровне и сам сервер пользуется теми же средствами декодирования что и клиент... насколько я понял... в общем пока ничего сказать не могу, на работе разберу ваши предложения .. спасибо за помощь
Нет проблем, пишите результаты. 1. Видео пожатое приходит прямо с камеры? Т.е. используются не аналоговые камеры, подключенные к плате видеозахвата, а цифровые? Если да, то от какого производителя камеры, если не секрет? 2. И если так, то зачем серверу декодировать поток? Делает некий анализ видео (активность и т.д.)?
Всё оказалось намного проще, просто была ошибка в том как я парсил пакеты, кусок видео действительно уходил в никуда = ) Однако в заголовках пакетов действительно имеются таймстэмпы! Камеры подключены к плате, которая и производит аппаратное сжатие. Вы правы сервер действительно анализирует поток, в момент движения он включает запись в файл... кроме того он просто выдаёт изображение с камер на дисплей. Вот сайт производителя, если интересно. А у меня ещё куча работы по обработке пришедшего видео и приведении его в вид удобный для переваривания. Тема закрыта
