Comments 21
Интересно, спасибо! Правда мне показалось маловато, статья больше похожа на «памятку для самого себя». Впрочем, буду ждать продолжения, материал понравился, смысл аббревиатур искать не пришлось :).
Про анализ видео на питоне хорошо бы услышать. И показ результата пользователю в браузер. Потому что на этом пути есть много интереснейших грабель — источник исходного сигнала в разных форматах, обеспечение реалтайма и желательно подешевле, стриминг пользователю в браузер, где всё разнообразно и не очень хорошо.
А сможете поделиться собственно конкретными примерами вызовов ffmpeg с объяснением что как и почему? В т.ч. для разных устройств
Хорошо, включу больше примеров в следующую статью.
От устройства и даже от архитектуры параметры не сильно отличаются, если есть одинаковые кодеки. Если же речь идёт об аппаратном кодировании, то там используется более широкий набор утилит и совсем другой граф данных — ffmpeg может вообще не использоваться.
От устройства и даже от архитектуры параметры не сильно отличаются, если есть одинаковые кодеки. Если же речь идёт об аппаратном кодировании, то там используется более широкий набор утилит и совсем другой граф данных — ffmpeg может вообще не использоваться.
На фото — первый летающий четырёхколёсный велосипед
Интересно было бы услышать:
1)Чем на пальцах отличаются профили кодирования у h264
2)Примеры кодирования, чтобы получить минимальный размер при сохранении приемлемого качества
3)Способы доставки в плеер, а также обеспечения просмотра рекламы (т.е. чтобы пользователь не мог по прямой ссылке скачать, а только с сайта)
4)Возможно не сильно относится к теме, но интересен опыт проброс видеокарт в виртуальные машины. Собственно для использования их в кодировании.
1)Чем на пальцах отличаются профили кодирования у h264
2)Примеры кодирования, чтобы получить минимальный размер при сохранении приемлемого качества
3)Способы доставки в плеер, а также обеспечения просмотра рекламы (т.е. чтобы пользователь не мог по прямой ссылке скачать, а только с сайта)
4)Возможно не сильно относится к теме, но интересен опыт проброс видеокарт в виртуальные машины. Собственно для использования их в кодировании.
1 — Хорошо, включу в следующую, или одну из следующих статей. Не знаю только, как глубоко — тема возможностей и особенностей h264 сама по себе тянет не на один цикл статей.
2 — Будет в следующей статье.
3 — Я постараюсь затронуть методы ограничения доступа в статье про доставку.
4 — Особого опыта нет, т.к. я работал с гибридными облачными решениями, а там пробрасывать не приходилось. Пробросы я делал, разве что, на рабочей машине и по руководствам — не на том уровне, чтобы писать статьи на тему. К тому же это очень сильно зависит от платформы.
2 — Будет в следующей статье.
3 — Я постараюсь затронуть методы ограничения доступа в статье про доставку.
4 — Особого опыта нет, т.к. я работал с гибридными облачными решениями, а там пробрасывать не приходилось. Пробросы я делал, разве что, на рабочей машине и по руководствам — не на том уровне, чтобы писать статьи на тему. К тому же это очень сильно зависит от платформы.
1 — ну вот конкретно тут меня интересует одна такая практическая вещь, что иногда для проигрывания текущего места нужно, чтобы было прогружено что-то из будущего видеопотока при кодировании main. И это немного напрягает, да и хотелось бы избавиться без потерь качества
Вы имеете в виду метаданные, которые находятся в конце файла?
Нет — как я читал по умолчанию метаданные вроде разбросаны по файлу, их можно перенести в начало. Для ускорения воспроизведения онлайн.
Но я стал замечать, что вот допустим я начинаю воспроизводить файл онлайн и по буферу видно, что у меня впереди ещё дофига загружено, а плеер встаёт и задумывается, прогружает что-то. Причём, если смотреть в браузере где отображаются именно кусочки кешированные получается, что эти части могут быть прилично впереди.
Но я стал замечать, что вот допустим я начинаю воспроизводить файл онлайн и по буферу видно, что у меня впереди ещё дофига загружено, а плеер встаёт и задумывается, прогружает что-то. Причём, если смотреть в браузере где отображаются именно кусочки кешированные получается, что эти части могут быть прилично впереди.
Куча вопросов накопилось на эту тему :)
Касаемо хранения видео пользователей на сервере. К примеру, пользователь загрузил на сервер видео. Затем оно автоматом перекодируется под разное качество и в другой кодек. А загруженный исходник потом удаляется?
Скоро (в этом году) в Firefox и хроме уберут поддержку флеша окончательно. Сайт rutube.ru отдаёт видео только во флеше. Как они выйдут из этого положения и реально ли за такое короткое время перекодировать всё видео и переделать сайт?
Почему видеохостинги не пытаются использовать p2p для распространения видео? IPv6 уже к 30% подбирается, NAT как таковой перестаёт быть проблемой во многих местах. Например сделать так, что с сервера кусочки файлов грузятся с начала, а с обычных пользователей с конца.
Некоторые сайты дают возможность скачать видео, или открыть это видео в плеере. При чём есть такие, где и расширений в браузер ставить не надо. ruclip.com сделали что можно скачать и в любой плеер ссылку перетянуть. Почему другие так не делают? Просмотр рекламы с сайта — это причина?
Видео с 60fps тянет не каждый комп, для ютуба есть расширение h264ify которе просит ютуб отдавать видео в 30fps, а не 60. Собственно, почему все гонятся за 60fps? Я понимаю когда видео идёт в динамике, там это заметно, но когда просто кто-то сидит за столом и открывает рот, там и 24 кадра достаточно. Как ютуб делает 30fps? он отдаёт пользователю куски через кадр или отдельно хранит у себя перекодированное видео в 30 fps?
Касаемо хранения видео пользователей на сервере. К примеру, пользователь загрузил на сервер видео. Затем оно автоматом перекодируется под разное качество и в другой кодек. А загруженный исходник потом удаляется?
Скоро (в этом году) в 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.
Планируете ли раскрывать тему аппаратного транскодирования?
Какую бы технологию и платформу посоветовали бы? Какой софт?
Задача классическая, спутниковые каналы перегнать в H264.
Аппаратные кодеры, выпущенные в последние годы, все на достойном уровне. NVENC кодирует чуть качественнее, Quick Sync быстрее, но разница становится существенной только в больших проектах. Для «домашнего» использования или для относительно небольших объёмов подойдёт любая платформа; используйте, что есть.
Проще всего будет настроить тот же ffmpeg, но с аппаратными кодеками —
https://trac.ffmpeg.org/wiki/HWAccelIntro
Рекомендации:
— использовать только свежий ffmpeg, ещё лучше собрать его самому. Не представляете, сколько времени на отладке можно потратить перед тем, как обнаружится, что причиной проблем была старая версия;
— обновлять ffmpeg с осторожностью и после проверки работоспособности новой версии в вашем окружении;
— проверять работу параметров; сравнивать результаты;
— проверять работу муксера, ремуксить при необходимости.
Отдельную статью делать не планирую, т.к. в последнее время ситуация с аппаратным кодированием быстро меняется и многие старые трюки перестают работать или становятся ненужными.
Проще всего будет настроить тот же ffmpeg, но с аппаратными кодеками —
https://trac.ffmpeg.org/wiki/HWAccelIntro
Рекомендации:
— использовать только свежий ffmpeg, ещё лучше собрать его самому. Не представляете, сколько времени на отладке можно потратить перед тем, как обнаружится, что причиной проблем была старая версия;
— обновлять ffmpeg с осторожностью и после проверки работоспособности новой версии в вашем окружении;
— проверять работу параметров; сравнивать результаты;
— проверять работу муксера, ремуксить при необходимости.
Отдельную статью делать не планирую, т.к. в последнее время ситуация с аппаратным кодированием быстро меняется и многие старые трюки перестают работать или становятся ненужными.
Sign up to leave a comment.
Своя видео-платформа или чем занять много вычислительных ресурсов. Part 1