Начиная с этого года на моём Youtube канале стали выходить интервью. Среди гостей уже были и чёрные хакеры и бывший киберпреступник. Сейчас вышло интервью с одним из самых активных авторов раздела ИБ на Хабре - Лукой Сафоновым.

В первой части интервью Лука раскрыл следующие темы:

• история своего прихода в инфобез

• знакомство с инструментом Intercepter-NG

• любопытные и веселые случаи из жизни

• Работа в PentestIT и влияние пентест-лабораторий на специалистов по ИБ

• опыт содействия правоохранительным органам

• причина специализации на Web безопасности

• уязвимости на крупнейших ресурсах рунета

Сегодня вышла вторая часть интервью, в которой затронуты вопросы:

• пентесты

• программы багбаунти

• преподавательская деятельность

• используемые в работе операционные системы и security-инструменты

• Pentest VS Red Teaming

• текущая деятельность

• конкуренция среди ИБ компаний

• Whitehat VS Blackhat

• хобби, предпочтения в музыке

• ответы на вопросы подписчиков

Интервью получилось насыщенным и интересным. Приятного прослушивания.

В рамках этих выпусков организован розыгрыш.

Победителю достанется смартфон OnePlus 7 (8/256), на котором мною лично установлен полностью функционирующий дистрибутив Kali NetHunter.

С этим девайсом можно проводить аудит WiFi сетей, применять атаки типа BadUSB и многое другое.

Условия участия

Подписаться на Youtube канал.
Подписаться на Telegram канал.
Оставить любой комментарий с хештегом #хочудевайс под второй частью интервью.

Как только первая часть наберёт 10-000 просмотров - победитель будет выбран рандомным образом.

Как известно, у YouTube отсутствует фича захвата RTSP потока. Возможно, это сделано не случайно, а исходя из голой прагматики, чтобы люди не повесили на YouTube статическое видеонаблюдение за своими подъездами и не утилизировали его каналы, которые, как оказалось в пандемию, вовсе не резиновые. Напомним, что некоторое время назад имели место истории с ухудшением и ограничением качества стримов до 240p. Или есть еще одно предположение: стримы с IP камер это зло для YouTube, потому что у них чуть более ноля зрителей, на которых не накрутишь миллион просмотров рекламы. Так или иначе, фича не представлена, и мы постараемся заполнить этот пробел - помочь YouTube осчастливить пользователей.

Допустим, мы хотим взять обычную уличную IP камеру, которая отдает H.264 поток по RTSP и перенаправить ее на YouTube. Для этого потребуется принять RTSP поток и сконвертировать в RTMPS поток, который принимает YouTube. Почему именно в RTMPS, а не RTMP? Как известно несекьюрные протоколы отмирают. HTTP предан гонениям, и его участь постигла другие протоколы, не имеющие буквы S - значит Secure на конце. От RTMP потока отказался Facebook, но спасибо, оставил RTMPS. Итак, конвертируем RTSP в RTMPS. Делаем это Headless способом (без использования UI), т.е. на сервере.

Для одного RTSP потока потребуется один YouTube аккаунт, который будет принимать поток. Но что делать если камер не одна, а много?

Да, можно насоздавать вручную несколько YouTube-аккаунтов, например, чтобы покрыть видеонаблюдением приусадебный участок. Но это с огромной вероятностью нарушит условия пользовательского соглашения. А если камер не 10, а все 50? Создавать 50 аккаунтов? А дальше что? Смотреть это как? В этом случае на помощь может прийти микшер, который объединит камеры в один поток.

Посмотрим, как это работает на примере двух RTSP камер. Результирующий поток mixer1 = rtsp1 + rtsp2. Отправляем стрим mixer1 на YouTube. Все работает - обе камеры идут в одном потоке. Здесь стоит заметить, что микширование - достаточно ресурсоемкая по использованию CPU операция.

При этом, так как мы уже имеем RTSP поток на стороне сервера, мы можем перенаправить этот поток на другие RTMP endpoints, не неся при этом дополнительных расходов по CPU и памяти. Просто снимаем трафик с RTSP стрима и тиражируем на Facebook, Twitch, куда угодно без дополнительного RTSP захвата и депакетизации.

Меня, как девопса, будет мучать совесть, если я не заскриптую то, что можно было бы заскриптовать. Автоматизации способствует наличие REST API для управления захватом видео с камеры и ретрансляцией.

Например, с помощью запроса:

/rtsp/startup

можно захватить видеопоток от IP камеры.

Запрос:

/rtsp/find_all

позволит получить список захваченных сервером RTSP потоков.

Запрос для завершения RTSP сессии выглядит так:

/rtsp/terminate

Захватом и ретрансляцией видеопотоков можно управлять или с помощью простого браузера и любого удобного REST клиента, или с помощью минимального количества строчек кода встроить функционал управления сервером в свой web проект.

Давайте подробно рассмотрим, как это можно сделать.

Небольшой мануал, как с помощью минимального кода организовать Live трансляцию на YouTube и Facebook

В качестве серверной части мы используем demo.flashphoner.com. Для быстрого развертывания своего WCS сервера воспользуйтесь этой инструкцией или запустите один из виртуальных инстансов на Amazon, DigitalOcean или в Docker.

Предполагается, что у вас имеется подтвержденный аккаунт на YouTube и вы уже создали трансляцию в YouTube Studio, а так же создали прямую видеотрансляцию в своем аккаунте на Facebook.

Для работы Live трансляций на YouTube и Facebook нужно указать в файле настроек WCS flashphoner.properties следующие строки:

rtmp_transponder_stream_name_prefix= Убирает все префиксы для ретранслируемого потока.

rtmp_transponder_full_url=true В значении "true" игнорирует параметр "streamName" и использует RTMP адрес для ретрансляции потока в том виде, в котором его указал пользователь.

rtmp_flash_ver_subscriber=LNX 76.219.189.0 - для согласования версий RTMP клиента между WCS и YouTube.

Теперь, когда все подготовительные действия выполнены, перейдем к программированию. Разместим в HTML файле минимально необходимые элементы:

Подключаем скрипты основного API и JS скрипт для работы live трансляции, который мы создадим чуть позже:

 <script type="text/javascript" src="../../../../flashphoner.js"></script> <script type="text/javascript" src="rtsp-to-rtmp-min.js"></script>

Инициализируем API на загрузку web-страницы:

<body onload="init_page()">

Добавляем нужные элементы и кнопки поля для ввода уникальных кодов потоков для YouTube и Facebook, кнопку для републикации RTSP потока, div элемент для вывода текущего статуса работы программы и кнопку для остановки републикации:

<input id="streamKeyYT" type="text" placeholder="YouTube Stream key"/><input id="streamKeyFB" type="text" placeholder="FaceBook Stream key"/><button id="repubBtn">Start republish</button><div id="republishStatus"></div><br><button id="stopBtn">Stop republish</button>

Затем переходим к созданию JS скрипта для работы републикации RTSP. Скрипт представляет собой мини REST клиент.

Создаем константы:

Константа "url", в которую записываем адрес для запросов REST API . Замените "demo.flashphoner.com" на адрес своего WCS.

Константа "rtspStream" указываем RTSP адрес потока с IP камеры. Мы для примера используем RTSP поток с виртуальной камеры.

var url = "https://demo.flashphoner.com:8444/rest-api";var rtspStream = "rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov"

Функция "init_page()" инициализирует основной API при загрузке web - страницы. Так же в этой функции прописываем соответствие кнопок вызываемым функциям и вызываем функцию "getStream", которая захватывает RTSP видеопоток с IP камеры:

function init_page() {Flashphoner.init({});repubBtn.onclick = streamToYouTube;stopBtn.onclick = stopStream;getStream();}

Функция "getStream()" отправляет на WCS REST запрос /rtsp/startup который захватывает видеопоток RTSP адрес которого был записан в константу rtspStream

function getStream() {    fetchUrl = url + "/rtsp/startup";    const options = {        method: "POST",        headers: {            "Content-Type": "application/json"        },        body: JSON.stringify({            "uri": rtspStream        }),    }    fetch(fetchUrl, options);console.log("Stream Captured");}

Функция "streamToYouTube()" републикует захваченный видеопоток в Live трансляцию на YouTube:

function streamToYouTube() {fetchUrl = url + "/push/startup";const options = {        method: "POST",        headers: {            "Content-Type": "application/json"        },        body: JSON.stringify({            "streamName": rtspStream,"rtmpUrl": "rtmp://a.rtmp.youtube.com/live2/"+document.getElementById("streamKeyYT").value        }),    }  fetch(fetchUrl, options);streamToFB()}

Эта функция отправляет на WCS REST вызов /push/startup в параметрах которого передаются следующие значения:

"streamName" - имя потока, который мы захватили с IP камеры. Имя потока соответствует его RTSP адресу, который мы записали в константу "rtspStream"

"rtmpUrl" - URL сервера + уникальный код потока. Эти данные выдаются при создании Live трансляции в YouTube Studio. В нашем примере мы жестко закрепили URL в коде, вы можете добавить для него еще одно поле на свою web страницу. Уникальный код потока указывается в поле "streamKeyYT" на нашей Web странице.

Функция "streamToFB" републикует захваченный видеопоток в Live трансляцию на Facebook:

function streamToFB() {fetchUrl = url + "/push/startup";const options = {        method: "POST",        headers: {            "Content-Type": "application/json"        },        body: JSON.stringify({            "streamName": rtspStream,"rtmpUrl": "rtmps://live-api-s.facebook.com:443/rtmp/"+document.getElementById("streamKeyFB").value        }),    }  fetch(fetchUrl, options);document.getElementById("republishStatus").textContent = "Stream republished";}

Эта функция так же отправляет на WCS REST вызов "/push/startup" в параметрах которого передаются значения:

"streamName" - имя потока, который мы захватили с IP камеры. Имя потока соответствует его RTSP адресу, который мы записали в константу "rtspStream"

"rtmpUrl" - URL сервера + уникальный код потока. Эти данные можно найти на странице Live трансляции в Facebook в секции Live API. Url сервера в этой функции мы указали в коде, как и для функции републикации на YouTube. Уникальный код потока берем из поля "streamKeyFB" на Web странице.

Функция "stopStream()" отправляет RTSP запрос "/rtsp/terminate" который прекращает захват потока с IP камеры на WCS и соответственно прекращает публикации на YouTube и Facebook:

function stopStream() {fetchUrl = url + "/rtsp/terminate";    const options = {        method: "POST",        headers: {            "Content-Type": "application/json"        },        body: JSON.stringify({            "uri": document.getElementById("rtspLink").value        }),    }    fetch(fetchUrl, options);document.getElementById("captureStatus").textContent = null;document.getElementById("republishStatus").textContent = null;document.getElementById("stopStatus").textContent = "Stream stopped";}

Полные коды HTML и JS файлов рассмотрим немного ниже.

Итак. Сохраняем файлы и пробуем запустить.

Последовательность действий для тестирования

Создаем Live трансляцию в YouTube Studio. Копируем уникальный код видеопотока:

Открываем созданную ранее HTML страницу. Указываем в первом поле уникальный код видеопотока, который мы скопировали на YouTube:

Создаем Live трансляцию в своем аккаунте на Facebook. Копируем уникальный код видеопотока.

Возвращаемся на нашу web страничку, вставляем скопированный код во второе поле и нажимаем кнопку "Start republish

Теперь проверяем работу нашей републикации. Снова переходим в YouTube Studio и на Facebook, ждем несколько секунд и получаем превью потока.

Для завершения републикации нажмите кнопку "Stop"

Теперь, как и обещали, исходные коды примера полностью:

Листинг HTML файла "rtsp-to-rtmp-min.html"

<!DOCTYPE html><html lang="en">    <head>        <script type="text/javascript" src="../../../../flashphoner.js"></script>        <script type="text/javascript" src="rtsp-to-rtmp-min.js"></script>    </head>    <body onload="init_page()">        <input id="streamKeyYT" type="text" placeholder="YouTube Stream key" /> <input id="streamKeyFB" type="text" placeholder="Facebook Stream key" /> <button id="repubBtn">Start republish</button>        <div id="republishStatus"></div>        <br />        <button id="stopBtn">Stop republish</button>    </body></html>

Листинг JS файла "rtsp-to-rtmp-min.js":

var url = "https://demo.flashphoner.com:8444/rest-api";var rtspStream = "rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov"function init_page() {    Flashphoner.init({});    repubBtn.onclick = streamToYouTube;    stopBtn.onclick = stopStream;    getStream();}function getStream() {    fetchUrl = url + "/rtsp/startup";    const options = {        method: "POST",        headers: {            "Content-Type": "application/json"        },        body: JSON.stringify({            "uri": rtspStream        }),    }    fetch(fetchUrl, options);    console.log("Stream Captured");}function streamToYouTube() {    fetchUrl = url + "/push/startup";    const options = {        method: "POST",        headers: {            "Content-Type": "application/json"        },        body: JSON.stringify({            "streamName": rtspStream,            "rtmpUrl": "rtmp://a.rtmp.youtube.com/live2/" + document.getElementById("streamKeyYT").value        }),    }    fetch(fetchUrl, options);    streamToFB()}function streamToFB() {    fetchUrl = url + "/push/startup";    const options = {        method: "POST",        headers: {            "Content-Type": "application/json"        },        body: JSON.stringify({            "streamName": rtspStream,            "rtmpUrl": "rtmps://live-api-s.facebook.com:443/rtmp/" + document.getElementById("streamKeyFB").value        }),    }    fetch(fetchUrl, options);    document.getElementById("republishStatus").textContent = "Stream republished";}function stopStream() {    fetchUrl = url + "/rtsp/terminate";    const options = {        method: "POST",        headers: {            "Content-Type": "application/json"        },        body: JSON.stringify({            "uri": rtspStream        }),    }    fetch(fetchUrl, options);    document.getElementById("republishStatus").textContent = "Stream stopped";}

Для минимальной реализации требуется совсем немного кода. Конечно для итогового внедрения функционала еще потребуется небольшая доработка напильником - добавить стили на web страницу и разные проверки на валидность данных в код JS скрипта. Но это работает.

Удачного стриминга!

Ссылки

Наш демо сервер

WCS на Amazon EC2 - Быстрое развертывание WCS на базе Amazon

WCS на DigitalOcean - Быстрое развертывание WCS на базе DigitalOcean

WCS в Docker - Запуск WCS как Docker контейнера

Трансляция WebRTC видеопотока с конвертацией в RTMP - Функции сервера по конвертации WebRTC аудио видео потока в RTMP

Трансляция потокового видео с профессионального устройства видеозахвата (Live Encoder) по протоколу RTMP - Функции сервера по конвертации видеопотоков от Live Encoder в RTMP

HTML5-трансляции с RTSP-IP камер - Функции сервера по воспроизведению RTSP видеопотоков

Привет, Хабр!

Меня зовут Алексей Жуков. Более 10 лет вместе с командой разработчиков я занимаюсь созданием и дизайном приложений и интернет-платформ. В статье хочу поделиться своим видением трендов на рынке видеоконтента. Разберемся в том, что будет после пандемии и что учесть при создании приложения для зумеров.

В 2020 году видеоконтент стал важнейшей частью интернет-потребления. Его популярность отчасти связана с миллениалами и поколением Z. Именно они не видят свою жизнь без интернета и предпочитают развлекаться или узнавать новое из онлайн-видео. Согласно результатам опроса YouTube, 50% людей в обоих поколениях заявили, что они "не могут жить" без видео в своей повседневной жизни.

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

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

Видеоролики брендов вышли на первое место

В прошлом пользователи использовали широкий набор источников для получения информации о продукте: веб-сайты брендов, онлайн-обзоры, рекламные ролики, видеоролики на YouTube. Теперь, когда видео доступно во всех крупных соцсетях, они больше полагаются на видеоконтент: демонстрации продуктов, видео-обзоры, распаковки, учебные пособия. Этот контент намного более аутентичен, чем отретушированный снимок продукта.

Пользователи хотят расслабиться и убежать от реальности

В прошлом зрители включали телевизор и ходили в кино, чтобы отвлечься от стресса. Сегодня потребность в расслабляющем или развлекательном контенте никуда не ушла. Первая и основная причина, почему пользователи YouTube смотрят видео это развлечение и отдых. В ТОП-7 рейтинга причин входят также возможность посмеяться и желание забыть об окружающем мире.

Профессионализм видеооператора не важен

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

Причины, по которым зрители смотрят видео, далеки от таких пунктов, как высокое качество производства и популярность актеров. Более того, миллениалы и поколение Z целенаправленно предпочитают контент, создаваемый обычными пользователями, а не профессиональными студиями.

Зумеры предпочитают длинные видео

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

Что предлагает рынок обработки медиаконтента

Рынок мобильных приложений для обработки фото- и видеоконтента постоянно пополняется новыми игроками как в России, так и на Западе. Однако это не значит, что спрос на такие продукты растет. Скорее, растет генерация визуального контента пользователями. От этого, в первую очередь, выигрывают социальные гиганты, Instagram, TikTok, которые идеально отвечают желанию самовыражения. Если говорить о приложениях, основной функцией которых является обработка медиаконтента, то здесь я бы выделил InShot, Splice, VivaVideo, Prequel, Instories.

Чего хотят зумеры

Зумеры практически родились с гаджетом в руках, поэтому им недостаточно просто снять видео. В условиях, когда видео снимают все кому не лень, на первое место выходит фактор уникальности контента. Это подтолкнуло к появлению самого сильного тренда, который мы до сих пор наблюдаем создание Stories. Маски, в свою очередь, постепенно теряют популярность, хотя имеют потенциал возродиться в каком-то другом виде. Возможно, здесь сказывается то, что последние полгода пользователям и так пришлось их носить постоянно.

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

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

Здесь нужно смотреть глубже. Важна не обертка видео, а пользовательский кейс, сценарий, повод, ради которого человек решил что-то снять и опубликовать. Узкопрофильные приложения, отлично справляющиеся с одной конкретной задачей, а не мультикомбайны, пытающиеся повторить функционал Adobe Premiere Pro или iMovie вот новый тренд в этой отрасли. Свежими примерами можно назвать Boomerang или Hyperlapse от Instagram.

Что будет после пандемии

Пандемия COVID-19 заметно подстегнула интерес к подобным приложениям. Запросы некоторых игроков увеличились вдвое. Но это временное явление, уже виден спад пользовательской активности. А гиганты рынка и вовсе остались на прежнем уровне поисковых запросов. Очевидно, режим самоизоляции стимулировал людей обратиться к своей медиаколлекции прошлых лет и отпусков, чтобы продолжить свою активность в соцсетях. Это само по себе тоже можно назвать краткосрочным трендом.

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

Какие приложения выиграют

Очевидно, выигрывают специализированные приложения. Здесь нужно держать руку на пульсе своей аудитории и запускать кросс-проекты. Отличным примером может служить история со Stories в Instagram и приложения, позволяющие сделать Stories интереснее и разнообразнее.

Также в выигрыше будут продукты, позволяющие обрабатывать видео в реальном времени. Это сильно снижает время, которое пользователь тратит на создание контента, то есть время использования приложения. И, как ни парадоксально, это же повышает привязку человека к таким продуктам, поскольку он получает результат практически мгновенно.

Мобильные редакторы медиаконтента сильно похожи друг на друга. У них почти одинаковый набор функций и пользовательский интерфейс. Здесь победит тот, кто максимально удобно и быстро решает задачу. Например, Splice предлагает очень комфортный процесс создания видео, шустрый рендеринг и подгрузку дополнительных медиаресурсов, будь то эффекты, музыка или текст.

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

Я бы посоветовал разработчикам таких приложений отойти от общей схемы построения интерфейсов и прислушаться к самим пользователям мобильных платформ. Полезно будет также анализировать действия людей в вашем продукте и отслеживать изменения метрик за счет сплит-тестирования. Это позволит улучшить опыт без полной переделки дизайна.

Как создать приложение для зумеров

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

1. Идея

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

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

2. Целевая аудитория

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

3. Удобство

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

Неплохо начать с версии MVP (minimum viable product минимально жизнеспособный продукт). Как только пользователи привыкнут к приложению, изучите аналитику и их отзывы. Таким образом, вы получите представление о функциях, которые они предпочитают, например:

• добавление звуковых эффектов или дорожек;

• объединение нескольких файлов в один (как видео, так и фотографии);

• обрезка видеоролика или добавление кадров;

• расширенные правки (экспозиция, насыщенность, контраст, температура, оттенки, тени и т. д.);

• редактирование во время записи с помощью специальных эффектов, фильтров и текстур;

• функции совместного использования соцсетей;

• сохранение видеоролика в нескольких форматах.

4. Монетизация

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

5. Интеграция с соцсетями

Интеграция с соцсетями это самый важный элемент для любого подобного приложения. Зумеры могут одновременно вести активную жизнь в семи и более соцсетях. Поэтому как только пользователь создаст интересный контент, он захочет мгновенно поделиться им в TikTok, Instagram, Twitter и т. д. Необходимо добавить как можно больше каналов в приложение, чтобы исключить рутинные операции.

Каждое поколение рождает новые запросы и потребности. То, что важно для миллениалов и поколения Z, не так важно для бумеров. Сейчас зумеры формируют тренды на рынке мобильных приложений для создания визуального контента.

На подходе поколение альфа. Пока специалисты лишь строят предположения о том, что от них ожидать. Возможно, с ними мы переживем еще более глубокое проникновение визуальной информации в повседневную жизнь. Именно они станут драйвером роста AR/VR-соцсетей, полноценными хозяевами совершенно нового виртуального пространства, в котором маски и Stories останутся приятным напоминанием о старом мире.

Продолжаем "изобретать" свой медиацентр. Начало здесь - KODI. Как я собирал свой самый удобный и функциональный медиацентр для дома. Часть 1.

Содержание:

1. Просмотр YouTube

2. Внешнее управление медиацентром и системой

   1. Управление qBittorrent (веб-интерфейс и мобильное приложение для Android)

   2. Управление KODI Android-устройством (Yatse, Kore)

   3. Веб-интерфейс KODI и Elementum

3. Учет трафика медиацентра (vnStat + веб-интерфейс)

4. Резервное копирование KODI

1. Просмотр YouTube

Было бы странно иметь современный медиацентр без возможности просмотра роликов на самом популярном видеохостинге - YouTube. Для этого есть одноименное дополнение из официального репозитория. Дополнение отлично взаимодействует и синхронизирует историю, каналы, подписки и прочее. Все как у всех. Что-то особо описывать и обозревать не вижу смысла.

Единственное, с чем могут возникнуть проблемы с авторизацией на сервисе. Для этого необходимо в консоли приложений Google создать API-проект и получить идентификатор клиента, ключ API и cсекретный код клиента. Только имея эти данные вы сможете авторизовать дополнение. На просторах сети достаточное количество пошаговых инструкций. Например, одна из них на overclockers.ru.

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

2. Внешнее управление медиацентром и системой

Построив такой умный медиацентр, было бы не лишним иметь возможность управлять всеми процессами не только с самого медиацентра и подключенного в него пульта ДУ или клавиатуры/мыши.

Возможность удаленного администрирования Ubuntu по SSH-протоколу реализовали, VNC-подключение есть. Все исправно работает как с Windows, так и c Android-устройств (если пропустили, смотрите разделы 2 и 5 предыдущей публикации).

2.1. Управление qBittorrent (веб-интерфейс и мобильное приложение на Android)

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

Для этого в настройках qBittorrent включить использование веб-интерфейса, задав логин/пароль и порт. Я указываю 8081, если помните порт 8080 мы указывали в настройках KODI, он уже занят.

Теперь можем проверить доступность веб-интерфейса. Он полностью повторяет интерфейс самого приложения, работает без нареканий - рекомендую!

Помимо веб-интерфейса, использую и приложение на android-устройствах - qBittorrent Controller. Настроить подключение к вашему серверу не сложно. Вам понадобиться все тот же порт, логин и пароль.

2.2. Управление KODI Android-устройством (Yatse, Kore)

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

Для Android-платформ на выбор есть два варианта:
Kore официальное бесплатное приложение;
Yatse стороннее платное ($3.56). Большинству будет достаточно и бесплатного функционала.

Оба варианта отлично справляются со своими задачами. Для подключения используется порт 8080 и логин/пароль, заданный при первоначальной настройке KODI. Оба приложения позволяют управлять просмотром IPTV и контента из библиотеки, дополнениями. Библиотека кэшируется и доступна без подключения к медиацентру, просматривать информацию о фильмах и сериалах можно за пределами домашней сети. Хочется отметить, что Yatse с этим справляется немного лучше. Например, моя библиотека, наполненная исключительно онлайн контентом из Elementum, отображается со всеми постерами и изображениями, Kore отображает только локальные. С логотипами каналов из m3u8-плейлиста IPTV не справляется ни одно приложение, если логотипы локальные отобразят оба.

Из отличительного функционала обоих приложений, хотелось бы выделить интеграцию с Android. На любом медиафайле из контекстного меню можно выбрать пункт Воспроизведение на медиацентре KODI. Итого, любую фотографию, видео или аудиофайл, буквально в несколько кликов вы можете отправить на большой экран вашего телевизора. Еще более приятно - из приложения YouTube на своем телефоне/планшете вы можете нажать Поделиться и также выбрать Воспроизведение на медиацентре KODI - видеоролик мгновенно начнет воспроизведение на вашем телевизоре. По этой причине, кстати, я не использую дополнение YouTube, о котором недавно шла речь, хоть оно установлено и подключено к аккаунту. Гораздо удобнее и быстрее проигрывать ролики с телефона, чем из дополнения.

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

Какое выбрать решать вам. Лично я отдаю предпочтение Yatse. Больше возможностей даже в бесплатной версии, гибкие настройки и более привлекательный интерфейс.

Таким не хитрым способом можно проиграть любой медиа-файл с вашего телефона на телевизоре. Это же работает и в приложении YouTube

2.3. Веб-интерфейс KODI и Elementum

Также для удаленного управления у медиацентра есть и веб-интерфейс. Для доступа необходим все тот же порт (8080) и логин/пароль. Функционал довольно-таки ограниченный, но его вполне достаточно для просмотра и запуска контента из библиотеки и IPTV. Взаимодействие с дополнениями также поддержано. Внешний вид веб интерфейса можно изменить, доступно несколько вариантов из стандартного официального репозитория KODI.

Свой веб-интерфейс также имеет и дополнение Elementum. Позволяет просматривать текущее состояние торрентов, добавлять новые из файла или magnet-ссылки, а также удалять уже имеющиеся. Из него также можно напрямую запустить воспроизведение торрента на медиацентре.

3. Учет трафика медиацентра (vnStat + веб-интерфейс)

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

Для простого учета и отображения статистики отлично подойдет vnStat - легковесная программа для мониторинга сетевого трафика для операционной системы Linux с использованием интерфейса командной строки. Программа будет следить не за нашим KODI, а за сетевым интерфейсом. Это именно то, что нужно, так как помимо KODI, работает еще и qBittorrent.

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

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

Методом перебора нашел последнюю поддерживаемую версию vnStat 1.14. В репозиториях Ubuntu ее уже нет. Можно скачать из репозитория моего GitHub.

Скачиваем и устанавливаем нужную версию

wget https://github.com/arboozov/kodi/raw/master/vnstat_1.14-1ubuntu2_amd64.debsudo dpkg -I vnstat_1.14-1ubuntu2_amd64.deb

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

sudo apt-mark hold vnstat

Создаем БД для нашего сетевого интерфейса (в моем случае это enp1s0)

vnstat -i -u enp1s0

Устанавливаем и запускаем веб-сервер

sudo add-apt-repository ppa:ondrej/phpsudo apt-get updatesudo apt-get install apache2 php5.6 php5.6-gd wget libapache2-mod-php5.6sudo service apache2 restart

Теперь необходимо загрузить и разместить сам веб-интерфейс на нашем медиацентре. Можно использовать оригинальный вариант с сайта разработчика, либо немного измененный мой вариант. Глобальных правок я не вносил, но немного подправил внешний вид, цвета, убрал лишнее и скорректировал расчет суммарного объема входящего/исходящего трафика в ТБ.

Загружаем, например, мой вариант

wget https://github.com/arboozov/kodi/raw/master/jsvnstat.zip

Распаковываем архив по пути /var/www/html/stat/

unzip jsvnstat.zip -d /var/www/html/stat/

Задаем параметру $interface наш сетевой интерфейс, с которым будем работать, сохраняем изменения

mcedit /var/www/html/stat/settings.php

Настройка завершена, переходим по адресу http://IP-адрес_вашего_медиацентра/stat/. Если все сделано верно отобразится наш веб-интерфейс с анализом трафика с момента установки пакета. БД по умолчанию будет обновляться автоматически каждые 5 минут.

4. Резервное копирование KODI

Медиацентр с KODI на борту, обросший дополнительными возможностями на базе Kubuntu 20.04, полностью настроен и готов к работе. На этом этапе стоит задуматься над резервным копированием и сохранением всего, что сделано, в этом первоначальном состоянии. Не будем недооценивать стабильность и надежность работы нашей операционной системы, но на случай выхода из строя аппаратной части, того же SSD-накопителя, например, хотелось бы иметь возможность быстро восстановить работу, причем в том же состоянии, с наименьшими усилиями. С нуля производить установку и настройку снова сомнительное удовольствие.

Рекомендую иметь хотя бы одну копию (например, первоначального состояния) всей системы. Я сохранил образ диска с помощью Clonezilla. Имея такую копию, без особого труда, можно сказать в пару кликов, меняем накопитель и поднимаем Kubuntu со всеми настройками. Подробно описывать порядок снятия или установки образа не буду. Кто не сталкивался с работой Clonezilla хорошая инструкция на русском языке со скриншотами на losst.ru.

Что касается резервирования самого KODI, то я выполняю копирование с помощью программного дополнения Backup из официального репозитория в автоматическом режиме 1 раз в неделю. Никакого участия от меня в этом не требуется, нужно лишь один раз все правильно настроить.

Так как у меня медиацентр работает и подключен к сети круглосуточно, работу планировщика настроил на еженедельное копирование всех данных KODI в понедельник в 4:00 с хранением двух копий в архиве. То есть, условно, на третей неделе, при резервном копировании будет удалена самая старая копия (с первой недели).

Но где же хранить резервные копии? Хранить под собой на том же диске выстрел себе в ногу, на такой бэкап можно даже не тратить время. Сетевой каталог на другом домашнем хосте в моем случае не вариант, ночью все ПК выключены, днем тоже нет постоянного графика. Включать, например, в ночь каждого понедельника (по моему расписанию) домашний компьютер сомнительная автоматизация. Хотелось бы не участвовать в этом процессе от слова совсем.

Dropbox

Дополнение поддерживает интеграцию с этим популярным файловым хостингом. Подключение не сложное. Необходимо через консоль в личном кабинете сервиса создать приложение для работы с API, предоставить ему необходимый доступ (чтение, запись и удаление), а полученные ключи указать дополнению и авторизоваться. Для авторизации Backup сгенерирует ссылку, перейдя по которой Dropbox сгенерирует код валидации для подтверждения. Работает все очень хорошо, за одним исключением. Авторизации хватает на одну сессию. После перезапуска KODI авторизоваться необходимо повторно. Без авторизации, понятное дело, резервная копия не будет загружена на хостинг. Как итог, процесс опять же требует нашего вмешательства вариант нам не подходит.

Яндекс.Диск

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

В разделе Управление аккаунтом Яндекс.Диска создаем пароль приложения по WebDAV API.

Для работы с WebDAV API в Ubuntu, устанавливаем в систему пакет davfs2

sudo apt-get install davfs2

Создаем каталог, куда будем монтировать наш Яндекс.Диск и назначаем права

sudo mkdir /mnt/yandex.disksudo chmod -R 0777 /mnt/yandex.disk

Добавляем аккаунт нашего Яндекса в davfs2, где:
логин имя пользователя в сервисе Яндекс, без @домена
пароль ID, созданный в паролях приложений аккаунта Яндекс.Диск

echo "https://webdav.yandex.ru логин пароль" >> /etc/davfs2/secrets

Монтируем в директорию /mnt/yandex.disk

sudo mount -t davfs https://webdav.yandex.ru /mnt/yandex.disk

Конфигурируем fstab, чтобы монтирование Яндекс.Диска в наш каталог происходило автоматически, при старте системы

sudo mcedit /etc/fstab

Вставить в конец файла

https://webdav.yandex.ru:443 /mnt/yandex.disk davfs user,rw,_netdev 0 0

Осталось лишь указать наш каталог в настройках дополнения Backup.

Не будем дожидаться ближайшей ночи понедельника и запустим создание резервной копии вручную. После года работы KODI, объем данных для резервирования у меня составляет 1.61 Гб, после архивации 1.35 Гб. В верхнем правом углу будет выводиться информация о ходе выполнения резервной копии.

Google Drive

По аналогии можно настроить бэкап KODI и на сервис от Google. Отличие будет лишь в монтировании его в систему. Приступаем.

Нам понадобится пакет google-drive-ocamlfuse. Добавляем в систему репозиторий, обновляем список пакетов и устанавливаем

sudo add-apt-repository ppa:alessandro-strada/ppasudo apt-get updatesudo apt-get install google-drive-ocamlfuse

Создаем директорию, куда будем монтировать и назначаем права

sudo mkdir /mnt/google.drivesudo chmod -R 0777 /mnt/google.drive

Теперь необходимо из-под пользователя (не sudo), авторизованного в системе из консоли выполнить команду

google-drive-ocamlfuse /mnt/google.drive

Вы будете перенаправлены в браузер для авторизации. По ее завершении Google у вас спросит разрешить ли KODI управлять вашим диском подтверждаем.

Готово, можно перейти в директорию /mnt/google.drive и увидеть там свои файлы в облаке.

Как и в случае с Яндекс.Диском, Google Drive после перезапуска системы автоматически не смонтирует ваш диск. Настроим автомонтирование самостоятельно.

Создаем скрипт

mcedit /usr/bin/gdfuse

Вставляем содержимое

#!/bin/bashgoogle-drive-ocamlfuse -label $1 $*exit 0

Назначаем права на выполнение и копируем в root

sudo chmod +x /usr/bin/gdfusesudo cp -r /home/имя_пользователя/.gdfuse /root/

Осталось лишь сконфигурировать fstab

sudo mcedit /etc/fstab

Вставляем в конец файла

gdfuse#default /mnt/google.drive fuse allow_other 0 0

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

В завершении темы о резервном копировании KODI, хочется добавить, что, помимо стандартных данных для резервирования, можно добавить и свой каталог. С единственным ограничением каталог должен быть по пути /home/имя_пользователя/.kodi/. Например, у меня там находится каталог wiki с какими-то моими заметками, скриптами и настройками. Для этого в настройках дополнения Backup в Типы файлов сменить режим с Simple на Advanced и добавить нужный каталог он теперь также будет добавлен в архив резервной копии.

Таким образом, при наличии небольшого количества времени и навыков, получаем мультимедийный комбайн с дополнительными возможностями домашнего сервера и множеством комфортных способов управления, способного работать 24/7/365, аналога которому я пока не нашел, возможно лишь по тому, что и не искал он целиком и полностью устраивает меня и моих домочадцев.

P.S. В планах на втором телевизоре также поднять KODI (вероятно на Raspberry Pi 3/4) и синхронизировать оба устройства с помощью MySQL. Публикация о проделанной работе в этом направлении обязательно будет.

Есть несколько вариантов сделать качественное освещение быстро, дешево:

Вариант первый - галогеновые (галогенные) лампы

минусы: мало фиолетового/синего в спектре или очень маленький срок службы <100 часов (для ламп работающих с перекалом) и требуются хорошие софтбоксы для рассеивания света и защита их от воспламенения :)

Вариант второй - светодиоды

минусы: отсутствие фиолетового в спектре, проблемы с равномерным рассеиванием света.

Все эти варианты решаемые, но вопрос цены и целесообразности.

Но есть еще один вариант - "дневные лампы"

Вы скажете "но это прошлый век..."

А вот и нет, нас интересуют только определенные лампы: Philips - серии "graphica" ЦТ 5000k - 2330лм (65лм/вт) и ЦТ 6500k - 2100лм (58лм/вт)

Упаковка максимально простая, явно не для продажи в масс-маркете :)

Некоторые путают с "обычными" дневными лампами с высоким индексом цветопередачи, выглядит они так:

Даташит graphica 950 и graphica 965, они отличаются цветовой температурой 5000k и 6500k, ниже спектры ламп с сайта производителя

Некоторые путают данные лампы с "обычными" 9XX серии, вот спектр "обычной" 965

Спектр светодиода "обыкновенного" 6500k, CRI>90, масштаб другой, но что было на сайте Philips

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

Т.к. лампа не за 100р, для нее требуется нормальный ЭПРА (с прогревом и плавным стартом). Если обходимся без "колхоза", то смотрим в сторону готовых ЛПО.

Philips vs Osram (оба 1x36), цена вопроса 1500-1800р

Мне нравятся оба, они имеют металлическое основание, но Philips имеет зазор между лампой и рассеивателем, что дает более мягкий свет.

Хотя ЛПО Philips больше похож на тот, который делался изначально под ЭмПРА, просто у него производитель провел небольшой upgrade :)

Как возникла идея проекта

Аисты жили в нашей деревне давно. Пока работал, было не до них. Просто любовался красивыми птицами и все.

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

И только с выходом на пенсию появилось время для реализации этой идеи.

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

Был сварен Z-образный кронштейн и аналоговая камера в апреле месяце 2020 стала фиксировать все, что происходит на высоте 9 метров в гнезде.

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

Тем временем прилетели аисты и начали откладывать яйца.

Я несмотря на 64 года вполне комфортно чувствую себя в соцсетях поэтому для продвижения проекта завел инстаграм @storks40, куда и стал выкладывать фото и видео из гнезда.

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

К моему удивлению вскоре на карточку стали поступать деньги. Денег хватило для оплаты мобильного интернета и даже для возмещения расходов на оборудование. А в конце сезона поступил разовый большой взнос на новую камеру к следующему сезону. И я уже решил в новом сезоне обязательно сделать прямые трансляции на YouTube.

Технические моменты.

Я не системный администратор и моя работа не связана с компьютерными сетями. В молодости программировал на Clipper summer87, Access 2.0. Это немного помогло и практически всю нужную информацию нашел в сети.

В первом сезоне сделал ошибку и установил аналоговую камеру. Для вывода ее видео в сеть нужен регистратор. Это лишнее звено в этой цепочке.

За осень и зиму изучил опыт других круглосуточных трансляций на YouTube. С некоторыми организаторами даже удалось встретиться и пообщаться лично. Это были люди с двухгодичным опытом непрерывных прямых трансляций и сотней тысяч подписчиков..

К новому сезону 2021года к дому в деревне был подключен проводной интернет и над гнездом вознеслась новая поворотная IP камера Hikvision с 4-х кратным зумом.

К дому был проведен проводной интернет 80 Mbps получен статический IP адрес. Это обязательное условие для удаленного доступа к камере без танцев с бубнами. Достаточно пробросить порт на роутере.

Камера передает rtsp поток, с которым теперь можно делать потоковое вещание на различные площадки. Иногда вел вещание на Youtube, FB,VK и Twith одновременно.

Для вещания в YouTube и другие сервисы нужен rtmp поток. Можно использовать программу по типу OBS, но мне это не подошло. Я решил работать с утилитой ffmpeg. Это бесплатная программа с широчайшим спектром функций по работе с видео. Не требует установки, запускается в командной строке, работает на всех трех крупных операционных системах.

В сети много ссылок с форматом ключей для обработки rtsp потока с видеокамер. Я использовал такой.

ffmpeg -re -rtsp_transport tcp -i "****rtsp ссылка****" -c:a libmp3lame -ab 128k -ar 44100 -c:v copy -threads 2 -bufsize 4000k -f flv -crf 0 -minrate 4000k -maxrate 5000k -tune zerolatency "rtmp://a.rtmp.youtube.com/live2/*ключ потока**"

Где брать rtsp ссылку? Ее надо искать на сайте производителя камеры. В нее вписывают логин и пароль камеры, номер канала.

Ссылка для Hikvision "rtsp://логин:пароь@IP_адрес_камеры/ISAPI/Streaming/Channels/101"

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

Какой компьютер нужен для круглосуточной трансляции?

Лучше чужой. Свой будет постоянно шуметь, тратить электроэнергию и вообще мешаться под ногами. Я не сразу это понял. Работал над тем, как включать и управлять удаленно компьютером, который установил в деревне.

Это тупиковый путь. Лучше сразу брать в аренду виртуальный сервер, тем более что есть варианты бесплатного доступа на 90 дней от google, amazon и microsoft.

Я подключил виртуальную машину от гугла https://cloud.google.com/ . Никогда раньше не имел дела с VPS, но легко разобрался за полчаса с настройкой по этому видео https://youtu.be/duKOkL1Sjww

Установил сервер c Microsoft, Windows Server, 2012 R2, 4 Гб память,SCSI 50Гб.

Для быстрого запуска ffmpeg cделал bat файл. Потом заметил, что иногда ffmpeg вылетает и трансляция виснет. Тогда в bat файле сделал цикл от 1 до 1000 и проблема исчезла.

При минимальной конфигурации VPS загружен только на 5%.

При регистрации аккаунта в cloud.google надо указывать данные реальной банковской карты. Для этого я завел виртуальную карту в тинькофф банке. Главное не забыть отключить услугу до окончания 90 дневного срока.

Запуск прямой трансляции на ютубе описан во многих видео, поэтому здесь об этом не буду.

Сезон 2021 года. Прямая круглосуточная трансляция на YouTube.

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

К прилету первого аиста его уже ждали в прямом эфире несколько десятков подписчиков канала на YouTube. Их было не больше 40 человек. Я сделал посты в соцсетях и новость о интересной трансляции очень быстро разошлась по местным СМИ. Газеты сделали хорошую рекламу на своих интернет ресурсах , а телеканалы помогли еще больше. (Это для меня было открытием. Люди сидели перед экраном где было только гнездо и просто общались в чате. А просмотры шли и подписчики прибавлялись.)

Трансляции уже велись круглосуточно. При этом я даже не задействовал свой компьютер. Был арендован бесплатный (на 90 дней) виртуальный сервер google, который прекрасно справляется с этой задачей.

Во время трансляции заметил в чате активного пользователя и сделал ее модератором чата. Это было неожиданно для Марины, но она согласилась и стала мне активно помогать в эфире.

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

Все это помогло меньше чем за месяц собрать 1000 подписчиков и 4000 минут просмотров. YouTube - дал добро на монетизацию.

Неочевидные плюсы прямых трансляций из гнезда аистов.

• Не надо постоянно монтировать новые видео. Видео делает сама жизнь.

• Круглосуточные трансляции дают много просмотров. Доход от рекламы растет.

• Прямо во время трансляции можно делать подборку интересных кадров и тут же публиковать на канале. Это функция ютуба явно мало кому известна. Я так сделал очень много интересных видео.

• Чат трансляций очень способствует просмотрам. Люди приходят на канал, как в клуб по интересам. Дают аистам имена, переживают за птенцов, ждут возращения взрослых на ночевку

• Это очень познавательно. Хорошая камера дает возможность рассмотреть все подробности жизни. Увидеть как вылупляется птенец, чем их кормят. Разрушаются многие мифы о аистах.

• Все это помогает развитию канала и росту просмотров.

Через полтора месяца с начала трансляций уже каждый день приносил по 140 -210 рублей в день за счет рекламы. И эта цифра продолжает расти. А донаты полностью покрыли расходы и осталось на развитие проекта.

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

Есть куда развиваться. Канал постоянно набирает просмотры и подписчиков. На 25 мая 2061подписчиков. А еще недавно в соседней речке завелись бобры и я уже строю планы по видеотрансляции из хатки бобров)

Ссылка на канал https://www.youtube.com/channel/UCwgh6pJpiVlVObWaXKLjGqw

Я бы никогда не стал публиковать это на хабре, если бы не получил приглашение от замредактора сайта

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

YouTube вновь отбивается от критики. В этот раз акцент сместился с качества рекомендаций на взаимодействие с музыкантами. Последние недовольны размером компенсаций за стримы, жалуются на монополизацию индустрии и критикуют все крупные платформы. Те, в свою очередь, перекладывают вину на YouTube и вместе с лейблами не торопятся что-либо менять.

Денег нет

Авторы и исполнители музыкальных произведений все чаще делятся личным опытом заработка и критикуют площадки за незначительные выплаты. В случае с The Flashbulb они составили 24 тысячи долларов за 7 млн прослушиваний. Это $0,003 за стрим на Spotify, причем большая часть суммы в итоге ушла на оборудование и запись партий с помощью сторонних музыкантов. Сопоставимые данные об этой площадке $0,0035-0,004 за прослушивание привел и RAC, лауреат премии Грэмми. Для сравнения девяти платформ ему хватило одного твита.

Как показывает пример этого музыканта, компенсация за миллион стримов на YouTube превышает поступления от Pandora и SoundCloud. Однако представители Британской ассоциации производителей фонограмм считают, что именно крупнейший видеохостинг сдерживает рост выплат музыкантам. По их мнению, Spotify платит в десять раз больше, а YouTube еще и способствует распространению бесплатного контента и мешает другим стриминговым сервисам повышать стоимость ежемесячных платежей для слушателей, а значит и распределять более существенные суммы между авторами треков. Вот что говорит эксперт: Стоимость подписки на музыкальные сервисы не меняется уже практически десять лет, а пока идет время инфляция делает свое дело. Еще на рынке присутствуют площадки вроде YouTube, где пользователи практически ничего и не платят, по сравнению с аудиторией Spotify.

Стоит заметить, что прямые нападки поддержали конкуренты этой платформы например, Елена Сегал, глобальный директор паблишинга в Apple Music. Она заявила, что бороться за слушателя с бесплатными альтернативами весьма затруднительно.

Что в ответ

Общение с представителями платформ и профильных ассоциаций инициировал парламентский Комитет по вопросам цифровой среды, культуры, медиа и спорта [Digital Culture, Media and Sport Committee, DCMS] Соединенного Королевства. В рамках очередных слушаний менеджмент крупнейшего видеохостинга мира отверг обвинения в рекордно низком уровне выплат музыкантам по сравнению с компенсацией, которую предоставляют другие стриминговые платформы. Однако все-таки признал, что порядок расчетов стоит сделать прозрачнее.

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

Вероятнее всего, дело исключительно в экономическом интересе. Даже с учетом того, что кто-то пиратит стримы, выкладывает чужую музыку в открытый доступ и обходит систему трекинга Content ID за счет многочисленных ухищрений, YouTube уже выплачивает правообладателям огромные суммы. Только за 2020-й сервис перевел в счет авторов и лейблов около 12 млрд долларов, а к 2025-му его руководство планирует стать лидером по этому показателю среди всех игроков музыкальной индустрии, включая конкурентов по стримингу музыки.

Как это понимать

Стоит признать, что мало кто откажется от возможности моментального стриминга практически любой из существующих музыкальных композиций и захочет вернуться к покупке дисков [хотя в этом есть свои преимущества]. Платить по доллару за трек или по центу за стрим вариант, на который тоже готовы пойти далеко не все. Вариативная стоимость стриминга альбомов? Тогда о плейлистах можно будет просто забыть. Кажется, готовых предложений, которые могли бы положительным образом повлиять на выплаты музыкантам и устроить как лейблы, так и онлайн-платформы, пока не существует. Поэтому нам еще предстоит узнать, какими они будут.

Что еще почитать у нас в Мире Hi-Fi:

• Нельзя так просто взять и перейти на стриминг, но телевизионщики пытаются

• Лев уже не торт: одна из киностудий выставлена на продажу, но со скидкой в 50%

• Чего музыканты боятся больше: пиратства или монополизации прав на их творчество

• Одно неловкое движение, и сразу вал рекомендаций: за что критикуют видеохостинги

• Плейлистификация захватила умы паблишеров, но так ли она интересна слушателям

Спросите: играют ли ваши дети в Роблокс-игры? - Ответ будет положительным!А как ваши дети-подростки выбирают компьютерную игру? Знаете? - Давайте попробуем сами: "Карантин", "Граница", "Белый Дом", "Пигги" и еще куча разных названий... Даже встроенный в некоторые игры 30-секундный трейлер ничего не проясняет! Нужно просто начать игру!

И тут оказывается, что игры имеющие самые разные названия похожи друг на друга, как братья-близнецы. Большинство представляют собой "симуляторы убийств" - не важно, чем и по какому поводу! Бей битой! Стреляй! Бей ножом! Не нужно особенно разбираться! Здесь почти каждый - враг! А раз так, то просто бей каждого - чтобы выжить! Хочешь получить автомат, а не пистолет, монтажку или нож? - Плати и стреляй хоть ракетами!

Становится страшно, когда видишь мальчишек и девчонок регулярно "заливающих кровью" экраны своих компьютерных мониторов и смартфонов. Это не может не сказаться на их психике и мировосприятии. Но, что вы можете предложить им взамен? Признайтесь: вы в этом не ориентируетесь!

А что, если научить детей делать "хорошие" игры, чтобы они могли и играть, и удивлять своих друзей? Сделать их Творцами и Повелителями своих собственных Миров! Сегодня вряд-ли кого-либо нужно убеждать, что навыки программирования - дело полезное. Без "цифры" уже нельзя обойтись и сегодня. Завтра - тем более! Более того, программирование - важнейший из навыков, которым могут овладеть современные дети, ведь оно развивает другие (самые полезные) "4К-навыки". Вопрос лишь в доступности обучения программированию и в мотивации самих детей.

Возможно даже, что ваш ребенок уже (в той или иной мере) освоил программирование в среде "Scratch". А вот до признания среди сверстников, уверен, дело не дошло, а это сильно демотивирует! Спросите: "Почему?" Ответ прост - все хорошо, но в среде "Scratch" нет простой возможности для работы с 3D-моделями, да и разрешение изображений очень низкое ("пиксельное"). То есть, все, что ни сделает ваш ребенок в среде "Scratch" будет сильно проигрывать в качестве картинки современным игровым платформам типа "Roblox". Такими достижениями трудно похвастать перед сверстниками! Многие не оценят!

Точно такая же ситуация возникла и у одного из наших курсантов. Достаточно преуспев в "Scratch" (дважды заняв 2-е места в Международной Scratch-Олимпиаде и дважды став дипломантом конкурса "Мастер_ИТ"), он с головой погрузился в самостоятельное изучение Роблокс. Оказалось, во встроенной библиотеке ("тулбоксе") Роблокс лежит в свободном доступе такое огромное количество всяких 3D-моделей, картинок и звуковых файлов, что Scratch и не снилось! И с разрешением в Роблокс все в порядке!

И, как говорится: "Терпение и труд все перетрут!" Стало получаться! За плечами нашего курсанта разработка уже нескольких Роблокс-игр. И если первые две игры были созданы из уже готовых моделей и без самостоятельного кодирования, то последующие строились с использованием своих кодов, что сделало игры классными и сразу отразилось на их посещаемости другими игроками. Более того, мальчишке захотелось поделиться знаниям, полученными из изучения (англоязычных) инструкций Роблокса, и собственными лайфхаками - он освоил видеоредактор Movavi. После серии видеороликов, созданных в помощь фанатам популярных Роблокс-игр, он решил начать публиковать уроки по программированию в Роблокс на своем youtube-канале и приглашает всех желающих стать его подписчиками-учениками. Понятно, что нельзя было не пригласить в читатели журнала и программистов-скрэтчеров. На его "профиле" сайта "Scratch" появились соответствующие мультики-приглашения.

В сравнении со многими имеющимися в youtube роликами, уроки юного преподавателя имеют несомненные достоинства: они компактны и очень качественны - с ними разберется даже первоклашка! А уж тем, кто освоил Scratch - тем более! Особое достоинство скриптов, описываемых юным учителем - наличие комментариев к каждой строке кода. Его устные объяснения коротки, но очень продуманны и потому его уроки воспринимаются очень легко. Важно, что автор сразу же демонстрирует и варианты модификации своих программ. Применив эти модификации, каждый сможет запрограммировать именно то, что ему нужно. Приглашайте ваших детей поучиться! Это легко и интересно!

И еще, говорят: "Привычка - вторая натура!" Дети могут начать множить то, к чему привыкли. Но, им вовсе не обязательно создавать свои "симуляторы-убийства". Помогите им придумать сюжет своей "доброй" игры. А в качестве примера покажите им игру "Космос", созданную тем же юным преподавателем! В ней каждый сможет стать космонавтом-исследователем, открыть для себя планеты и спутники Солнечной системы, побывать на МКС, полетать на летающих тарелках и даже поискать клады космических пиратов. Посмотрите захватывающий ролик об этой игре! Уверен, вы сами (ктов нашем с вами детстве не мечтал стать космонавтом?) захотите сыграть в эту игру. Возьмите и поиграйте! Это - просто круто!

Или вот еще одна его относительно "мирная" Роблокс-игра - "Полигон". Здесь начинающий игрок-роблоксер научится ловко управлять своим игровым аватаром и боевой техникой - танками и БТРами. Это - ролевая игра, в которой можно, начав призывником, стать крутым бойцом спецназа военной разведки, научиться метко стрелять и преодолевать сложные препятствия на танках "Армата" и "Т-70".

Думаете это просто? - Ошибаетесь! Модели танков, БТР и автомобилей в Роблокс не всегда имеют низко расположенный центр тяжести. Поэтому иногда даже наезд гусениц танка на самый обыкновенный бордюр дороги может приводить к опрокидыванию модели, в которой сидит ваш аватар. Метко стрелять из танка по подвижным мишеням - тоже не просто! А когда вы станете "профи", вы сможете примерить на себя роль врага-диверсанта, попробовать разыскать секретный центр управления и запустить ядерную ракету или телепортироваться в игру "Зона боевых действий", чтобы помочь "нашим" и, победив врага, под звуки российского гимна поднять флаг Родины...

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

Спросите: играют ли ваши дети в Роблокс-игры? - Ответ будет положительным!А как ваши дети-подростки выбирают компьютерную игру? Знаете? - Давайте попробуем сами: "Карантин", "Граница", "Белый Дом", "Пигги" и еще куча разных названий... Даже встроенный в некоторые игры 30-секундный трейлер ничего не проясняет! Нужно просто начать игру!

И тут оказывается, что игры имеющие самые разные названия похожи друг на друга, как братья-близнецы. Большинство представляют собой "симуляторы убийств" - не важно, чем и по какому поводу! Бей битой! Стреляй! Бей ножом! Не нужно особенно разбираться! Здесь почти каждый - враг! А раз так, то просто бей каждого - чтобы выжить! Хочешь получить автомат, а не пистолет, монтажку или нож? - Плати и стреляй хоть ракетами!

Становится страшно, когда видишь мальчишек и девчонок регулярно "заливающих кровью" экраны своих компьютерных мониторов и смартфонов. Это не может не сказаться на их психике и мировосприятии. Но, что вы можете предложить им взамен? Признайтесь: вы в этом не ориентируетесь!

А что, если научить детей делать "хорошие" игры, чтобы они могли и играть, и удивлять своих друзей? Сделать их Творцами и Повелителями своих собственных Миров! Сегодня вряд-ли кого-либо нужно убеждать, что навыки программирования - дело полезное. Без "цифры" уже нельзя обойтись и сегодня. Завтра - тем более! Более того, программирование - важнейший из навыков, которым могут овладеть современные дети, ведь оно развивает другие (самые полезные) "4К-навыки". Вопрос лишь в доступности обучения программированию и в мотивации самих детей.

Возможно даже, что ваш ребенок уже (в той или иной мере) освоил программирование в среде "Scratch". А вот до признания среди сверстников, уверен, дело не дошло, а это сильно демотивирует! Спросите: "Почему?" Ответ прост - все хорошо, но в среде "Scratch" нет простой возможности для работы с 3D-моделями, да и разрешение изображений очень низкое ("пиксельное"). То есть, все, что ни сделает ваш ребенок в среде "Scratch" будет сильно проигрывать в качестве картинки современным игровым платформам типа "Roblox". Такими достижениями трудно похвастать перед сверстниками! Многие не оценят!

Точно такая же ситуация возникла и у одного из наших курсантов. Достаточно преуспев в "Scratch" (дважды заняв 2-е места в Международной Scratch-Олимпиаде и дважды став дипломантом конкурса "Мастер_ИТ"), он с головой погрузился в самостоятельное изучение Роблокс. Оказалось, во встроенной библиотеке ("тулбоксе") Роблокс лежит в свободном доступе такое огромное количество всяких 3D-моделей, картинок и звуковых файлов, что Scratch и не снилось! И с разрешением в Роблокс все в порядке!

И, как говорится: "Терпение и труд все перетрут!" Стало получаться! За плечами нашего курсанта разработка уже нескольких Роблокс-игр. И если первые две игры были созданы из уже готовых моделей и без самостоятельного кодирования, то последующие строились с использованием своих кодов, что сделало игры классными и сразу отразилось на их посещаемости другими игроками. Более того, мальчишке захотелось поделиться знаниям, полученными из изучения (англоязычных) инструкций Роблокса, и собственными лайфхаками - он освоил видеоредактор Movavi. После серии видеороликов, созданных в помощь фанатам популярных Роблокс-игр, он решил начать публиковать уроки по программированию в Роблокс на своем youtube-канале и приглашает всех желающих стать его подписчиками-учениками. Понятно, что нельзя было не пригласить в читатели журнала и программистов-скрэтчеров. На его "профиле" сайта "Scratch" появились соответствующие мультики-приглашения.

В сравнении со многими имеющимися в youtube роликами, уроки юного преподавателя имеют несомненные достоинства: они компактны и очень качественны - с ними разберется даже первоклашка! А уж тем, кто освоил Scratch - тем более! Особое достоинство скриптов, описываемых юным учителем - наличие комментариев к каждой строке кода. Его устные объяснения коротки, но очень продуманны и потому его уроки воспринимаются очень легко. Важно, что автор сразу же демонстрирует и варианты модификации своих программ. Применив эти модификации, каждый сможет запрограммировать именно то, что ему нужно. Приглашайте ваших детей поучиться! Это легко и интересно!

И еще, говорят: "Привычка - вторая натура!" Дети могут начать множить то, к чему привыкли. Но, им вовсе не обязательно создавать свои "симуляторы-убийства". Помогите им придумать сюжет своей "доброй" игры. А в качестве примера покажите им игру "Космос", созданную тем же юным преподавателем! В ней каждый сможет стать космонавтом-исследователем, открыть для себя планеты и спутники Солнечной системы, побывать на МКС, полетать на летающих тарелках и даже поискать клады космических пиратов. Посмотрите захватывающий ролик об этой игре! Уверен, вы сами (ктов нашем с вами детстве не мечтал стать космонавтом?) захотите сыграть в эту игру. Возьмите и поиграйте! Это - просто круто!

Или вот еще одна его относительно "мирная" Роблокс-игра - "Полигон". Здесь начинающий игрок-роблоксер научится ловко управлять своим игровым аватаром и боевой техникой - танками и БТРами. Это - ролевая игра, в которой можно, начав призывником, стать крутым бойцом спецназа военной разведки, научиться метко стрелять и преодолевать сложные препятствия на танках "Армата" и "Т-70".

Думаете это просто? - Ошибаетесь! Модели танков, БТР и автомобилей в Роблокс не всегда имеют низко расположенный центр тяжести. Поэтому иногда даже наезд гусениц танка на самый обыкновенный бордюр дороги может приводить к опрокидыванию модели, в которой сидит ваш аватар. Метко стрелять из танка по подвижным мишеням - тоже не просто! А когда вы станете "профи", вы сможете примерить на себя роль врага-диверсанта, попробовать разыскать секретный центр управления и запустить ядерную ракету или телепортироваться в игру "Зона боевых действий", чтобы помочь "нашим" и, победив врага, под звуки российского гимна поднять флаг Родины...

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

Этот самодельный электровездеход имеет название Восток, в честь первого космического корабля Советского Союза, который доставил первого космонавта на орбиту Земли. Это гордость, что были такие предшественники. В частности, Сергей Павлович Королев со своей командой. Поэтому вездеход Восток это попытка внесения новизны и посильного вклада в развитие Отечественной техники. Отсюда было выбрано такое символическое название. Кстати, первый выезд по случайному стечению обстоятельств состоялся 12 апреля 2021 года в день 60-летия со дня первого полета человека в космос.

Идея создания вездехода на электрической тяге весьма тривиальна. В ее основу легли мысли главного конструктора и идейного вдохновителя вездехода Сергеева Петра. Он является поклонником внедорожного спорта и любит ездить на природе, в частности, на квадроциклах. И в один из жарких летних дней его посетила мысль о том, что некомфортно ездить на обычном бензиновом квадроцикле, который скидывает с себя кучу тепла, выхлопных газов, издаёт громкий шум и треск. И собственно оттуда (а это было полтора года назад) и пошла идея сделать электрическое транспортное средство. Поначалу были мысли доработать какое-то существующее транспортное средство ну, например, мотоцикл или багги. Но, взвесив все за и против, было принято решение, что нужно постараться добиться минимального энергопотребления, чтобы запас электроэнергии был достаточен, чтобы совершать и весьма продолжительные поездки. Это подразумевает формирование определенных требований, которые нужно предъявить к конструкции будущей машины. В частности, высокий дорожный просвет, небольшую массу и высокие ходы подвески. Еще одно не менее важное требование - возможность преодоления водных препятствий вплавь. Отсюда и родилась конструкция, которая представлена перед Вами.

Вездеход является двухмоторным, то есть в нем два электромотора, которые расположены в переднем и заднем мостах. Подвеска здесь зависимая, потому что только с ее помощью можно обеспечить постоянный дорожный просвет и высокие ходы подвески. Здесь высота хода подвески примерно метр, то есть, если поднимать одно из боковых колес, то другое оторвется только спустя метр. Никакой независимой подвеской такого добиться не получится. Мост здесь нетрадиционный как на большинстве автомобилей. Он представляет из себя ферменную конструкцию, сваренную из листовых деталей. И его главная особенность состоит в том, что редуктор и электродвигатель размещены значительно выше оси вращения колес. Это позволяет обеспечить большой дорожный просвет. Здесь он, надо сказать, полметра под мостами и почти 70 см под днищем автомобиля. В дополнение, мост обеспечивает высокую прочность и надежность, потому что ШРУСы, которыми наделены эти мосты работают в постоянных, не сильно нагруженных условиях, и это обеспечивает высокую надежность. То есть не будет вероятности поломки из-за того, что углы вывешивания будут критичными для их конструкции.

Примечательно то, что дорожный просвет под мостом остается неизменным. Это одно из достоинств этой системы по сравнению с обычной независимой подвеской, где дорожный просвет определяется загрузкой машины. Здесь применен объединенный мотор-редуктор, который через ШРУСы передает крутящий момент на колеса. Мосты, поворотные кулаки рассчитывались, проектировались и изготавливались собственноручно.

Недостаток традиционных систем управления рулевыми колесами в случаях с зависимым мостом - это разъезд колес во время артикуляции моста. То есть когда мост преодолевает препятствия, то углы установки колес относительно кузова меняются и колеса разъезжаются в разные стороны. Для того, чтобы от этого уйти, рулевая рейка была размещена непосредственно на мосту, а вот управление этой рулевой рейкой, то есть крутящий момент непосредственно от рулевого колеса передается с помощью хитрого вала. Этот вал одет в кожух, имеющий водонепроницаемую конструкцию, потому что машина предполагает взаимодействие с водой. Рулевой вал выходит из салона и посредством угловых редукторов идет к входному валу рулевой рейки. Это обеспечивает жесткую связь между рулем и рулевыми колесами. Это одно из требований к подобному классу техники. То есть здесь нет гидрообъёмной трансмиссии и дополнительных систем. Здесь обычная механическая связь, плюс электрический усилитель руля. Благодаря угловым редукторам мы изменяем направление хода вала. Вал имеет внутри себя шлицевые соединения, чтобы компенсировать длину, которая меняется во время движения моста по бездорожью.

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

Высокого качества подгонки материалов удалось добиться благодаря проектированию всех элементов автомобиля в САПР Solid Works и благодаря небольшому станочному парку металлообрабатывающего оборудования, который позволяет резать, гнуть и сваривать этот кузов. Надо сказать, что благодаря Solid Works все, что есть собралось с первого раза. Не было никаких запчастей, доделок и переделок.

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

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

Машина в том виде в котором она представлена сделана для того, чтобы успеть опробовать ее летом 2021 года. К сезону 2022 года планируется полная доделка. Должен появиться и полноценный салон, и внешний вид будет совершенно преобразован.

Процесс эволюции силовой части был тернистый и непростой. Идея в том, что в этом элетровездеходе используются два мотора и две идентичные друг другу системы управления на передней и задней они. Дорога к той силовой установке, которая стоит сейчас, была довольно таки долгая. Первым делом на электрическом вездеходе стояли электродвигатели от Toyota Estima. В связи с отсутствием управляющей системы пришлось перейти на перемотанный вариант этих моторов под 72 Вольта и под китайские контроллеры. Но этот путь оказался утопичным для тяжелой техники, так как нужно делать автомобили сразу на высоком напряжении. За кажущейся доступностью дешевых китайских инверторов и электродвигателей, скрываются подводные камни, которые на тяжелой технике вылезают первым делом. Простым языком сложно найти китайские контроллеры на высокое напряжение и двигатель на хороший момент на низком напряжении. Если применять существующие электродвигатели, например, китайские на низкое напряжение, то надо понимать, что им нужен хороший редуктор с хорошей степенью редукции, иначе хорошего результата не получится. Собственно, это и получилось, когда первый раз собралась вся эта система на 72В. Ехать автомобиль ехал, но мотор был перемотан и работал не в своем режиме. Постоянно перегревался и хорошего крутящего момента не выдавал. По прямой он ехал пол часа после чего перегревался и нужно было еще полчаса отдыхать.

Дальше пути развития силовой части раздвоились. Были заказан мотор и инвертор от Nissan leaf. А также еще один электромотор от Toyota Estima, чтобы сравнить как перемотанный мотор отличается от не перемотанного. В пике электромотор Estima выдает порядка 35кВт, вездеход на нем едет, но мощность показалась недостаточная. Поэтому в конечном варианте скорее всего будет именно двигатель от Nissan leaf.

В принципе для своих задач электромотор от Toyota Estima очень неплох. По соотношению доступности/полученного эффекта этот мотор (если его не перематывать) для легкой техники идеален. Он не греется, потребляет небольшое количество мощности от аккумулятора. По сути он аналогичен жигулевскому мотору. То есть если Вы понимаете, что сможете приделать его к существующей коробки передач, то он выдаст потрясающие характеристики и этого будет более чем достаточно для простой легкой техники. В случае с электровездеходом ситуация резко осложнилась установкой больших 33 дюймовых внедорожных колес. Но и эти колеса не предел. Следующим этапом планируется применение 900 мм колес. Там, конечно, характеристик электромотора Toyota Estima точно мало.

На бездорожье главная задача - это обеспечение хорошего крутящего момента. Он никакими другими способами, кроме того, как применять понижение частоты оборотов и повышения момента, не может быть достигнут. Поэтому сейчас вездеход переходит на моторы от Leaf. И то мотор от Leaf берется за основу, а мост дооснащается колесными редукторами, которые имеют передаточное число 1:2. Таким образом мы получаем на колесах двойное увеличение момента. Момент родного момента электромотора Nissan Leaf до 280 НМ до 3000 оборотов/мин, дальше характеристики начинают спадать, но на бездорожье это не важно, так как нет задачи развить колоссальные скорости. С учетом того, что родная редукция 1:8 и плюс колесные редуктора 1:2, то суммарная редукция 1:16. Таким образом крутящий момент на одной оси получается 4480 нм. А общий крутящий на всех 4 колесах 8960 нм. Для примера Нива, установленная на первую передачу и на пониженный ряд раздаточной коробки, имеет суммарный крутящий момент на всех 4 колесах 3890 НМ. Но очень важный момент, что максимальный крутящий момент Нивы появляется только в районе 4000 тысяч оборотов/мин на моторе. Здесь же, в самодельном электрическом вездеходе, момента на одной оси больше чем у нивы на всех осях и появляется он практически сразу при нажатии педали газа.

Суммарный вес электровездехода планируется получить менее тонны - 900 с небольшим кг.

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

Для тех, кто сомневается какие применять аккумуляторы. В электрическом вездеходе Восток активно применяются NMC пакеты. Сейчас на борту имеется родное напряжение электромоторам от Nissan leaf 360-390В в зависимости от степени заряженности. Всего 96 пакетов по 60Ah. Это примерно 21 кВтЧ. Вес батарейного отсека без учета корпуса получился чуть более 90 кг. Эти пакеты, по сравнению с железо фосфатом и никель металл гидридом, имеют самые лучшие на данный момент показатели по весу. Да, у этих пакетов есть недостатки. Это более узкий температурный диапазон эксплуатации и повышенная пожароопасность. С точки зрения безопасности в электровездеходе Восток выгорожен специальный отсек под аккумуляторы. При возникновении аварийной ситуации внутреннее пространство салона автомобиля останется вне опасности, так как батарейный отсек находится под багажником и не имеет связи с салоном, при этом огорожен перегородкой из нержавеющей жаропрочной стали. И плюс, конечно, контролируется каждая ячейка по напряжению, по разрядному току, по наличию или отсутствию короткого замыкания. Вопросы безопасности очень важны и ими никогда не стоит пренебрегать.

