Передача видео с глубоководного робота

Я это делал только средствами DirectDraw, который уже мёртв. Так то это к Videoman больше вопрос.

Передача видео с глубоководного робота

Создаёте столько буферов, сколько вам нужно, средствами DirectX. И все иные операции делаете этими же средствами.

Осторожнааа! Велобайк! Или 5 ошибок сервиса стоимостью в 1000 рублей

Так мы тут ещё и обсуждаем отношение у клиентам, а не кривую техническую реализацию. Это точно хабр?

Осторожнааа! Велобайк! Или 5 ошибок сервиса стоимостью в 1000 рублей

А, т.е. мы его слепили вот тут как-то в строго заданные временные рамки, а потом можно бабушку-вахтёршу посадить на саппорт и тёту Клаву на бухучёт. Ну и слесаря дядю Петю, чтоб велики с замками ремонтировал. Программисты в штате не нужны. Блин, да пусть даже и так. Потери связи — это вообще первое, о чём нужно думать и закладывать соответствующее поведение нужно на этапе проектирования системы. Если в велы заложен не тупой RFID, а нормальный Mifare, то вот через этот Mifare в велосипеде можно уже осуществлять обмен данными между паркингами в защищёном виде. Т.е. связь будет нужна только на парковке, на которой вы этот велосипед берёте. А вообще, довольно странно в описанном случае происходит — время-то поездки как-то отображается. Т.е. что, связь есть, и проблема не в этом? Или на велосипеде стоит свой отдельный бортовой компьютер?

Передача видео с глубоководного робота

Вот, кстати, как к профессионалу в данной области вопрос — что здесь лучше использовать как референс? Пытаться привязаться к вертикальной синхронизации монитора или использовать какой-то мультимедиа-таймер из DirectShow? Или на современном железе системные таймеры стали довольно точны?

Передача видео с глубоководного робота

В первую очередь ваш подход в случае аппаратного кодирования не годится потому, что всё будет рендерится в буферы, находящиеся в памяти видеокарты. Записав данные в эти буферы, не стоит пытаться их вычитать обратно, что-то там поделать средствами CPU чтобы в конечном итоге отрендерить всё видеокартой. Гонять трафик по шине взад вперёд — не самое лучшее, чем можно занять это железо.

Передача видео с глубоководного робота

На наколеночных тестах у меня год назад лучше всего себя в скорость DXVA показал именно MPC. При этом в качестве декодера он использовал LAV Filters. Это просто для информации :)

Осторожнааа! Велобайк! Или 5 ошибок сервиса стоимостью в 1000 рублей

Было дело мне на мегафон смски двое суток ходили. Разбивать палатку прям у велосипеда? И просто ждать смску, пока время тикает? Кто вообще придумал эту схему взаимодействия пользователя с сервисом?

Передача видео с глубоководного робота

Посмотрите на решения от Intel — https://software.intel.com/en-us/intel-media-server-studio Ничего не могу по ним сказать, кроме того, что качество кодирования у них ниже софтового варианта судя по отзывам, но вам не кино в IMAX показывать.

Передача видео с глубоководного робота

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

Осторожнааа! Велобайк! Или 5 ошибок сервиса стоимостью в 1000 рублей

Ёпрст. Ну как так-то? Для факта блокировки не нужна связь с облачком. Нужно физически заблокировать вел, считать его код по RFID и отпустить пользователя. На это нужно максимум три секунды. А дальше уже не отдавать велосипед никому до завершения предыдущей сессии.

Осторожнааа! Велобайк! Или 5 ошибок сервиса стоимостью в 1000 рублей

А какая разница? У них эти терминалы не умеют проставлять временные метки согласно своим внутренним часикам в случае отсутствия связи с облачком? Ну не было связи, так пусть синхронизирует позже, но с временной метка возврата, а с меткой занесения события в базу. Бред какой-то.

Передача видео с глубоководного робота

