Запрос о производном потоковом протоколе h.264 - PullRequest
0 голосов
/ 05 июля 2018

Прежде всего, пожалуйста, прости меня за полное отсутствие знаний в этой области. Некоторое время назад я получил пару действительно дешевых Wi-Fi IP-камер, которые я надеялся использовать в своей локальной сети. К сожалению, оказалось, что производитель (zmodo) около года назад представил собственный протокол потоковой передачи и покончил с портом rtsp, присутствующим в предыдущих моделях. Приложения, поставляемые производителем, основаны только на облачной среде, что не дает мне покоя. К счастью, люди пытались найти решения для этого и были довольно успешны с более старыми моделями. Поэтому я попытался понять, что я могу сделать сам.

По сути, камера прослушивает порт 8000 для команд длиной 12 байт. Одна из этих команд запускает поток данных. Данные немного похожи на последовательность фрагментов AVI, которые начинаются с 00dc или 01dc. Как и в AVI, за этими тегами следует четырехбайтовый размер (назовем его S) и 24 байта, которые выглядят как отметка времени (но могут также содержать больше информации). Общее количество байтов между тегами 00dc или 01dc ровно на 32 байта больше, чем S. Итак, у нас есть что-то вроде

30 30 64 63 S[0] S[1] S[2] S[3] ....24 bytes for a time stamp? ... S bytes of data that seems encrypted...

30 31 64 63 S[0] S[1] S[2] S[3] ....24 bytes for a time stamp? ... 00 00 00 01 61 .... S - 5 bytes of data...

Второй тип чанка с префиксом 01dc, кажется, содержит незашифрованные блоки NAL в B- или P-кадрах (если мое базовое понимание верно), но мой вопрос о первом типе. Первый тип, вероятно, содержит I-кадры, но я не могу найти разделитель NAL или байт типа. Кроме того, первые 32 байта из S байтов фактических данных одинаковы для каждой единицы, т. Е. У меня есть

30 30 64 63 S[0] S[1] S[2] S[3] ....24 bytes for a time stamp? ... 32 constant bytes ... S-32 bytes of data

Камера также обеспечивает 128-битный ключ, который я, естественно, предполагал для потокового шифрования (хотя это может быть для облачной аутентификации или TLS или кто знает что). Итак, по вашему опыту, какая (зашифрованная) версия h.264 является наиболее близкой к? Есть идеи, что такое 32 байта констант?

РЕДАКТИРОВАТЬ: Я не уверен, что ключевые кадры зашифрованы, я только предположение. На самом деле, они, кажется, содержат большие области постоянных байтов в конце (хотя байты меняются от одной единицы к другой, то есть e4 e4 .... e4 в одной, затем 93 93 .... 93, что исключает AES, я думаю)

...