wingblack

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

Так я где-то в своих старых постах, в рамках изучения языка С#, предъявил Пикабу свою поделку - программу которая "конвертирует" любой файл в видео состоящее из цветных или черно-белых квадратиков, которое можно залить на ютуб (перекодировать), скачать, и все еще иметь возможность извлечь исходные данные (почти всегда) без ошибок.

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

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

А на днях я решил изучить язык Go (можно гуглить как Golang). Ну а поскольку учить нужно на практике... Да, снова взялся за ту же старую задумку, с учетом наработанного опыта по реализации старой идеи... ну почти...

На этот раз идея встала вокруг использования Twitch в качестве передачи данных онлайн. В принципе, можно использовать любую онлайн платформу для стриминга игр и прочего, лишь бы была возможность передавать видео не только через официальный клиент. Так, например, множество платформ принимают стрим по протоколу RTMP.

Ну и еще один очень важный момент - должна быть возможность скачивать стрим напрямую, в режиме онлайн. Так для Твича я использовал FFmpeg для стрима, и Youtube-dl + FFmpeg для скачивания трансляции.

На данном этапе программа еще не готова для публичного "потыкать" - к примеру командная строка не реализовна. На гитхаб репозиторий еще не делал но обязательно сделаю

В качестве теста работоспособности идеи я взял интернет радио в формате MP3 и его транслировал на Твич, записал прямой эфир и "конвертировал" обратно в MP3. Запись правда делал в ручном режиме, а потом конвертировал файл с видео, так как нужно было сначала просто проверить что так можно сделать, следующим шагом буду автоматизировать это.

Но хотя при прослушивании MP3 явных косяков не замечено, не исключено что не все так гладко, хоть Твич и позволяет смотреть исходный сигнал без перекодирования, что позволяет считать в кадрах видео ошибок не будет, но я предполагаю что какие-то кадры могут потеряться целиком (надеюсь что этого не будет).

Примерно так выглядит кадр из видео

Да, ч/б квадратики - решение далеко не оригинальное, даже сказать (на данном этапе работы над программой) это и есть сырые данные без доп обработки. Но использование такого формата, как показал мой опыт над предыдущей программой, является более предпочтительным, в том числе из-за простоты конвертации. Ну и размер файла раздувается примерно одинаково при разных примененных способах формирования квадратов, раз в 10, а бывает даже больше (при учете что видео делается так чтобы была возможность обратного преобразования). А я пробовал и квадраты разных цветов, и даже выдирал кусок кода из енкодера x264, то что касается  DCT и IDCT - для формирования соответствующих квадратов.

С учетом что наиболее важен размер, и не столько важно количество формируемых кадров, выбор ч/б квадратов считаю вполне оправданным.

Тут даже можно картинку полупрозрачную поверх рисовать, в теории, надо проверять как это повлияет на все факторы.

Сделав прогу с ч/б квадратами можно потом переделать и под что-то другое, закончить бы сначала :)

Из минусов такого способа "передачи данных" можно назвать один явный (то что это вообще никому нифига не нужно - пропустим :) ) - это то что это передача данных в один конец. Это ж трансляция, на нее невозможно напрямую отвечать. Если кто-то захочет использовать эту хрень для двунаправленной передачи данных, то нужно запускать отдельный стрим для каждого из участников.

Другой минус - что передача и получение большого объема данных требует существенных вычислительных затрат (нагрузка CPU). Плюс, я уже говорил, нужна ширина канала примерно в 10 раз больше исходного потока данных.

P.S. Нет, это не имеет отношение к стеганографии, и да это очевидно заметная передача данных. Если, как предлагали уже многие, пытаться скрывать данные за каким-нибудь фильмом, то доступная плотность данных резко уменьшится при увеличении вычислительной сложности.

По поводу незаметного использования игро-стриминговых платформ для передачи данных очевидно напрашивается создать что-то похожее на игру, но чтобы можно было легко соотнести происходящее на экране с определенными сообщениями. К этому будет сложнее придраться, но опять же плотность данных падает, а вычислительная сложность (хотя бы для случая декодирования) сильно возрастает.

Проект не претендует на новизну и полезность, так - бред недопрограммиста.

Вопрос к водителям квадрокоптеров.

Поделитесь опытом работы на новом сайте Системы предоставления планов полетов.

https://new.ivprf.ru

https://sppi.ivprf.ru

Раньше таким даже не интересовался, а тут захотелось попробовать официально запустить квадрокоптер на 500 м (DJI Mavic Air 2 выше не летает).

Основные вопросы:

- работает ли он в регионах (судя по старым гайдам раньше нужно было заходить на отдельный региональный сайт)

- какая общая схема работы - например, минимальный срок за сколько дней до того отправлять план полета, и надо ли что-то делать в день полетов и после него, может какие-то особенности заполнения формы заявки. (типа как правильно указывать высоту полета)

- в рамках работы на данном сайте есть ли какие-то особенности организации полетов в диспетчерских и прочих зонах (для меня такой цели сейчас не стоит, "проблемных" зон у меня нет, но в плане набивания собственных шишек возможно когда-нибудь все же придется более внимательно изучать и этот вопрос тоже).

На самом сайте то хоть и придумали раздел "Помощь" с понятными видеороликами по работе с сайтом, но там не освещаются нюансы не известные нубам, да и интересен именно частный случай с квадрокоптером до 30 кг, а то, например, там в видео для планов полетов БПЛА указывается аэропорт как точка взлета.

В идеале, конечно, посмотреть видео на ютубе с пояснениями, но про новый сайт не нашел таких (хоть и очень подозреваю что схема та же как и с старым сайтом).

В остальном же нахожу сайт по большей части весьма удобным, легко зарегистрировался как водитель БПЛА, добавил свой квадрокоптер и потыкал составление черновика плана полетов. Может в ходе постоянного использования и вылезут какие-нибудь косяки.

Да, что за метод диагностики и что за картинка с графиком в посте - описывается весьма скудно, и пост оказывается не более чем малоинформативной копипастой

Что ж, давайте разберемся.

Вот "информационный бюллетень" PDF в котором в общих чертах описываются методы измерения.

Есть облегченная версия опроса на английском (в научной статье идет речь о опросе который в целом занимает порядка 1.5 часа) по ссылке, перед самим опросом там дается обучающий материал, в котором все показано максимально доходчиво.

Собственно, содержимое обучалки:

Положение ушей

Положение вибрисов

Прикрытые глаза.

Напряжение морды (расслабленная или напряженная).

Положение головы относительно линии плеч. Опущена ли морда.

Ну и собственно, а что же было в картинке в "родительском" посте?

Если погуглить перевод заголовка, то это, оказывается, показатель насколько ответы респондентов согласуются между собой. Т.е. по ушам, глазам, они почти совпадают. По положению головы начинаются расхождения у обычных владельцев кошек, студенты ветеринарки отвечали уже получше. А уж по усам и морде ухудшение уже у всех. Т.е. людям сложнее определить что кошке плохо по морде и вибрисам.

Пусть гуру статистики меня поправят если я где-то ошибся. Вот ссылка на саму статью.