В вездеходе с электромотором очень интересная конструкция стеклоочистителя. Идейным вдохновителем стал шведский производитель гиперкаров Koenigsegg, а поставщиком запчастей стал Mercedes. Была взята система стеклоочистителя от 210 мерседеса, сделана ревизия. Также было проработано изменение нейтрального положения и изменение геометрии поверхности очистки под стекло вездехода. Смысл его в тоа что он двигается по стеклу не только слева направо и обратно, но вверх-вниз-вверх, тем самым добиваясь быстрой и качественной очистки большей поверхности стекла.

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

Более подробную информацию о вездеходе Восток можно посмотреть на нашем канале в Youtube "Время инженеров"

Всем привет.

Решили заняться с другом созданием мощного заднеприводного багги для езды по грунтовой дороге. Для себя определили, что разгон должен быть около 5 секунд до 100 км в час. В идеале выйти из 5 секунд. Строить по классической схеме, где сердце багги - это двигатель от ВАЗ нам показалось неинтересным. Долго думали, чтобы такое придумать и идея пришла сама собой. В свое время мы ездили с ним в Японию и уже там на выставках познакомились с входящими тогда в популярность электромобилями.

За основу Багги мы взяли электрический бесколлекторный мотор от Nissan. Его изюминкой является большой крутящий момент порядка 280нМ с самого начала оборота. Так как багги электрический, а нынче тренд ко всему электрическому добавлять "e", то и наш проект мы назвали еБагги.

В японском электрокаре установлен синхронный трехфазный электромотор мощностью 80 киловатт (109 л.с.) при 2730-9800 оборотов в минуту. Двигатель Nissan Leaf дает крутящий момент280 Нм. Паспортный разгон до 100 км/ч составляет11,9 с., а максимальная скорость авто равна145 км/ч. При весе автомобиля значительно превышающим вес нашего багги. График

По графику сразу видно, что диапазон работы оборотов двигателя гораздо выше, чем у 1.6 литрового атмосферного собрата. В электромоторе от 0-10500 оборотов. У атмосферника 900-6500. Во вторых полка момента в 280 Нм доступна сразу с 0 оборотов и вплоть до 2700 оборотов и далее идет плавное уменьшение крутящего момента. Связано это с тем, что с ростом оборотов магнитное поле не успевает за скоростью мотора и его влияние на отталкивание ослабевает. Именно поэтому в любом электромобиле типо Теслы, Лифа, да и просто троллейбуса/трамвая Вы чувствуете с самого старта пинок а потом плавное ускорение. А вот пик лошадиных сил доступен не сразу, но зато с 2700 и вплоть до 10 тысяч оборотов. Если посчитать площади крутящего момента и мощности, то они будут не менее в чем в 2 раза превышать площади атмосферного двигателя.

Один из самых дорогих элементов самодельной электробагги это высоковольтная батарея. Мы брали на разборке одну из самых недорогих. Основная задача это покатушки на даче и в деревне, никаких важных поездок по городу или межгороду не предвиделось. Цена батарейки с 6 делениями остатка емкости порядка 100 тысяч рублей. В нашей батареи остаток чуть более 60%, что с весом багги порядка 850 килограмм позволит кататься в районе 80 км по пересеченной местности. Мы хотели оставить именно родной корпус батареи от Ниссан Лиф. Почему? Во первых он герметичен, что позволит испытывать нашу багги и в водных условиях. Во вторых качество исполнения электроники самой батареи и ее защиты на самом высочайшем уровне. В дальнейшем мы можем экспериментировать, меняя ячейки батареи на более современные. Что позволит или значительно уменьшить массу при той же емкости батареи или увеличить емкость при примерно той же массе.

Параметры бaтapeи 24 kВтч; Tип Li-on; Koличecтвo ячeek 192 шт.; Cрок cлyжбы 5 лeт; Macca 270 kг Пoтpeблeниe элeктpoэнepгии нa 100 km 21 kВтч; Вpemя зapядkи (220 Вoльт) 9 чacoв; Нomинaльнoe нaпpяжeниe 360 V.

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

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

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

Собрав рулевое управление, нам стало интересно сделать не просто багги, а радиоуправляемую и в дальнейшем автономную машину. Начали копать в сторону работы электромотора усилителя руля. Выяснили, что его принцип рассчитан на работу тензодатчика. Тензометрический датчик (тензодатчик; от лат. tensus напряжённый) датчик, преобразующий величину деформации в удобный для измерения сигнал (обычно электрический), основной компонент тензометра (прибора для измерения деформаций). Далее разобрались с командами, которые необходимо присылать на ЭУР в зависимости от скорости движения. Тем самым научились менять усилия ЭУР как нам надо. Изучив тензодатчик поняли его непростое управление и сэмитировали сигналы на ардуино, подключив библиотеки от пульта PS4 PRO.

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

Всем привет.

Прошло около недели после нашего последнего поста, где мы рассказали о концепции нашей задумки и о первых этапах сборки. Кто пропустил и кому интересно, то можете почитать здесь http://personeltest.ru/aways/habr.com/ru/post/551750/

За эти 2 недели работы мы сильно продвинулись дальше в построении нашего ELVO eBuggy.

Первое, чем мы занялись, это поиск и покупка колес. Начали мониторить разные варианты. Мы точно не хотели литые диски, так как при ударных нагрузках они могли бы разлететься в самый неподходящий момент. Поэтому мониторили или усиленную штамповку, или крепкую ковку. Сразу хотелось бы отметить момент, что для нас построение электробагги - это хобби. У нас нет спортивных команд и спонсоров, поэтому наши бюджеты ограничены. Мечтали, конечно, о ковке на хороших шинах максис. Но и то, что Выбрали мы, также отнюдь не плохой вариант. Это усиленные немецкие диски Dotz Dakar, обутые во внедорожную резину Cordiant Offroad.

Далее нарисовали блок схему всех необходимых нам элементов.

Оранжевый цвет - это высоковольтная часть.

Зеленый цвет - это CAN шина.

Желтый цвет это 12V постоянного тока.

Потом мы приступили к установке модуля заряда PDM (Power Distribution Module) и инвертора.

"Электрокулибины на опыте" могли обратить внимание, что сам мотор взят от 1ого поколения ниссановских моторов, а модуль инвертора и заряда - от современных поколений. Всё это не просто так. Мы долго копались в технических документациях и определили, что в первых выпусках Ниссана перед конструкторами была поставлена задача сделать надёжный электромотор с большим запасом по прочности, чтобы уверенно завоевать массмаркет и не ударить в грязь лицом. В следующих версиях местами начали упрощать конструкцию, чтобы сэкономить на производстве. При этом такие моторы всё равно остаются хорошими и надёжными. Но мы хотим выжать из мотора больше мощности и запасы прочности нам пригодятся.

Что касается модуля зарядки, то в новых версиях он стал более современным, так как этого требовал рынок, чтобы ускорять процесс заряда батарей. Мы осознанно шли на риск и знали, что новые модули заряда ещё никому не удалось запустить, минуя центральный контроллер Nissana. Однако неделя работы со схемами и, как бы это громко не звучало, мы нашли способ. Но сделали это не программно, а электронно. И теперь получаем благодарственные письма со всех уголков мира, включая заокеанские Канаду и США.

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

Первое, с чего начали, это проектирования ввода силовых кабелей к инвертору. Рассчитали кабель, ввода и прокладки по госту. Спроектировали все в SolidWorks. И напечатали на 3Д принтере деталь, которая печаталась более суток.

Сканирование двигателя и перенос в 3Д модель

Разработка выходного модуля для соединения контактов.

Далее мы приступили к печати детали.

И вот, что мы получили на выходе.

Деталь, которая на выходе мало чем отличается от заводского исполнения.

Далее настало время плести и распутывать лапшу. Много лапши не бывает)

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

Времянка проводки самодельного багги.

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

Всем привет.

Кто пропустил тему про саму идею, создание рамы и установку мотора, высоковольтной батареи и подвески http://personeltest.ru/aways/habr.com/ru/post/551750/часть 1

Установка колес, подключение электрики и модуля заряда PDM Nissan Leafhttp://personeltest.ru/aways/habr.com/ru/post/552888/часть 2

Последний наш пост был 3 недели назад. За это время мы шагнули далеко вперед.

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

Сначала были установлены тормозные суппорта. Далее сделана разводка тормозных трубок и шлангов через блок АБС.

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

Блок АБС установлен, но пока через него просто транзитом проходит жидкость. В будущем нам предстоит установка датчиков АБС и отстройка режимов работы АБС.

При первом выезде мы на скорую руку написали программу управления электродвигателем. Суть заключалась в том, что при нажатии газа багги ехал вперед, а при нажатии тормоза включалась рекуперация на 10%. И при остановке багги вместо рекуперации начинал ехать в обратную сторону. Но мощности явно не хватало, да и ехать назад посредством торможения не правильно.

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

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

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

Кто смотрел видео с первым выездом, то видели, что вместо сидения у нас стоял ящик от инструментов. Это дело мы также поправили. Были установлены вот такие самодельные ковши.

Также во время пробной поездки у нас не был закреплен 12В бортовой аккумулятор. И это дело мы исправили. Установили площадку спереди. Это положительно повлияло и на развесовке.

При промежуточных выездах мы заметили, что через какое то время багги терял первоначальную мощность. На форумах некоторые люди катаются без системы охлаждения при этом в полной уверенности, что у них все в порядке. Сначала мы не понимали как это возможно. Но потом все стало ясно. В основном на Leaf катаются не гонщики и так как заряд батареи ограничен, то люди в основном передвигаются в плавном режиме. Мы же ездили "тапка в пол". У лифа существует ошибка P3252 Limits the maximum torque of traction motor to 50%. И выскакивает она при недостаточном охлаждении IGBT ключей. Поэтому далее мы установили систему охлаждения.

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

Впереди еще много работы, но мы с энтузиазмом готовы ей заниматься. Будем доделывать АБС, изготавливать приборную панель, делать визуализацию для панелей.

Кому интересно более подробная информация, то ее можно увидеть на нашем канале "Время инженеров" ниже.

Привет, Хабр!

На связи команда JetBrains YouTrack, и у нас для вас новый релиз! Мы дополнили интеграцию с GitLab теперь YouTrack не только отслеживает коммиты и merge-реквесты, но и поддерживает интеграцию с GitLab CI/CD. А это значит, что задачи в YouTrack смогут обновляться автоматически по результатам автоматизированных сборок в GitLab CI/CD. Также мы дополнили релиз интересными улучшениями для работы с задачами. За подробностями добро пожаловать под кат!

Об интеграции с GitLab CI/CD что это и зачем

Непрерывная интеграция и развертывание (CI/CD) были придуманы, чтобы упростить жизнь разработчикам. Благодаря CI/CD вы можете не беспокоиться о том, что ваш код навредит проекту или сломает его, а самое главное вам больше не нужно проверять это вручную.

Как это работает? CI/CD периодически забирает новый код из системы контроля версий (VCS), собирает проект, прогоняет автотесты и разворачивает собранную и протестированную версию, например на сервере, где тестировщики смогут провести остальные этапы тестирования. Если что-то упало, CI/CD сообщит об этом кому нужно, например техлиду проекта или разработчику, который сделал злосчастный коммит.

YouTrack уже давно позволяет интегрировать в процесс управления задачами TeamCity и Jenkins, а теперь к ним присоединился и GitLab CI/CD.

GitLab CI/CD работает с конвейерами (пайплайнами), каждый из которых состоит из ряда заданий (jobs). При появлении изменений в коде GitLab CI/CD выполняет соответствующие задания из пайплайна, чтобы убедиться, что новый код ничего не сломал. Если задание в пайплайне выполнено успешно, GitLab делится этой радостью с YouTrack, который в свою очередь обновляет нужные задачи.

Как именно обновляет? Как скажете! Например, YouTrack может автоматически помечать задачи, упомянутые в сообщении коммита, как завершенные и прописывать в задаче номер пайплайна и ссылку на него. Как обычно, вы можете завязать на интеграцию рабочие процессы (например, указать, чтобы при изменении значения поля Fixed build на странице задачи появлялся комментарий о том, что фикс доступен в продакшене).

Что еще нового?

Мы внесли ряд улучшений в YouTrack Lite и Classic. В YouTrack Lite появилась функция Похожие задачи, которая позволяет избежать дублирования задач. Когда при создании задачи вы вводите ее название, YouTrack ищет задачи со схожим названием и предлагает вам просмотреть их и убедиться, что новая задача их не дублирует. В YouTrack Classic мы добавили удобный текстовый редактор такой же, как в базе знаний и в YouTrack Lite. Теперь вы можете одним щелчком переключаться между режимом разметки и режимом WYSIWYG, встраивать мультимедийные объекты, создавать таблицы и контрольные списки.

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

Лучше один раз увидеть, чем сто раз прочитать. Напомню, что YouTrack со всеми его новшествами можно попробовать бесплатно. Мы будем рады вашей обратной связи!

Команда YouTrack

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

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

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

Метрики вместо развития

Универсальный характер проблемы достаточно точно описал Даниел Канеман, известный психолог и лауреат многочисленных премий по экономике. Он констатировал, что основная масса соцсетей вовсе не стремятся вооружить нас инструментами для саморазвития и поиска качественного контента среди сотен тысяч и миллионов ежедневных публикаций. Их задача максимизировать уровень вовлеченности пользователей, чем и заняты соответствующие алгоритмы и рекомендательные движки, в том числе и популярных видеохостингов. С их помощью мы незаметно для себя день за днем строим персональный инфококон, из которого потом придется выбираться: Воззрения, которыми вы обладали несколько лет назад, становятся все более экстремальными за счет влияния соцсетей, замечает Канеман.

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

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

Даже разработчик, поучаствовавший в проектировании рекомендательного алгоритма YouTube, убежден, что задачи для него можно было бы сформулировать несколько иначе. За этим последовала бы совсем другая реализация и эффект в масштабе пользовательской базы сервиса.

