Comments 49
Спасибо! :)
Круто, но это нужно иметь такой хороший опыт в дебаге прошивок, чтобы угадывать хеш-суммы по виду и смещения.
Особенно, момент когда оказалось, что хеш сумма идет после раздела фс.
Интересно, сколько времени потратил автор на эту работу.
Особенно, момент когда оказалось, что хеш сумма идет после раздела фс.
Интересно, сколько времени потратил автор на эту работу.
просто не малый опыт реверса и низкоуровневого программирования. + немного психологии программирования.
суммарно убито чистыми около 10 часов.
суммарно убито чистыми около 10 часов.
А как камера себя поведет, если она вещает поток 2мбит/с, и подключено 2 клиента: у одного канал, предположим, 10мбит/с, а у другого — 1 мбит/с. Правильно ли я понимаю, что у 10мбит/с клиента будут невероятные лаги?
Как вообще правильно должна себя вести камера в таких случаях? Может знаете, как ведут себя в таком случае серверы-ретрансляторы?
Как вообще правильно должна себя вести камера в таких случаях? Может знаете, как ведут себя в таком случае серверы-ретрансляторы?
При текущем решении — да, 10мбит будет лагать так же как и мегабитный клиент. По этой причине я бы не стал подцепляться к камере напрямик мобильным клиентом — только через сервера.
Правильно должна камера дропать на мегабитном потоке, и отдавать всё 10мегабитному.
Для этого надо держать для каждого клиента «aghtung» буфер размером в 1 кадр.
Все отправки — только неблокирующие.
Если ушло не всё — остаток копируется в ахтунг буфер, и при следующей отправке отправляется не кадр, а досылается ахтунг.
Если ахтунг пустой — отсылаем данные.
Только тут главное не запороть всё отправкой RTSP пакетов ортогонально, как в камере, о которой я писал в самом конце предыдущей статьи.
Правильные ретрансляторы ведут себя правильно :) erlyvideo себя правильно ведёт.
Правильно должна камера дропать на мегабитном потоке, и отдавать всё 10мегабитному.
Для этого надо держать для каждого клиента «aghtung» буфер размером в 1 кадр.
Все отправки — только неблокирующие.
Если ушло не всё — остаток копируется в ахтунг буфер, и при следующей отправке отправляется не кадр, а досылается ахтунг.
Если ахтунг пустой — отсылаем данные.
Только тут главное не запороть всё отправкой RTSP пакетов ортогонально, как в камере, о которой я писал в самом конце предыдущей статьи.
Правильные ретрансляторы ведут себя правильно :) erlyvideo себя правильно ведёт.
Я все же не понимаю, что именно она должна дропать. Расскажите, пожалуйста, чуть больше о процессе энкода. Камера использует H.264 Main Profile, или Baseline? Если Main, то использует ли B-фреймы? Если да, то как много.
В общем, мой вопрос такой: какие именно мы можем дропать кадры, чтобы картинка хотя бы не полностью развалилась?
В общем, мой вопрос такой: какие именно мы можем дропать кадры, чтобы картинка хотя бы не полностью развалилась?
Я, наверное, дурак. Никто ж не будет B-фреймы в камерах использовать.
Но, в любом случае, нам нельзя дропать I-фрейм. Так что камера должна знать тип кадра.
Но, в любом случае, нам нельзя дропать I-фрейм. Так что камера должна знать тип кадра.
О, если вопрос ставить _так_, то случай сложный.
Дело в том, что rtsp стример ортогонален энкодеру. И когда к стримеру приходит пакет, максимум что мы можем сделать — это дропнуть целиком _кадр_. Именно это позволит делать анализ таймстампа — все пакеты одного кадра выходят одновременно и с одним таймстампом.
Если в стример передавать море доп. информации, то всё сильно усложняет и вводит жесткую зависимость частей. Это неправильно.
Дело в том, что rtsp стример ортогонален энкодеру. И когда к стримеру приходит пакет, максимум что мы можем сделать — это дропнуть целиком _кадр_. Именно это позволит делать анализ таймстампа — все пакеты одного кадра выходят одновременно и с одним таймстампом.
Если в стример передавать море доп. информации, то всё сильно усложняет и вводит жесткую зависимость частей. Это неправильно.
UFO just landed and posted this here
Apple вот решил эту проблему в корне, брутально изобрев свой протокол стриминга.
Там поток режут на кусочки в банально складывают в папку. А клиент их банально
выкачивает по HTTP. В результате TCP соединения постоянно переоткрываются и ошибка
не накапливается.
Вот к чему приводит нежелание читать книжки папы Стивенса (W. Richard Stevens).
Там поток режут на кусочки в банально складывают в папку. А клиент их банально
выкачивает по HTTP. В результате TCP соединения постоянно переоткрываются и ошибка
не накапливается.
Вот к чему приводит нежелание читать книжки папы Стивенса (W. Richard Stevens).
постоянно переоткрываемое соединение = регулярный лаг на открытие соединения = неравномерный стриминг…
протокол RTP over TCP совершенно корректен. а вот для корректной реализации алгоритма надо иногда знать чуток больше, чем названия функций.
протокол RTP over TCP совершенно корректен. а вот для корректной реализации алгоритма надо иногда знать чуток больше, чем названия функций.
Можно «немножко кешировать» пару секунд и пускать несколько TCP потоков на скачивание. Это даст лаг от realtime но видео будет гладкое и пушистое.
Кстати, VLC уже умеет делать стриминг в стиле Apple.
RTP хочет полосу. Изначальная заявка (в первой статье, насколько я помню) была именно борьба бобра с ослом, протиснуть поток там где он не пролезает.
Насчет квалификации программистов — согласен.
Кстати, VLC уже умеет делать стриминг в стиле Apple.
RTP хочет полосу. Изначальная заявка (в первой статье, насколько я помню) была именно борьба бобра с ослом, протиснуть поток там где он не пролезает.
Насчет квалификации программистов — согласен.
это хорошо для броадкаста, где не страшна задержка в минуту или час, но не годится для риалтайм стриминга, где хочется уложиться в секунду-две.
HLS был придуман для несколько иной задачи, и от части с заделом на особенности применения на мобильных девайсах.
У меня наблюдаются похожие проблемы с Hikvision камерой. Но патчить прошивку не хватает квалификации.
Хе, это та самая камера, которая собрана на том же модуле, похоже?
Странно, мне репортили что с ней нет проблем. Вероятно, её при этом подцепляли по своему личному протоколу.
бегло глянул — прошивка архив похоже сразу с fs внутри, ни cram ни cpio ни tar оберток не нашел почему-то; но это не сильно критично.
судя по строкам типа
«Error! sendRtpPacket sendLen = %d»
rtp_tcp_sendstream close and pnet_connect = 0x%x
check_payload failed
rtp_tcp_sendstream close and pnet_connect=0x%x
wtitev rtp data error: %d
Timeout: Lost frame data retval = %d send_len %d errno = %d
rtpoverrtsp_sendstream: setsockopt:TCP_NODELAY ERROR:
rtpoverrtsp_sendstream: setsockopt:TCP_CORK ERROR:
<RTP_OVER_RTSP_Send()>frame_readidx=%d,rtpBufwriteIdx=%d,frameCnt=%d,overlaped_threshold=%d
похоже, что за значениями присматривают, вот только чутьё подсказывает, что они при проблемах закрывают со своей стороны.
в теории можно запатчить, на практике — попробуйте написать производителю камер о проблеме.
Странно, мне репортили что с ней нет проблем. Вероятно, её при этом подцепляли по своему личному протоколу.
бегло глянул — прошивка архив похоже сразу с fs внутри, ни cram ни cpio ни tar оберток не нашел почему-то; но это не сильно критично.
судя по строкам типа
«Error! sendRtpPacket sendLen = %d»
rtp_tcp_sendstream close and pnet_connect = 0x%x
check_payload failed
rtp_tcp_sendstream close and pnet_connect=0x%x
wtitev rtp data error: %d
Timeout: Lost frame data retval = %d send_len %d errno = %d
rtpoverrtsp_sendstream: setsockopt:TCP_NODELAY ERROR:
rtpoverrtsp_sendstream: setsockopt:TCP_CORK ERROR:
<RTP_OVER_RTSP_Send()>frame_readidx=%d,rtpBufwriteIdx=%d,frameCnt=%d,overlaped_threshold=%d
похоже, что за значениями присматривают, вот только чутьё подсказывает, что они при проблемах закрывают со своей стороны.
в теории можно запатчить, на практике — попробуйте написать производителю камер о проблеме.
Спасибо, что посмотрели.
а есть возможность выставить её на немного в сеть? (урл и логпасс в личку плиз).
я потыкаю палочкой
я потыкаю палочкой
Спасибо за доступ! Потыкал палочкой. Камера вполне корректно буферизует и поток _вроде_ не ломает.
Но какой-то шлак и мусор можно поймать после лага:
UNK NAL = 27
UNK NAL = 31
UNK NAL = 18
UNK NAL = 13
и камера бывает рвёт по своему желанию.
то есть такие какая-то некорректность у неё есть.
Но какой-то шлак и мусор можно поймать после лага:
UNK NAL = 27
UNK NAL = 31
UNK NAL = 18
UNK NAL = 13
и камера бывает рвёт по своему желанию.
то есть такие какая-то некорректность у неё есть.
> патчем, защищающим TCP поток от порчи
«Патч, защищающий от порчи» — такое пол-Хабра с руками оторвет! ) Особенно, если не только по поводу TCP-потока
«Патч, защищающий от порчи» — такое пол-Хабра с руками оторвет! ) Особенно, если не только по поводу TCP-потока
А нельзя это было объединить с предыдущим постом?
А за статью спасибо.
А за статью спасибо.
Сначала я хотел подумал что «вот нищеброд и бездельник, вместо того чтобы выкинуть китайскую камеру, ковыряет её», но когда прочитал подход и способ — проникся таким уважением к автору. Автор, ты просто молодец! Так держать!
P.S. Кстати не прочитал и половины, не разбираюсь я в этом однако автор все равно немерено крут ))
P.S. Кстати не прочитал и половины, не разбираюсь я в этом однако автор все равно немерено крут ))
вот три внутренних камеры, которые на HiSilicon собраны (HI3516C 53H20L) скорее всего именно выкину. спишу в расход по 150$ за каждую, но сил моих уже нет — лагалище еще то. вот там совсем мрак и жуть внутри.
Так и не удалось их победить несмотря на ежемесячное обновление их прошивок китайцами?
У меня одна такая живёт и ещё 5 подобных ползут из Китая. Вроде как с родным видеорегистратором они ещё дружат, но там, похоже, используется какой-то свой протокол.
У меня одна такая живёт и ещё 5 подобных ползут из Китая. Вроде как с родным видеорегистратором они ещё дружат, но там, похоже, используется какой-то свой протокол.
если хочешь, я могу три своих (объективы 4мм либо 2.8мм) сдать тебе за недорого :)
их DVR цепляет через свой протокол.
Но падение fps при совершенно непонятных условиях меня убивает.
Кроме просадки от числа коннектов, fps падает от освещённости.
Причем выключить эту лажу где — не представляю.
Они low lux походу интеграцией кадров получили.
Я выставил ограничение выдержки <40ms (то есть 25фпс на ура пролазит), всё равнок вечеру fps на обеих 8.33.
утром на ярком свету — снова 25fps.
их DVR цепляет через свой протокол.
Но падение fps при совершенно непонятных условиях меня убивает.
Кроме просадки от числа коннектов, fps падает от освещённости.
Причем выключить эту лажу где — не представляю.
Они low lux походу интеграцией кадров получили.
Я выставил ограничение выдержки <40ms (то есть 25фпс на ура пролазит), всё равнок вечеру fps на обеих 8.33.
утром на ярком свету — снова 25fps.
Есть такая мысль, что ночью включается подсветка, лезут помехи из-за отсутствия фильтров по питанию, изображение покрывается какой-то рябью, а чип не справляется с возросшим потоком «мусора».
Я такую американской сборки за 430 баков видел (хохо) что уж говорить про китайцев.
Вот её фамилия: IQinVision IQD32SV-F1, ближе к ночи после заката — 1 кадр в минуту.
Вот её фамилия: IQinVision IQD32SV-F1, ближе к ночи после заката — 1 кадр в минуту.
в конце всех кручений, когда убрал DWDR, отрубил чего-то там еще, в общем, они стали себя вести лучше.
но всё равно, в моём случае она бесполезна — мне важнее видеть кто прошел и куда, чем какого цвета была шапка.
поэтому снял, все три лежат в коробках, на их место повесил на базе топсишных модулей.
но всё равно, в моём случае она бесполезна — мне важнее видеть кто прошел и куда, чем какого цвета была шапка.
поэтому снял, все три лежат в коробках, на их место повесил на базе топсишных модулей.
Захотел узнать про команду strings, вбил в гугл «man strings». Зря.
А в каком месте rtsp_streamer можно увеличить TCP таймаут до 10 секунд? Автоматическим патчером из следующей статьи пропатчил, обрывы прекратились но картинка рассыпается.
а не знаю. в последних билдах найти место с таймаутом мне не удалось.
+ самые последние билды вообще надо заново расковыривать формат прошивки.
+ самые последние билды вообще надо заново расковыривать формат прошивки.
у меня TS38JK 2.5.1.0, сейчас еще раз протестировали со своей пропатченной и с прошивкой с datacompboy.ru/camfw/
ffmpeg -i rtsp://192.168.0.123/mpeg4 -vcodec copy test.avi
время от времени сыпет
[avi @ 0x138af00] H.264 bitstream error, startcode missing3 bitrate=3928.5kbits/s
Last message repeated 19 times
Но картинка без существенных артифактов.
ffmpeg -i rtsp://192.168.0.123/mpeg4 -vcodec copy test.avi
время от времени сыпет
[avi @ 0x138af00] H.264 bitstream error, startcode missing3 bitrate=3928.5kbits/s
Last message repeated 19 times
Но картинка без существенных артифактов.
Sign up to leave a comment.
Что нам стоит пофиксить баг, которого «нет»