Один из тех случаев, когда у меня просто нет идей и я надеюсь на святого.
В настоящее время я пытаюсь декодировать и использовать собственный видеопоток IP-камеры, и я чувствую, что я очень близок, но я просто не могу найти последнюю часть головоломки. Для максимальной согласованности камеры задано значение 1 FPS, CBR и интервал I-кадра 1.
Обзор того, что я сейчас делаю: буферизуйте пакеты, ищите заголовок проприетарного протокола камеры (35 байт), ищите другой / следующий, сбрасывайте все промежуточное в файл (ради поста это называется "сегмент"), промыть, повторить.
Если я установлю поток с очень низким качеством, то есть 352 * 288 с очень низким битрейтом, я могу совершенно нормально открыть и воспроизвести полученный файл в MPC (или преобразовать его с помощью FFMPEG, а затем воспроизвести в VLC ).
Но здесь возникает проблема: все больше и больше повышая качество видео, после определенного момента видео начинает повреждаться. Одна вещь, которая также начинает происходить, когда происходит этот случай: максимальный найденный «сегмент» ограничен 8183 байтами (довольно специфический размер, который я нашел, очень близок к 2 ^ 13). Поэтому я решил посмотреть, что на самом деле пишется, когда встречается раздел 8176, и то, что я обнаружил, кажется, действительно очень странным - многие из почти совпадающих байтов! (Эти байты записываются только для первого 8176 сегмента кадра)
Образец 1:
0000 0001 4001 0c01 ffff 0160 0000 0300 b000 0003 0000 0300 3cac 0900 0000 0142 0101 0160 0000 0300 b000 0003 0000 0300 3ca0 0b08 0485 8dae 4932 fcdc 0404 0402 0000 0001 4401 c0f2 f03c 9000 0000 014e 01e5 04cc cc00 0080 0000 0001 2601 af1b 686f 315f 8bcd 7007
Образец 2 (пару секунд спустя):
0000 0001 4001 0c01 ffff 0160 0000 0300 b000 0003 0000 0300 3cac 0900 0000 0142 0101 0160 0000 0300 b000 0003 0000 0300 3ca0 0b08 0485 8dae 4932 fcdc 0404 0402 0000 0001 4401 c0f2 f03c 9000 0000 014e 01e5 049b 9b00 0080 0000 0001 2601 af17 68c3 3d14 cf63 2cab
Как видите, вплоть до 8000 0000 0126 01af они кажутся каким-то типом заголовка для / by ... чего-то. Редактировать: Похоже, эта часть содержит VPS / SPS / PPS следующего следующего кадра.
Почти кажется, что демультиплексор просто не имеет ни малейшего представления, что текущий кадр содержит больше данных, чем начальный 8176-байтовый сегмент, видя, как при настройке качества, когда один кадр состоит из одного 8176-го и одного ~ 2000-байтового сегмента, видео хорошо на верхних двух третях и только начинает портиться на нижнем конце. Эта «точка повреждения» ofc продвигается все дальше и дальше, когда я увеличиваю битрейт потока.
Почему бы вам просто не использовать подходящую камеру?!
Эта камера на самом деле в порядке.
Просто используйте его обычный поток RTSP?
Ну, есть проблема, почему я даже начал это делать - он поддерживает только RTSP через UDP, в то время как этот частный протокол работает по TCP, и если есть потеря пакетов (которая есть), поток RTSP начнет повреждаться, что я ofc пытается не случиться.
Надеюсь, здесь есть кто-то, кто сможет мне помочь. Если вам нужны образцы файлов или что-то еще, я был бы рад предоставить их для любой души, которая заинтересована, чтобы попытаться помочь мне.
Спасибо!
Редактировать: Похоже, я мог быть на что-то. Я только что скачал пробную версию Zond 265 (анализатор HEVC), и при открытии в нем результирующего файла он выдает ошибки для каждого фрейма с обоими значениями «Обнаружены непредвиденные оставшиеся X байтов», а также «end_of_subset_one_bit», равным 1 ». Так что, если я просто возьму эти оставшиеся биты и уберу количество битов перед ним - обе эти ошибки исчезнут! (Появляется новый, расшифруйте CTU #x: исключение). Очевидно, что изображение, тем не менее, все еще повреждено, поскольку теперь отсутствует информация, но, по крайней мере, ее нужно отработать. До сих пор не совсем понятно, каким будет следующий шаг.