Сегодня вопрос заключается в том, какую долю от семи с лишним сотен миллионов часов, затрачиваемых на просмотр роликов, люди расходуют на достаточно посредственные видео. Если одной из ключевых метрик для включения того или иного сюжета в топы и related-подборки остается суммарный объем времени, потраченного на него пользователями, то такие рекомендации будут соответствующего качества.

Слабые рекомендации

Сегодня все чаще можно встретить критику алгоритмов YouTube. Вот так на эту тему высказываются на Hacker News: Болею, целую неделю сижу дома. Фактически обновляю главную каждые пятнадцать минут, но видео, которые я пропускаю уже сотый раз, остаются на месте. Снова и снова нужно скроллить, чтобы найти что-то другое. Базовая рекомендация в таких ситуациях самостоятельно редактировать, чистить или замораживать историю просмотров. Если избавиться от пары записей с роликами об условных теориях заговора, алгоритм пессимизирует это тематическое направление и не будет рекомендовать подобный контент. Более радикальный подход режим приватного просмотра [инкогнито или private browsing], если возникает спонтанное желание провалиться в черную дыру с кучей сомнительных сюжетов. Так можно будет и не тратить время на чистку watch history.

Резиденты HN отмечают и другие особенности рекомендательного движка этой площадки: Помню, как в далеком 2009-м искал электронную музыку и в related к трекам с условной тысячью просмотров были аналогичные по популярности композиции. Их мало кто слушал, поэтому и я всего за несколько часов открыл для себя кучу новых исполнителей. Сегодня все иначе алгоритм выдает похожие видео, но это почти всегда стотысячники.

Стоит признать, что встречаются и мнения в защиту YouTube, хотя по большей части ключевую роль в примерах играют не алгоритмы, а пользовательский опыт: На моем ноуте слушал музыку чуть ли не весь дом, но ситуацию спас хороший вкус окружающих теперь сервис радует меня шикарными рекомендациями. Они круче, чем у Spotify. На HN говорят и о других видеохостингах вроде Netflix, но даже в случае этой стриминговой площадки пользователи сожалеют о низком качестве действующих алгоритмов фильтрации контента по сравнению с временами, когда компания работала с DVD-дисками и предлагала качественные рекомендации.

Отсутствие точечных настроек

Зачастую, чтобы улучшить выдачу, аудитории YouTube приходится обходить заводскиевозможности сервиса и прибегать к ухищрениям вроде регистрации нескольких аккаунтов для различных задач. Допустим, первый они используют для изучения всего нового, что имеет отношение к работе, а второй для просмотра видео по сторонним темам.

Еще один лайфхак пригодится тем, кто не успевает изучать ролики, отложенные для последующего просмотра. Часть из них рано или поздно пропадают с площадки либо за нарушения правил, либо по желанию авторов, решивших обновить канал. В таком случае стоит заранее воспользоваться youtube-dl одним из наиболее популярных менеджеров загрузок [более 87 тыс. звезд на GitHub на момент публикации]. Либо выбрать более доступный вариант закинуть ссылку на видео в Wayback Machine. Однако в этом случае гарантированной архивации ждать не стоит снэпшот могут и не сделать по единственному запросу [хотя общее число захватываемых сервисом роликов еще в 2018-м оно доходило до 800 тыс. в неделю].

По мнению резидентов HN, чтобы не отвлекаться на рекомендации, иногда стоит полностью скрывать related-секции с помощью адблокеров. Или настроить автоматический редирект с главной к ленте тех каналов, на которые вы подписаны. Вообще говоря, среди аудитории площадки уже давно сформировался запрос на подобный функционал и точечные возможности вроде белых и черных списков, которые позволили бы прятать из выдачи ролики с определенными ключевыми словами, тегами и параметрами. Однако зрители вынуждены делать все это с помощью сторонних сервисов например, RSS-ридеров. Хотя и эту возможность, кажется, уже ограничили, так что довольствоваться остается лишь расширениями для браузеров.

Что будет происходить дальше

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

Следует признать, что перекос в строну исключения человеческого фактора из рекомендательного процесса пока не принес выдающихся результатов, поэтому маятник уже начал движение в обратную сторону. Мы продолжим рассказывать о том, как развиваются альтернативные способы поиска интересных видеороликов и музыки здесь и в нашем Мире Hi-Fi, а пока предлагаем несколько материалов для дополнительного чтения по теме:

• Одна из киностудий снова выставлена на продажу, но ее стоимость снизилась вдвое

• В каких странах взносы за ТВ обязательны, а где их растягивают еще дальше

• Почему индустрия подкастов походит на стриминг сериалов и фильмов

• Домашние проекты: как из подвала игровую комнату сделали

• Вендор-лок для подкастов: к чему он приведет

• Смотрим дома: технологии и форматы

• Dolby Atmos и его друзья

• Новогодняя распродажа скидки до 75%

Привет, Хабр!

Я 8 лет занимаюсь проектами в антимонопольной сфере одном из самых интересных направлений юриспруденции. Сейчас руковожу командой в юридической фирме ART DE LEX, которая специализируется на цифровых рынках. Мы ведем работу по возбужденному сегодня Федеральной антимонопольной службой делу против Google.

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

В последнее время заметно беспрецедентное внимание государства к сфере IT и в первую очередь к деятельности техногигантов Apple, Alphabet, Amazon, и Facebook. Важное значение здесь имеет активность Минюста США и Федеральной торговой комиссии, известных ранее своим мягким отношением к этим компаниям и делавших ставку на возможность саморегуляции отрасли. Например, основания для подачи иска против Google из-за действий по монополизации рынка мобильного поиска были у ФТС еще восемь лет назад, но экономисты регулятора не усмотрели тогда существенных рисков.

Теперь ситуация изменилась в конце прошлого года Минюст США подал иск против Google, ФТС против Facebook, а Конгресс США и вовсе рассматривает возможность принудительного разделения компаний. Такая активность на родине техногигантов (с учетом высокого уровня протекционизма) стала еще одним сигналом другим странам к работе в данном направлении. Тем более, что есть уже примеры довольно агрессивного поведения со стороны отдельных компаний. Так, в Австралии в ответ на новый закон, обязывающий делиться частью рекламных доходов, получаемых за счет использования контента новостных изданий, Google пригрозил закрыть в стране свою поисковую систему, а Facebook на какое-то время заблокировал ссылки на новости от австралийских издателей.

Вчера ФАС объявила о возбуждении антимонопольного дела в отношении компании Google. По тому же нарушению, признаки которого недавно ведомство усмотрело в действиях Яндекса, злоупотреблению доминирующим положением. Ранее злоупотребившими доминирующим положением ФАС признавала Apple, HeadHunter, Microsoft, Booking и Google.

Злоупотребление доминирующим положением

Первое, на что обращают внимание при описании злоупотребления доминирующим положением, доминирование само по себе нарушением не является. Даже доля в 100 % на мировом рынке и рыночная власть над всеми контрагентами это не нарушение. Но определенные действия (или бездействие) наносят вред экономике, если совершаются именно доминантом. Это логично исключение русскоязычного сайта из поисковой выдачи Google и Яндекса приведет к катастрофическому падению трафика, а отсутствие в выдаче DuckDuckGo, скорее всего, вообще не будет заметно (не в обиду отличному сервису).

В антитрасте есть два подхода к определению злоупотребления доминирующим положением:

• прямое указание видов действий доминанта, признаваемых нарушением, они запрещаются per se (лат. "сам по себе") без оценки и доказывания последствий,

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

В Федеральном законе "О защите конкуренции" от 26.07.2006 135-ФЗ (ЗоЗК) прямо перечислены 11 видов действий, которые запрещаются per se. Среди таких действий установление или поддержание монопольно высокой цены, создание дискриминационных условий, навязывание невыгодных условий договора и др.

Но одновременно используется и второй подход, в качестве последствий указаны (достаточно одного):

• недопущение, ограничение, устранение конкуренции,

• ущемление интересов других лиц (хозяйствующих субъектов) в сфере предпринимательской деятельности,

• ущемление интересов неопределенного круга потребителей, в том числе следующие действия (бездействие).

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

Я буду в тексте использовать слово "товар" также для обозначения услуг и работ. Это юридический термин, используемый в антимонопольном законодательстве. Терминология в антитрасте выглядит так, как будто речь всегда идет о физических товарах. Например, формулировка "Google продает YouTube Дудю" означает, что Google LLC оказывает Дудю комплекс бесплатных услуг сервиса YouTube.

В общем виде алгоритм установления злоупотребления доминирующим положением выглядит следующим образом:

Рассмотрим на актуальном примере:

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

Основные претензия КСП к Apple:

высокая комиссия за платежи в App Store и платежи внутри приложений,

ограничения на использование альтернативных средств оплаты.

Нарушает ли Apple российское законодательство?

Позиция на рынке

На первом этапе устанавливается доминирующее положение. И часть работы здесь уже выполнила ФАС.

По результатам рассмотрения дела Лаборатория Касперского vs Apple ФАС определила, что существует мировой рынок распространения приложений для мобильных устройств, функционирующих под управлением операционной системы iOS. На этом рынке доля у Apple будет близка к 100 %, так как официальные альтернативные каналы установки приложений отсутствуют. Можно, конечно, попробовать рассмотреть Testflight, PWA, IPA Sideloading (с джейлбрейком и без) в качестве таких каналов. Но первым же опросом разработчиков и пользователей такое предположение будет опровергнуто, да и фактическая доля использования этих каналов будет минимальной.

Почему именно для мобильных устройств и операционной системы iOS? Здесь все просто опросы разработчиков показали неготовность к отказу от разработки приложений для мобильных устройств и разработки приложений для одной мобильной ОС в пользу любой другой.

Итак, переход на другую ОС или другой канал распространения с целью обхода уплаты комиссии не альтернатива для разработчиков.

По механизмам монетизации Apple разделил приложения на 8 групп:

бесплатные не платят комиссию,

бесплатные с рекламой не платят комиссию,

бесплатные с физическими товарами и услугами не платят комиссию,

бесплатные с оплатой внутри приложений платят комиссию с платежей внутри приложений,

платные платят комиссию с платежей в App Store при приобретении,

бесплатные с подпиской платят комиссию с платежей за подписки, оформленные через сервис Apple,

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

кроссплатформенные платят комиссию только с платежей на iOS, с платежей на других платформах не платят.

Получается, что у разработчиков есть несколько вариантов обхода необходимости платить комиссию:

сделать приложение бесплатным,

изменить модель монетизации и получать доход с рекламы,

проводить платежи на другой платформе или через браузер.

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

Таким образом, возможность найти альтернативу платежной системе Apple выглядит сомнительной. Наверное, при наличие такой возможности КСП и не появилась бы. Чтобы это проверить необходимо провести опрос репрезентативной выборки разработчиков и пользователей. С высокой вероятностью он подтвердит наши предположения. В таком случае мы получим близкую к 100 % рыночную долю Apple, и, соответственно, установим доминирующее положение.

Навязывание

Эквайринг Apple неразрывно связан с магазином App Store. Но являются ли они одним товаром? Чтобы ответить на этот вопрос, необходимо определить будут ли разработчики приобретать App Store и эквайринг по отдельности при наличии такой возможности. В контексте нашей ситуации вопрос упрощается до "Будут ли разработчики использовать альтернативные системы эквайринга при наличии такой возможности?". Для ответа даже не нужен опрос можно просто посмотреть способы оплаты в приложениях доставки еды, такси и интернет-магазинов, которым Apple дает возможность выбора. И практически везде мы увидим набор различных способов оплаты (вплоть до оплаты наличными). Да и сам факт допустимости использования для отдельных видов приложений различных способов оплаты показывает, что Apple продает свой эквайринг и App Store по отдельности.

Так как это различные товары, то перед нами может быть классический случай связывания или продажи "в нагрузку". За практику связывания в 2015 г. был признан злоупотребившим доминирующим положением Google он обязывал разработчиков устанавливать с Play Store весь пакет GMS и ставить Google поиском по умолчанию. Для тех, кто помнит покупку билетов на вокзале, продажа страховки ЖАСО вместе с ж/д билетом без указания на возможность отказа один первых кейсов по этому виду нарушений в России.

На классических рынках связывание это чаще всего нарушение. Но на цифровых рынка связывание бывает позитивным явлением и может приносить больше пользы, чем вреда. Например, единство аппаратной части и ОС в планшетах и смартфонах Apple вполне можно было бы обосновать целями обеспечения стабильности, безопасности и совместимости. Но в нашем случае довольно сложно дать обоснование полезности связывания App Store с системой обработки платежей, да и сам Apple отлично обходится без такого связывания для отдельных категорий приложений.

Связывание и навязывание условий, препятствующих использованию альтернативных систем платежей, могут быть квалифицированы как нарушение п. 3 ч. 1 ст. 10 ЗоЗК навязывания контрагенту условий договора, невыгодных для него или не относящихся к предмету договора.

Создание препятствий доступу на рынок

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

Это нарушает еще один запрет п. 9 ч. 1 ст. 10 ЗоЗК создание препятствий доступу на товарный рынок.

Завышение цены и ценовая дискриминация

Комиссию можно рассматривать как цену на услугу. В ЗоЗК есть отдельный состав для случаев завышения цены установление монопольно высокой цены. МВЦ цена, которая превышает цену на сопоставимом конкурентном рынке, а расходы на производство и реализацию и прибыль при такой цене выше "необходимых". Эта "необходимость" не определена, что для антимонопольного регулирования нормально, так как невозможно прописать в законе единую формулу для всех цен на всех рынках.

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

В первом случае сравнение проводится с такими сервисами как Stripe, PayPal, которые позволят организовать оплату в приложении. Допустим, что наше приложении не приносит больших доходов, средний платеж в нем составляет 5$ и Apple применяет пониженную комиссию в 15 %. Для Stripe и PayPal возьмем размер комиссии за внутренние платежи в США.

Apple 5 * 0,15 = 0,75$

Stripe 5 * 0,029 + 0,3 = 0,445$

