Android RTP (NAL) заголовок для потоковой передачи H264 - PullRequest
Новая
       41

Android RTP (NAL) заголовок для потоковой передачи H264

0 голосов
/ 26 августа 2011

Я пытаюсь написать приложение для потоковой передачи видео, например, SipDroid, но SipDroid только потоковое видео с кодеком H263. Я хотел бы транслировать видео с кодеком H264, поэтому мне нужно написать заголовок NAL.

Я получил некоторую информацию отсюда: http://www.networkdictionary.com/rfc/rfc3984.php?page=0%2C0 и я решил использовать фрагментированные блоки для потоковой передачи (5.8. Фрагментарные блоки (FU) (стр. 8)).

Я пытался создать заголовок NAL, как это:

Нал заголовок http://www.networkdictionary.com/images/rfc3984f14.gif

со следующими значениями показателя:

индикатор http://www.networkdictionary.com/images/rfc3984-3.gif

F = 0, NRI = 2, Type = 28;

и заголовок:

заголовок http://www.networkdictionary.com/images/rfc3984-4.gif

S=0 (1 at first packet), E = 0 (1 at last packet), R = 0, Type = 1;

Значения пакетов установлены правильно на стороне клиента и сервера. Но я не могу прочитать видеопоток из этих пакетов.

сервер - это простой java-сервер, который получает данные и записывает их в файл. Я также пытался показать поток на VLC Player, но он также не работает.

Кто-нибудь знает, в чем проблема или чего не хватает для получения видеопотока на стороне сервера?

EDIT:

хорошо, я думаю, что решил проблему. я пытался получить значения заголовка из потока (vlc player) rtp. в этом потоке формат пакета зависит от размера кадра. размер кадра достаточно мал для 1 пакета, поэтому пакет должен быть объявлен как один конечный пакет со следующими значениями: заголовок NAL: f 0, nri 2, тип 1. если размер кадра больше размера пакета, пакеты разделиться, и формат выглядит так, как будто я опубликовал свой вопрос.

1 Ответ

2 голосов
/ 18 сентября 2011

Обратите внимание, что RFC 3984 был заменен RFC 6184 , хотя это не влияет на этот вопрос.

Теоретически вы можете иметь пакет FU с S = 1 и E = 1, но это пустая трата битов. Соответствующий декодер должен декодировать его должным образом, но я сомневаюсь, что это тестовый сценарий, хорошо выполненный.

Также убедитесь, что вы используете пакетный режим = 1 в fmtp SDP, или получатель не должен правильно его декодировать (хотя некоторые могут в любом случае). FU-A недоступен в режиме 0, который используется по умолчанию.

...