Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 21

Интересно, спасибо! Правда мне показалось маловато, статья больше похожа на «памятку для самого себя». Впрочем, буду ждать продолжения, материал понравился, смысл аббревиатур искать не пришлось :).
Такого типа материал вообще очень сложно подавать в повествовательном стиле; это же не курс «for dummies». Потому в шапке и выделил полтора абзаца на предупреждение о формате.
Впрочем, некоторые из готовящихся статей, похоже, будут легче в этом плане.

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

Реалтайм и онлайн анализаторов не делал, впрочем для несложных метрик это возможно.
Остальное — в соответствующей статье, правда, судя по голосованию, она будет только через некоторое время.
А сможете поделиться собственно конкретными примерами вызовов ffmpeg с объяснением что как и почему? В т.ч. для разных устройств
Хорошо, включу больше примеров в следующую статью.
От устройства и даже от архитектуры параметры не сильно отличаются, если есть одинаковые кодеки. Если же речь идёт об аппаратном кодировании, то там используется более широкий набор утилит и совсем другой граф данных — ffmpeg может вообще не использоваться.
Я больше про то как условно входной формат XXX отдать скажем на iphone — вроде бы не очень тривиальная задача, если на входе сильно разное видео по параметрам
А, понятно. Я думал, для разных устройств, на которых кодируется. Думаю, включу в следующую статью.
На фото — первый летающий четырёхколёсный велосипед

image
Интересно было бы услышать:
1)Чем на пальцах отличаются профили кодирования у h264
2)Примеры кодирования, чтобы получить минимальный размер при сохранении приемлемого качества
3)Способы доставки в плеер, а также обеспечения просмотра рекламы (т.е. чтобы пользователь не мог по прямой ссылке скачать, а только с сайта)
4)Возможно не сильно относится к теме, но интересен опыт проброс видеокарт в виртуальные машины. Собственно для использования их в кодировании.
1 — Хорошо, включу в следующую, или одну из следующих статей. Не знаю только, как глубоко — тема возможностей и особенностей h264 сама по себе тянет не на один цикл статей.
2 — Будет в следующей статье.
3 — Я постараюсь затронуть методы ограничения доступа в статье про доставку.
4 — Особого опыта нет, т.к. я работал с гибридными облачными решениями, а там пробрасывать не приходилось. Пробросы я делал, разве что, на рабочей машине и по руководствам — не на том уровне, чтобы писать статьи на тему. К тому же это очень сильно зависит от платформы.
1 — ну вот конкретно тут меня интересует одна такая практическая вещь, что иногда для проигрывания текущего места нужно, чтобы было прогружено что-то из будущего видеопотока при кодировании main. И это немного напрягает, да и хотелось бы избавиться без потерь качества
Вы имеете в виду метаданные, которые находятся в конце файла?
Нет — как я читал по умолчанию метаданные вроде разбросаны по файлу, их можно перенести в начало. Для ускорения воспроизведения онлайн.
Но я стал замечать, что вот допустим я начинаю воспроизводить файл онлайн и по буферу видно, что у меня впереди ещё дофига загружено, а плеер встаёт и задумывается, прогружает что-то. Причём, если смотреть в браузере где отображаются именно кусочки кешированные получается, что эти части могут быть прилично впереди.
С обычным видео такого быть не должно. Может быть вы используете DASH и есть проблемы с доступом к какому-то блоку?
Куча вопросов накопилось на эту тему :)

Касаемо хранения видео пользователей на сервере. К примеру, пользователь загрузил на сервер видео. Затем оно автоматом перекодируется под разное качество и в другой кодек. А загруженный исходник потом удаляется?
Скоро (в этом году) в Firefox и хроме уберут поддержку флеша окончательно. Сайт rutube.ru отдаёт видео только во флеше. Как они выйдут из этого положения и реально ли за такое короткое время перекодировать всё видео и переделать сайт?

Почему видеохостинги не пытаются использовать p2p для распространения видео? IPv6 уже к 30% подбирается, NAT как таковой перестаёт быть проблемой во многих местах. Например сделать так, что с сервера кусочки файлов грузятся с начала, а с обычных пользователей с конца.

Некоторые сайты дают возможность скачать видео, или открыть это видео в плеере. При чём есть такие, где и расширений в браузер ставить не надо. ruclip.com сделали что можно скачать и в любой плеер ссылку перетянуть. Почему другие так не делают? Просмотр рекламы с сайта — это причина?

Видео с 60fps тянет не каждый комп, для ютуба есть расширение h264ify которе просит ютуб отдавать видео в 30fps, а не 60. Собственно, почему все гонятся за 60fps? Я понимаю когда видео идёт в динамике, там это заметно, но когда просто кто-то сидит за столом и открывает рот, там и 24 кадра достаточно. Как ютуб делает 30fps? он отдаёт пользователю куски через кадр или отдельно хранит у себя перекодированное видео в 30 fps?
Видео то зачем перекодировать?

Во флэше только программа-плеер. Кодеки, которыми сжато видео сами по себе и универсальны — от плеера не зависят.
А сайт можно быстро передалеть.
Сайт rutube.ru отдаёт видео только во флеше. Как они выйдут из этого положения и реально ли за такое короткое время перекодировать всё видео и переделать сайт?

Уже 2 года как flash там используется только для Windows XP (в котором поддержка flash не отключится уже никогда), к тому же весь контент хранится в MP4 и на лету "нарезается" на нужные форматы — в основном HLS.
Сайт переделывать не пришлось, таргетирование форматов видеоотдачи там делалось плавно и аккуратно. А вот с плеером пришлось повозиться: в первую очередь из-за перевода рекламы с Flash на HTML5. Еще много проблем с т.з. железа доставил повсеместный переход на HTTPS (возрасла нагрузка на CPU кэша видеоотдачи, новые сервера тюнили с полгода или даже больше).


Почему видеохостинги не пытаются использовать p2p для распространения видео?

Инхаус дорогая разработка, интеграция — дорогое обслуживание. Использовали, экономия порядка 20-30% (по данным интегратора) или 10-15%, если считать падение общего трафика при включении p2p. На вопрос "почему такая разница" ответили "ой, мы там учет только что пофиксили" — и разница стала в два раза меньше. Мухлёж кароч.


Почему другие так не делают? Просмотр рекламы с сайта — это причина?

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

А загруженный исходник потом удаляется?

На большинстве видеоплощадок удаляется, или, по крайней мере, уходит в архив и становится недоступен.
Сайт rutube.ru отдаёт видео только во флеше. Как они выйдут из этого положения и реально ли за такое короткое время перекодировать всё видео и переделать сайт?

В большинстве случаев внутри проигрываемого с помощью flash контента — mpeg в том или ином виде — максимум потребуется ремукс. Могут возникнуть проблемы со старыми FLV-VP6, если архив очень старый, но у таких роликов обычно настолько низкое качество, что их перекодирование не займёт много времени.
Почему видеохостинги не пытаются использовать p2p

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

Да, думаю, на 99% причина в рекламе.
Собственно, почему все гонятся за 60fps?

60fps это круто. Как, у вас не 60fps? Я вчера разогнал свой CRT монитор до 59 дюймов, только греется силь^U
fps берётся из исходника, исходник от блогеров, а те прочитали где-то, что так лучше, вот и делают не задумываясь.
Перешел со второй части статьи.

Планируете ли раскрывать тему аппаратного транскодирования?
Какую бы технологию и платформу посоветовали бы? Какой софт?
Задача классическая, спутниковые каналы перегнать в H264.
Аппаратные кодеры, выпущенные в последние годы, все на достойном уровне. NVENC кодирует чуть качественнее, Quick Sync быстрее, но разница становится существенной только в больших проектах. Для «домашнего» использования или для относительно небольших объёмов подойдёт любая платформа; используйте, что есть.

Проще всего будет настроить тот же ffmpeg, но с аппаратными кодеками —
https://trac.ffmpeg.org/wiki/HWAccelIntro
Рекомендации:
— использовать только свежий ffmpeg, ещё лучше собрать его самому. Не представляете, сколько времени на отладке можно потратить перед тем, как обнаружится, что причиной проблем была старая версия;
— обновлять ffmpeg с осторожностью и после проверки работоспособности новой версии в вашем окружении;
— проверять работу параметров; сравнивать результаты;
— проверять работу муксера, ремуксить при необходимости.

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

Публикации