Pull to refresh
31
0
Send message
Какой write concern вы использовали для Mongo? Без его конкретизации не понятны результаты.
почему приемник не должен напрягаться? буфер присутствует и на приемнике.
Так а кто спорит что TCP для надежной передачи? Но повторюсь, что в общем случае никаrих проблем нет, если сеть достаточно надежна. Т.е. в локальной сети проблем нет совсем, там хоть TCP, хоть UDP. Для интернета все зависит от того какой канал между камерой и медиасервером.
А кто сказал, что в сложном проекте нельзя использовать то или иное решение? Камера может так или иначе попадать в VPN (либо с помощью спец прошивки, либо с помощью маршрутизатора) и делай с ней что хочешь, общайся по каким хочешь портам. Все ведь зависит от того какую систему делать. Если надо чтобы работало со всеми возможными камерами, то да, не вариант, а если это известные камеры, то почему нет.
>>> установление соединения = задержки
так ли уж существенна задержка при подключении к камере? тем более что они выполняются параллельно. Накладные расходы не так велики, ибо у нас быстрее «кончится» сеть, чем вырастут накладные расходы в ОС и приложении (это я про передачу живого видео).

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

>>> Вот еще раз, на пальцах — есть кей-фрейм, весом в 260 пакетов
У декодера тоже есть своя скорость. Важно адаптивно подбирать размер буфера так, чтобы пока декодер работает буфер бы не переполнился, но и не был бы пустым к тому моменту как декодер освободится. Тогда флуктуации внутри буфера будут незаметны для декодера и видео будет плавным. Алгоритм jitter буфера описан в спецификации RTP. Я его не пробовал реализовывать, поэтому деталей не расскажу.
>>> прямо параллельно с командами
верно, это называется interleaved режим. Но кто-нибудь может привести use case где надо использовать interleaved режим? Я вот не встречал. Это уже точно будет работать медленнее традиционной схемы. При этом если камера еще и со звуком, то придется мультиплексировать уже 4 потока (1 — видео, 2 — контроль видео, 3 — аудио, 4 — контроль аудио). Конечно так можно обойти ограничения на разрешенные порты и работать скажем с тем же 80 портом, но это внесет существенную задержку передачи потоков и усложнит систему.

>>> каким образом пульсации убирает RTP на примере h264?
h264 это payload. RTP является payload-agnostic, ему все равно хоть h264, хоть «крокодилы». На пальцах, jitter-буфер должен накапливать пакеты так, чтобы писатель мог писать в него с одной скоростью (или с variable скоростью), а читатель мог бы извлекать с constant скоростью, при этом чтобы буфер не переполнялся никогда и не был бы пуст, т.е. его размер должен быть адаптивным.
Что такое инкапсуляция внутри RTSP? Может вы tunneling имели ввиду? RTSP по отношению к TCP и к UDP работает одинаково, в том смысле, что RTSP всего навсего позволяет договориться в какие порты пойдут данные, а дальше он не участвует и ничего не инкапсулирует, до тех пор пока не потребуется закрыть сессию. Если сеть достаточно надежная и с достаточной пропускной способностью, то пульсаций и потерь не будет ни при TCP, ни при UDP, либо они будут не существенные. Если сеть не достаточно надежная или с не достаточной пропускной способностью, то ни TCP, ни UDP не будет работать и кино мы не увидим.
И все-таки «пульсаций» не должно быть, как минимум, теоретически. RTP протокол не зря считается real-time протоколом. В нем используется понятие jitter-буфера, так вот он как раз призван выравнивать поток. Если все грамотно реализовано, то между источником и потребителем будет непрерывный равномерный поток. Другое дело, что спецификацию либо игнорируют, либо не понимают. И если RTSP можно реализовать за несколько дней, то вот грамотная имплементация RTP/RTCP протоколов требует на порядок больше времени и глубокого понимания как RTP/RTCP спецификации, так и TCP/IP.
да нет, вкусил по полной, на шлифовку параметров ушел примерно год.
вряд ли шейпер поможет. такой артефакт может явиться следствием потери пакетов, декодер при этом пытается скомпенсировать недостаток пакетов и получается вот такой мусор. а почему пакеты теряются как раз подробно описано выше в статье.
Показанный на видео «хрестоматийный глюк» является в большинстве своем свидетельством использования ffmpeg и говорит, как правило, о двух причинах:

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

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

Кому интересно могу дать доступ посмотреть как работает тут demo.webglaz.net/
>>> разрулить с помощью property использование различных конфигов в контексте, в зависимости от окружения, невозможно.

Возможно:
<context:property-placeholder location="classpath:etc/env/${env}/app.properties" system-properties-mode="OVERRIDE" />
, где env задается как параметр JVM.
Т.е. Хабр для вас как бы есть, и как бы его нет. Вы чаще дома или на работе, чем на конференции. Т.е. Хабра для вас скорее нет, чем есть, а это уже похоже на необоснованный аскетизм или как будто у вас зависимость от Хабра и вы себя так от него ограждаете. Это как сладкоежке положить шоколад дома и на работе в специальный сейф и есть шоколад только на праздники, и то не из сейфа. Шоколад может себе спокойно лежать на столе или в холодильнике и не надо его сразу целиком съедать. Можно вполне сидеть рядом за столом и читать книжку.
Спасибо, в очередной раз напомнили, что гештальты и гештальтики надо завершать, а не накапливать, иначе они высосут нашу энергию, как неуклонно увеличивающееся количество потребителей и паразитных токов на нашем аккумуляторе. И если в автомобиле аккумулятор можно просто заменить, то мы такого позволить себе не можем.
Эволюция мира и эволюция человека неразделимы, если человек отстает от движения мира, то у него нарастает конфликт, который в худшем случае перерастает в глубокий кризис, а кризис в смерть…
Я бы посоветовал еще одну книжку в тему — «Чёрный лебедь», Н. Талеб
Совет — регулярный спорт

Я занимаюсь боксом три раза в неделю — пн, ср, пт. В пн на боксе и после бокса чувствую себя идеально, как психологически, так и физиологически. К среде начинаю постепенно «расшатываться», но вечерний бокс все «лечит» и т.д. Это конечно как своего рода «заплатка», но другого способа пока не нашел.

5 проектов — это много ) У меня было три работы в одно время (две софтверных компании и НИРы в аспирантуре) и тоже порядка 4-5 проектов. Тогда я не думал ни почему столько работаю, ни почему я устал в итоге. Сейчас я понял — я просто не знал чего я хотел — не было ЦЕЛИ.

Information

Rating
Does not participate
Registered
Activity