|
Модераторы: feodorv |
|
batchar |
|
||||||
Новичок Профиль Группа: Участник Сообщений: 2 Регистрация: 11.4.2015 Репутация: нет Всего: нет |
Всем привет! Прошу помощи в реализации RTP протокола для стриминга H.264 видео.
Имею в своем распоряжении Raspberry PI(B+) и модуль камеры. В состав Raspberry входит аппаратный энкодер H.264. Энкодер кодирует "сырые" кадры поступающие от камеры в H.264. Кодированое видео хочу отстримить, завернув в RTP. Однако, в результате плеер не может нормально воспроизвести полученый RTP стрим: рассыпается и тормозит видео. I-frame является через каждые 30 кадров. Смотря на ffplay у меня сложилось впечатление, что все P-кадры неправильно декодируются. Меньший интервал появления I-frame проблемы не решил. Перед каждым I-frame энкодер генерирует [SPS] [PPS] кадры, которые я закидываю в отдельные пакеты RTP. Поток H.264 выгядит так: [SPS] [PPS] [I-Frame] [P-FRAME] [P-FRAME] [P-FRAME] .... [SPS] [PPS] [I-Frame] ...... Лог vlc при просмтре RTP стрима:
Буду рад любой подсказке! Ребят, прошу только не надо мне тыкать разными либами Работа с аппаратным энкодером осуществляется через OpenMAX. Приведу часть кода настраивающий экнодер:
Энкодер отдает данные, пакую данные в RTP пакет и пишу в сокет. Один из фреймов выгялит след.образом: 0000 0001 2588 804f ec82 b9bf e0b7 1789 ..... До вызова функции send_data_to_rtp(приведена ниже) отсекаю 00 00 00 01 и заголовок NALU. В готовом пакете после заголовка RTP(12 байт) и еще двух байтов(заголовки для фрагментации, поскольку все фремы фреймы, кроме SPS и SPP, большие и не вмещаются в MTU) последовательность в готовом пакете выгядит так 88 804f ec82 b9bf e0b7 1789 ..... Данные фрейма в правильном порядке «растекаются» по пакетам(смотрел в вайршарке) ничего лишнего не копируется и не теряется. Следовательно вопрос: правильно ли я формирую заголовки пакетов? Смотрел RFC и кучу примеров, однако вроде правильно я делаю. Может какие-то дополнительные или специфичные параметры энкодеру передать надо? Может еще что-то надо добавить? Привожу функцию-упаковщик в RTP ниже вместе с определениями структур:
Спасибо за проявленное внимание! Бюсь над проблемой уже несколько дней Это сообщение отредактировал(а) batchar - 11.4.2015, 13:05 |
||||||
|
|||||||
feodorv |
|
||||||||
Эксперт Профиль Группа: Комодератор Сообщений: 2214 Регистрация: 30.7.2011 Репутация: 10 Всего: 45 |
Здесь точно нужно static? А то при последующих вызовах функции send_data_to_rtp() эти переменные непереинициализируются... Далее. Здесь понятно:
Почему у длины нет -1? Если один байт выпадает, то перед подсчетом числа фрагментов нужно сделать
-------------------- Напильник, велосипед, грабли и костыли - основные инструменты программиста... |
||||||||
|
|||||||||
feodorv |
|
|||
Эксперт Профиль Группа: Комодератор Сообщений: 2214 Регистрация: 30.7.2011 Репутация: 10 Всего: 45 |
Тогда уж и здесь len-1+13...
-------------------- Напильник, велосипед, грабли и костыли - основные инструменты программиста... |
|||
|
||||
batchar |
|
|||
Новичок Профиль Группа: Участник Сообщений: 2 Регистрация: 11.4.2015 Репутация: нет Всего: нет |
Нет, на самом деле те "неучтенные" байты роли не играют, в силу того, что NALU установлен менее, чем "стандартный". Ну, так да - косяк небольшой признаю. Статические переменные - так и задумывалось: счетчики, да и просто какие-то объявленны, но они перед "употреблением" всегда "готовятся". Магия тут. Проблемы со стримом появляется только при стриммминге "живого" потока, т.е. подхватываю кадры от OpenMAX и передаю в сеть. Что самое поразительное и непонятное, сбивающее с толку, так это при стримминге "статического" файла, с предварительным парсингом по кадрам и засовыванием их в фунцию "send_data_to_rtp", вроде того, как от OpenMAX приходит, стримм идет на "УРА" - нет ошибок. Времменые интервалы между кадрами при отправке- соизмеримые и в случае статич.файла(чаитаю данные и покадрово передаю через 33мс для 30фпс) и в случае "живого". Тот же самый код ломает стрим при живом вещании просто в хлам. Однако, стоит мне приписать при передачи в "send_data_to_rtp" мифический FPS > 200(для того же живого) - стрим идет норм при живом потоке, но это КАК-ТО НЕ НОМАЛЬНО. Данные не бьются в любом случае. |
|||
|
||||
feodorv |
|
||||
Эксперт Профиль Группа: Комодератор Сообщений: 2214 Регистрация: 30.7.2011 Репутация: 10 Всего: 45 |
Вы про эту строчку: ? Гм. Честно говоря, я не знаю, насколько тут все правильно сделано... Согласно Some Frequently Asked Questions about RTP:
То есть стоит не прибавлять каждый раз фиксированную величину, а вычислять реальное время отправки очередной пачки пакетов в милисекундах, адаптированных к 90кГц:
Было бы недурно увидеть и реальную временную разницу между посылкой кадров, например, через GetTickCount(). -------------------- Напильник, велосипед, грабли и костыли - основные инструменты программиста... |
||||
|
|||||
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | C/C++: Сети | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |