До публикации этой статьи я считал, что проблемы в ffmpeg нету и фиксить в нем нечего, но whisk в обсуждении поста написал
Да, пожалуй, concat работает верно — неверно работает HLS demuxer (URL, начинающийся с concat, явно не соотвествует спекам HLS)
и я с ним согласен
Постараюсь на выходных (а может и раньше) сделать патч / хотя бы отписать разработчикам ffmpeg с указанием хорошего, по моему мнению, решения для фикса.
Первая строчка?
Для всего файла нужно поступить чуть хитрее, полного описания этого способа я в статье не выложил, но сам проверял — все работает. Если интересно — смотреть нужно на протокол subfile
Я сталкивался с таким, это из-за того, что в header.m3u8 в самом конце после «example.org?» есть \r и/или \n который вставил редактор, нужно их обязательно удалить, чтобы последний байт был "?".
Проверить можно через $ hexdump -C header.m3u8 — это 0x0a / 0x0d
В ffmpeg 2.8.x пару месяцев назад все воспроизводилось.
Вот что я могу посоветовать:
— запускать ffmpeg в изолированном окружении — всегда хорошо и может помочь и при нахождении уязвимостей в самом ffmpeg
— ffmpeg внутри этого окружения из под отдельного пользователя с доступом на запись/чтение только туда, куда нужно.
— отключить (--disable-network в configure) или ограничить (в iptables можно делать правила по uid'у пользователя) доступ к сети ffmpeg'у, если полное отключение невозможно
в случае описанной аттаки даже любое одно из этих простых правил усложнило бы эксплуатацию уязвимости, а вместе они бы позволили защититься от нее.
Небольшое обсуждение по теме было в комментариях к другому посту, там я объяснял, почему мне не нравится идея с построением белого/черного списка форматов/кодеков.
Очевидно, что телефон имеет необходимые декодеры для своего же видео.
Для своего же видео — да, имеет. Но даже в этом случае возможна ситуация, что сняли тяжелое (по объему) 1080p видео и хотим посмотреть его из облака при подключении к 3G — в нашем случае проблем с этим не будет, видео просто будет отдаваться в 360p или даже 240p — и пользователь все же будет иметь возможность посмотреть его без больших задержек.
Если же сняли на один телефон или на видео-камеру, а хотим посмотреть на другом телефоне, то в довольно существенном проценте случаев без конвертации не обойтись.
как часто случается, что более одного пользователя смотрят один и тот же ролик или даже фрагмент
Запросов, на которые у нас уже есть готовый кусочек (не важно — этим же пользователем созданный или кем-то еще, ведь у нас дедубликация по хэшам файлов) у нас около 30%
в первую очередь из-за этого, точнее конвертит не обязательно сервер с файлом (но может так случиться, что это будет и он).
Мы решили сделать такой вариант, т.к. он более универсален и позволяет ставить конвертеры где угодно, где есть CPU (а не исходный файл) — в нашем случае это стораджа.
Это так же позволило не наступить на возможную проблему, когда несколько популярных тяжелых для конвертирования файлов оказались на одном сторадже и их смотрят прямо сейчас.
так исходники и попадают внутрь
и это тоже верно, прямого доступа у изолированного окружения к файлам нету
У нас ключевые кадры сбрасываются строго раз в секунду, и перемотка должна работать тоже с точностью до секунды, известных багов про это мы пока не знаем.
Пожалуйста, напишите мне в личку или на m.andreev@corp.mail.ru подробности: ОC, браузер/версия приложения, email, по возможности — ссылка на файл, с которым наблюдались проблемы.
Да, только на CPU, и нас пока это устраивает.
Немного смотрели в сторону использования GPU, но для этого пришлось бы ставить отдельные сервера для конвертации, т.к. на доступных стораджах (которые уже есть, их много и на которых есть свободное процессорное время) нет подходящих для этого GPU.
Ничего страшного :)
У каждого кусочка есть поминутный счетчик запросов к нему за последние 5 минут, и на основе этих данных принимается решение о популярности кусочка (сейчас критерий это «за последнюю минуту больше N запросов») и в случае если он становится популярным, то происходит его распространение на другие сервера.
Т.е. непопулярные кусочки отдаются только с одного сервера, и если запрос приходит на другой фронт, то он просто переадресуется, а для популярных кусочков любой фронт может отдать его из своего локального кэша.
Мы удаляем лишь те кусочки, к которым не было обращений некоторое время. Если какой-то кусочек не запрашивали скажем сутки, то весьма вероятно, что в следующий раз за ним придут не скоро, или вообще никогда не придут.
Сейчас у нас довольно большой запас по CPU + время конвертации весьма мало, поэтому такая стратегия показывает себя хорошо.
делать черный список форматов, которые не конвертировать — плохая идея, можно что-то не учесть, аналогично и с белым списком — не учтешь особенностей каждого из нескольких сотен вариантов, может где-то есть неявная возможность обращения к сети например.
проще обрабатывать ошибки
Важно просто знать, успешной была конвертация или нет + была ли она прервана по таймауту или раньше.
Как может помочь выполнить конвертацию знание, что например файл начиная с 2млн байта полностью битый — я не понял.
просто как-то неправильно
Извините, но я пока не увидел ни одного довода, который смог бы меня убедить в утверждении «запускать бинарник ffmpeg для решения конкретной данной задачи — не правильно, а вот написать свой бинарник используя те же библиотеки и запускать его — лучше».
Для меня пока это выглядит как «не использовать goto в C, потому что это не правильно — ведь все же так говорят».
Зачем, какие будут плюсы именно в задаче конвертирования видео?
Про некоторые минусы я уже говорил выше — время на написание/тестирование/поддержку, хотя по сути это будет копипаст бОльшей части ffmpeg.c. Затраты на fork()+exec() пренебрежимо малы со временем работы процесса конвертации.
Несколько плюсов модели «запуск отдельного процесса на каждую конвертацию»:
— конвертация не может повлиять на враппер — демон, который принимает решение о необходимости запуска процесса конвертации конкретного файла с конкретными параметрами
— возможность запуска из под отдельного пользователя, с более урезанными чем «демон-враппер» правами
— удобное управление лимитами — память, максимальное время работы (считаем, что в библиотеках могут быть баги)
Если согласиться с тем, что для конвертации все же лучше запускать отдельный процесс — то так ли важно, будет ли это ffmpeg или самописнная утилита на основе тех же самых библиотек?
И да, интерфейс у библиотек не сильно высокоуровневый, т.е. там нет функции convert(const char *infile, const char *outfile, struct convert_params *params), а возможности, которые они за счет этого предоставляют (помимо тех, что есть в утилите ffmpeg) в задаче конвертирования не нужны.
И по теме выступления — использование библиотек FFmpeg вместо утилиты ведь не должно спасти от такой аттаки, или есть мнение что должно?
как раз наоборот — требуется довольно много настроек кодека + цепочка фильтров в нужном порядке со своими настройками + другие различные опции, и все это очень легко задается опциями утилиты ffmpeg.
Конечно, и для моего примера использовать system() это не хорошо и не стоит так делать в большинстве случаев, но думаю мысль понятна.
Кстати, мне встречались биндинги для некоторых языков именно к утилите ffmpeg — т.е. идея запускать бинарник ffmpeg вместо использования библиотек именно в случае FFmpeg довольно распространена.
и я с ним согласен
Постараюсь на выходных (а может и раньше) сделать патч / хотя бы отписать разработчикам ffmpeg с указанием хорошего, по моему мнению, решения для фикса.
Для всего файла нужно поступить чуть хитрее, полного описания этого способа я в статье не выложил, но сам проверял — все работает. Если интересно — смотреть нужно на протокол subfile
Проверить можно через $ hexdump -C header.m3u8 — это 0x0a / 0x0d
В ffmpeg 2.8.x пару месяцев назад все воспроизводилось.
— запускать ffmpeg в изолированном окружении — всегда хорошо и может помочь и при нахождении уязвимостей в самом ffmpeg
— ffmpeg внутри этого окружения из под отдельного пользователя с доступом на запись/чтение только туда, куда нужно.
— отключить (--disable-network в configure) или ограничить (в iptables можно делать правила по uid'у пользователя) доступ к сети ffmpeg'у, если полное отключение невозможно
в случае описанной аттаки даже любое одно из этих простых правил усложнило бы эксплуатацию уязвимости, а вместе они бы позволили защититься от нее.
Небольшое обсуждение по теме было в комментариях к другому посту, там я объяснял, почему мне не нравится идея с построением белого/черного списка форматов/кодеков.
Для своего же видео — да, имеет. Но даже в этом случае возможна ситуация, что сняли тяжелое (по объему) 1080p видео и хотим посмотреть его из облака при подключении к 3G — в нашем случае проблем с этим не будет, видео просто будет отдаваться в 360p или даже 240p — и пользователь все же будет иметь возможность посмотреть его без больших задержек.
Если же сняли на один телефон или на видео-камеру, а хотим посмотреть на другом телефоне, то в довольно существенном проценте случаев без конвертации не обойтись.
Запросов, на которые у нас уже есть готовый кусочек (не важно — этим же пользователем созданный или кем-то еще, ведь у нас дедубликация по хэшам файлов) у нас около 30%
в первую очередь из-за этого, точнее конвертит не обязательно сервер с файлом (но может так случиться, что это будет и он).
Мы решили сделать такой вариант, т.к. он более универсален и позволяет ставить конвертеры где угодно, где есть CPU (а не исходный файл) — в нашем случае это стораджа.
Это так же позволило не наступить на возможную проблему, когда несколько популярных тяжелых для конвертирования файлов оказались на одном сторадже и их смотрят прямо сейчас.
и это тоже верно, прямого доступа у изолированного окружения к файлам нету
Пожалуйста, напишите мне в личку или на m.andreev@corp.mail.ru подробности: ОC, браузер/версия приложения, email, по возможности — ссылка на файл, с которым наблюдались проблемы.
Немного смотрели в сторону использования GPU, но для этого пришлось бы ставить отдельные сервера для конвертации, т.к. на доступных стораджах (которые уже есть, их много и на которых есть свободное процессорное время) нет подходящих для этого GPU.
У каждого кусочка есть поминутный счетчик запросов к нему за последние 5 минут, и на основе этих данных принимается решение о популярности кусочка (сейчас критерий это «за последнюю минуту больше N запросов») и в случае если он становится популярным, то происходит его распространение на другие сервера.
Т.е. непопулярные кусочки отдаются только с одного сервера, и если запрос приходит на другой фронт, то он просто переадресуется, а для популярных кусочков любой фронт может отдать его из своего локального кэша.
Сейчас у нас довольно большой запас по CPU + время конвертации весьма мало, поэтому такая стратегия показывает себя хорошо.
см. мой комментарий выше:
Важно просто знать, успешной была конвертация или нет + была ли она прервана по таймауту или раньше.
Как может помочь выполнить конвертацию знание, что например файл начиная с 2млн байта полностью битый — я не понял.
Извините, но я пока не увидел ни одного довода, который смог бы меня убедить в утверждении «запускать бинарник ffmpeg для решения конкретной данной задачи — не правильно, а вот написать свой бинарник используя те же библиотеки и запускать его — лучше».
Для меня пока это выглядит как «не использовать goto в C, потому что это не правильно — ведь все же так говорят».
Про некоторые минусы я уже говорил выше — время на написание/тестирование/поддержку, хотя по сути это будет копипаст бОльшей части ffmpeg.c. Затраты на fork()+exec() пренебрежимо малы со временем работы процесса конвертации.
Несколько плюсов модели «запуск отдельного процесса на каждую конвертацию»:
— конвертация не может повлиять на враппер — демон, который принимает решение о необходимости запуска процесса конвертации конкретного файла с конкретными параметрами
— возможность запуска из под отдельного пользователя, с более урезанными чем «демон-враппер» правами
— удобное управление лимитами — память, максимальное время работы (считаем, что в библиотеках могут быть баги)
Если согласиться с тем, что для конвертации все же лучше запускать отдельный процесс — то так ли важно, будет ли это ffmpeg или самописнная утилита на основе тех же самых библиотек?
И да, интерфейс у библиотек не сильно высокоуровневый, т.е. там нет функции
convert(const char *infile, const char *outfile, struct convert_params *params), а возможности, которые они за счет этого предоставляют (помимо тех, что есть в утилите ffmpeg) в задаче конвертирования не нужны.И по теме выступления — использование библиотек FFmpeg вместо утилиты ведь не должно спасти от такой аттаки, или есть мнение что должно?
как раз наоборот — требуется довольно много настроек кодека + цепочка фильтров в нужном порядке со своими настройками + другие различные опции, и все это очень легко задается опциями утилиты ffmpeg.
Пример с system('sleep 10') лучше заменить на
system('cat /proc/blabla | grep aaa | awk '{print $3" "$4}' | sort | uniq -c | sort -n | head -n3')Конечно, и для моего примера использовать system() это не хорошо и не стоит так делать в большинстве случаев, но думаю мысль понятна.Кстати, мне встречались биндинги для некоторых языков именно к утилите ffmpeg — т.е. идея запускать бинарник ffmpeg вместо использования библиотек именно в случае FFmpeg довольно распространена.