Comments 33
Что-то я не понял. Статья содержит очень много повторений одной и той же мысли, а главное — суть умещается в одну фразу: Есть кодеки, например H264 или H265, и у каждого кодека есть набор профилей, а от профиля зависит все остальное: битрейт, степень сжатия, фпс и прочее. Между H265 с восьми-битным 2К профилем и H265 шестнадцати-битным 8К профилем — огромная разница. Один может работать в вашем браузере, второй нет, при этом оба H265.
Тест страница с разными профилями https://lf-tk-sg.ibytedtos.com/obj/tcs-client-sg/resources/video_demo_hevc.html
Это ваш сайт и разработка? или байтденс? К меня, к стати, ни одно видео на этой странице не открывается в Google Chrome. Ограничения c H.265 в веб-браузерах больше лицензионные, а не технические, т.к. патенты на hevc принадлежат Access Advance
Ограничения c H.265 в веб-браузерах больше лицензионные
Это больше миф. Не все видеокарты умеют декодировать этот кодек, и если у вас ни одно видео не работает, значит или вообще нет видеокарты, или она старая, или в браузере выключена настройка hardware acceleration.
Все современные браузеры этот кодек поддерживают (если железо его поддерживает), а прошлым летом его занесли даже в WebRTC.
Пы сы — сайт не мой.
Отвратительный ИИ мусор. Читать нет смысла.
У вас есть конструктивная критика по существу? Мы занимаемся разработкой программного обеспечения для видеонаблюдения, тестируем сотни моделей камер большого числа производителей, и эта проблема возникла не на пустом месте. В статье речь идет о том, что нагрузка на сеть, CPU, GPU у камер со схожими заявленными производителем характеристиками может отличаться не на 10-15%, а в разы. Если вы работаете только с камерами 1-2 производителей, то действительно можете с этим не столкнуться.
Отстойная статейка. Печально, что всё больше и больше подобного нейрошлака проникает на страницы Хабра.
Чего автора-то ругать за ИИ? Не каждый умеет красиво и структурированно оформить материал. Ладно, не мне судить, раз модераторы пропустили, значит, тема живая и может найти свою аудиторию. А она и правда годная, я как раз прекрасно понимаю, о чём там речь 😅 На практике это ежедневная боль ставишь на объект партию камер, а в итоге одна спокойно держит битрейт, другая ночью сеть кладёт, третья с VMS вообще странно себя ведёт. Так что пусть хоть с нейросетью, но главное мысль правильная и для многих актуальная.
Всем, кто проектирует,закупает, эксплуатирует советую не ленитьсякрутите тестовый образец в своих условиях, гоняйте сутки на вашей VMS, проверяйте пиковые всплески и совместимость с клиентами. Надпись на коробке это маркетинг, а не гарантия. Спасибо автору, что тему поднял, она реально нужная, даже если изложена с помощью ИИ.
Автор явно не работал с этим серьезно. Тогда бы он упомянул то, о чем я написал в комментариях выше, а главное про то, что некоторые вендоры, особенно Китайцы, спецом ломают профиль, что бы видео нормально работало только в их клиентах. Я двух таких нашел, поток разбирал, смотрел каждый пакет, и искал в чем же косяк. Берут какой-то байт подменяют другим значением, из-за чего некорректно формируется профиль, условно говоря вместо hev1.2.3.e получается hev1.2.3.f — и вуаля, любой клиент говорит «я не знаю что это за кодек, воспроизвести не могу».
А в главном автор как раз ошибается. При одинаковых пресетах, и в одинаковых условиях (освещение, сцена и пр), две камеры разных производителей на одном и том же кодеке ведут себя вполне одинаково.
Для тех, кто не занимался видеонаблюдением, это может показаться ерундой. Но те, кто работал с реальным зоопарком камер, хорошо знают эту ситуацию: на коробке характеристики вроде одинаковые, а в работе нагрузка на сеть и размер архива могут отличаться в разы.
Автор, Вы представляете, как кодирует h.264 и как h.265? В чём их одинаковость?
В статье не сравниваются h.264 и h.265. Она о другом.
О том, что трафик h.265 ниже трафика h.264 на 30%?
Нет, статья о том, что вы покупаете, например, 2 камеры разных производителей, на коробке которых написано h.264, одинаковое разрешение, одинаковый fps и другие параметры, в нагрузка на процессор и на сеть может отличаться на 50 процентов и более
Спасибо.
Для разрабатываемого устройства хотел применить аппаратный кодек h.265x, но теперь, благодаря Вам, понял, что людям требуется не качество, а возможность работать в загруженной сети. То есть на железе можно сэкономить. Немного пережать видео. Пореже ключевые кадры. Пониже fps. Заодно железка будет дешевле. Всякие артефакты на видео - ну бывает. Это же не ТВ.
Нет, не устройство видеонаблюдения. Просто использовать такую возможность.
у разных людей разные потребности
не все камеры технически могут хорошо кодировать, так как экономия на оборудование.
поэтому слабая работа encoder выливается в большое количество трафика который надо передавать.
с другой стороны его может быть проще обрабатывать, так как декодеру не надо будет прилагать усилий для декодирования.
это все компромисы
Здесь больше зависит от динамичности передаваемой сцены и освещённости. У меня есть камера, которая пишет... не соврать бы, до 21 МБ 5-минутая запись, минимум 10 МБ на 5 минут записи (не каждая минута, а 5 минут), 2304х1296, 15fps. Фокус в том, что картинка, как мне кажется, по качеству 640х360. Возможно это просто пережато кодированием, и матрица как раз даёт 2304х1296. Но в конечном счёте качество страдает. Вторую я бы не купил, но согласитесь - 21 МБ на 5 минут - очень даже круто. При том что картинка явно HDR. Наверное именно это и нужно большинству.
Есть персональный видеорегистратор с точно таким же характеристиками. Вот им пользоваться... можно! Потому что он сразу в облако дублирует. Хотя картинка иногда просто каша, а ночью смазанное изображение. Не всегда, но часто.
Компромисы, компромисы...
Кстати, производитель один и тот же. Vstarcam. Первую вообще для видеосвязи можно использовать - есть дисплей. Собственно, для того и купил. Для помещений. Ах да, персональный видеорегистратор тоже для этой же цели можно использовать...
почему одинаковая надпись "колбаса" не делает всю колбасу одинаковой.
Статья полезная и точно разбирает типичные заблуждения заказчиков. Похоже, многие из тех, кто не работает с видеонаблюдением на практике, не уловили ее основной смысл и думают, что она о сравнении H.264 и H.265, возможно из-за самой первой картинки. Особенно странно видеть, столько анонимного хейта и желания обесценить чужой труд.
Статья заставляет задумываться, а стоит тратиться на этот аппаратный h.265 или нет? Особенно если задача - разработать железо. Я, например, был уверен что стоит. И даже после прочтения статьи так думал. А прочитал комментарий и понял, что не стоит. И нужно это единицам. Да и аппаратный кодек h.264 проще найти. Вчера как раз получил. Теперь даже не буду заморачиваться с h.265.
Тяжёлая статейка. Как раз сейчас работаю с захватом и сжатием потоков с ip камер. Ну можно же было как-то попроще и покороче написать.
Если не упрощать, то статья выглядела бы как учебник по видеокодированию. И в ней пришлось бы разбирать хотя бы вот этот “скромный” набор параметров: разрешение, fps, interlace или progressive, битовая глубина 8/10/12, chroma 4:0:0, 4:2:0, 4:2:2, 4:4:4, color range, aspect ratio, profile, level, tier, режим битрейта CBR, ABR, VBR, CRF, CQP, VBV maxrate и bufsize, qp, qpmin, qpmax, qpstep, qcomp, ipratio, pbratio, multi-pass, GOP, keyint, min-keyint, scenecut, intra-refresh, open или closed GOP, bframes, b-adapt, b-pyramid, rc-lookahead, slices, tiles, reference frames, mixed-refs, метод поиска движения, subpixel refinement, search range, ограничения motion vectors, weightp, weightb, temporal MVP, разбиение macroblocks или CTU, CU, TU, размер transform, transform skip, RDO, RDOQ, trellis, AQ, psy-RD, deblock, SAO, limit-sao, strong-intra-smoothing, параллелизм threads, WPP, frame-threads, slices, режимы задержки, presets и tunes. И главный вывод все равно будет тот же: “да, камеры действительно кодируют по-разному”.
а что мешало написать статью, что видео наблюдение состоит из следующих вещей.
“оптика” камеры.
encoder (количество ресурсов используемых для кодирования потока, ограничено оборудованием камеры и настройками).
трафиком между камерой и получателем.
Требованием к получателям по ресурсам для декодирования полученного видео.
перекодирование опционально
хранение либо в том виде что прислала камера либо перекодирование.
перекодирование - это требование к ресурсам.
если камера на кодирование тратит мало ресурсов, значит производитель может сэкономить на “мозгах” камеры, но это все выльется в большое количество трафика между камерой и получателем.
При этом если поток слабо кодировали, значит его будет легко декодировать (прочитать).
При этом ниикто не мешает прочитав его перекодировать так как надо, с тем же “ffmpeg” с нужными параметрами, да это требует ресурсов, но это цена за зоопарк.
При этом если камера шибко умная и может кодировать в av1, то трафика между камерой может быть мало, но цена этому требования к ресурсам на декодере чтобы декодировать av1 и аппаратная поддержка далеко не у всего есть.
поэтому надо понимать что камера это связка объектив + encoder и его настройки (и способность камеры им следовать).
при этом я абсолютно не эксперт по видеонаблюдению и не эксперт по ffmpeg и для написания комментария не использовал ии.
Я с вами соглашусь: всё, что вы перечислили, абсолютно верно. Но если подробно разбирать только раздел, посвящённый алгоритмам кодирования, то это будет уже не статья, а полноценный том страниц на двести. Основной смысл статьи, который не все поняли, заключается в том, что h.264 (265) - это не один кодек, а набор стандартов с множеством допущений и вариантов реализации.
Было бы полезно выложить несколько примеров с анализатора потока чем одну мысль пять раз повторять.
Даже если брать классический вещательный DVB mpeg4 CBR, всё равно возникают проблемы совместимости. И я сейчас про крупнейших вендоров, а не китайский ноунейм.
Профессионально видеонаблюдением не занимаюсь. Решаю эту проблему закупкой оборудования одного бренда. Фактически вендорлок, увы
Почему одинаковая надпись H.264 или H.265 на IP-камерах не делает их одинаковыми