Comments 39
Вчера в комментариях просили рассказать о реальных use-case использования Tarantool.
Вот и один из реальных примеров, правда еще на предыдущей версии Тарантула. Сервис в проде (cloud.mail.ru).
Вот и один из реальных примеров, правда еще на предыдущей версии Тарантула. Сервис в проде (cloud.mail.ru).
Ряд сервисов (например, YouTube, социальные сети и прочие) конвертирует пользовательское видео в пригодные для воспроизведения форматы сразу после загрузки. Только после окончания конвертации ролик становится доступным для просмотра, но оригинал при этом удаляется.
Выделенное неверно. Оригинал доступен для скачивания через google.com/takeout
Понятно, что у облачного файлового хранилища отношение watch qps / corpus size гораздо меньше, чем у специализированного видео-хостинга, но неужели CPU настолько дешевле хранилища, что вы даже уже перекодированные куски видео удаляете?
Мы удаляем лишь те кусочки, к которым не было обращений некоторое время. Если какой-то кусочек не запрашивали скажем сутки, то весьма вероятно, что в следующий раз за ним придут не скоро, или вообще никогда не придут.
Сейчас у нас довольно большой запас по CPU + время конвертации весьма мало, поэтому такая стратегия показывает себя хорошо.
Сейчас у нас довольно большой запас по CPU + время конвертации весьма мало, поэтому такая стратегия показывает себя хорошо.
А у вас перемотка идет не на ключевой кадр, и от этого вся картинка идет зеленым при перемотке.
У нас ключевые кадры сбрасываются строго раз в секунду, и перемотка должна работать тоже с точностью до секунды, известных багов про это мы пока не знаем.
Пожалуйста, напишите мне в личку или на m.andreev@corp.mail.ru подробности: ОC, браузер/версия приложения, email, по возможности — ссылка на файл, с которым наблюдались проблемы.
Пожалуйста, напишите мне в личку или на m.andreev@corp.mail.ru подробности: ОC, браузер/версия приложения, email, по возможности — ссылка на файл, с которым наблюдались проблемы.
Вообще вы бы там лучше биткойны майнили, а не занимались одинаковыми бессмысленными вычислениями каждый день :)
Было б неплохо, если бы вы webdav реализовали
Сделайте лучше статью «Криворукие во всем: как мы повесили две вывески друг перед другом»
так это ж отказоустойчивость
это когда сказать нечего, а «обосрать» хочется?
Отличная техническая статья, а вы вывеску явно не эти люди вешали и даже рядом не стояли (максимум мимо проходили когда ее рабочие вешали, причем скорее всего уткнувшись в телефон).
В обще Mail.ru много всего хорошего про технические аспекты рассказывает и выкладывает, за что им спасибо.
Отличная техническая статья, а вы вывеску явно не эти люди вешали и даже рядом не стояли (максимум мимо проходили когда ее рабочие вешали, причем скорее всего уткнувшись в телефон).
В обще Mail.ru много всего хорошего про технические аспекты рассказывает и выкладывает, за что им спасибо.
Уж не знаю, что хорошего в статьях мэйл.ру, но все их конечные продукты выглядят примерно также, как и эта вывеска.
А мне нравится. Раньше не нравилось, но с тех пор прошло много времени и они изменились.
ну так вы почитайте статьи, они интересные, даже если конкретно этим не занимаешься.
а еще они проводят встречи, за все не знаю, но я был на Встреча по web-разработке. Отличное выступление разработчиков, рассказывали что использовали, как решали проблемы взаимодействия команд и управления кодом — без пафоса и гонора, рассказывали боль и проблемы с которыми сталкивались, какие шишки набивали.
Мы же тут не продукты обсуждаем, а вполне конкретное техническое решение.
Если Вы хотите рассказать какие плохие продукты они делают — напишите статью.
а еще они проводят встречи, за все не знаю, но я был на Встреча по web-разработке. Отличное выступление разработчиков, рассказывали что использовали, как решали проблемы взаимодействия команд и управления кодом — без пафоса и гонора, рассказывали боль и проблемы с которыми сталкивались, какие шишки набивали.
Мы же тут не продукты обсуждаем, а вполне конкретное техническое решение.
Если Вы хотите рассказать какие плохие продукты они делают — напишите статью.
Коллеги, а сколько корова дает молока видео трафика исходящего?
Эх, в лохматом 2008-м, помню, похожее чудо примерно так уже и работало :))) www.kip.ru/realtime/2008/11/smooth-streaming.html Потом так много где стало. Молодцы — хорошо сделали. Работает здорово!
Конвертация просто на CPU идет? Рассматривались ли какие-то специализированные аппаратные варианты?
А что прозойдет, если я загружу какое-нибудь видео, а потом запощу его куда-нибудь в твиттер, где 100к подписчиков и примерно 1000 из них кинется смотреть этот файл одновременно?
Ничего страшного :)
У каждого кусочка есть поминутный счетчик запросов к нему за последние 5 минут, и на основе этих данных принимается решение о популярности кусочка (сейчас критерий это «за последнюю минуту больше N запросов») и в случае если он становится популярным, то происходит его распространение на другие сервера.
Т.е. непопулярные кусочки отдаются только с одного сервера, и если запрос приходит на другой фронт, то он просто переадресуется, а для популярных кусочков любой фронт может отдать его из своего локального кэша.
У каждого кусочка есть поминутный счетчик запросов к нему за последние 5 минут, и на основе этих данных принимается решение о популярности кусочка (сейчас критерий это «за последнюю минуту больше N запросов») и в случае если он становится популярным, то происходит его распространение на другие сервера.
Т.е. непопулярные кусочки отдаются только с одного сервера, и если запрос приходит на другой фронт, то он просто переадресуется, а для популярных кусочков любой фронт может отдать его из своего локального кэша.
А можно Ваш патч к ffmpeg где-то посмотреть?
Вот чес-слово, лучше бы вы облаку дали быть хранилищем, а не видеохостингом — а для этого немалые силы не тратили бы на видео, а допатчили вашу реализацию webdav и выполнили бы свое обещание, дававшееся неоднократно и здесь, и в личных ответах ТП, что webdav скоро-скоро будет-будет.
Не в обиду, и, конечно, обещанного три года ждут, но и облако работает с декабря 2013 (в то время, плюс-минус, WebDav, кстати, работал), так что как раз третий год начинается — как думаете, дождемся ли?
P.S. Догадываюсь, что dav могут открыть только для юзеров платных аккаунтов. Но тут свои грабли: доверие к mail.ru. Не у всех оно есть, как раз из-за таких вот обещаний (а также всяких лимитов http://habrahabr.ru/post/272661/ в безлимитных ящиках).
Не в обиду, и, конечно, обещанного три года ждут, но и облако работает с декабря 2013 (в то время, плюс-минус, WebDav, кстати, работал), так что как раз третий год начинается — как думаете, дождемся ли?
P.S. Догадываюсь, что dav могут открыть только для юзеров платных аккаунтов. Но тут свои грабли: доверие к mail.ru. Не у всех оно есть, как раз из-за таких вот обещаний (а также всяких лимитов http://habrahabr.ru/post/272661/ в безлимитных ящиках).
А им-то самим webdav — зачем?
Ну с той же пользой, что и проигрывание видео )
Я понимаю, что облако позиционируют как хранилку для всей цифровой жизни, а заодно и для работы, и под это пилят просмотр. Но, серьезно, кто-то из нас верит, что оно проживет 100 лет? А 50? А 10? А на год-два копировать туда-сюда — стоит ли оно того? Причем еще не берем во внимание шанс не найти свои файлы, а потом получить ответ от ТП со ссылкой на TOS, а иногда и припиской «попробуйте сейчас».
Это я к тому, что любые фичи кто-то делает, и кто-то заказывает. Мне лично внешний жесткий диск с TLS был бы нужнее, чем чистое «облако» (я тогда сам буду понимать, как и куда синкается; верить же в алгоритмы облачного загружателя я побаиваюсь). Видео же я лучше локально скачаю и потом посмотрю: у меня просто нет супербольших файлов, а небольшие даже на SSD всегда поместятся.
Я понимаю, что облако позиционируют как хранилку для всей цифровой жизни, а заодно и для работы, и под это пилят просмотр. Но, серьезно, кто-то из нас верит, что оно проживет 100 лет? А 50? А 10? А на год-два копировать туда-сюда — стоит ли оно того? Причем еще не берем во внимание шанс не найти свои файлы, а потом получить ответ от ТП со ссылкой на TOS, а иногда и припиской «попробуйте сейчас».
Это я к тому, что любые фичи кто-то делает, и кто-то заказывает. Мне лично внешний жесткий диск с TLS был бы нужнее, чем чистое «облако» (я тогда сам буду понимать, как и куда синкается; верить же в алгоритмы облачного загружателя я побаиваюсь). Видео же я лучше локально скачаю и потом посмотрю: у меня просто нет супербольших файлов, а небольшие даже на SSD всегда поместятся.
Я думаю, они там не рассчитывали на продвинутых гиков, которые принесут к ним свои бэкапы. Поэтому и не делают webdav. Они думали, что у ним придут тихие-спокойные end-user'ы, которые не будут заливать терабайты данных и требовать webdav'ов и прочих красот, тихо перенесут свою почту, будут тихо смотреть рекламу и приносить копеечку, Гики с запросами на webdav, думаю, там не очень нужны. Отсюда и отсутствие какой-либо инициативы в этой области (как подтверждение моей гипотезы). Нужно ли нести к ним свои данные гикам при такой их мотивации? Не знаю. Вряд ли. Есть много других мест, более технологичных. Зачем страдать-то? :)))
Вы наверняка правы. Только вот возьмем облако: хорошо, когда у меня есть пяток устройств с безлимитной памятью, в которые я мечтаю заливать то же, что на них всех лежит. Сферическая синхронизация, да, в вакууме.
В жизни все проще и грустнее. На телефоне памяти/флешки свободно N Мб, на компе — M Мб, на еще одном компе — S Мб. Какие бы эти числа не были, я хочу держать на каждом устройстве только нужные на нем данные. Скажем, на телефоне только в дальнейшем нужные фото, на компе одном — все-все, а на третьем, где SSD, тоже, только нужные, но немного другие, чем на телефоне. В синхронизаторе cloud.mail.ru есть выбор, какие папки синхронизировать, но, если папку сначала добавить в список синхронизации (чтобы она в облако улетела), то потом, при исключении из списка синхронизируемых (чтобы не заниматься синхронизацией ее в дальнейшем) папка/файлы удаляется на локальной машине. И, наоборот, при удалении файла локально, он удалится в облаке. И, обращаю внимание, точность указания — до папки, так что нельзя по одному файлу отправлять в облако, а затем удалять только локально (что было бы для фото полезно).
Т.е. вариант «наснимать снимков на телефоне, загрузил их на комп1, а часть на комп2, а потом на телефоне постирал ненужные» — такое не прокатит. Фактически, есть два рабочих подхода: загружать через веб-морду (но цель-то была сделать seamless работу, нет?), либо создать папку в папочке, из которой беред данные cloud-синхронизатор, положить (скопировать!) в нее контент, дождаться окончания синхронизации, убрать папку из списка синхронизируемых (она локально удалится, в облаке же данные останутся). И то, и то требует сил, и то, и то потенциально ведет к потере данные при неверном движении. Браузером, однако, пользоваться понятнее и проще, потому что там работаешь просто с файлами, а во втором варианте надо еще думать, что из-за чего произойдет, и что можно потенциально потерять.
И это, заметьте, я описываю работу с данными в режиме как раз цифрового дневника — т.е. как раз в сценарии, когда и просмотр видео в браузере актуален, и вроде как в котором синхронизация пригодится.
Просто синхронизация — отличная вещь, но надо понимать, что если в телефоне 16 Гб флешки, а в компе — 1Тб, то юзер должен долго попрыгать, чтобы синхронизация работала. Сделает ли это не гик? Может быть, но не факт.
В жизни все проще и грустнее. На телефоне памяти/флешки свободно N Мб, на компе — M Мб, на еще одном компе — S Мб. Какие бы эти числа не были, я хочу держать на каждом устройстве только нужные на нем данные. Скажем, на телефоне только в дальнейшем нужные фото, на компе одном — все-все, а на третьем, где SSD, тоже, только нужные, но немного другие, чем на телефоне. В синхронизаторе cloud.mail.ru есть выбор, какие папки синхронизировать, но, если папку сначала добавить в список синхронизации (чтобы она в облако улетела), то потом, при исключении из списка синхронизируемых (чтобы не заниматься синхронизацией ее в дальнейшем) папка/файлы удаляется на локальной машине. И, наоборот, при удалении файла локально, он удалится в облаке. И, обращаю внимание, точность указания — до папки, так что нельзя по одному файлу отправлять в облако, а затем удалять только локально (что было бы для фото полезно).
Т.е. вариант «наснимать снимков на телефоне, загрузил их на комп1, а часть на комп2, а потом на телефоне постирал ненужные» — такое не прокатит. Фактически, есть два рабочих подхода: загружать через веб-морду (но цель-то была сделать seamless работу, нет?), либо создать папку в папочке, из которой беред данные cloud-синхронизатор, положить (скопировать!) в нее контент, дождаться окончания синхронизации, убрать папку из списка синхронизируемых (она локально удалится, в облаке же данные останутся). И то, и то требует сил, и то, и то потенциально ведет к потере данные при неверном движении. Браузером, однако, пользоваться понятнее и проще, потому что там работаешь просто с файлами, а во втором варианте надо еще думать, что из-за чего произойдет, и что можно потенциально потерять.
И это, заметьте, я описываю работу с данными в режиме как раз цифрового дневника — т.е. как раз в сценарии, когда и просмотр видео в браузере актуален, и вроде как в котором синхронизация пригодится.
Просто синхронизация — отличная вещь, но надо понимать, что если в телефоне 16 Гб флешки, а в компе — 1Тб, то юзер должен долго попрыгать, чтобы синхронизация работала. Сделает ли это не гик? Может быть, но не факт.
если попросить его сконвертировать тот же файл сначала с 0 по 10 секунду, а потом (отдельным запуском FFmpeg) с 10 по 20 секунду, и сделать правильный плейлист, то при переходе с одного файла на другой (примерно на 10-й секунде) мы услышим заметный звуковой щелчок. Мы потратили не один день на перебор различных параметров запуска FFmpeg, но ни к какому результату не пришли. Пришлось влезть внутрь и написать небольшой патч, который при передаче определенного параметра командной строки исправляет этот недочет, возникающий из-за особенностей кодирования аудио- и видеодорожек.Как в итоге поправили, просто начинаете кодировать аудио чуть раньше и обрезаете его до нужного фрейма, или как-то умнее? Я тоже натыкался на эту проблему, но из-за того, что мне аудиодорожку нужно кодировать целиком, а не по кускам, и кодируется она на порядки быстрее видео, решил, что мне достаточно кодировать аудио отдельно.
Немного не понятен момент:
Если конвертация на тех же машинах, где хранятся файлы, то зачем HTTP-ссылки? Или изоляция подразумевает, что доступ вовне есть только по HTTP, и как раз так исходники и попадают внутрь? (Вариант, что конвертит не тот сервер, который хранит файл, тоже, в принципе, возможен...)
И, выходит, что патчик для «медленного mov» нужен как раз для работы с этими HTTP-ссылками: были б файлы локальными, было бы проще.
конвертеры, готовые получить на вход HTTP-ссылку на файл
…
(конвертация) работает на наших стораджах в специальной изолированной среде
Если конвертация на тех же машинах, где хранятся файлы, то зачем HTTP-ссылки? Или изоляция подразумевает, что доступ вовне есть только по HTTP, и как раз так исходники и попадают внутрь? (Вариант, что конвертит не тот сервер, который хранит файл, тоже, в принципе, возможен...)
И, выходит, что патчик для «медленного mov» нужен как раз для работы с этими HTTP-ссылками: были б файлы локальными, было бы проще.
конвертит не тот сервер, который хранит файл
в первую очередь из-за этого, точнее конвертит не обязательно сервер с файлом (но может так случиться, что это будет и он).
Мы решили сделать такой вариант, т.к. он более универсален и позволяет ставить конвертеры где угодно, где есть CPU (а не исходный файл) — в нашем случае это стораджа.
Это так же позволило не наступить на возможную проблему, когда несколько популярных тяжелых для конвертирования файлов оказались на одном сторадже и их смотрят прямо сейчас.
так исходники и попадают внутрь
и это тоже верно, прямого доступа у изолированного окружения к файлам нету
В системе видеонаблюдения с тысячами камер делали конвертацию на лету без кэширования, т.к. вероятность того, что два оператора будут смотреть одинаковый фрагмент стремится к нулю. При этом тем клиентам, которые способны декодировать оригинальное видео, пересылали именно его, чтобы не занимать ресурсы на конвертацию. От стриминговых решений от Microsoft и Apple отказались, т.к. был необходим мгновенный отклик — видео на клиенте должно идти максимум через 200 мс.
В вашем случае непонятно зачем пережимать в сценариях «снял на телефоне, кинул в облако и удалил». Очевидно, что телефон имеет необходимые декодеры для своего же видео. Могли бы пояснить этот момент?
А еще любопытно узнать как часто случается, что более одного пользователя смотрят один и тот же ролик или даже фрагмент? Кажется, что в большинстве сценариев люди сами смотрят свои же ролики.
В вашем случае непонятно зачем пережимать в сценариях «снял на телефоне, кинул в облако и удалил». Очевидно, что телефон имеет необходимые декодеры для своего же видео. Могли бы пояснить этот момент?
А еще любопытно узнать как часто случается, что более одного пользователя смотрят один и тот же ролик или даже фрагмент? Кажется, что в большинстве сценариев люди сами смотрят свои же ролики.
Очевидно, что телефон имеет необходимые декодеры для своего же видео.
Для своего же видео — да, имеет. Но даже в этом случае возможна ситуация, что сняли тяжелое (по объему) 1080p видео и хотим посмотреть его из облака при подключении к 3G — в нашем случае проблем с этим не будет, видео просто будет отдаваться в 360p или даже 240p — и пользователь все же будет иметь возможность посмотреть его без больших задержек.
Если же сняли на один телефон или на видео-камеру, а хотим посмотреть на другом телефоне, то в довольно существенном проценте случаев без конвертации не обойтись.
как часто случается, что более одного пользователя смотрят один и тот же ролик или даже фрагмент
Запросов, на которые у нас уже есть готовый кусочек (не важно — этим же пользователем созданный или кем-то еще, ведь у нас дедубликация по хэшам файлов) у нас около 30%
Интересно, сколько времени заняла разработка такого функционала и сколько разработчиков было задействовано?
Если не можете ответить, то всё равно спасибо за интересную статью.
Если не можете ответить, то всё равно спасибо за интересную статью.
Sign up to leave a comment.
Важнейшее из искусств: как мы реализовали проигрывание видео в Облаке Mail.Ru