Поверьте, в IP-камерах стоят специализированные SoC, которые именно для этого и предназначены. Зачастую те-же SoC, что стоят в авторегистраторах и экшн-камерах, зачастую и более производительные. Да, можно взять камеры Prosilica от Alliedvision (https://www.alliedvision.com/en/products/cameras.html) или им подобные и подобрать более удачные параметры кодирования, придумать, как разместить и как питать ещё и отдельно стоящий видеосервер на этом агрегате. Но сколько будет стоить такая система? Время разработки тут не считаем, поскольку у этих камер отличное SDK и документация и получить с них изображение дело пары часов.

Передача видео с глубоководного робота

В любом случае с рисованием средствами GDI через равные интервалы вам не уйти от возможных разрывов изображения на две части на экране, связанных с отсутствием контроля вертикальной синхронизации. На записи этого не видно поскольку вы просто записываете то, что отрендерили, но при наблюдении в реальном времени наверняка этот эффект прослеживается. По хорошему, вам нужно максимально уйти от временных меток и за опорный сигнал брать вертикальную синхронизацию. Как это лучше сделать сейчас — не подскажу, первый и последний раз делал это давным давно силами DirectDraw, а его успешно закопали. Попробуйте поэкспериментировать с LAV Filters, возможно добьётесь ещё и аппаратного декодирования видео.

Передача видео с глубоководного робота

Моё вышестоящее сообщение было адресовано BalinTomsk. Для вас в нём содержится разве что объяснение причин мерцания, с которым вы столкнулись. Моё сообщение, которое вы потеряли, вы случайно отклонили при модерации, поэтому я первую часть вопроса по модемам продублировал выше. «я буду затирать любое окно покрывающее область рисования в том числе и элементы интерфейса» — вот тут я сильно сомневаюсь. Насколько помню, если вы получаете HDC от HANDLE конкретного элемента формы, то вы просто рисуете на нём. Все вышестоящие элементы должны остаться неповреждёнными, об этом думает винда, это её забота. Вы сможете из закрасить только в случае, если получите DeviceСontext от HANDLE, равного нулю, и будете на нём рисовать. Обработка WM_PAINT полезна в случае, если вам нужно перерисовать лишь часть вашего элемента, поскольку так можно получить конкретный регион, требующий перерисовки (который был перекрыт вышестоящим окном). В случае рисования в реальном времени от неё лучше уходить, кмк. Т.е. в repaint() вам вместо посыла форме сообщения на отрисовку можно было было бы сразу делать рендер, которые вы делаете в WM_PAINT. Но, задача решена, если все всех устраивает — то и замечательно.

Передача видео с глубоководного робота

Или вообще LAV Filters и получить ещё и аппаратный декодинг из коробки. Мои тесты на древних ATI-картах показывают, что три потока FullHD они на DXVA в параллели тянут без проблем. Четвёртый уже придётся декодировать программно.

Передача видео с глубоководного робота

Понимаю, что тут вопрос не совсем к вам, но но интересно было узнать, что это за модемы. Ибо стандартные модемы VDLS2 на 8a-Bandplan, ограниченные диапазоном в 8,5 Мгц, способны протащить порядка 10 Мбит/с в нисходящем потоке при длине линии в 2,5 км на кабеле ТПП 0,5 (от диапазона остаются рабочими на данной длине только 3 Мгц). Да, здесь иные напряжения в кабеле и иные уровни помех, но странно, что выбранные под это дело модемы обеспечивают столь малую дальность передачи. через 1 Мбит/с три FullHD картинки не протащить (да ещё и учётом ретрансмитов).

Передача видео с глубоководного робота

Для вашей задачи вообще оверлея в браузере было бы достаточно. Цитату, выдранную из контекста, вы сами до конца не поняли. Если начинать рисовать сразу на экране, а не использовать двойной (тройной etc) буфер, картинка может успеть отрисоваться монитором когда на ней будет сформирована лишь часть изображения. В итого получим мерцающее отображение отдельных элементов либо всего изображения целиком, если мы ещё и заливку чёрным фона делаем на первой стадии.

Передача видео с глубоководного робота

Камеры по RTSP уже отдают сжатый поток. При этом битрейт выбирается пользователем. Дальнейшие попытки его сжать приведут лишь к ухудшению качества/увеличению битрейта. Основная задача тут подобрать камеры, сжимающие максимально эффективно поток в рилтайм, обладающие нормальным буфером с нормальной реализацией RTSP-стриминга, ну и имеющие нормальную матрицу само собой.

WiFi-чайник в домашних условиях, или как сделать обычный чайник по-настоящему умным

Твердотельное реле само как-то ещё охлаждать нужно. Боюсь, внутри чайника ему придётся туго.