Почему рост качества вызывает рост некачества, или должна ли работать основная функция

    Аналоговое видео Глупо спорить с тем, что аналоговое видеонаблюдение уходит в прошлое: дешевые IP камеры дают картинку сопоставимого качества с дорогими аналоговыми. Помимо этого, IP камеры не ограничены сверху ничем, кроме производительности регистратора, тогда как аналоговые камеры требуют жесткого соответствия приёмной карты, согласования уровней сигнала передатчиков/усилителей/приемников и прочего шаманства.
    Конструируя систему на базе IP камер в любой момент можно снять камеру и заменить на более качественную — если при этом сохранить IP адрес и логин-пароль, то, скорее всего, даже не придётся менять настройки приемника — просто в архив пойдёт более качественная картинка.
    С другой стороны, это накладывает ограничения на регистратор — он должен быть готов работать с любым разрешением, любым битрейтом, любым кодеком и любым протоколом… Ну или по крайней мере, корректно работать с заявленным.

    Шива В мире софта есть два пути — есть linux-way: это набор небольших программ, каждая из которых делает одну функцию, но очень хорошо; и есть windows-way: это огромные кухонные комбайны, которые умеют делать всё, и немного больше. Главная проблема linux-way — это отсутствие интерфейса. Чтобы получить всю пользу придётся скурить маны (или хотя бы прочитать --help), и поэкспериментировать. А так же сообразить, что и с чем можно скомбинировать и как. Главная проблема windows-way — это потеря основной функции. Очень быстро при обрастании доп.функционалом теряются тесты ключевого функционала, и со временем начинаются проблемы даже с ним. А еще при этом начинается инерция мышления: «это главная функция, она оттестирована сильнее всего, там бага быть не может, пользователь делает что-то не то».

    Теперь переходим к нашим баранам: сейчас идёт постоянный рост качества IP камер. Любой, кто видел разницу FullHD камеры, установленной на том же месте, где до этого стояла даже ультракрутая 700TVL, уже не захочет вернуться назад (тем более, что по цене сейчас это уже примерно одинаково). Дальнейшее развитие приводит к тому, что камеры 3MP (2048x1536) и 5MP (2592x1944) уже не редкость. Единственная цена за повышенное качество — возрастающие затраты на хранение и передачу. Однако цена гигабайта на жестком диске уже давно падает (и вполне оправилась от потопа на заводе), а потому не является проблемой.

    Буквально сегодня был небольшой спор с maxlapshin на тему должен ли производитель софта чего-либо пользователю, после продажи, или нет. Да, любой софт продаётся «как есть» без каких-либо обещаний. Поэтому даже заплатив сколько бы то ни было, вы не факт что получите даже рабочий софт. Вот только если софт не работает, и это известно — поток покупателей иссякнет в один прекрасный момент. Хотя пока покупают, очевидность исправления ошибок (а уж тем более, реализация фич) под большим вопросом.

    Закончим вступление, и посмотрим небольшое, но очень показательное видео (можно даже не смотреть — на стоп.кадре всё видно):


    Это хрестоматийный глюк, который я наблюдаю практически на всём ПО, предназначенном для видеорегистрации. Я видел это на VideoNet, вижу регулярно на Axxon Next, как видите на видео — этим меня поприветствовал Trassir. Та же байда даже в родном просмотрщике камеры. Можно бы и списать все проблемы на камеру. Можно списать на сеть. Можно на высокую нагрузку на CPU. Можно на электромагнитные помехи. Можно посоветовать проверить память. Можно переустановить систему. В общем, способов вместо разбирательства заставить человека принести унитаз
    Вот только подключаясь к тому же rtsp потоку через vlc никаких артефактов и сбоев — нет. На том же компьютере я запускаю наколенный тест-скрипт, который читает из камеры поток и пишет на диск — и никаких потерь и проблем нет, а потому работает только один метод — снижать разрешение камеры и снижать битрейт.

    То есть несмотря на гибкость, заявленную поддержку кучи камер, работу по ONVIF и RTSP… Всё равно можно не получить никаких плюсов от IP наблюдения, так как принимающий софт оказался не готов к этому.

    Основной причиной такого поведения, как ни странно, является IP сеть, кодеки, и… канализация.

    Итак, для начала, краткая базовая теория по IP сети. В сети всё бегает в форме пакетиков. У каждого пакета есть максимальный размер (MTU, 1500 на обычных линках), отправитель и получатель. Пакетик как-то там по пути пересылается и в итоге должен добраться до получателя. Может не добраться. Может порезаться. Может придти кусочек… В общем, возможны варианты. Из этих пакетиков сверху накручивают транспортные протоколы: UDP и TCP (из интересующих нас). На UDP ничего не меняется, только появляется порт отправителя и порт получателя, чтобы можно было пакеты разделять между собой; а на TCP наворачивается куча логики, которая «гарантирует доставку». Точнее — гарантирует доставку или генерацию ошибки, если что-то не может быть доставлено. Ну как гарантирует… обещает (обещать — не значит жениться ;) Любой админ многократно видел «зависшие» соединения, на том же мобильном инете, например).

    Как TCP гарантирует доставку? А просто — каждый пакет должен получить подтверждение. Нет подтверждения в течение некоего времени — пакет потерян — переотправим его. Но если на каждый пакет ждать подтверждения — скорость упадёт чудовищно, и тем больше, чем выше задержка между общающимися точками. Поэтому вводится понятие «окна» — мы можем отправить максимум N пакетов без подтверждения, и только потом ждать подтверждения. Но ждать N подтверждений тоже много — приёмник тоже будет принимать и посылать подтверждения не на каждый, а просто «максимальный виденный». Тогда подтверждений меньше. А еще подтверждение можно посылать вместе с отправляемым пакетом, чтоб два раза не вставать. В общем — логики море, вся направлена на исполнение обещания доставки, но при этом максимальной утилизации канала. Размер окна — величина непостоянная, и выбирается системой исходя из магии вуду, настроек, погоды на марсе. Плюс, меняется в процессе работы потока. Этого момента коснёмся чуть позже.

    Итак, теперь перейдём к нашим баранам — H264 поверх RTSP. (На самом деле, это практически неважно — что за кодек и что за транспортный протокол. Не думайте, что если вы используете какой-либо свой гениальный протокол, который в разы проще RTSP, что это вас не касается). Поток состоит из периодически повторяющегося ключевого кадра, и потока изменений относительно текущего состояния. Подключаясь к видео надо дождаться ключевого кадра, после чего мы берём его за текущее состояние, и далее принимаем диффы, которые накладываем и показываем. Что это значит? Это значит, что раз в X секунд прилетает МНОГО данных — полный кадр. И тем больше, чем выше разрешение камеры и чем выше битрейт (хотя, будем честными, битрейт слабо влияет на размер кейфрейма). Итак, вот у нас момент времени 0 — начало ключевого кадра, при котором прилетает сразу полный кадр (допустим, у нас камера все 3 мегаписеля — это 2048x1536 = 3145728 пикселей. После сжатия это жалких ~360 килобайт). Всего поток у нас 8 мегабит = 1 мегабайт, кейфрейм раз в 5 секунд, а FPS=18. Тогда у нас будет нечто типа 360к, затем по 52к каждые 1/18 секунды, спустя 5 сек опять 360к, потом опять по 52к.

    Теперь опять вернёмся к UDP и TCP. Пришедший на сетевую карту пакетик складывается в буфер сетевой карты, и процессору ставится флаг (или вызывается прерывание) что есть данные. Процессор приостанавливает исполнение всего полезного, достаёт из карты пакет, и начинает подъём и раздевание его по TCP/IP стеку. Этот процесс выполняется на высочайшем приоритете (ибо работа с железом). Но у нас всё-таки винда или линукс, ни то ни то не RTOS, поэтому нет никаких гарантий, когда именно приложение сможет добраться до этого пакета. А посему, как только система разобралась что это за пакет, к какому соединению относится, пакет пытается уложиться в буфер.
    На UDP: если места в буфере нет, пакет выкидывается.
    На TCP: если места в буфере нет, включается алгоритм управления потоком — отправителю посылается сигнал переполнения, мол заткнись, пока я тут не освобожусь немного. Как только приложение забирает часть данных из буфера, система отправляет «ОК, погнали дальше» отправителю, общение возобновляется.

    Теперь давайте сложим всё, и распишем как происходит приём данных от камеры. Для начала — простой случай, на UDP. Камера считывает следующий кадр, засовывает его в сжиматель, из сжимателя достаёт сжатые данные, режет на пакетики, добавляет заголовки и отправляет получателю. Получатель сперва получает 260 UDP пакетов, потом пауза, еще 40 пакетов, пауза, еще 40 пакетов и т.д. Первые 260 UDP пакетов прилетают моментально — за где-то 30 миллисекунд; а уже на 55й миллисекунде прилетают следующие 40 (за еще 4 миллисекунды). Допустим, буфер у нас стоит 128 килобайт. Тогда, они забьются за 10 миллисекунд. И если за это время приложение буфер не опустошит в едином вычитывающем всё порыве (а на деле читают за раз по одному пакету...) — мы потеряем остаток ключевого фрейма. Учитывая, что у нас не RTOS, и приложение может принудительно «заснуть» по любой из причин (например, пока ОС сбрасывает буфера на диск) на ту же секунду, единственный способ ничего не терять — нужно иметь сетевой буфер размером больше, чем мы можем спать. То есть в идеале буфер ОС нужно устанавливать равным ~2 секундам потока, в данном случае — 2 мегабайта. Иначе потери гарантированы.

    О'кей, но у нас же есть TCP! Который гарантирует доставку, и попросит подождать отправителя если что! Давайте переключимся на TCP, и посмотрим на ту же картину. Дополнительным оверхедом можно пренебречь, просто давайте посмотрим, что происходит. Итак, у нас вылетает 360 килобайт данных. Они отправляются по 100мбит каналу где-то 30 миллисекунд. Где-то на 10й миллисекунде буфер приёмника переполнился, и камеру попросили помолчать. Допустим, спустя еще 20мс приложение прочитало весь доступный буфер (а на деле — прочитало 4 байта, затем 1400, затем еще 4, еще 1400...), и ОС попросило камеру продолжать. камера отправила еще треть кейфрейма и опять заткнулась. Спустя еще 20мс поехали дальше — но камера произвела еще данных, которые легли в буфер самой камеры. И тут мы подходим к скользкому моменту — а какой размер TCP буфера в камере? К тому же, из-за постоянных «заткнись»-«продолжай» эффективная пропускная способность сети падает катастрофически — вместо 100мбит у нас 128кбайт в 30мс = 32 мегабита максимум. In Windows Server, the default quantum is a fixed 120ms. При 120мс у нас предельная скорость будет 8.5мбит. То есть на серверной ОС используя буфер в 128кбайт принять 8мбитный поток будет не просто сложно, а архисложно. На десктопных ОС проще, но всё равно проблемы будут при любом чихе. Если буфер больше — становится всё лучше, но всё равно — при любой нестабильности вычитывания начинаются проблемы, которые приводят в простейшем случае к движению рывками, в отдельных случаях к поломке потока или багу аналогичному этому, если переполнится TCP буфер внутри камеры.

    Откуда можно сделать только один вывод — буфер так же в идеале должен быть с запасом, примерно в 2 секунды потока, в данном случае — 2 мегабайта. Иначе проблемы вероятны.

    Может я и не прав, но если приложение, задача которого принять и сохранить поток от камер, не может этого сделать — это баг. И этот баг надлежит чинить, а не предлагать сводить задачу к уже решенной снижая качество до аналоговой камеры. Dixi.
    Поддержать автора
    Поделиться публикацией

    Комментарии 51

      +3
      Крик души для трассиров/девлайнов и прочих аксонов?
        +4
        Я уже не упомню полный список, где я на это напарывался. Так что это просто уже наболело.
          0
          Во-во! Свеже-пришедшая китайчатина полный поток только через vlc и отдаёт нормально.

          Думал mplayer прикрутить на просмотр, так ни через ffmpeg-обёртку в старом, ни напрямую в «новом» убунте (свежий mint накатил) RTSP 720p без артефактов не идёт… Вот-вот доделаю бокс под cubietruck, погляжу как получится…
        0
        кто, где и как настраивает размер буфера для tpc/udp-соединения?
        0
        Отличный слог изложения!

        И по теме — если приложение не использует setsockopt, то OS применяет параметры по умолчанию, их можно настраивать. Ну а если использует, но с неправильными значениями, то тут, ясно дело, баг приложения.
          +5
          Если приложение занимается такой задачей и не использует setsockopt, то это тоже баг этого приложения.

          TCP очень критичен к равномерности данных. Большая часть эвристик расчитана на «типичные применения» — равномерная нагрузка, максимально быстрое пропихивание слона, либо запрос-ожидание-ответ. Передача в форме пульсаций немного выбивается из схемы, и потому на умолчания полагаться нельзя.
            0
            Просто это в некоторой степени практика «а у нас всё работает».
            Вот и у разработчиков видимо тестовая система стоит с голой виндой и без посторонних задач.
              +1
              Не просто тестовая система с голой виндой, а ещё и прямая коммутация на одном свитче всех восьми камер с единственным компьютером, на котором даже косынку не запустишь.

              При этом о том, что в реальной жизни витую пару всегда обматывают вокруг работающего перфоратора, почему-то забывают.
                0
                Да ладно тебе. Я это отлаживал на схеме Комп<=>Камера, даже без свича.
              0
              И все-таки «пульсаций» не должно быть, как минимум, теоретически. RTP протокол не зря считается real-time протоколом. В нем используется понятие jitter-буфера, так вот он как раз призван выравнивать поток. Если все грамотно реализовано, то между источником и потребителем будет непрерывный равномерный поток. Другое дело, что спецификацию либо игнорируют, либо не понимают. И если RTSP можно реализовать за несколько дней, то вот грамотная имплементация RTP/RTCP протоколов требует на порядок больше времени и глубокого понимания как RTP/RTCP спецификации, так и TCP/IP.
                0
                Пульсации будут при использовании инкапсуляции RTP внутри RTSP сессии, т.е. по TCP.

                При этом исключаются (по идее) спонтанные потери отдельных RTP пакетов.

                В случае с RTP по UDP — да, риалтайм. Но тогда потери данных без шанса на восстановление.
                  0
                  Что такое инкапсуляция внутри RTSP? Может вы tunneling имели ввиду? RTSP по отношению к TCP и к UDP работает одинаково, в том смысле, что RTSP всего навсего позволяет договориться в какие порты пойдут данные, а дальше он не участвует и ничего не инкапсулирует, до тех пор пока не потребуется закрыть сессию. Если сеть достаточно надежная и с достаточной пропускной способностью, то пульсаций и потерь не будет ни при TCP, ни при UDP, либо они будут не существенные. Если сеть не достаточно надежная или с не достаточной пропускной способностью, то ни TCP, ни UDP не будет работать и кино мы не увидим.
                    0
                    А не расскажете на пальцах каким образом пульсации убирает RTP на примере h264?

                    зю: rtp over tcp идёт мультиплексированием с доп.оберткой в том же канале что и сам rtsp, прямо параллельно с командами.
                      0
                      >>> прямо параллельно с командами
                      верно, это называется interleaved режим. Но кто-нибудь может привести use case где надо использовать interleaved режим? Я вот не встречал. Это уже точно будет работать медленнее традиционной схемы. При этом если камера еще и со звуком, то придется мультиплексировать уже 4 потока (1 — видео, 2 — контроль видео, 3 — аудио, 4 — контроль аудио). Конечно так можно обойти ограничения на разрешенные порты и работать скажем с тем же 80 портом, но это внесет существенную задержку передачи потоков и усложнит систему.

                      >>> каким образом пульсации убирает RTP на примере h264?
                      h264 это payload. RTP является payload-agnostic, ему все равно хоть h264, хоть «крокодилы». На пальцах, jitter-буфер должен накапливать пакеты так, чтобы писатель мог писать в него с одной скоростью (или с variable скоростью), а читатель мог бы извлекать с constant скоростью, при этом чтобы буфер не переполнялся никогда и не был бы пуст, т.е. его размер должен быть адаптивным.
                        0
                        Всегда, когда между камерой и клиентом есть какой-нибудь NAT, стоит использовать interleaved режим.

                        >>> читатель мог бы извлекать с constant скоростью

                        UDP устроен так, что пакеты должны доходить без задержек или не доходить вовсе. Должны. Можно ещё RTCP NACK вспомнить, который работает только у микрософта.

                        А на практике бери китайчатину и выковыривай из неё байты так, что бы доходило.
                          0
                          А как же VPN?
                            0
                            VPN? Вы ещё предложите что-нибудь из серии «пусть админ настроит» =))

                              0
                              А кто сказал, что в сложном проекте нельзя использовать то или иное решение? Камера может так или иначе попадать в VPN (либо с помощью спец прошивки, либо с помощью маршрутизатора) и делай с ней что хочешь, общайся по каким хочешь портам. Все ведь зависит от того какую систему делать. Если надо чтобы работало со всеми возможными камерами, то да, не вариант, а если это известные камеры, то почему нет.
                                0
                                А кто сказал, что мы должны ограничиваться только и исключительно сложными проектами?
                          0
                          Use Case простой — установление соединения = задержки; каждое новое соединение = затраты. А у нас уже есть установленное соединение. Передача по физическому уровню что одного соединения что 4х одна и та же (только добавляются лишние пакеты подтверждений, и окно настраивается для каждого соединения заново своё). То есть используя 5 соединений вместо одного мы увеличиваем накладные расходы, причем сопоставимо с использованием interleaved. И таки нет, задержку не вносит — точно так же передаётся в том виде в каком уходило бы и так — как данные пришли, мы их отправили.

                          >> На пальцах, jitter-буфер должен накапливать пакеты
                          Вот еще раз, на пальцах — есть кей-фрейм, весом в 260 пакетов, и есть delta фреймы весом в 60 пакетов. Если мы пакеты начнём выпускать с равномерной скоростью, то каждый кейфрейм будет вызывать лаг видео — ибо пока мы его целиком не примем, мы не можем отобразить ни его, ни любые последующие.
                            0
                            >>> установление соединения = задержки
                            так ли уж существенна задержка при подключении к камере? тем более что они выполняются параллельно. Накладные расходы не так велики, ибо у нас быстрее «кончится» сеть, чем вырастут накладные расходы в ОС и приложении (это я про передачу живого видео).

                            >>> точно так же передаётся в том виде в каком уходило бы и так
                            верно, но появляются затраты на мультиплексирование и демультиплексирование. кроме того видео и аудио перемешивается, что должно потребовать еще большего буфера декодера.

                            >>> Вот еще раз, на пальцах — есть кей-фрейм, весом в 260 пакетов
                            У декодера тоже есть своя скорость. Важно адаптивно подбирать размер буфера так, чтобы пока декодер работает буфер бы не переполнился, но и не был бы пустым к тому моменту как декодер освободится. Тогда флуктуации внутри буфера будут незаметны для декодера и видео будет плавным. Алгоритм jitter буфера описан в спецификации RTP. Я его не пробовал реализовывать, поэтому деталей не расскажу.
                              0
                              Вы сейчас всё говорите о посторонних вещах.

                              Главная и основная причина использования TCP для передачи видео от камеры к клиенту — что бы видео поменьше терялось и побольше доходило в условиях плохоконтролируемой агрессивной среды.

                                0
                                Так а кто спорит что TCP для надежной передачи? Но повторюсь, что в общем случае никаrих проблем нет, если сеть достаточно надежна. Т.е. в локальной сети проблем нет совсем, там хоть TCP, хоть UDP. Для интернета все зависит от того какой канал между камерой и медиасервером.
                                +1
                                итак, то есть камера должна буферизовать видео для обработки; затем буферизовать сжатое на случай потерь и еще дополнительно буферизовать чтобы сгладить сетевые пики; плюс отсылать не когда данные есть, а когда подойдёт время гладкости.
                                то есть мало того, что у нас есть задержки от обработки и энкодера, мы еще добавим задержку отправки по сети, и если приёмник вдруг захочет показывать сразу что приходит — пусть идиоты наблюдают рывки.

                                А, ну и при этом плевать что сеть 100 мбит а поток 8 мбит, утилизовать оставшиеся 92 никак не будем, чтобы избавиться от этих рывков. Главное, чтобы бедные программисты софта приемника не напрягались.
                                  0
                                  почему приемник не должен напрягаться? буфер присутствует и на приемнике.
                                    +1
                                    потому, что если до приемника дошло, он может просто показывать.
                                    если же передатчик посылает «как пришло так и посылаю» то мы никак в сети данные не сглаживаем и пульсации все на месте.
                                      0
                                      Антон, в идеале всё именно так, как ты описываешь.

                                      Передатчик получает со спутника константный битрейт видео, шлет монотонно, никто с таймстемпами нигде не сверяется, потому что аккуратно мультиплексированное видео на передатчике укладывает пакеты ровно по потоку и, следовательно, по времени.

                                      Всё это счастье было в глубокой древности CBR-а.
                          0
                          RTP interleaved RTSP. Данные идут в том же TCP канале, что и RTSP команды.

                          Разница в поведении TCP и UDP существенно тоньше чем «не будет работать и кино мы не увидим» и одна из этих тонкостей описывается в этой статье.
                  +3
                  Совсем не так!

                  Я про потроха линукса. Я не гуру, пересказываю, что знаю:

                  по приходу фреймов на сетевуху, они поступают в очередь. До определённого предела каждый пришедший кадр вызывает аппаратное прерывание, выше определённого, посылается прерывание, а все остальные кадры просто кладутся в очередь (irq throttling).

                  Далее: при обработке прерывания ОС делает минимальное количество телодвижений, после чего делает тасклет для дальнейшей обработки данных. Это так называемая «нижняя и верхние части прерываний». Верхняя часть прерываний скедулится когда удобно линуксу (и может быть прервана другими прерываниями).

                  Далее: сетевая карта бывает умной, в этом случае несколько кадров обрабатываются с помощью LRO/GRO (large recieve offload/generic recieve offload), в этом случае в часть уровней ОС пропускается, а TCP получает гигантский фрейм. В tcpdump'е это выглядит как пакет с размером в 8, а то и 16кб размером (это при выключенном jumbo). Сетевуха сама проверяет чексуммы, с минимальным участием сетевого стека проверяет номера сегментов и т.д.

                  Это не отменяет описанного в статье, просто процесс много более тонкий и сложный. Например, сетевуха с поддержкой нескольких процессоров способна под irq утилизовать все ядра (igb/ixbe). Есть сетевухи, которые могут утилизовать только одно ядро (e1000e, bmx). Вторые, очевидно, много хуже первых держат нагрузку.

                  Да, про десятки милисекунд обработки, это точно не так. Микросекунд — может быть. Не милисекунд точно.
                    +4
                    Общая обработка пакетов очень и очень утрирована — не она главное. Главное, что из канала в ОС пакет поступил, потерь в канале и на свичах — нет. Потерь на дровах — нет.
                    А десяток миллисекунд берётся из Task Scheduling'а — приложение тупо должно получить квант, прочитать что может, потом её вытеснят.
                    Но пакеты теряются на приложении… И это — обидно.
                      +2
                      Но если сетевая карта обрабатывает данные, то данные копятся в очереди уже не сетевой карты, а линукса (и там размер буфера много больше). В современных линуксах HZ — это 1000, то есть скедулинг происходит раз в 1ms, а не раз в 20мс, как это было при HZ50.

                      То есть я понимаю, что любое приложение может забить буферы TCP до неприличия, но мне кажется, что схема происходящего там должна быть сильно другая, чем в посте описывается.
                        +4
                        Таки забиваются не системные буфера, а вполне себе буфера конкретного приложения. И изменения SO_RCVBUF весьма значительно влияют на результат.
                        Схему происходящего восстанавливал опытом, матом и wireshark'ом. :(
                    +5
                    Показанный на видео «хрестоматийный глюк» является в большинстве своем свидетельством использования ffmpeg и говорит, как правило, о двух причинах:

                    1. Непонимание как работает ffmpeg
                    2. Транскодирование live видео вместо трансмуксинга все тем же ffmpeg

                    Чтобы настроить транскодирование с помощью ffmpeg надо хорошо «покурить» ffmpeg и проработать команду, которая в консоли займет строчки 3 минимум. Но транскодирование настолько ресурсоемкий процесс, что вряд ли можно будет смасштабировать такое решение. Надо использовать трансмуксинг. Чтобы настроить трансмуксинг, надо понимать как корректно сформировать тот же H264 поток и как его упаковать в контейнерный формат. Везде пишут что ffmpeg не стабильная штука, глючит, падает, ест память и т.д. Но по факту могу сказать, что он очень стабилен, но и сложен при этом в использовании, его надо еще и правильно собрать. Проблемы с его не стабильностью исключительно в непонимании матчасти. Занимаюсь проектом, где интенсивно используется ffmpeg, проблем нет, работает 24/7, потоки с камер не закрываются месяцами.

                    Кому интересно могу дать доступ посмотреть как работает тут demo.webglaz.net/
                      +1
                      на видео глюк еще до транскодирований — это просто показ во время настройки камеры. возможно, тут ffmpeg что-то и значит, но дело не в нем.
                        0
                        У вас там какой-то баг с калькулятором (смотреть на стоимость в месяц):

                        www.youtube.com/watch?v=iYX6gttOnc8
                          0
                          там много багов — это dev environment
                          0
                          ffmpeg стабилен, но только на этапе использования, а не настройки. Вам, вероятно, повезло, что вы не сталкивались с очевидными, и, что куда хуже, неочевидными багами в реализации демуксеров, муксеров, фильтров ffmpeg-а. Их, честно говоря, просто уйма, и желательно их всех знать. Спасибо, что напомнили. Пойду пофикшу давно бесящий меня баг с ремуксингом аудио в flv.
                            0
                            да нет, вкусил по полной, на шлифовку параметров ушел примерно год.
                          0
                          Не Linux, а Unix way.
                            0
                            Переключите камеру в 10 Mbit, если она позволяет, и все пойдет как по маслу.
                              0
                              Вы, вероятно, говорите о проблемах, связанных с декодером, как и habrahabr.ru/post/227483/#comment_7715897?
                                0
                                Это просто включается некий аппаратный шейпер, который очень хорошо сглаживает пики.
                                  0
                                  вряд ли шейпер поможет. такой артефакт может явиться следствием потери пакетов, декодер при этом пытается скомпенсировать недостаток пакетов и получается вот такой мусор. а почему пакеты теряются как раз подробно описано выше в статье.
                                    0
                                    Это очень помогает сгладить всплески от I фреймов на 100 Mbit, мы это используем в своих камерах когда в цепочки больше 3-x штук
                                    0
                                    а, ну логично, диффы весом почти в кейфрейм становятся :))
                                    при этом системный алгоритм адаптации TCP окна начинает лучше себя вести.
                                0
                                Не совсем понятно, вы жалуетесь на некий софт, который не может принимать большой поток? Тогда пишите прямо, что за софт и какие параметры заявлены производителем.
                                  0
                                  Это слишком популярный глюк, чтобы называть всех. Из крупных игроков — Trassir от DSSL, Axxon Next от ITV, VideoNet от Скайрос. Точно есть на актуальных версиях Trassir и Axxon Next, VideoNet тестировал 7й, сейчас актуальный 9й. Macroscop спокойно принимает, глюков и потерь нет. Всякую остальную мелочь без аналитики даже вспоминать и тестировать опять не хочу. А! На flussonic / erlyvideo — бага нет.
                                    0
                                    Да. Но flussonic пока без аналитики.

                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                Самое читаемое