PayPal (Micropayment) 5 * 0,05 + 0,05 = 0,3$

Если брать российского разработчика с небольшим оборотом, то на платеж в 300 руб. комиссия Apple составит 45 руб., а сервиса интернет-эквайринга Тинькофф всего 9 руб.

Даже для льготного разработчика с "льготной" комиссией разница с ценами известных эквайринговых сервисов довольно большая. Колоссальные различия будут, например, у крупных разработчиков F2P игр для них комиссия Apple не упадет ниже 30 %, а вот комиссии за внешний эквайринг будут очень малы за счет объемных скидок.

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

Второй вариант Apple берет комиссию не только за эквайринг, но и за возможность использования инфраструктуры, компенсируя тем самым инвестиции в создание и поддержание этой инфраструктуры.

У этого толкования есть ряд проблем.

Только 16 % из всех приложений приносят Apple комиссионные, остальные пользуются инфраструктурой бесплатно. Такое явление называется кросс-субсидирование и зачастую оно связано с дискриминацией. Есть ситуации, когда оно допустимо и обосновано. Например, при наличии на платформе платных и бесплатных тарифных планов. В таком случае пользователи сами выбирают использование платного плана, а бесплатные осуществляют важную функцию привлечения новых пользователей, которые затем могут перейти на платные тарифы.

В нашем случае трудно найти обоснование дискриминации. Разработчик крупного приложения доставки еды с десятками тысяч загрузок будет работать бесплатно, а инди-разработчик текстового квеста платить 15 %. Дискриминация есть и при первом варианте, но здесь она более очевидна, так как инфраструктуру используют все, а платит за нее меньшинство.

App Store как платформа подвержена влиянию сетевого эффекта (подробнее см. ниже) увеличение количества разработчиков увеличивает ценность услуг платформы для пользователей (и наоборот). Повышение ценности App Store, в свою очередь, повышает ценность iPhone и iPad основных товаров Apple. Следовательно, за счет создания и поддержания разработчиками приложений для iPhone и iPad растут (или не падают) доходы Apple. Можно даже попробовать оцифровать пользу разработчиков для Apple, например, выяснив путем опроса какой процент пользователей откажется от приобретения нового iPhone, если из App Store пропадут все приложения членов КСП.

Таким образом, в действиях Apple можно найти признаки п. п. 1 и 8 ЗоЗК установления монопольно высокой цены и создания дискриминационных условий.

Следовательно, в действиях Apple есть признаки 4 из 11 прямо перечисленых видов злоупотребления доминирующим положением. Возможно, что Epic Games и Spotify стоит развернуть фронт борьбы и в России.

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

Яркий пример из нового дела против Google только за период с июля по сентябрь 2020 г. YouTube удалил более 1,8 млн каналов более 32 млн видеозаписей. При этом в блоге сервиса сообщается о высокой вероятности блокировки даже без прямых нарушений, в том числе из-за более активного использования автоматических систем оценки контента и сдвигами к стратегии чрезмерной защиты приоритета скорости модерации перед качеством.

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

Что делать платформам и пользователям?

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

Российский антимонопольный орган был создан и приобретал опыт в сложных условиях переходной экономики, на фоне столкновения огромного количества разнонаправленных интересов. В рамках своих полномочий он выступал медиатором, помогая сторонам разбирательства в короткие сроки прийти к консенсусу. Благодаря этому сейчас у ФАС есть ряд свойств, необходимых для разрешения конфликтов в на цифровых рынках:

• скорость с поступления жалобы до принятия решения проходит около 16 мес. (в Еврокомиссии дела могут рассматриваться до 8 лет), дело Яндекс vs Google было рассмотрено за 7 мес.,

• эффективность предписания ФАС почти всегда исполняются,

• компетентность ФАС получила признание на международном уровне, ее решения успешно проходят судебную проверку.

Важное значение имеет наличие коалиции при рассмотрении в ФАС антимонопольных дел. Фактически процесс в ФАС очень состязательный и весьма желательно иметь сильное представительство и единую позицию. Коалиция позволит выполнить и прикладную задачу обеспечить привлечение экспертов (экономистов, социологов, технических специалистов) для формирования позиции.

Для платформ, особенно самых крупных, важен конструктивный диалог со всеми категориями пользователей. С их участием имеет смысл вести работу по саморегуляции. Примеры отраслевой саморегуляции разрабатанные участниками рынка под эгидой ФАС Кодекс поведения автопроизводителей и автодилеров и Кодекс добросовестных практик в фармацевтической отрасли. Индивидуальная саморегуляция обычно осуществляется путем разработки, обсуждения с ФАС и заинтересованными лицами (например, в рамках экспертного совета при ФАС) и принятия публичных правил торговой практики компании.

Для цифровых платформ потребуется более детальная проработка актов саморегуляции и более широкое их обсуждение, а для трансграничных цифровых платформ обсуждение и согласование на международном уровне.

Анализ состояния конкуренции. Предварительное определение продуктовых границ

В антимонопольном анализе самая сложная часть анализ состояния конкуренции. Именно в результате его проведения выясняется занимает ли компания доминирующее положение. И первый шаг здесь это определение рынка.

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

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

В этой статье я ограничусь темой продуктовых границ одной из самых интересных в антитрасте. Для начала необходимо предварительно определить о каком собственно товаре идет речь. Это можно сделать, например, на основе условий договоров или оценок специалистов, перечень способов открытый. Уже на этом этапе задача становится нетривиальной у нас нет четкого алгоритма предварительного определения товара.

Приведу пример по мотивам дела "о колдунщиках":

Владелец агрегатора отелей ABC вбивает в Google запрос "отели Москва" и видит вместо первой ссылки (или второйтретьей, это как повезет) Google OneBox с формой и данными сервиса Google Travel. Уже есть основания для подачи заявления в ФАС здесь признаки и недобросовестной конкуренции, и злоупотребления доминирующим положением. Но для начала можно установить какую именно услугу оказывал Google владельцу ABC.

Для этого открываем договор между компаниями пользовательское соглашение. Но в Условиях использования Google про поисковый сервис лишь упоминается никакого перечня услуг, оказываемых Google владельцу сайта ABC, нет. Как в данном случае определять продуктовые границы? Поисковый запрос гласил "отели Москва". Значит, может быть, речь идет об услугах поиска средств размещения? Но на этом рынке Google никаких услуг владельцу ABC не оказывал, здесь они прямые конкуренты. Этот рынок релевантен с точки зрения недобросовестной конкуренции, но не злоупотребления доминирующим положением.

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

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

В таком случае речь идет уже о рынке услуг поиска в интернете общего характера. Этот рынок будет многосторонним его участниками будут владельцы универсальных поисковых систем, владельцы индексируемых интернет-ресурсов и авторы поисковых запросов. Именно такой подход к определению границ рынка использовала ФАС, выдавая Яндексу предупреждение и возбуждая антимонопольное дело.

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

Пример предварительного определения продуктовых границ:

ФАС предварительно определила товар как колесо цельнокатаное диаметром 957 мм с набором технических характеристик: марка стали, внутренний диаметр отверстия ступицы. Каждое колесо с отличающимся набором обозначенных характеристик предварительно рассматривалось в качестве отдельного товарного рынка. Это обоснованное сужение границ взаимозаменяемость колес с каждой связкой характеристик еще предстояло определить в дальнейшем.

С учетом этого попробуем назвать услугу, оказываемую Google через сервис YouTube. Посмотрим как определяют YouTube сам Google и коллективный разум (Wikipedia):

Terms of Service

The Service allows you to discover, watch and share videos and other content, provides a forum for people to connect, inform, and inspire others across the globe, and acts as a distribution platform for original content creators and advertisers large and small.

Условия использования YouTube

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

Wikipedia (en)

YouTube is an American online video-sharing platform headquartered in San Bruno, California.

Wikipedia (ru)

Видеохостинг, предоставляющий пользователям услуги хранения, доставки и показа видео.

И обратимся к определениям вида платформ, к которым относится YouTube:

Wikipedia (en)

An online video platform (OVP), provided by a video hosting service, enables users to upload, convert, store and play back video content on the Internet, often via a structured, large-scale system that may generate revenue. The website, mainly used as the video hosting website, is usually called the video sharing website.

Wikipedia (ru)

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

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

Начнем с функционала. Функциональное назначение являлось отправной точкой выявления продуктовых границ делах Лаборатория Касперского vs Apple (в качестве функционального назначения товара определена возможность распространения приложений, предназначенных для использования на абонентских устройствах) и Стафори v. HeadHunter (функциональное назначение определено перечнем функций для каждой из выделенных категорий пользователей - соискателей и работодателей).

В нашей ситуации оптимальным будет по аналогии с делом Стафори vs HeadHunter определить перечень функций YouTube:

• Загрузка, хранение и показ видеоконтента

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

• Поиск видеозаписей

  Для авторов и зрителей важны не только и не столько само загрузка, хранение и показ видеоконтента (эти функции можно реализовать и на собственном сервере), но и возможность в широком смысле найти контент. В этом помогает витрина видеоконтента разделы Главная (с рекомендованным на основе истории просмотра и поиска, сведений из аккаунта Google и браузера Chrome видеоконтентом), Популярные видео и Подписки.

  Cервис обладает высококачественным поиском, в выдаче которого также учитываются данные, на основе которых делаются рекомендации. Кроме того, в сервисе имеется функция Следующее, предлагающая схожий контент при просмотре видео. В плане поиска YouTube сильно обгоняет сервисы с видеофункционалом. Но мы не будем это свойство ограничивать функционалом и качеством YouTube. Будем понимать под поиском функцию, для которой бы подошло более емкое слово "discovery".

  Такой функционал позволяет зрителям быстро и удобно находить интересующие их видеозаписи и трансляции, а авторам набирать просмотры и подписчиков. Рекомендации позволяют показывать пользователю наиболее релевантные для него видео. Это означает, что контент канала будет автоматически предлагаться к просмотру зрителям, с высокой степенью вероятности относящимся к целевой аудитории канала.

• Социальные функции, связанные с видеоконтентом

  Это комментирование и оценка. Без них описываемый вид платформ сложно представить. Но здесь мы ограничиваемся функциями, завязанными на основной вид контента. Иначе границы будут изначально сильно расширены, что не позволит достоверно учесть мнение пользователей.

Функциональные характеристики имеет смысл дополнить характеристиками качественными.

• Диверсифицированность контента, авторов и зрителей

В приведенном ранее примере я упоминал, что ФАС выделил рынок услуг поиска в интернете общего характера. Однако поисковые функции предлагает подавляющее большинство платформ: поиск по средствам размещения в Booking, по репозиториям в GitHub, по видеоконтенту в YouTube и т. д. Не следовало ли ФАС разбить общий поиск на сегменты и анализировать их как отдельные рынки?

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

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

Конвергенция привела к тому, что все три услуги начали продаваться едиными пакетами. Ценовая политика операторов привела к экономической нецелесообразности приобретения услуг мобильной связи по отдельности. Сейчас профиль потребления очевиден подавляющее большинство абонентов приобретает услуги мобильной связи в пакете. Поэтому на данный момент следует определять единый рынок мобильной связи. Не исключено, что использование пакетной продажи приведет к объединению рынка мобильной связи с рынками фиксированной связи.

Сферы использования общих и специализированных поисковиков иногда пересекаются отель, репозиторий и видеозапись можно найти и в Google. Однако, например, в ситуации с репозиторием Google не предоставит удобных функций фильтрации поисковой выдачи и расширенного поиска, возможности ознакомления и взаимодействия с репозиторием и т. д. Поэтому пользователи предпочтут использовать GitHub для поиска репозитория с конкретными параметрами. Но заменить Google коллекцией спецпоисковиков тоже никто не спешит.

YouTube это специализированный на видеоконтенте сервис, но в отношении видов контента такая специализированность отсутствует. На YouTube размещают видеоконтент и крупнейшие СМИ, и бьюти-блогеры. Аудитория YouTube тоже диверсифицирована это люди разных возрастов, видов профессиональной деятельности, интересов. Диверсифицированность аудитории и контента отличает YouTube от, например, сервиса Twitch, специализирующегося на тематике компьютерных игр.

• Отсутствие существенных ограничений по длительности, размеру и формату видеоконтента

Важным свойством YouTube, отличающим его, например, от TikTok, является возможность хранения (показа и трансляции) длительных видеозаписей. На YouTube можно добавлять файлы размером до 128 ГБ включительно. Максимальная продолжительность видео 12 часов.

YouTube активно используется на всех видах устройств компьютерах, телевизорах, смартфонах и планшетах для просмотра как горизонтального, так и вертикального видео. Сервисы TikTok, Instagram и IGTV в подавляющем большинстве случаев используются для просмотра вертикального видео на смартфонах. Профиль использования этих сервисов является фактическим ограничением для показа на них горизонтального видеоконтента.

Я не указал еще две особенности YouTube, которые важны для потребителя и влияют на его выбор. Их учет, скорее всего, позволил бы признать Google единственным участником рассматриваемого рынка. Это высокое качество и большая пользовательская база.

На пользовательской базе остановлюсь подробнее.

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

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

В нашем случае имеют место, в первую очередь, косвенные сетевые эффекты:

1. Чем больше на YouTube зрителей, тем больше просмотров, что увеличивает ценность платформы для авторов и приводит к увеличению их количества и активности на платформе;

2. Чем больше на YouTube авторов, тем больше контента и тем выше его качество, что привлекает зрителей;

3. Увеличение количества просмотров и видеоконтента приводит к повышению привлекательности YouTube для рекламодателей увеличивается как их количество, так и их расходы на рекламу;

4. Популярность сервиса среди рекламодателей, в свою очередь, привлекает новых авторов и мотивирует их на повышение количества и качества контента goto п. 1.

Этот цикл позволяет обеспечить сервису стабильный рост количества и активности пользователей, а, следовательно, и рост рекламных доходов. Он также дает платформе стабильность группы пользователей удерживают друг друга от возможного отказа от YouTube.

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

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

Следующим этапом будет определение взаимозаменяемых товаров. Об этом в следующей статье.