Архив недели
Понедельник
Всем привет! Я - Ваня Бурцев, медиа инженер. Работал в таких ОТТ компаниях, как IVI.RU и OKKO.TV. Я расскажу что вообще такое медиа в интернете, как оно устроено внутри и много всякого интересного из мира ютубов, тиктоков и нетфликсов.
Что хотелось бы рассказать:
Пн.-Что такое медиа и что там интересного
Вт.-Найти IT призвание и не прогадать
Ср.-Хитрости от TikTok и Netflix
Чт.-Как войны корпораций мешают жить
Пт.-Работа в компании меньше года - норм?
Сб.-Почему свой YouTube - ни разу не просто
Вс.-Поговорим?
Ну-с приступим)
Как оно вообще в мире медиа и как лично меня затянуло на это поприще. Начну с небольшой школьной предыстории.
Началось все с телефона Siemens S65)
Это был мой первый телефон с возможностью смотреть видео и слушать музыку. И так как показать братюням мощные клипы с Linkin Park на телефоне оч хотелось - я нашел на диске Игромании какую-то программулину по конвертации видео и пошло-поехало.
Там я дотошно изучал все возможные ручки и настройки для видео и аудио, чтобы уместить на MMC карте телефона в 64МБ максимум своей муз-коллекции, но чтобы при этом картинка не разваливалась, fps не падал, а звук был приемлемый. Так начало моей страсти к медиа и было положено.
После этого было много всего: увлечение музыкой и домашние сессии звукозаписи своих треков, свой проект на C++ с видео анализом и OpenCV, владивостокский стартап с риалтайм чатом и мини-играми и многое-многое другое.
Все это привело меня в мою первую серьезную компанию - Иви.
Именно тут, в Иви, я понял, что именно с медиа я хотел бы связать свою проф. жизнь, так как на столько многогранной сферы деятельности я не мог найти долгое время. Вот только некоторые из них:
- транскодинг
- платформы
- плееры
- плейбек
- раздача контента
- вендоры
- сеть
Транскодинг
Чтобы контент могли воспроизвести - его нужно преобразовать в нужный кодек, упаковать в контейнер, аккуратно "пожать" и приготовить к транспортировке. Это достаточно ресурсоёмкая операция, так как обрабатывается приличное количество информации.
Например, чтобы транскодировать файл, который пользователь отправляет на YouTube, серверам Google нужно:
-декодировать видео/аудио в RAW формат
-применить фильтры (скейлер/компрессор/кроппер)
-енкодировать из этого видео/аудио в разных качествах и кодеках
-положить в контейнер
После этого нужно полученные файлы с медиа контентом:
-сегментировать (нарезать малыми файлами)
-зашифровать (если это допустим приватный/платный контент)
-описать все имеющиеся части контента и мета информацию (длительность, разрешение, кодек и пр.) в манифесте
И только после этого всего полученные файлы могут лететь в телевизоры/телефоны/компьютеры/подставь_свой_вариант для того, чтобы скрасить Ваш досуг на вечер) Как видите - не все так просто и быстро, как может показаться на первый взгляд.
Платформы
Их приличное множество и каждая со своими "Фи". Вот самые основные:
- Apple
- Android
- WEB
- SmartTV
- Игровые приставки
- Set-top boxes (например: коробочки-приставки от Ростелекома)
В каждой из платформ есть дополнительные разделения на вендоров. Например: для SmartTV есть разделение на LG, Samsung, Sony, Philips и так далее, которые работают только со своим API и под каждого по нужен свой клиент и свой контент.
Плееры
Для каждой платформы может существовать несколько плееров со своими особенностями и возможностями. Например: на LG WebOS можно использовать плеер от LG, а можно использовать плеер Shaka или DASH на JavaScript, которые будут разные по функционалу и возможностям.
Плейбек
Никому не нравится, когда видео рассыпается, тормозит, дрожит, рябит или попросту - не играет нормально. На это могут влиять огромное кол-во параметров: от состояния сети и пресетов транскодирования до криво написанного софта и ограничений платформы.
Так, например, видео, которое закодировано в кодеке vp9 от Google и хорошо играет в Chrome, не может быть воспроизведено в Safari. Или фильм с 6-канальным звуком в аудио кодеке AAC не может воспроизвестись корректно на домашнем кинотеатре с 6-ю каналами по AirPlay от Apple
Раздача контента
Фильм в интернете может раздаваться просто как MP4 файл, который скачивается по сети, а может раздаваться через HTTP стриминг кусочками (чанками), которые с помощью алгоритмов адаптивизации на основании текущей пропускной способности будут скачиваться плеером.
Также в зависимости от выбранного типа HTTP стриминга может отличаться качество воспроизведения на разных устройствах. Например: HLS стриминг от Apple будет весомо отличаться в воспроизведении адаптивного контента от MSS стриминга от Microsoft.
Вендоры
Тут можно застрять надолго)
Главный нюанс разнообразия вендоров - это отсутствие какого-то общего и везде работающего типа контента. Каждое устройство/плеер/платформа очень щепетильна в выборе поддерживаемых технологий и форматов для медиа.
Самый любимый мой пример - это SmartTV Samsung 2013 года, которые принципиально не будут играть контент, если в URL до контента не прописать определенную строку. Плеер даже не будет пытаться его воспроизвести, так как будет считать, что контент этот не является медиа контентом)
Сеть
В зависимости от кучи параметров: выбора типа доставки (TCP/UDP), протокола доставки (https/http/rtmp/rtc), настроек серверов на отдачу контента и ,конечно же, качества сети обслуживания конечного пользователя будет зависеть качество и скорость воспроизведения медиа.
Все вышеперечисленное - это только часть разнообразия того, что охватывает медиа инженерия. Каждая отдельная часть может сильно сказаться на качестве медиа-сервиса в целом и требуемых ресурсах для корректной работы. Поэтому скучать от типичной "рутины" в медиа точно не получится)
Ну и в целом, медиа-весьма востребованная часть IT, которая есть практически повсеместно в разных сферах: начиная с развлечений и связи, заканчивая научной деятельностью, космонавтикой и медициной. Поэтому иметь представление на базовом уровне про медиа в целом-полезный скилл)
Штош, немного "по верхам" я пробежался, надеюсь было интересно! Если хотите чтобы я что-то рассказал более подробно - не стесняйтесь, спросите) Всем хорошего дня и приятного вечера!
PS. Это моя так называемая "проба пера", поэтому не судите строго)
Тред #1
Вторник
Про мир IT и свое призвание в нем.
Во-первых: нужно понимать зачем тебе это всё. Очевидно, что делать что-то только ради денег - очень глупая затея.
Во-вторых: важно понимать от чего тебя прёт. Нравится делать модные кнопки - делай, кайфуй от себя, это очень важно.
В-третьих: мир IT разнообразен, пробуй, не ссы)
Я поработал в разных сферах (от тренера по спортивным бальным танцам до звукорежиссёра) и пробовал разные вещи именно в IT(от инженера связи до геймдева) и понял: не попробуешь - не поймешь. Естественно везде есть плюсы и минусы, и тут уже вопрос личных компромиссов и желаний.
Как понять, что выбранная область IT -это твое?
ИМХО: профессия должна лаконично вписываться в твою жизнь и интересы, предоставляя новые эмоции и крутые челенджи.
Если на энтузиазме пилишь фичу до победного и после возвращаешься домой измотанный, но с горящими глазами - это оно!
Помню, мы сидели с нашим ПМом до 2-х часов ночи и пытались завести стриминг на старых Sony (еще без андройда). Сделали для этого стенд с сервером, шифрующим медиа на лету, кеш-проксю, подменяющую хедеры и приложение-самопал на телек на JSе. Это был крутой и приятный челлендж)
Тут стоит отметить, что очень важна команда, с которой ты двигаешься и растешь профессионально.
Топ-команда для каждого своя, но я для себя вывел три вещи-лакмусовой бумажки, определяющих тех самых "своих братюней"
Так или иначе - ты работаешь с людьми. И лучше если это твои "Бро".
Однажды на собесе посреди тех-вопросов меня спросили: "Вань, как ты относишься к мату?". Я ,не долго думая, ответил: "Ох$%тельно, бл:%ть, отношусь!". После этих слов мы поняли - я буду работать с этими людьми)
В команде мечты должны быть люди, с которыми ты можешь и пошутить, и покутить, и работу работать. Поверьте, такие команды есть и вы удивитесь на сколько их может быть много! И тут не важно кто вы: интроверт любящий Джабу Хатта из SW, или местный любитель баров и танцев до утра)
В команде ты должен понимать, что с ними - ты сможешь прокачаться.
Не важно в чем: будь это умение качественно писать код, уметь находить лаконичное архитектурное решение или прокачать умение вести диалог и выступать с докладом. Чем больше ты развит "вширь" - тем ты мощнее!
Понимание общих целей команды.
Если каждый в команде, какой бы она крутой не была, не понимает что и для чего - процесс работы замедлится, потеряется остаток энтузиазма и все, рано или поздно, пойдет по одному месту. Общее инфо-поле - мастхеф!
Наверное стоит еще сказать, что немаловажной составляющей будет тот продукт, который ты делаешь, и его ценность для тебя и других. Очень поднимает желание "вджобывать" осознание того, что продукт, над которым ты трудишься, делает кого-то счастливее, веселее, здоровее, лучше.
В одном приморском стартапе, где мы делали соц-сеть с мини-играми и риалтайм стримингом, на бета-тестировании мы сидели и смотрели, как люди развлекаются, играют, общаются и веселятся. Это неимоверно подняло нам желание сделать проект лучше и мощнее. Такие вещи - бесценны.
В случае, если так сложились звезды, и ты попал туда, где тебе не нравится, не качает вайб, не прет мууд, и ничего с этим сделать не можешь - не переживай и пробуй что-то другое. Скорее всего на следующей итерации трудоустройства будет то, что заставит твое сердечко трепетать)
Подытоживая, скажу так:
пойми что ты желаешь от IT
если понял - попробуй
если попробовал - подумай, как послевкусие
если так себе - поменяй рецепт и попробуй еще раз с 1 пункта
если ниче так - попробуй выходить на уровень повыше
если начало переть - поздравляю)
Тред #2
Среда
Сегодня - про магию некоторых мастодонтов в медиа - Netflix и TikTok.
Итак, в период пандемии (да и раньше) подавляющее большинство пользователей с огромным энтузиазмом юзают и продолжают юзать всевозможные видео-платформы и онлайн-кинотеатры. Причины ясны: сидим дома, книги перечитаны, углы комнат изучены, скучно, а инет - вот он, зовет и манит.
Так почему же Netflix и TikTok настолько полюбились пользователям?
Естественно, это достаточно мощные продукты, которые позволяют развлекаться и самовыражаться, но если "кормить" пользователя абы-как - он расстроится и уйдет. И тут вступают в ход хитрости и "магия")
Начну пожалуй с TikTok.
Есть мнение, что человек, который говорит "Я в тик-токе пару минут посижу" пробудет там как минимум часик-полтора) И это достаточно реальная картина, сами попробуйте!
Но магия не в том "отборном контенте" платформы, а в способе и скорости ее подачи.
Контент в TikTok буквально "вываливается" на тебя.
Это создается из-за совокупности тонкостей устройства самого приложения и контента. Вот основные из них:
- видео подается в кодеках с макс сжатием
- видео раздается через мощную систему CDN
- на каждое видео есть легкая "превью"
Про сжатие в TikTok
ТикТок пользует контейнер MP4 с одним видео и аудио, в котором метаданные (описание потоков с их хар-ми) перенесены в самое начало файла (хедер) для инстантного плейбека по http. Так, при получении первых нескольких кбайт плеер может начать играть контент
Так как нет адаптивности (как например у Netflix или YouTube), плееру не кадо думать какой поток воспроизводить в текущем состоянии сети и стартовать много быстрее.
Также TikTok пользует свои плееры под каждую платформу. Их можно подкрутить как удобно, выигрывая время старта.
Сам флоу пост-обработки видео в TikTok такой:
-пользователь на телефоне жмет видео в самом распространенном кодеке H264, в котором видео сразу может быть проиграно где угодно
-на бэке оно в фоне сильно жмется в кодеки HEVC/VP8 и уже легким отдается на основную массу
Для сравнения порядков сжатия H264 и HEVC/VP8 небольшая статейка:
thebroadcastbridge.com/content/entry/…
Из нее видно, что видео прилично теряет в весе. Конечно же оно при сжатии теряет и в качестве, но в TikTok вывели середину, где вес файла минимальный, но и глаза не сильно кровоточат)
TikTok использует CDN (content delivery network) для быстрого доступа к контенту. Работает просто: при запросе к контенту видео проксируется на ноду, географически недалеко от пользователя. Второй пользователь будет смотреть это видео уже с этого сервера, миную поход в сторадж.
Для ощущения супер-быстро влетающего Вам в ленту видео, на стороне бэкенда в TikTok генерится первый кадр в виде JPEG. При запросе клиента ленты ему приходит JSON с сылками на превью, которые весят мало. При свайпе вы вначале видите именно JPEG, а уже после - подгруженное видео.
Очень важная "фича" - префетчинг видео. Если вы думаете, что первое показанное видео ТикТока грузится в момент открытия приложения - подумайте еще раз)
Первые несколько (!) видео частично (!!!) уже в вашем телефоне, готовые к проигрыванию первых нескольких секунд.
Конечно же очень влияет на качество как ты рендеришь (проигрываешь) видео. На телефонах например это делать можно software и hardware методами. В первом случае - телефон начинает декодить на CPU, что сильно бьет по батарейке и работе телефона в целом. HW декодинг намного лучше)
Также не могу пройти мимо и не осветить медиа-редактор TikTok. Оч быстрый (хотя местами очень кривоватый) редактор.
Интересный кейс с ускорением видео и аудио. В редакторе оно происходит почти мгновенно. Просто транскодить - оч долго и дорого, поэтому решение - оч элегантное)
Чтобы молниеносно ускорить медиа, нужно взять поток, пройтись в нем по семплам потока (кадрам/сегментам) и переписать внутри них timestamp-ы - временной параметр, который показывает когда на таймлайне должна быть воспроизведена та или иная часть медиа. Без перекодирования. ШИК!)
Учитывая, что на мобильном поприще особо в мощностях и возможностях не разгуляешься (относительно слабые процы, ПО от вендоров, технологические нюансы), TikTok - оч крутое приложение в технологическом плане.
PS. Контент судить не буду - это, каггрицца, на вкус и цвет)
Следующие - Netflix.
Эти ребята всегда и во всем лично для меня были референсом №1. Это можно просмотреть как на уровне обработки и доставке контента, так на просто интерфейсе их приложений.
Ссылку на их технобложек оставлю тут для любознательных:
netflixtechblog.com
Приведу пару кейсов почему ребята крутые:
- свой протокол стриминга с DRMом, адаптивом и полным фаршем и свой нативный клиент на всём, до чего можно добраться и посмотреть медиа
- контенто-ориентированный транскодинг
- свои "очеловеченные" метрики оценки качества транскодинга
Свой протокол и плеер.
Из-за войн корпораций (об этом скоро) есть оооочень много проблем и нюансов с воспроизведением контента, особенно если он должен быть зашифрован. Ну и доставка по TCP контента в мобильные сети с большими потерями - очень неприятная история.
Свой протокол инженеры из Netflix сделали из всего приятного, что предлагали уже имеющиеся HTTP протоколы для стриминга (HLS/DASH/MSS), и, естественно, сделали свои плееры под это.
Вот небольшой подкаст от русского разработчика в Netflix:
youtu.be/U8iq3JMQugA
В Netflix каждая единица контента анализируется на обилие сменяемых сцен. По анализу выбирается "жирность" пресета на транскодинг. Например, "Мстители" со взрывами и погонями будут откодированы с бОльшим битрейтом, чем нежели "Прибытие" с большим кол-вом статичных сцен.
У Netflix есть VMAF - это алгоритм оценки качества видео. Ссылочка на него:
github.com/Netflix/vmaf
Смысл в том, что оценка "глазами" - очень субъективна, нужны цифры, метрики. Такие есть - SSIM, PSNR, VIF и прочее. Но для полноты картины - их нужно комбинировать.
Даже если ты знаешь, что такое эти ваши SSIM, PSNR и прочие абры-кадабры - метрики, которые они показывают, тяжеловато интерпретировать и показать людям не особо осведомленным в них. VMAF же выдает просто процент схожести референсного потока к оригиналу, используя спец модели.
Тем самым, с использованием VMAF от Netflix можно более глобально и очевиднее дать результат анализа видео.
Вот кейсы, где это очень полезно:
- на сколько хуже стало пожатое видео
- на сколько отличаются видео в H264 и VP8
- на сколько хуже транскодинг на GPU чем на CPU и т.д.
В треде я попытался рассказать о некоторых, на мой взгляд, простых, но крутых медиа-решениях и нюансах, которые и делают Нетфликс с ТикТок такими крутыми.
PS: надеюсь, было как минимум не скучно)
Тред #3
Четверг
Как войны корпораций мешают жить
В этом треде я поделюсь своими мыслями про корпорации, их влияние на жизни простых разработчиков и поведаю пару кейсов из мира медиа, где, поверьте, с этим боли не меньше.
Большие корпорации достаточно часто создают прордукты, которые делают мою (да и вашу) жизнь веселее и приятнее.
Первое, что мне приходит на ум - это GarageBand! Очень благодарен Apple за возможность записать хорошую демку в дороге, имея гитарку, шнур и аудиоинтерфейс iRig.
Но когда продукты корпораций-гигантов начинают что-то делить (рынок, объем пользователей, технологии, патенты) - получается вообще не круто. Начиная с пользователей их продуктов, заканчивая разработчиками, связанными с продуктами таких гигантов.
Примеров таких - очень много. Медиа-инженеров они тоже не обошли стороной.
Начну с одной относительно недавней истории, в которой я возненавидел Google и Apple за неумение договариваться. Она связана с риалтайм-стримингом через WebRTC в браузерах (ссылка webrtc.org)
Вкратцие про WebRTC - это peer-to-peer технология, которая позволяет в ВЕБе без Flash-a (господи прости) созваниваться друг с другом по видеосвязи, писать в чатиках и пересылать друг другу мемесы в рамках одной сессии без установки дополнительного софта и минуя сервера.
Связь двух юзеров происходит примерно след образом:
-юзеры идут на хост для установки соединения между собой в виртуальной комнате для сигналинга
-если соединение ОК - юзеры обмениваются возможностью передавать и принимать медиа-потоки
-если потоки всеми поддерживаются - бинго!)
Для описания поддерживаемых медиа-потоков используется SDP, в котором указан: кодек, индекс потока, частота дискретизации и доп. инфо.
Например, чтобы обменяться аудио в OPUS кодеке будет примерно такая строка:
a=rtpmap:111 opus/48000/2
109-индекс,opus-кодек,48к-частота,2-стерео
И если с аудио все более-менее нормально, то вот с видео ты будешь делать танцы с бубном... жаркие танцы:
- индексы в Сафари и Хроме на стримы отличаются
- "вездесущий" H264 кодируется по разному
В итоге вы друг друга не увидите, ибо декодеры в браузере просто не заведутся)
Разработчики из Zoom/Mail Group посмотрели на это вот все и просто сделали свои протоколы на основе WebRTC, естественно, не забыв про свои плееры, которые помогают избежать всей этой нездоровой движухи)
Более подробно про опыт ОК с видеозвонками: youtu.be/2z4XO3fyn3U
Еще одна боль связана с HTTP стримингом и DRM. Немного информации для понимания дела)
Есть основные виды HTTP стриминга:
-HLS(Apple)
-MSS (Microsoft)
-DAHS (MPEG)
Есть основные виды DRM для HTTP стриминга:
-FairPlay(Apple)
-PlayReady(Microsoft)
-Widevine(Goolge)
DRM (en.wikipedia.org/wiki/Digital_r…) - штука, без которой в OTT нереально выжить. Именно благодаря системам DRM в стриминге вы можете смотреть Джентельменов Гая Ричи у себя дома на телевизоре через какой-нить Netflix или Кинопоиск, ибо DRM позволяет защитить контент от "слива" в сеть.
Как оно примерно работает:
-контент сегментируется и шифруется уникальным ключом
-в манифест контента (описание HTTP стрима) записывается payload для получения ключа дешифровки
-при плейбеке контента, плеер идет за ключом уникального контента и, после верификации, получает его
Определенный вид стриминга может уметь только в определенный DRMи не уметь в другой. Например, MSS может только в PlayReady, но в Widevine он не умеет.
Также, для разных типов устройств есть свои пересечения поддерживаемых типов HTTP стриминга и типов DRMa.
Чувствуете проблему?)
В итоге, чтобы ОТТ сервис мог показать контент, который по договору правообладателя должен быть зашифрованный, на iOS, Samsung TV, XBox и вооон том андройд-свистке, нужно иметь достаточно приличный перечень по разному хранящегося контента.
PS. И не факт что он еще заработает))
Кстати, относительно недавно Huawei решил накинуть на вентилятор - и запилил свой DRM. Естественно, радости для ОТТ компаний и инженеров в частности не прибавилось)
Ссылка на инфу: medium.com/huawei-develop…
Сам зашифровать как тебе нужно ты не сможешь, так как:
-есть добрый перечень видеоплееров, с которыми твое лихое шифрование не будет работать
-есть правообладатель, который на твое "мамой клянусь, мое шифрование не взломать" просто не даст тебе показывать кинчик... ну или суды)
Есть конечно решения, которые делают весь зоопарк шифрованного контента поменьше. Например, хранить контент, зашифрованный набором ключей разных вендоров DRM и раздавать только разные манифесты на нужные плееры, но работает это, особенно со старыми устройствами, иногда никак)
"Подружиться" вендоры не могут, поэтому приходится с этим мириться и делать как-нибудь, лишь бы покрытие устройств было больше, а плейбек - ровнее. При этом нужно еще уложиться в "косты" и технические возможности.
Поверьте, это не так все просто что "ОП-ОП и завелось")
Для понимания боли приведу такой факт.
В 2014 году бахнул кризис. Люди побежали сметать все, что только можно в магазинах, в том числе и SmartTV. Чтобы вы понимали - смарты очень "тупенькие" на железо. Ну и 2014 год говорит о том, что телеки много чего из современного не могут)
Вопрос - сколько раз в год/два/пять вы меняете телевизор?
Думаю ответ - "лол-што?")
В России телевизор если меняют раз в 10 лет - это уже счастье для производителей! У Самсунга, кстати, если телевизору больше 5 лет, то его поддержка прекращается)
"А вот если бы был какой-то универсальный вид стриминга с DRM, аккредитованным для правообладателей..." - влажные мечты думаю если не каждого, то почти каждого инженера, так или иначе связанного с ОТТ.
Кстати, Netflix решили эту проблему через свой протокол и свои плееры)
Кстати, есть немалое такое "ANTI-DRM" движение, которое против этого всего.
Основные доводы:
- даже аккредитованный DRM можно сломать (из недавнего: krebsonsecurity.com/2020/10/google…)
- DRM усложняет жизнь и пользователям, и правообладателям, и артистам.
- скринкапчуринг?)))
Мое мнение по этому всему следующее:
Думаю, если бы люди из разных корпораций работали бы над одной и той же смежной проблемой/фичей в кооперативе и не бодались друг с другом - жизнь многих была бы намного проще и веселее.
Каггрицца "Make love, not war"✌️
Тред #4
Пятница
Йочекиряу!
Сегодня хотел бы порефлексировать на оч важную для меня тему: "Работа в компании меньше года - норм?"
Некоторые говорят, что это плохо, некоторые - наоборот. Давайте подискутируем)
Мой круг знакомых делится на 2 лагеря - те, кто считает, что работать нужно в рамках одной компании и расти внутри нее, и на тех, кто хочет попробовать максимум всякого, получая кучу разного експириенса с разных мест работы. И у тех и у других есть вполне себе внятные доводы.
У первых это:
- стабильность
- отсутствие "распыления" на разные продукты/команды
- меньше стресса от смены привычного хода рабочего процесса
- глубокое погружение в проект
- бОльшая лояльность к тебе внутри компании
У вторых:
- бОльший опыт от разных реальных проектов
- возможность реализовать себя как разносторонний специалист
- разнообразие рабочего окружения
- отсутсвие "рутинности" работы и "замыленности" глаз
- большой круг знакомых и друзей из IT
Для полноты картины нужно иметь примерный список причин, почему люди уходят или остаются на текущем месте работы. Естественно, варианты а-ля "увольнение за то, что в пьяном угаре ты кому-то настучал в бубен" мы не рассматриваем)
Основные причины сменить работу:
-желание чего-то нового
-отсутсвие роста внутри компании
-отсутсвие интересных задач
-конфликты с сотрудниками
-деньги и плюшки
-желание работать в компании другого типа (уйти из стартапа в большую компанию и наоборот)
-желание релоцироваться
Основные причины не менять текущее место работы:
-знаешь проект, его нюансы
-пройденный испытательный срок
-команда, которую не первый день знаешь
-есть возможности расти внутри компании
-есть интересные фичи, над которыми работаешь
-крутой офис
-плюшки по истечении опр. времени
Естественно, есть много нюансов, которые так или иначе могут перечеркнуть что те, что другие доводы. Причины могут быть связаны с конкретной ситуацией, временем, состоянием здоровья, семейное положение, выгорание и прочее-прочее-прочее.
Как показала практика - я отношусь больше к людям, которые не могут усидеть на одном месте долгое время.
Я выделил три основных причины почему так происходило и происходит:
- нет возможности интересующего меня развития внутри компании
- постоянное желание новизны
- воля случая
Нет возможности роста
Тут есть две крайности - либо ты "впитал" все возможности, которые предлагает компания, либо тут не могут тебе предложить интересующую тебя деятельность. В том или ином случае решить данную траблу можно либо фоновым саморазвитием, либо искать это на стороне
Постоянное желание новизны
Я - холерик, и усидеть на одном месте мне физически сложно. Если нет интересных мне задач, нет новых рубежей и проф-челенджей на текущем месте - я пробую их найти. И нахожу, но в других компаниях.
Работа без интереса-не по мне, нужны горящие глаза.
Воля случая
Вот тут конечно бывало всякое. Например, однажды, когда работал в Малайзии, возникли проблемы с получением местной визы и, чтобы не оказаться в оранжевой робе, нужно было найти работу, но уже в другом месте (до пандемии мало кто рассматривал удаленку).
Иногда на собеседованиях спрашивали про мой послужной список и почему есть такие места, где я работал по пол года. Редко, но все же спрашивают.
В таких случаях главное - откровенно говорить что да почему, без швыряния какахами и перехода на личности. Это как минимум некрасиво)
По моему опыту HRы и собеседующие вполне адекватно воспринимали трудовые "перескоки" с место на место.
Конечно, после таких разговоров чувствовал себя разработчиком "легкого поведения", но это быстро проходило, так как каждая смена компании была подкреплена парой-тройкой причин.
Так получилось, что я не работал на одном месте больше 2-х лет. Самый продолжительный мой "забег" внутри одной компании - 1 год и 10 месяцев. Причем это было на стадии когда я только переехал в Мск из Хабарейро (aka Хабаровск) и только пробовал жизнь и работу в мегаполисе.
По поводу расставания с текущим местом работы
У меня, к счастью, нет таких мест работы, где люди были глупы, токсичны или недружелюбны. Поэтому каждый раз на прощальном вечере очень тяжело морально: это твои товарищи, друзья, семья так сказать. Тут главное - потом не потеряться)
Я до сих пор хорошо и тепло общаюсь с бывшими коллегами и не вижу никаких преград этого не делать. Вы же делали крутые штуки, вместе съели не один пуд соли, таким кол-вом ох#$нных историй обросли! Такие вещи просто так не проходят)
Также не нужно забывать, что уходить надо как минимум на позитивной ноте. Не то, чтобы редко, но видел, как сотрудник оставляет хз как сделанные таски без внятного состояния. Этого делать не стоит точно. Так ты подставляешь своих "бро", мнение которых мб будет играть роль потом.
Например, при собеседовании в "забугорные" компании достаточно часто требуется фитбек с двух-трех предыдущих мест работы кандидата. Не думаю, что будет хорошо, если твой "бывший" расскажет о тебе нелицеприятный отзыв, который решит склонить выбор работодателя не в твою пользу)
Немного про ребят, долго работающих на одном месте
Таких я знаю прилично. В основном это либо фанатики (в хорошем смысле этого слова) продукта, за который готовы на многое, либо ребята, которые потеряли энтузиазм и "остыли" к IT, либо не имеют возможности (ипотека например).
Есть конечно и такие, которые максимально поглощают плюшки и ресурсы компании: начиная от бесплатной еды на кухне, заканчивая корпоративными скидками, бонусами и поездками в командировки/на митапы. Такое я не особо понимаю, но оно есть и видимо кому-то так нормально)
ИМХО: работа - огромная часть твоей жизни, и растрачивать себя на то, что тебе не нравится - точно плохая идея.
Если на текущем месте работы ты себя как-то не так чувствуешь, или знаешь, что на другом месте тебе будет как минимум лучше или комфортнее - задумайся как минимум)
Естественно, смена работы - это риск прогадать (думал будет ВАХ ВАХ, а получилось НАХ НАХ), это выход из зоны комфорта, это притирание с новыми людьми, новая корпоративная этика, правила, уставы и прочее-прочее-прочее. К этому надо быть готовым и понимать это.
Как итог мыслей, тезисно:
-работать меньше года на одном месте - норм, если это обосновано
-нужно понимать, куда ты хочешь двигаться и с кем - возможно то ,что ты ищешь - в соседнем отделе
- не надо бояться выходить из зоны комфорта - если все делать с мозгами - все будет впрок)
Тред #5
Суббота
Почему свой YouTube - ни разу не просто
В данном треде я попробую рассказать о том, что нужно для видеоплатформы и почему это - достаточно непросто.
Русская вики пишет, что Ютуб- это видеохостинг.
Штош, интересное заявление, так как сейчас на Ютубе ты можешь смотреть за денюжки фильмы, смотреть и создавать видеотрансляции, использовать как музыкальный плеер и еще многое другое)
ИМХО: Ютуб - скорее медиаплатформа, чем хостинг.
С помощью чего Google зарабатывает на Ютуб? Вот некоторые виды монетизации:
- реклама (пре/пост-ролы)
- подписочная модель (покупаешь YouTube Premium и смотришь "ламповый" ютубчик без рекламы и с доп. плюшками)
- платные каналы (закрытые показы)
- аренда/продажа контента (OTT)
Что нужно для создания такой видеоплатформы? Как минимум следующее:
- приложения на желаемых платформах со своими плеерами
- свой протокол для стриминга
- хранилище
- сеть по доставке контента с максимальным покрытием (CDN)
- мощную систему транскордирования
- аудитория
Приложения YouTube
У Ютуба достаточно большое покрытие разных платформ и устройств, чем может похвастаться не каждый. Сами приложения работают достаточно хорошо и стабильно, не зависимо от "старости" устройства, что говорит об их разработке на более низком уровне.
Плеер для видеоплатформы- это её сердце. Тут есть большое количество всяких фич и наворотов. Расскажу про одну, пусть не уникальную, но интересно реализованную фичу в плеере, которая позволяет пользоваться перемоткой по таймлайну, не загружая весь контент, а только его миниатюры.
Если открыть Ютуб и подвести курсор на таймлайн (полоса перемотки), то на миниатюре юзер увидит маленькую миниатюру, которая будет картинкой. Очень очевидная и, кажется, простая фича. Но не все так как на первый взгляд)
На самом деле это - не отдельная картинка, а часть одной из матриц стоп-кадров, которые генерируются на бэкенде при кодировании. В зависимости от продолжительности контента, транскодер Ютуба вырезает кадры и мерджит их в матрицы 10х10 (LowQuality) и 5х5(HighQuality).
Шаг забора кадров - 2 сек (если длительность видео не превышает, кажется, мин 20) или 5 секунд (если видео больше 20 минут). Такие миниатюры намного проще доставить на клиента и дешевле показать, отобразив часть картинки-матрицы, чем качать весь видео-контент.
Кстати, на месте плеера, если зажать и двигать ползунок таймлайна, юзер видит как раз эти миниатюры, а не видео. После того, как пользователь отпускает ползунок - плеер начинает грузить сам контент для воспроизведения, т.е. по требованию.
Такая фича реализована в каждом приложении YouTube, которое попадало ко мне в руки - телефоны, телевизоры, игровые приставки и т.д.
Естественно, для всех этих платформ используются одни и те же матрицы с кадрами, для оптимизации доставки и корректном кешировании на CNDах.
Протокол для стриминга
Как я уже рассказывал, для поддержания огромного зоопарка разных плееров от сторонних вендоров нужно иметь большое количество по разному подготовленного контента. НО! Если у тебя есть свои плееры, которые ты можешь контролировать - делай свой протокол)
Ютуб (как и Нетфликс) подумали и решили, что это как минимум выгодно, когда на все платформы улетает +/- один и тот же тип контента и играется без сторонней black-box магии, накрученной каким-нить Samsung или Apple. Отсюда - больше контроля за плейбеком и QoS метриками.
Хранилище
Я не знаю такого слова, которое может быть использовано для примерной оценки количества данных, хранимых на серверах Google для YouTube) Это оооочень много! Одних записей видеоуроков от разработчиков с Индии там наверное в 100500 ПетаБайт)
Прикинуть, сколько занимает один видеоролик от, например, Жени "Бэда" Баженова можно следующим образом:
- посмотреть кол-во качеств
- посмотреть средние битрейты видео/аудио дорожек
- умножить битрейты на продолжительность
- сложить все вместе
Сейчас так и попробуем сделать)
Возьмем видеоролик про "Зою".
Тут мы видим 6 качеств видео (144p/240p/360p/480p/720p/1080p) и 3 качества аудио (50/65/120 kbit/sec). Каждое из видео качеств закодировано в 3 кодеках: H264/VP9/AV1. Аудио закодировано в OPUS кодеке. Все они работают через их DASH-образный стриминг.
Также Ютуб хранит 2 варианта (360p и 720p) мультиплексированных вариантов (в одном контейнере есть поток видео и аудио). Это для поддержки оооочень старых устройств.
Итак, подсчитав все вместе, получаем ~ 5,7Gb.
Вроде и не так много, но это только один видеоролик, а их больше)
Свой CDN
Распространить видео на аудиторию по всему миру - достаточно дорогое удовольствие, если пользовать CDN провайдера, тем более с хорошим покрытием. Какой нибудь CDN от Akamai будет хорошо перформить, но будет стоить как 2 чугунных моста, что, естественно, не выгодно.
Поэтому Google пользует свои сервера для более качественного обслуживания пользователей, которые можно контролировать, прогревать, тюнить и дополнять железом, если таковая потребность будет. И это будет на перспективу намного дешевле, чем аренда сторонних мощностей.
Система транскодирования
Как быстро перелопатить кучу видео, которое льют пользователи? Как говорилось ранее - транскодинг дорогая операция. Для понимания порядков скоростей: часовой ролик в FullHD с вменяемым выходным качеством откодируется за мин 20 на i7 с 12 ядрами в полку.
Для промышленных масштабов обычно применяют транскодеры с HW ускорением. Тот же часовой видеоролик на NVidia RTX2060 будет откодирован примерно за 6 мин, при том, что GPU будет работать в пол силы. Проанализировав контент Ютуба видно, что юзаются именно GPU.
Кстати, по непроверенным данным, для популярных каналов все же используют CPU транскодинг, так как он дает более качественную картинку. Для не особо популярных каналов Ютуб пользует скоростное GPU транскодирование на быстрых пресетах.
Аудитория
Естественно, для того чтобы это все как-то приносило денег - нужна внушительная масса пользователей. Не будет их - будет мало подписок, некому будет смотреть рекламу и т.д..
Кстати, понимание кол-ва пользователей и их требовательность может здорово вам сэкономить.
Например, аренда GPU типа Tesla T4 в облаке у Амазона/Гугла будет стоить приличных денег. В то время как CPU тачки бывают отдают с бешеной скидкой, которая может быть в конечном счете много выгоднее под конкретно ваши потребности.
В целом, видеоплатформа - это огромные вложения в мощности и человеко-ресурсы. Не скажу, что это рокет-сайенс, но особенностей и подводных камней тут прилично. Тем более если делать всё не на 3 с полом человека, а на приличные масштабы)
На сегодня у меня все. Всех с праздником!)
Тред #6
Воскресенье
Сегодня у меня особой темы нет, поэтому попробую ответить на некоторые вопросы ребят, которые вполне себе требуют освещения. Ну и, если хотите, спросите чего-нить! Думаю вопросы можно и не из IT мира. Попробую ответить)
Что вообще такое видео и как оно устроено
В этом треде попробую в 2-х словах накидать про видео-потоки, кодеки и покажу на примере пару особенностей.
Вообще видео, если очень упростить - это куча картинок, которые сменяют друг друга на экране в определенном порядке и с определенной скоростью.
Картинки должны быть одинакового размера и иметь таймстемп (так называемое, время воспроизведения на таймлайне).
Если взять какую-нить монтажку (например: Final Cut, Adobe Premiere) и глянуть на окно предпросмотра - мы увидим там набор из результирующих картинок, которые собирается из слоев, эффектов и доп. обвязок. Это так называемые RAW (сырые) кадры, которые рендерятся без сжатия.
Очевидно, если мы возьмем и сложим вместе кучу таких RAW-кадров или даже пожатых JPEGов и поставим их в хронолог. порядке - получится очень жирный файл, в интернете его будут качать до появления внуков. Поэтому лучшие умы человечества придумали такую штуку как CODEC.
CODEC - это железка или софт, который может сжимать/расжимать данные. Слово CODEC образовано от двух слов - coder/decoder.
Coder - штука, которая сжимает по своим алгоритмам данные, а Decoder соответсвенно - расжимает обратно (КО). В медиа кодеки - это сжатие с потерями.
Немного теории видеостроения. Если взять 5-сек. ролик и присмотреться, то весь видос можно снести к самому первому кадру и к тому, что из него "вытекает".
Например, на видео летит фризби. Первый кадр будет его начальное положение. А следующие - перемещение фризби по старому фону.
То есть, посмотрев и описав разность между кадрами, можно "выкинуть" лишние группы пикселей, а оставить только разницу между ними и описать где она происходит. Тем самым, второй и последующие кадры мы значительно уменьшаем в "весе" и финальное видео будет меньше JPEGового
Как идет разбиение видео
Видеопоток делится на группы пикселей, которые "перетаскиваются" по области рендера. В области, где картинка не меняется - макроблок заимствуется из предыдущего кадра. При движении же макроблок дробится на блоки/пиксели и "дорисовывается" поверх старого.
В видео есть 3 вида кадров:
- I-Frame - ключевой кадр, описанный полностью
- P-Frame - кадр, который опирается на предыдущий кадр
- B-Frame - кадр, который опирается на предыдущий и последующий кадры
Вот статейка про это: blog.video.ibm.com/streaming-vide…
Кол-во фреймов между одним и следующим ключевым (опорным) кадром называется GOP (en.wikipedia.org/wiki/Group_of_…). Он может быть константный или "плавающий". В зависимости от типа желаемого контента на выходе может быть применен один или другой тип и дать свои "плюшки".
Например, если вы показываете обычные MP4 по сети, то лучше использовать динамический GOP, так как енкодер будет сам определять когда нужно поставить ключевой кадр. Например, при смене плана (когда картинка меняется очень сильно) лучше поставить ключевой кадр для лучшего качества
В теории P и B кадры должны быть меньше I кадров, но это не всегда так. Например, при использовании константного GOPа смена планов скорее всего не попадет на ключевой фрейм. Тут, из-за большой разности в кадрах, кол-во битрейта на такой P/B фрейм понадобится большое.
Про битрейт и его количество
Чем больше битрейта вы "накините" на файл-тем качественнее и отчетливее он будет. Заигрываться с этим параметром не стоит, ибо:
- файл может получиться оч жирным
- в зависимости от картинки, есть "точка насыщения" контента, когда больше уже не надо
Предположим, вы сделали контент вашей мечты и откодили его. И вот дорожки бинарями лежат на вашем сервере и ждут своего часа. Как его посмотреть по сети? Нужно сделать его пригодным к проигрыванию через сеть. Самый распространенный способ - раздавать по HTTP.
Есть варианты:
- отдавать файл как специально подготовленным MP4
- отдавать через HTTP стриминг (HLS/DASH/MSS), предварительно "нарезав его кусками"
И тот и другой вариант имеет свои достоинства и недостатки.
Устройство MP4
Структура MP4 файла описывается т.н. "атомами". Вот основные из них:
- ftyp (тип файла и совместимость)
- mdat(payload, или сам контент)
- moov(атом со всей метадатой дорожек в MP4)
PS: Про то как читать MP4 неплохо расписал Максим Лапшин (levgem.livejournal.com/275096.html)
При транскодинге медиа в MP4 вначале записывается [ftyp] (без него никак), потом пишется медиа [mdat], откодированное при определенных настройках кодека, а уже в конце - записывается [moov] со всеми данными о файле - его длительности, составе медиапотоков и хар-ми на их декодинг.
Воспроизведение (декодирование) MP4 файла начинается со считывания именно [moov] атома, так как декодеры нужно настроить таким образом, чтобы payload был корректно воспроизведен плеером. И если он в самом конце файла - нужно будет скачать файл целиком, после чего его можно играть
Для того, чтобы иметь возможность играть файл сразу - меняют структуру MP4 файла, а именно: ставят [moov] атом в начало файла.
Например, было:
[ftyp][mdat][moov]
Стало:
[ftyp][moov][mdat]
Таким образом, по получении первых нескольких килобайт информации можно играть контент.
Http стриминг в целом работает по примерно такой же схеме, за исключением того, что файл дробится на части (чанки) и отдается либо отдельными файлами, либо байт-ренджами. Все адреса-явки-пароли находятся в манифесте (файле, который описывает вариации потоков, их адреса и св-ва)
Классический стриминг работает так:
-плеер получает манифест на контент
-в плеер тянутся init-чанки с выбранными дорожками (в них есть тот самый [moov]-атом)
-получив init-чанк, плеер инициализируется и готов к плейбеку
-получив чанки с контентом, плеер их воспроизводит
-профит)
Как мы видим/слышим закодированный контент
В плеерах есть декодеры, которые на основании информации в [moov] атомах интерпретируют закодированный payload медиа-контента. В зависимости от алгоритмов codec-ов, на это может уходить достаточно большое количество ресурсов устройства.
Хороший пример - Ютуб. Основной видео-кодек Ютуба VP8. На некоторых устройствах идет софтварное декодирование потока, что сильно бьет по производительности устройства в целом. Взамен этому - видео в VP8 много легче H264 при +/- одинаковом качестве итоговой картинки.
Ну вот, как-то так. На всякий приложу пару статей интересных про это вот все:
bitmovin.com/adaptive-strea…
elcomienzo.ru/h265-vs-h264-s…
macxdvd.com/mac-video-conv…
Тред #7
Напоследок расскажу что такое HighFPS видео и о его проблемах применения в жизни.
HighFPS видео - это видео с непривычно большим количеством кадров в секунду (60, 120 и т.д.). Самый распространенный контент в 60 fps - это конечно же стриминг игр (Твичи, Ютубы и прочее).
Для начала проясню один нюанс - есть категория людей, которые не воспринимают разницу между низким и высоким fps. Почему так? По некоторым данным - это "натренерованность" глаз и скорости реакции. Например, заядлые геймеры с легкостью увидят разницу в 60 fps или даже больше.
Как оно работает.
В целом, нет разницы от обычного видео в 24 кадра в секунду, количество кадров (графической информации) на единицу времени становится больше. Отсюда контент должен быть "жирнее", чтобы не прискакали те самые "еб№%ие шакалы".
Для человека контент в 60 FPS отличается от обычного (в 30) по ощущениям в основном по двум параметрам:
- движения объектов на видео более плавные и четкие
- нет ощущения "киношности" (к этому еще вернемся)
Для плеера же это повод "напрячься" посильнее и взять в заложники побольше мощей от устройства на декодирование такого обилия пикселей. Вы когда-нить смотрели видео в 60 FPS в 4К в Хроме на старом ноутбуке? Я в основном помню только фризы и гудение куллеров)
В основном, контент такого рода добавляет динамики на экран, поэтому любители постримить PUBG или "КаЭс" на Твичах взахлеб стали так и делать. Также, очень много видеоблогеров подхватили эту возможность и стали пользовать ее. Хороший пример: Птушкин с проходами на квадрокоптерах.
Кино тоже это дело не миновало. Небезызвестный фильм "Хоббит" есть в 48 fps, или "Гемини" с Уиллом Смиттом в 60 fps. Как задумывалось - это даст новых ощущений и красок в местах с экшоном, взрывами и погонями, чтобы зритель как на иголках сидел...
Результат - народу "не зашло")
Про "киношность".
Есть такая штука, как "магия кино". И отчасти, FPS на уровне 24-25 кадров сохраняет ту самую "ламповость" кино-шедевров. Поэтому очень много артистов кино выступали с призывом отключать функции улучшайзеров на SmartTV, так как эти алгоритмы коверкают кино.
Работают улучшайзеры по следующим алгоритмам:
- на вход поступает видеопоток, скажем, в 25 FPS
- на собственных процессорах, телевизоры интерполируют два соседних кадра, получая некий гибрид посередине
- его дорисовывает рендер и создается впечатление HighFPS видео
Эти алгоритмы, естественно, вносят свои коррективы в картинку, иногда добавляя отвратительные артефакты и "барашки" на видео. Попробуйте присмотреться на видео, где волосы девушки развиваются на ветру, но с включенным улучшайзером. Уверен - мало кому понравится)
В общем, я, как огромный любитель кино и фанат быстрых игр, а-ля DOOM Eternal, советую пользовать данную вещь с умом. Для игр с диким экшоном - HighFPS добавляет жару, но при просмотре кино это - определенно излишне.
PS. Про "прон" в 60 FPS я вообще молчу, укачивать начинает)
Тред #8
Всем спасибо за то, что читали, комментили, лайкали и фитбечили!
Первый раз в жизни в твиттере что-то вещал - експириенс интересный.Надеюсь было иногда как минимум интересно)
Всем поки! Все крутые!
Ваш Ваня-Иван с Хабарейро)
