Этого треда уже нет.
Это копия, сохраненная 8 ноября 2015 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 8 ноября 2015 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
281 Кб, 600x450
Тред про кодирование вебмок.
Основным обсуждаемым здесь инструментом является ffmpeg. Пердолики с мокрописечными гуями вроде xmedia recode и прочие клепальщики распидорашенного кривопиксельного говна из порнотреда со своими воплями о ненужности консоли не нужны сами — пусть сначала научатся делать качественные вебмки, а потом уже лезут сюда с советами.
Делать WebM можно научиться в вики треда: https://github.com/pituz/webm-thread/wiki/
Там находится подробная информация о выборе и настройке кодеков на примерах использования консольных утилит ffmpeg, vpxenc и mkvmerge.
Если для кого-то это слишком сложно, то можно взять гуй с минимумом кнопок для умственно отсталых (сперма-only): https://gitgud.io/nixx/WebMConverter
О кодировании WebM для сосача:
— доступные кодеки — VP8 и VP9 для видео, Vorbis и Opus для звука;
— максимальный размер файла: 20480КБ в /b/ и /media/, 6144КБ в тематике, всех файлов в посте — около 22МБ.
Неочевидные моменты:
— начиная с версии 2.8 ffmpeg использует для WebM по умолчанию VP9 и Opus;
— libvorbis при указании битрейта (-b:a) работает в режиме CBR (постоянный битрейт), и это портит качество звука; для режима VBR вместо битрейта надо указывать качество (-q:a); параметр -vbr on работает только для Opus'а;
— в webm'ки не нужно включать софтсаб в формате webvtt (FFmpeg это делает по умолчанию при наличии сабов в контейнере, отключается параметром -sn): во-первых, это бесполезно (для его отображения на странице должен быть специальный код), а во-вторых, от этого ролики не воспроизводятся в firefox;
— ролики с opus'ом в firefox зацикливаются не с начала, а с последнего ключевого кадра.
Программы и их документация
http://webmproject.org http://ffmpeg.org http://mpv.io http://www.bunkus.org/videotools/mkvtoolnix/
Фронтенды к ffmpeg для кодирования вебмок
CLI, бидон: https://pypi.python.org/pypi/webm
CLI, zsh: https://github.com/pituz/webm-thread/tree/master/tools
CLI, дотнет: https://github.com/CherryPerry/ffmpeg-vp9-wrap
Основным обсуждаемым здесь инструментом является ffmpeg. Пердолики с мокрописечными гуями вроде xmedia recode и прочие клепальщики распидорашенного кривопиксельного говна из порнотреда со своими воплями о ненужности консоли не нужны сами — пусть сначала научатся делать качественные вебмки, а потом уже лезут сюда с советами.
Делать WebM можно научиться в вики треда: https://github.com/pituz/webm-thread/wiki/
Там находится подробная информация о выборе и настройке кодеков на примерах использования консольных утилит ffmpeg, vpxenc и mkvmerge.
Если для кого-то это слишком сложно, то можно взять гуй с минимумом кнопок для умственно отсталых (сперма-only): https://gitgud.io/nixx/WebMConverter
О кодировании WebM для сосача:
— доступные кодеки — VP8 и VP9 для видео, Vorbis и Opus для звука;
— максимальный размер файла: 20480КБ в /b/ и /media/, 6144КБ в тематике, всех файлов в посте — около 22МБ.
Неочевидные моменты:
— начиная с версии 2.8 ffmpeg использует для WebM по умолчанию VP9 и Opus;
— libvorbis при указании битрейта (-b:a) работает в режиме CBR (постоянный битрейт), и это портит качество звука; для режима VBR вместо битрейта надо указывать качество (-q:a); параметр -vbr on работает только для Opus'а;
— в webm'ки не нужно включать софтсаб в формате webvtt (FFmpeg это делает по умолчанию при наличии сабов в контейнере, отключается параметром -sn): во-первых, это бесполезно (для его отображения на странице должен быть специальный код), а во-вторых, от этого ролики не воспроизводятся в firefox;
— ролики с opus'ом в firefox зацикливаются не с начала, а с последнего ключевого кадра.
Программы и их документация
http://webmproject.org http://ffmpeg.org http://mpv.io http://www.bunkus.org/videotools/mkvtoolnix/
Фронтенды к ffmpeg для кодирования вебмок
CLI, бидон: https://pypi.python.org/pypi/webm
CLI, zsh: https://github.com/pituz/webm-thread/tree/master/tools
CLI, дотнет: https://github.com/CherryPerry/ffmpeg-vp9-wrap
>>1395795
Проиграл с этих пердолегайдов. Это блять не рокет саенс, это ебаные вебмки! Скачать любой конвертер там за пару сек можно всё обрезать, изменить разрешение. Всё с человеческим гуи. Нахуя это?
Проиграл с этих пердолегайдов. Это блять не рокет саенс, это ебаные вебмки! Скачать любой конвертер там за пару сек можно всё обрезать, изменить разрешение. Всё с человеческим гуи. Нахуя это?
5137 Кб, Webm
4857 Кб, Webm
5119 Кб, Webm
5111 Кб, Webm
>>1395798
Это для того, чтобы делать красиво.
Через гуй всегда получается большой размер при низком качестве, нормальных гуев пока не завезли.
Это для того, чтобы делать красиво.
Через гуй всегда получается большой размер при низком качестве, нормальных гуев пока не завезли.
>>1395798
> Пердолики с мокрописечными гуями вроде xmedia recode и прочие клепальщики распидорашенного кривопиксельного говна из порнотреда со своими воплями о ненужности консоли не нужны сами — пусть сначала научатся делать качественные вебмки, а потом уже лезут сюда с советами.
364 Кб, 1920x1080
>>1395930
Но консоль это совсем не страшно, особенно если это помершеллчик.
Но консоль это совсем не страшно, особенно если это помершеллчик.
Иногда в вебм треде проскакивает программа от Васяна. Просто указал путь до файла, путь сохранения, да лимит размера. Без пердольства. Где найти?
22 Кб, 1002x273
>>1396200
Последние строки оп-поста.
Последние строки оп-поста.
704 Кб, 3840x2160
1135 Кб, 3840x2160
6115 Кб, 3840x2160
>>1395994
О, спасибо, а я в поиске не смог найти.
Кстати, насчёт оп-пасты: VP9 и 12 бит поддерживает, -pix_fmt +yuvXXXp12le. Немного помогает от бандинга на градиентах, но не так хорошо как отдельный дизеринг-фильтр. Первая картинка — 8 бит, вторая — 12, третья — дизеринг 8 бит.
О, спасибо, а я в поиске не смог найти.
Кстати, насчёт оп-пасты: VP9 и 12 бит поддерживает, -pix_fmt +yuvXXXp12le. Немного помогает от бандинга на градиентах, но не так хорошо как отдельный дизеринг-фильтр. Первая картинка — 8 бит, вторая — 12, третья — дизеринг 8 бит.
3550 Кб, Webm
>>1395798
А я вот не понимаю, откуда такая боязнь CLI? Что это за панические фобии? Специалисты будут использовать те инструменты, которые обеспечивают максимально низкоуровневый доступ к процессу. И субъективное удобство в глазах обывателя стоит здесь далеко не на первом месте. Просто так сложилось, что консольные утилиты в основном лучше справляются с требованием предоставить минимальный набор абстракций при выполнении поставленой задачи. Но это вовсе не обязательно. Например, в случае различного рода анализаторов, визуализаторов. Никому и в голову не придёт использовать какое-нибудь подобие программы на ncurses для просмотра сведений о супрблоках/макроблоках/векторов движения/факторов квантования и прочего в видео — есть отличные GUI. Или интерактивное редактирование.
Абстракция — это то, что снижает уверенность в результате с каждым новый её слоем. Не бывает идеальных абстракций. Ты вот знаешь какое в твоей гуёвине (которые в большинстве своём всего лишь обёртки над ffmpeg) используется используется цветовое пространство при конвертировании из RGB в Y'CbCr? Full range или limited? Знаешь как повысить битность потока, чтобы уменьшить бандинг, да так, чтобы это действие произошло до преобразования цветового пространства, дабы не получить нехилые потери? Или можешь преобразовать картинку в y4m специализированной программой, размножить её на уровне демуксера, т.к. та программа таким не занимается и скормить на вход конвертеру? Можешь поставить тэг используемого цветового пространства в VPX фреймах? Здесь отдельные утилиты-то, написанные как раз для этих целей, далеко не всегда справляются, а ты в однокнопочной гуёвине хочешь всё задаром. А между тем задача вроде как простая стояла — сделать WebM с картинкой и музыкой, чтобы цвета не поехали.
В случае каких-нибудь неясностей, ошибок, ты землю грызть будешь, чтобы добраться до причины (разумеется, если тебе важен результат). И наличие лишних неизвестностей вроде closed-source GUI обёртки это то, что будет выкинуто в первую же очередь. Ты даже не подозреваешь, до чего всё плохо бывает. Хоть в asm зарывайся, хоть RFC по сто раз перечитывай, хоть в магазин за калибратором беги — какая-то хуйня и всё тут. И в гугле ничего, и программы хоть бесплатные, хоть платные, всё неправильно делают. Вот тебе неплохой пример подобного, касательно цветовых пространств и гуёвин: https://github.com/mpv-player/mpv/issues/534
Разумеется, ты сейчас про себя подумал «Нафиг это надо? Мне только смешной момент вырезать из кинчика и с пацанами под пивко поугарать». Ну так тред и не для тебя, проходи мимо. Возможно, вембрелейтед натолкнёт тебя на какие-нибудь размышления.
А я вот не понимаю, откуда такая боязнь CLI? Что это за панические фобии? Специалисты будут использовать те инструменты, которые обеспечивают максимально низкоуровневый доступ к процессу. И субъективное удобство в глазах обывателя стоит здесь далеко не на первом месте. Просто так сложилось, что консольные утилиты в основном лучше справляются с требованием предоставить минимальный набор абстракций при выполнении поставленой задачи. Но это вовсе не обязательно. Например, в случае различного рода анализаторов, визуализаторов. Никому и в голову не придёт использовать какое-нибудь подобие программы на ncurses для просмотра сведений о супрблоках/макроблоках/векторов движения/факторов квантования и прочего в видео — есть отличные GUI. Или интерактивное редактирование.
Абстракция — это то, что снижает уверенность в результате с каждым новый её слоем. Не бывает идеальных абстракций. Ты вот знаешь какое в твоей гуёвине (которые в большинстве своём всего лишь обёртки над ffmpeg) используется используется цветовое пространство при конвертировании из RGB в Y'CbCr? Full range или limited? Знаешь как повысить битность потока, чтобы уменьшить бандинг, да так, чтобы это действие произошло до преобразования цветового пространства, дабы не получить нехилые потери? Или можешь преобразовать картинку в y4m специализированной программой, размножить её на уровне демуксера, т.к. та программа таким не занимается и скормить на вход конвертеру? Можешь поставить тэг используемого цветового пространства в VPX фреймах? Здесь отдельные утилиты-то, написанные как раз для этих целей, далеко не всегда справляются, а ты в однокнопочной гуёвине хочешь всё задаром. А между тем задача вроде как простая стояла — сделать WebM с картинкой и музыкой, чтобы цвета не поехали.
В случае каких-нибудь неясностей, ошибок, ты землю грызть будешь, чтобы добраться до причины (разумеется, если тебе важен результат). И наличие лишних неизвестностей вроде closed-source GUI обёртки это то, что будет выкинуто в первую же очередь. Ты даже не подозреваешь, до чего всё плохо бывает. Хоть в asm зарывайся, хоть RFC по сто раз перечитывай, хоть в магазин за калибратором беги — какая-то хуйня и всё тут. И в гугле ничего, и программы хоть бесплатные, хоть платные, всё неправильно делают. Вот тебе неплохой пример подобного, касательно цветовых пространств и гуёвин: https://github.com/mpv-player/mpv/issues/534
Разумеется, ты сейчас про себя подумал «Нафиг это надо? Мне только смешной момент вырезать из кинчика и с пацанами под пивко поугарать». Ну так тред и не для тебя, проходи мимо. Возможно, вембрелейтед натолкнёт тебя на какие-нибудь размышления.
3550 Кб, Webm
>>1395798
А я вот не понимаю, откуда такая боязнь CLI? Что это за панические фобии? Специалисты будут использовать те инструменты, которые обеспечивают максимально низкоуровневый доступ к процессу. И субъективное удобство в глазах обывателя стоит здесь далеко не на первом месте. Просто так сложилось, что консольные утилиты в основном лучше справляются с требованием предоставить минимальный набор абстракций при выполнении поставленой задачи. Но это вовсе не обязательно. Например, в случае различного рода анализаторов, визуализаторов. Никому и в голову не придёт использовать какое-нибудь подобие программы на ncurses для просмотра сведений о супрблоках/макроблоках/векторов движения/факторов квантования и прочего в видео — есть отличные GUI. Или интерактивное редактирование.
Абстракция — это то, что снижает уверенность в результате с каждым новый её слоем. Не бывает идеальных абстракций. Ты вот знаешь какое в твоей гуёвине (которые в большинстве своём всего лишь обёртки над ffmpeg) используется используется цветовое пространство при конвертировании из RGB в Y'CbCr? Full range или limited? Знаешь как повысить битность потока, чтобы уменьшить бандинг, да так, чтобы это действие произошло до преобразования цветового пространства, дабы не получить нехилые потери? Или можешь преобразовать картинку в y4m специализированной программой, размножить её на уровне демуксера, т.к. та программа таким не занимается и скормить на вход конвертеру? Можешь поставить тэг используемого цветового пространства в VPX фреймах? Здесь отдельные утилиты-то, написанные как раз для этих целей, далеко не всегда справляются, а ты в однокнопочной гуёвине хочешь всё задаром. А между тем задача вроде как простая стояла — сделать WebM с картинкой и музыкой, чтобы цвета не поехали.
В случае каких-нибудь неясностей, ошибок, ты землю грызть будешь, чтобы добраться до причины (разумеется, если тебе важен результат). И наличие лишних неизвестностей вроде closed-source GUI обёртки это то, что будет выкинуто в первую же очередь. Ты даже не подозреваешь, до чего всё плохо бывает. Хоть в asm зарывайся, хоть RFC по сто раз перечитывай, хоть в магазин за калибратором беги — какая-то хуйня и всё тут. И в гугле ничего, и программы хоть бесплатные, хоть платные, всё неправильно делают. Вот тебе неплохой пример подобного, касательно цветовых пространств и гуёвин: https://github.com/mpv-player/mpv/issues/534
Разумеется, ты сейчас про себя подумал «Нафиг это надо? Мне только смешной момент вырезать из кинчика и с пацанами под пивко поугарать». Ну так тред и не для тебя, проходи мимо. Возможно, вембрелейтед натолкнёт тебя на какие-нибудь размышления.
А я вот не понимаю, откуда такая боязнь CLI? Что это за панические фобии? Специалисты будут использовать те инструменты, которые обеспечивают максимально низкоуровневый доступ к процессу. И субъективное удобство в глазах обывателя стоит здесь далеко не на первом месте. Просто так сложилось, что консольные утилиты в основном лучше справляются с требованием предоставить минимальный набор абстракций при выполнении поставленой задачи. Но это вовсе не обязательно. Например, в случае различного рода анализаторов, визуализаторов. Никому и в голову не придёт использовать какое-нибудь подобие программы на ncurses для просмотра сведений о супрблоках/макроблоках/векторов движения/факторов квантования и прочего в видео — есть отличные GUI. Или интерактивное редактирование.
Абстракция — это то, что снижает уверенность в результате с каждым новый её слоем. Не бывает идеальных абстракций. Ты вот знаешь какое в твоей гуёвине (которые в большинстве своём всего лишь обёртки над ffmpeg) используется используется цветовое пространство при конвертировании из RGB в Y'CbCr? Full range или limited? Знаешь как повысить битность потока, чтобы уменьшить бандинг, да так, чтобы это действие произошло до преобразования цветового пространства, дабы не получить нехилые потери? Или можешь преобразовать картинку в y4m специализированной программой, размножить её на уровне демуксера, т.к. та программа таким не занимается и скормить на вход конвертеру? Можешь поставить тэг используемого цветового пространства в VPX фреймах? Здесь отдельные утилиты-то, написанные как раз для этих целей, далеко не всегда справляются, а ты в однокнопочной гуёвине хочешь всё задаром. А между тем задача вроде как простая стояла — сделать WebM с картинкой и музыкой, чтобы цвета не поехали.
В случае каких-нибудь неясностей, ошибок, ты землю грызть будешь, чтобы добраться до причины (разумеется, если тебе важен результат). И наличие лишних неизвестностей вроде closed-source GUI обёртки это то, что будет выкинуто в первую же очередь. Ты даже не подозреваешь, до чего всё плохо бывает. Хоть в asm зарывайся, хоть RFC по сто раз перечитывай, хоть в магазин за калибратором беги — какая-то хуйня и всё тут. И в гугле ничего, и программы хоть бесплатные, хоть платные, всё неправильно делают. Вот тебе неплохой пример подобного, касательно цветовых пространств и гуёвин: https://github.com/mpv-player/mpv/issues/534
Разумеется, ты сейчас про себя подумал «Нафиг это надо? Мне только смешной момент вырезать из кинчика и с пацанами под пивко поугарать». Ну так тред и не для тебя, проходи мимо. Возможно, вембрелейтед натолкнёт тебя на какие-нибудь размышления.
82 Кб, 740x406
>>1396973
Ебать дебил.
>Специалисты будут использовать те инструменты, которые обеспечивают максимально низкоуровневый доступ к процессу.
Ебать дебил.
>>1396996
Я ж написал, в случае надобности. Да, будешь и исходники читать, и в хекс-редакторе сидеть, и не только.
Я ж написал, в случае надобности. Да, будешь и исходники читать, и в хекс-редакторе сидеть, и не только.
>>1397009
Я ваш гайд немного посмотрел. Там рекомендуется вручную битрейт рассчитывать (!). Вы же понимаете, что вы полностью поехавшие наркоманы-пердолики с карго-культом низкоуровневости? Все, что может быть автоматизировано - должно быть автоматизировано.
Я ваш гайд немного посмотрел. Там рекомендуется вручную битрейт рассчитывать (!). Вы же понимаете, что вы полностью поехавшие наркоманы-пердолики с карго-культом низкоуровневости? Все, что может быть автоматизировано - должно быть автоматизировано.
>>1397036
Про такие мелочи никто и не говорит. В оп-посте есть ссылки на обёртки, которые всё это делают (и от которых иногда приходится отказываться). Гайды обучают ffmpeg'у, базовому инструменту, в этом их ценность.
Про такие мелочи никто и не говорит. В оп-посте есть ссылки на обёртки, которые всё это делают (и от которых иногда приходится отказываться). Гайды обучают ffmpeg'у, базовому инструменту, в этом их ценность.
>>1397042
Так надо дорабатывать обертки до юзабельного в 99.9% случаев состояния, а не сидеть и пердолиться, кичась тем, что зазубрил зачем-то все ключи ffmpeg.
>и от которых иногда приходится отказываться
Так надо дорабатывать обертки до юзабельного в 99.9% случаев состояния, а не сидеть и пердолиться, кичась тем, что зазубрил зачем-то все ключи ffmpeg.
>>1397036
Попробуй серию SP в гуевине или на скриптиках с авторасчетом битрейта в 10МБ ужать без тотальных квадратов.
Для подобных фокусов и нужно небольшое понимание ффмпега.
А сложного там ничего нет, в чем надо было бы долго разбираться, если владеть английским хотя бы на уровне 5 класса общеобразовательной школы.
http://rghost.ru/8dzDksvLG
Попробуй серию SP в гуевине или на скриптиках с авторасчетом битрейта в 10МБ ужать без тотальных квадратов.
Для подобных фокусов и нужно небольшое понимание ффмпега.
А сложного там ничего нет, в чем надо было бы долго разбираться, если владеть английским хотя бы на уровне 5 класса общеобразовательной школы.
http://rghost.ru/8dzDksvLG
>>1397050
Ну, значит ты ничего не понял из того, что я написал. Я даже вебм специально прикрепил.
>Так надо дорабатывать обертки до юзабельного в 99.9% случаев состояния
Ну, значит ты ничего не понял из того, что я написал. Я даже вебм специально прикрепил.
>>1397054
То есть ты сидишь и подбираешь все руками, пока не ужмешь именно в 10 МБ? И сколько времени у тебя это занимает для одной вебмки? Интересна целесообразность подобного.
То есть ты сидишь и подбираешь все руками, пока не ужмешь именно в 10 МБ? И сколько времени у тебя это занимает для одной вебмки? Интересна целесообразность подобного.
>>1397062
Да, я подбираю все руками.
Один раз посчитать в калькуляторе сколько будет занимать видео и оставить необходимое место под звук до лимита, потом просто добавлять звук с максимальным качеством таким, чтобы он влез в лимит.
Сама подгонка звука занимает совсем немного, он кодируется очень быстро, занимает много времени кодирование видео с хорошим соотношением размер/качество, но это уже от процессора непосредственно зависит.
Да, я подбираю все руками.
Один раз посчитать в калькуляторе сколько будет занимать видео и оставить необходимое место под звук до лимита, потом просто добавлять звук с максимальным качеством таким, чтобы он влез в лимит.
Сама подгонка звука занимает совсем немного, он кодируется очень быстро, занимает много времени кодирование видео с хорошим соотношением размер/качество, но это уже от процессора непосредственно зависит.
2558 Кб, 960x540
495 Кб, 960x540
1892 Кб, 960x540
>>1396973
Вот. Реквестирую инфу о подводных камнях с этим делом при использовании ффмпега. С дефолтами выходит какая-то хуйня:
1. yuv420p10le (H.264) → rgb48be (png);
2. yuv420p10le (H.264) → yuv420p (vp9) → rgb24 (png);
3. yuv420p10le (H.264) → yuv420p10le (vp9) → rgb48be (png).
Оно уже обсуждалось в прошлом треде, но то ли я проебался, то ли готовой инструкции нами сгенерировано не было.
> при конвертировании из RGB в Y'CbCr? Full range или limited?
Вот. Реквестирую инфу о подводных камнях с этим делом при использовании ффмпега. С дефолтами выходит какая-то хуйня:
1. yuv420p10le (H.264) → rgb48be (png);
2. yuv420p10le (H.264) → yuv420p (vp9) → rgb24 (png);
3. yuv420p10le (H.264) → yuv420p10le (vp9) → rgb48be (png).
Оно уже обсуждалось в прошлом треде, но то ли я проебался, то ли готовой инструкции нами сгенерировано не было.
>>1397071
Нет, я понял бы, если бы для какого-нибудь блю-рей рипа (хотя у крупных релизеров и они наверно поставлены на поток), но для одной вебмки? Не надоедает, автоматизировать не хочется?
Нет, я понял бы, если бы для какого-нибудь блю-рей рипа (хотя у крупных релизеров и они наверно поставлены на поток), но для одной вебмки? Не надоедает, автоматизировать не хочется?
>>1397089
Нет, мне важнее качественно сделать, чем автоматизировать.
А так у меня наработки в текстовом файле есть, я обычно только битрейт, начало-конец и многопоточность меняю, ничего сложного.
Вот, кстати, под новый лимит 4К кодировал, когда ввели, но в последнее время в /b заходить даже лень, поэтому не кодирую особо, только для освящения вин10-треда иногда.
http://rghost.ru/7pDC7jzGT
> Не надоедает, автоматизировать не хочется?
Нет, мне важнее качественно сделать, чем автоматизировать.
А так у меня наработки в текстовом файле есть, я обычно только битрейт, начало-конец и многопоточность меняю, ничего сложного.
Вот, кстати, под новый лимит 4К кодировал, когда ввели, но в последнее время в /b заходить даже лень, поэтому не кодирую особо, только для освящения вин10-треда иногда.
http://rghost.ru/7pDC7jzGT
435 Кб, 960x540
Тест.
>>1397087
А какая задача-то? Если сконвертировать PNG в WebM, то подводные камни, которые я наблюдал:
1) Любое преобразование между RGB и Y'CbCr, цветовыми пространствами (BT.601 → BT.709), в любом направлении, происходит с потерями. Поэтому их должно быть минимальное количество.
2) Не забыть, что преобразование 4:4:4 в 4:2:0 теряет ¾ цветовой информации.
3) У ffmpeg дефолтное цветовое пространство при преобразовании RGB в YUV — BT.601. Изменить можно с помощью -vf scale=out_color_matrix=bt709 (положение внутри графа фильтров важно).
4) В VP8 используется только цветовое пространство BT.601, VP9 позволяет указывать произвольное, но в ffmpeg нет такого функционала, можно только с помощью опции в vpxenc -color-space поставить: ffmpeg -i test.png -pix_fmt yuv444p -f yuv4mpegpipe - | vpxenc - --codec=vp9 --passes=1 --pass=1 --profile=1 --lossless=1 --color-space=bt601 -o test.webm
5) Соответственно, при кодировании ffmpeg'ом VP9, у VPX кадров в поле vpx_color_t значение VPX_CS_UNKNOWN и плеерам приходится угадывать цветовое пространство.
6) В mpv для определения цветового пространства используется следующая эвристика: BT.601 для SD, BT.709 для HD (>= 1279x719). Поменять можно с помощью -vf format=colormatrix=bt.xxx Т.е. при кодировании HD PNG ffmpeg'ом (у которого всегда BT.601) и просмотра результата mpv ожидаемо поедут цвета. Нужно использовать фильтр scale, либо внедрить информации о цветовом пространстве во фреймы.
7) Самый популярный формат видео — Y'CbCr 4:2:0 limited range. full range вроде почти никогда не бывает, нужно limited (т.е. значения компонент между 16 и 235/240). Это вроде все по умолчанию используют, только в кривой ffplay видел full range по умолчанию, здесь проблем быть не должно. С дискретизацией 4:2:0 всё просто.
8) -pix_fmt в мане описана, ничего сложного. Единственное что лучше использовать плюсик перед значением, чтобы не было fallback на дефолт. И многобитные форматы, как правило, всегда LE, например yuv420p10le. Впрочем, всё что кроме yuv420p 8bit, плохо поддерживается плеерами/браузерами, особенно чуть устаревших версий. Про профили VP9: https://chromium.googlesource.com/webm/libvpx/+/master/vp9/common/vp9_enums.h#29 2-ой и 3-й профили могут быть не включены по умолчанию в используемый сборке libvpx, там отдельный флаг для этого при компиляции.
9) ffmpeg не делает dithering при преобразовании RGB в YUV (Y'CbCr по-простому), поэтому ожидаем бандинг на градиентах. Результат можно немного улучшить при использовании 12бит и даунсемплинга: -vf scale=out_color_matrix=bt709,format=yuv444p12le и -vf format=rgb48le,scale=out_color_matrix=bt709,format=yuv444p (даунсэмплинг 12бит RGB в 8бит YUV).
10) png2y4m из утилит Daala https://git.xiph.org/?p=daala.git;a=blob;f=tools/png2y4m.c;h=fe0979db826fea42f9b6a9cd2dca3ad85c04d3cf;hb=HEAD умеет dithering (только 8bit и не забыть --chroma-444 опцию, если нужно без потерь), но результат будет весить гораздо больше из-за шума. 12бит может быть более оправданным при маленьких лимитах.
11) В прошлом треде была некоторая полезная информация касательно утилит для визуализации графа фильтров ffmpeg и логгинга конвертаций цветовых форматов при -loglevel verbose: http://arhivach.org/thread/100617/#1253983 (но про цветовые пространства там лучше не читать, много ошибок).
12) Печальный факт: большая часть программ работает с цветовыми пространствами неправильно. Надо знать теорию, а её никто не читает. Поэтому ожидаемо огромное количество багов всех сортов при попытке сделать что-нибудь pixel accurate.
В гайд лень оформлять, да и я сам пока особо цветовые пространства не осилил. Вот только неплохую ссылку знаю на теорию:
http://ninedegreesbelow.com/photography/articles.html
>>1397089
Ну да, всё так просто, а все качают рипы THORA и прочих известных релизеров почему-то.
А какая задача-то? Если сконвертировать PNG в WebM, то подводные камни, которые я наблюдал:
1) Любое преобразование между RGB и Y'CbCr, цветовыми пространствами (BT.601 → BT.709), в любом направлении, происходит с потерями. Поэтому их должно быть минимальное количество.
2) Не забыть, что преобразование 4:4:4 в 4:2:0 теряет ¾ цветовой информации.
3) У ffmpeg дефолтное цветовое пространство при преобразовании RGB в YUV — BT.601. Изменить можно с помощью -vf scale=out_color_matrix=bt709 (положение внутри графа фильтров важно).
4) В VP8 используется только цветовое пространство BT.601, VP9 позволяет указывать произвольное, но в ffmpeg нет такого функционала, можно только с помощью опции в vpxenc -color-space поставить: ffmpeg -i test.png -pix_fmt yuv444p -f yuv4mpegpipe - | vpxenc - --codec=vp9 --passes=1 --pass=1 --profile=1 --lossless=1 --color-space=bt601 -o test.webm
5) Соответственно, при кодировании ffmpeg'ом VP9, у VPX кадров в поле vpx_color_t значение VPX_CS_UNKNOWN и плеерам приходится угадывать цветовое пространство.
6) В mpv для определения цветового пространства используется следующая эвристика: BT.601 для SD, BT.709 для HD (>= 1279x719). Поменять можно с помощью -vf format=colormatrix=bt.xxx Т.е. при кодировании HD PNG ffmpeg'ом (у которого всегда BT.601) и просмотра результата mpv ожидаемо поедут цвета. Нужно использовать фильтр scale, либо внедрить информации о цветовом пространстве во фреймы.
7) Самый популярный формат видео — Y'CbCr 4:2:0 limited range. full range вроде почти никогда не бывает, нужно limited (т.е. значения компонент между 16 и 235/240). Это вроде все по умолчанию используют, только в кривой ffplay видел full range по умолчанию, здесь проблем быть не должно. С дискретизацией 4:2:0 всё просто.
8) -pix_fmt в мане описана, ничего сложного. Единственное что лучше использовать плюсик перед значением, чтобы не было fallback на дефолт. И многобитные форматы, как правило, всегда LE, например yuv420p10le. Впрочем, всё что кроме yuv420p 8bit, плохо поддерживается плеерами/браузерами, особенно чуть устаревших версий. Про профили VP9: https://chromium.googlesource.com/webm/libvpx/+/master/vp9/common/vp9_enums.h#29 2-ой и 3-й профили могут быть не включены по умолчанию в используемый сборке libvpx, там отдельный флаг для этого при компиляции.
9) ffmpeg не делает dithering при преобразовании RGB в YUV (Y'CbCr по-простому), поэтому ожидаем бандинг на градиентах. Результат можно немного улучшить при использовании 12бит и даунсемплинга: -vf scale=out_color_matrix=bt709,format=yuv444p12le и -vf format=rgb48le,scale=out_color_matrix=bt709,format=yuv444p (даунсэмплинг 12бит RGB в 8бит YUV).
10) png2y4m из утилит Daala https://git.xiph.org/?p=daala.git;a=blob;f=tools/png2y4m.c;h=fe0979db826fea42f9b6a9cd2dca3ad85c04d3cf;hb=HEAD умеет dithering (только 8bit и не забыть --chroma-444 опцию, если нужно без потерь), но результат будет весить гораздо больше из-за шума. 12бит может быть более оправданным при маленьких лимитах.
11) В прошлом треде была некоторая полезная информация касательно утилит для визуализации графа фильтров ffmpeg и логгинга конвертаций цветовых форматов при -loglevel verbose: http://arhivach.org/thread/100617/#1253983 (но про цветовые пространства там лучше не читать, много ошибок).
12) Печальный факт: большая часть программ работает с цветовыми пространствами неправильно. Надо знать теорию, а её никто не читает. Поэтому ожидаемо огромное количество багов всех сортов при попытке сделать что-нибудь pixel accurate.
В гайд лень оформлять, да и я сам пока особо цветовые пространства не осилил. Вот только неплохую ссылку знаю на теорию:
http://ninedegreesbelow.com/photography/articles.html
>>1397089
Ну да, всё так просто, а все качают рипы THORA и прочих известных релизеров почему-то.
>>1397087
А какая задача-то? Если сконвертировать PNG в WebM, то подводные камни, которые я наблюдал:
1) Любое преобразование между RGB и Y'CbCr, цветовыми пространствами (BT.601 → BT.709), в любом направлении, происходит с потерями. Поэтому их должно быть минимальное количество.
2) Не забыть, что преобразование 4:4:4 в 4:2:0 теряет ¾ цветовой информации.
3) У ffmpeg дефолтное цветовое пространство при преобразовании RGB в YUV — BT.601. Изменить можно с помощью -vf scale=out_color_matrix=bt709 (положение внутри графа фильтров важно).
4) В VP8 используется только цветовое пространство BT.601, VP9 позволяет указывать произвольное, но в ffmpeg нет такого функционала, можно только с помощью опции в vpxenc -color-space поставить: ffmpeg -i test.png -pix_fmt yuv444p -f yuv4mpegpipe - | vpxenc - --codec=vp9 --passes=1 --pass=1 --profile=1 --lossless=1 --color-space=bt601 -o test.webm
5) Соответственно, при кодировании ffmpeg'ом VP9, у VPX кадров в поле vpx_color_t значение VPX_CS_UNKNOWN и плеерам приходится угадывать цветовое пространство.
6) В mpv для определения цветового пространства используется следующая эвристика: BT.601 для SD, BT.709 для HD (>= 1279x719). Поменять можно с помощью -vf format=colormatrix=bt.xxx Т.е. при кодировании HD PNG ffmpeg'ом (у которого всегда BT.601) и просмотра результата mpv ожидаемо поедут цвета. Нужно использовать фильтр scale, либо внедрить информации о цветовом пространстве во фреймы.
7) Самый популярный формат видео — Y'CbCr 4:2:0 limited range. full range вроде почти никогда не бывает, нужно limited (т.е. значения компонент между 16 и 235/240). Это вроде все по умолчанию используют, только в кривой ffplay видел full range по умолчанию, здесь проблем быть не должно. С дискретизацией 4:2:0 всё просто.
8) -pix_fmt в мане описана, ничего сложного. Единственное что лучше использовать плюсик перед значением, чтобы не было fallback на дефолт. И многобитные форматы, как правило, всегда LE, например yuv420p10le. Впрочем, всё что кроме yuv420p 8bit, плохо поддерживается плеерами/браузерами, особенно чуть устаревших версий. Про профили VP9: https://chromium.googlesource.com/webm/libvpx/+/master/vp9/common/vp9_enums.h#29 2-ой и 3-й профили могут быть не включены по умолчанию в используемый сборке libvpx, там отдельный флаг для этого при компиляции.
9) ffmpeg не делает dithering при преобразовании RGB в YUV (Y'CbCr по-простому), поэтому ожидаем бандинг на градиентах. Результат можно немного улучшить при использовании 12бит и даунсемплинга: -vf scale=out_color_matrix=bt709,format=yuv444p12le и -vf format=rgb48le,scale=out_color_matrix=bt709,format=yuv444p (даунсэмплинг 12бит RGB в 8бит YUV).
10) png2y4m из утилит Daala https://git.xiph.org/?p=daala.git;a=blob;f=tools/png2y4m.c;h=fe0979db826fea42f9b6a9cd2dca3ad85c04d3cf;hb=HEAD умеет dithering (только 8bit и не забыть --chroma-444 опцию, если нужно без потерь), но результат будет весить гораздо больше из-за шума. 12бит может быть более оправданным при маленьких лимитах.
11) В прошлом треде была некоторая полезная информация касательно утилит для визуализации графа фильтров ffmpeg и логгинга конвертаций цветовых форматов при -loglevel verbose: http://arhivach.org/thread/100617/#1253983 (но про цветовые пространства там лучше не читать, много ошибок).
12) Печальный факт: большая часть программ работает с цветовыми пространствами неправильно. Надо знать теорию, а её никто не читает. Поэтому ожидаемо огромное количество багов всех сортов при попытке сделать что-нибудь pixel accurate.
В гайд лень оформлять, да и я сам пока особо цветовые пространства не осилил. Вот только неплохую ссылку знаю на теорию:
http://ninedegreesbelow.com/photography/articles.html
>>1397089
Ну да, всё так просто, а все качают рипы THORA и прочих известных релизеров почему-то.
А какая задача-то? Если сконвертировать PNG в WebM, то подводные камни, которые я наблюдал:
1) Любое преобразование между RGB и Y'CbCr, цветовыми пространствами (BT.601 → BT.709), в любом направлении, происходит с потерями. Поэтому их должно быть минимальное количество.
2) Не забыть, что преобразование 4:4:4 в 4:2:0 теряет ¾ цветовой информации.
3) У ffmpeg дефолтное цветовое пространство при преобразовании RGB в YUV — BT.601. Изменить можно с помощью -vf scale=out_color_matrix=bt709 (положение внутри графа фильтров важно).
4) В VP8 используется только цветовое пространство BT.601, VP9 позволяет указывать произвольное, но в ffmpeg нет такого функционала, можно только с помощью опции в vpxenc -color-space поставить: ffmpeg -i test.png -pix_fmt yuv444p -f yuv4mpegpipe - | vpxenc - --codec=vp9 --passes=1 --pass=1 --profile=1 --lossless=1 --color-space=bt601 -o test.webm
5) Соответственно, при кодировании ffmpeg'ом VP9, у VPX кадров в поле vpx_color_t значение VPX_CS_UNKNOWN и плеерам приходится угадывать цветовое пространство.
6) В mpv для определения цветового пространства используется следующая эвристика: BT.601 для SD, BT.709 для HD (>= 1279x719). Поменять можно с помощью -vf format=colormatrix=bt.xxx Т.е. при кодировании HD PNG ffmpeg'ом (у которого всегда BT.601) и просмотра результата mpv ожидаемо поедут цвета. Нужно использовать фильтр scale, либо внедрить информации о цветовом пространстве во фреймы.
7) Самый популярный формат видео — Y'CbCr 4:2:0 limited range. full range вроде почти никогда не бывает, нужно limited (т.е. значения компонент между 16 и 235/240). Это вроде все по умолчанию используют, только в кривой ffplay видел full range по умолчанию, здесь проблем быть не должно. С дискретизацией 4:2:0 всё просто.
8) -pix_fmt в мане описана, ничего сложного. Единственное что лучше использовать плюсик перед значением, чтобы не было fallback на дефолт. И многобитные форматы, как правило, всегда LE, например yuv420p10le. Впрочем, всё что кроме yuv420p 8bit, плохо поддерживается плеерами/браузерами, особенно чуть устаревших версий. Про профили VP9: https://chromium.googlesource.com/webm/libvpx/+/master/vp9/common/vp9_enums.h#29 2-ой и 3-й профили могут быть не включены по умолчанию в используемый сборке libvpx, там отдельный флаг для этого при компиляции.
9) ffmpeg не делает dithering при преобразовании RGB в YUV (Y'CbCr по-простому), поэтому ожидаем бандинг на градиентах. Результат можно немного улучшить при использовании 12бит и даунсемплинга: -vf scale=out_color_matrix=bt709,format=yuv444p12le и -vf format=rgb48le,scale=out_color_matrix=bt709,format=yuv444p (даунсэмплинг 12бит RGB в 8бит YUV).
10) png2y4m из утилит Daala https://git.xiph.org/?p=daala.git;a=blob;f=tools/png2y4m.c;h=fe0979db826fea42f9b6a9cd2dca3ad85c04d3cf;hb=HEAD умеет dithering (только 8bit и не забыть --chroma-444 опцию, если нужно без потерь), но результат будет весить гораздо больше из-за шума. 12бит может быть более оправданным при маленьких лимитах.
11) В прошлом треде была некоторая полезная информация касательно утилит для визуализации графа фильтров ffmpeg и логгинга конвертаций цветовых форматов при -loglevel verbose: http://arhivach.org/thread/100617/#1253983 (но про цветовые пространства там лучше не читать, много ошибок).
12) Печальный факт: большая часть программ работает с цветовыми пространствами неправильно. Надо знать теорию, а её никто не читает. Поэтому ожидаемо огромное количество багов всех сортов при попытке сделать что-нибудь pixel accurate.
В гайд лень оформлять, да и я сам пока особо цветовые пространства не осилил. Вот только неплохую ссылку знаю на теорию:
http://ninedegreesbelow.com/photography/articles.html
>>1397089
Ну да, всё так просто, а все качают рипы THORA и прочих известных релизеров почему-то.
>>1397217
Забыл добавить. В JPEG Y'CbCr формат с нестандартным цветовым пространством (не 601/709), да ещё и full range, так что здесь может быть куча дополнительных камней. Меня от одного PNG с его sRGB, гаммами, хер знает как работающими просмотрщиками и перекодировщиками уже тошнить тянет. А ещё говорят без потерь. Как в compare orig.png result.png -compose src diff.png посмотришь, так плакать хочется.
Забыл добавить. В JPEG Y'CbCr формат с нестандартным цветовым пространством (не 601/709), да ещё и full range, так что здесь может быть куча дополнительных камней. Меня от одного PNG с его sRGB, гаммами, хер знает как работающими просмотрщиками и перекодировщиками уже тошнить тянет. А ещё говорят без потерь. Как в compare orig.png result.png -compose src diff.png посмотришь, так плакать хочется.
>>1397217
В случае с пикрелэйтедами выше — как можно меньше потерять при конвертации из H.264 в VP9, а потом результат сконвертировать в RGB подобно тому, как это делают видеокарты, и сохранить в PNG. Нужно это было для оценки полезности применения VP9 c глубиной цвета 10 бит.
За инфу спасибо, открыл для себя много нового.
> А какая задача-то?
В случае с пикрелэйтедами выше — как можно меньше потерять при конвертации из H.264 в VP9, а потом результат сконвертировать в RGB подобно тому, как это делают видеокарты, и сохранить в PNG. Нужно это было для оценки полезности применения VP9 c глубиной цвета 10 бит.
За инфу спасибо, открыл для себя много нового.
>>1397591
1) Использовать ту же цветовую субдискретизацию, что и на входе (или выше), 4:2:0 в твоём случае.
2) Использовать ту же битность, 10bit LE в твоём случае.
3) Использовать -lossless 1 опцию libvpx-vp9.
4) Открыть файл в mpv с opengl выводом и сделать png скриншот (использовать --screenshot-high-bit-depth=yes).
5) Сделать тем же mpv скриншот исходного файла, сравнить с результатом через compare orig.png result.png -depth 16 -compose src diff.png (16-битный diff не проверял у ImageMagick, правда).
Потерь теоретически быть не должно, т.к. у тебя YUV исходник и это должны быть две одинаковых конвертации 4:2:0 10bit LE → RGB 16bit при сравнении скриншотов H.264 и VP9. Но по факту lossless у VP9 может быть не таким уж и lossless из-за потерять на плавающей точке и прочей гадости. Так что тестируй, проверяй, прикладывай оригиналы/промежуточные результаты. В качестве проверки адекватности пайплайна перекодируй исходный H.264 в y4m (rawvideo) с той же битностью/дискретизацией и с него также сними скриншот.
Вообще, я при тестирование high bit-depth использовал обычные 8-битные PNG как на входе, так и на выходе. Там такой бандинг, что и невооружённым глазом всё отлично заметно.
>как можно меньше потерять при конвертации из H.264 в VP9, а потом результат сконвертировать в RGB подобно тому, как это делают видеокарты, и сохранить в PNG
1) Использовать ту же цветовую субдискретизацию, что и на входе (или выше), 4:2:0 в твоём случае.
2) Использовать ту же битность, 10bit LE в твоём случае.
3) Использовать -lossless 1 опцию libvpx-vp9.
4) Открыть файл в mpv с opengl выводом и сделать png скриншот (использовать --screenshot-high-bit-depth=yes).
5) Сделать тем же mpv скриншот исходного файла, сравнить с результатом через compare orig.png result.png -depth 16 -compose src diff.png (16-битный diff не проверял у ImageMagick, правда).
Потерь теоретически быть не должно, т.к. у тебя YUV исходник и это должны быть две одинаковых конвертации 4:2:0 10bit LE → RGB 16bit при сравнении скриншотов H.264 и VP9. Но по факту lossless у VP9 может быть не таким уж и lossless из-за потерять на плавающей точке и прочей гадости. Так что тестируй, проверяй, прикладывай оригиналы/промежуточные результаты. В качестве проверки адекватности пайплайна перекодируй исходный H.264 в y4m (rawvideo) с той же битностью/дискретизацией и с него также сними скриншот.
Вообще, я при тестирование high bit-depth использовал обычные 8-битные PNG как на входе, так и на выходе. Там такой бандинг, что и невооружённым глазом всё отлично заметно.
>>1397616
О, ничего себе, это дефолт оказывается. Я таки 16-битные скриншоты значит использовал/сравнивал. Одна из возможных причин погрешностей, кстати — сравниваемые файлы должны быть максимально схожих форматов.
>--screenshot-high-bit-depth=yes
О, ничего себе, это дефолт оказывается. Я таки 16-битные скриншоты значит использовал/сравнивал. Одна из возможных причин погрешностей, кстати — сравниваемые файлы должны быть максимально схожих форматов.
>>1397616
Не, задача была в сравнении сжатия с потерями с тем же средним битрейтом.
Этого тоже не нужно, т.к. мало кто использует 10-битный видеорежим. Конкретный use-case — сжатие анимы из yuv420p или yuv420p10le для отображения через rgb24. Пока что очевидных преимуществ использования десятибитного формата вместо восьмибитного не обнаружено — артефактов получается примерно столько же, только они возникают в других местах. Ну и чуть глаже выглядят градиенты.
> 3) Использовать -lossless 1 опцию libvpx-vp9.
Не, задача была в сравнении сжатия с потерями с тем же средним битрейтом.
> 4) Открыть файл в mpv с opengl выводом и сделать png скриншот (использовать --screenshot-high-bit-depth=yes).
Этого тоже не нужно, т.к. мало кто использует 10-битный видеорежим. Конкретный use-case — сжатие анимы из yuv420p или yuv420p10le для отображения через rgb24. Пока что очевидных преимуществ использования десятибитного формата вместо восьмибитного не обнаружено — артефактов получается примерно столько же, только они возникают в других местах. Ну и чуть глаже выглядят градиенты.
>>1397647
Ну тогда здесь по идее никаких особых проблем быть не должно, обычное перекодирование и сравнение по скриншотам. Битность исходника даже не важна. Я думал нужно проверить чистое отличие 10бит от 8бит, по максимуму сохраняя остальные детали («как можно меньше потерять при конвертации из H.264 в VP9»).
Ну на градиентах по мне так очевидное преимущество → >>1396756 Впрочем, я тестировал очень специфичный use-case (преобразование PNG в WebM), да и 8bit dithering не хуже результат даёт. Обычное перекодирование градиентов из yuv420p не пробовал.
Кстати, говорят что в VP10 будет 12бит по умолчанию и что это таки сказывается на качестве:
23:45 <+TD-Linux> I should mention also, of the 10% gains that VP10 has, 3-4% are just due to always using 12(?)bit
23:46 < q> Does VP10 support 12bit mode only?
23:54 <+TD-Linux> that figure was running it so
>Не, задача была в сравнении сжатия с потерями с тем же средним битрейтом
Ну тогда здесь по идее никаких особых проблем быть не должно, обычное перекодирование и сравнение по скриншотам. Битность исходника даже не важна. Я думал нужно проверить чистое отличие 10бит от 8бит, по максимуму сохраняя остальные детали («как можно меньше потерять при конвертации из H.264 в VP9»).
>Пока что очевидных преимуществ использования десятибитного формата вместо восьмибитного не обнаружено
Ну на градиентах по мне так очевидное преимущество → >>1396756 Впрочем, я тестировал очень специфичный use-case (преобразование PNG в WebM), да и 8bit dithering не хуже результат даёт. Обычное перекодирование градиентов из yuv420p не пробовал.
Кстати, говорят что в VP10 будет 12бит по умолчанию и что это таки сказывается на качестве:
23:45 <+TD-Linux> I should mention also, of the 10% gains that VP10 has, 3-4% are just due to always using 12(?)bit
23:46 < q> Does VP10 support 12bit mode only?
23:54 <+TD-Linux> that figure was running it so
Вопрос к специалистам: как можно просто без регистрации и смс обрезать все чёрные кадры в начале, чтобы на превьюшку попадал первый не пустой?
6125 Кб, Webm
>>1397675
Полсекунды от начала обрежь, если с ютуба скачал, и не еби мозги.
Можно отдельный кадр с превью добавить, если чернота слишком долгая в начале, чтобы часть звука не терять при ее обрезании.
Полсекунды от начала обрежь, если с ютуба скачал, и не еби мозги.
Можно отдельный кадр с превью добавить, если чернота слишком долгая в начале, чтобы часть звука не терять при ее обрезании.
>>1397675
WebMaster так делает по умолчанию: https://github.com/pituz/webm-thread/blob/master/tools/WebMaster#L158
WebMaster так делает по умолчанию: https://github.com/pituz/webm-thread/blob/master/tools/WebMaster#L158
>>1397688
Почему бы просто макабу не поправить, чтобы превью генерировалось из кадра посередине видео, как на всех нормальных бордах и видео-хостингах? Я фигею с этих костылей, конечно, как вообще можно было додуматься так сделать и ничего после этого не менять. Или поставить 20MiB лимит в /b/, а в тематике так и оставить мизерный 6. Так вообще пропадает всякое желание что-то оптимизировать, если можно просто дикий битрейт вфигачить; при этом эта работа по сути одноразова, т.к. на другую борду уже не перепостить. Хотя б 12-16 везде, ещё куда бы ни шло. Или 8 для совместимости с 8chan.
Заодно и H.265 разрешить, давно уж пора. Это было бы куда продуктивнее вколачивания бешеных лимитов — появилось бы некоторая конкуренция между VP9 и H.265 пользователями, что могло бы привести к выработке более эффективных гайдов.
Почему бы просто макабу не поправить, чтобы превью генерировалось из кадра посередине видео, как на всех нормальных бордах и видео-хостингах? Я фигею с этих костылей, конечно, как вообще можно было додуматься так сделать и ничего после этого не менять. Или поставить 20MiB лимит в /b/, а в тематике так и оставить мизерный 6. Так вообще пропадает всякое желание что-то оптимизировать, если можно просто дикий битрейт вфигачить; при этом эта работа по сути одноразова, т.к. на другую борду уже не перепостить. Хотя б 12-16 везде, ещё куда бы ни шло. Или 8 для совместимости с 8chan.
Заодно и H.265 разрешить, давно уж пора. Это было бы куда продуктивнее вколачивания бешеных лимитов — появилось бы некоторая конкуренция между VP9 и H.265 пользователями, что могло бы привести к выработке более эффективных гайдов.
>>1397858
Предсказуемость сломается. Нахуй нужно.
Какие браузеры его поддерживают?
> Почему бы просто макабу не поправить, чтобы превью генерировалось из кадра посередине видео
Предсказуемость сломается. Нахуй нужно.
> Заодно и H.265 разрешить, давно уж пора.
Какие браузеры его поддерживают?
>>1397941
Что это значит?
Нужно чтобы превью соответствовало содержимому, без специальных костылей и подпорок. Ладно бы это была распространённая практика, так данное решение это уникальный сосач-only идиотизм. У тебя аргумент уровня утки. Давай будем при генерации превью для изображения брать первые 200x200 пикселей. Что, не осилишь ImageMagick-скрипт накорябать?
Firefox в Linux играет с соответствующими gstreamer-плагинами. https://github.com/strukturag/gstreamer-libde265 для H.265, для MP4/AAC то же, что и в случае H.264. Только что проверил — всё работает, только с цветами налажал. Но у меня и на совершенно нормальных VP9 yuv444p цвета ехали, так что здесь в чём-то другом проблема.
Для Windows и Mac DivX плагин — http://labs.divx.com/node/127923 Может ещё какие плагины поддерживают, типа того же VLC. Вы же для 10bit ставите плагины, в чём проблема для H.265 тоже поставить?
>Предсказуемость сломается.
Что это значит?
>Нахуй нужно.
Нужно чтобы превью соответствовало содержимому, без специальных костылей и подпорок. Ладно бы это была распространённая практика, так данное решение это уникальный сосач-only идиотизм. У тебя аргумент уровня утки. Давай будем при генерации превью для изображения брать первые 200x200 пикселей. Что, не осилишь ImageMagick-скрипт накорябать?
>Какие браузеры его поддерживают?
Firefox в Linux играет с соответствующими gstreamer-плагинами. https://github.com/strukturag/gstreamer-libde265 для H.265, для MP4/AAC то же, что и в случае H.264. Только что проверил — всё работает, только с цветами налажал. Но у меня и на совершенно нормальных VP9 yuv444p цвета ехали, так что здесь в чём-то другом проблема.
Для Windows и Mac DivX плагин — http://labs.divx.com/node/127923 Может ещё какие плагины поддерживают, типа того же VLC. Вы же для 10bit ставите плагины, в чём проблема для H.265 тоже поставить?
>>1397981
Теперь для всего ставить васяноплагины? Нахуй не надо. Тем более как их загружать? Абу пришлось бы разрешить загрузку не только вебмок, а и других контейнеров под 265, короче ебли дохуя, толку нихуя.
Теперь для всего ставить васяноплагины? Нахуй не надо. Тем более как их загружать? Абу пришлось бы разрешить загрузку не только вебмок, а и других контейнеров под 265, короче ебли дохуя, толку нихуя.
>>1397981
Значит, что ты не сможешь сделать вебмку с определённым превью. А если и сможешь, то только путём впихивания кадра в середину видеоряда, что может нарушить целостность его восприятия.
Сейчас это лежит целиком на плечах создателя вебмки — он может выбрать для превью тот кадр, который по его мнению лучше всего укажет на содержимое.
Их ставят единицы. А макаке, я полагаю, нужно чтобы работало у большинства.
А ещё патентные отчисления за форматы. Неизвестно, где находится хостинг, и нужно ли там их платить.
> Что это значит?
Значит, что ты не сможешь сделать вебмку с определённым превью. А если и сможешь, то только путём впихивания кадра в середину видеоряда, что может нарушить целостность его восприятия.
> Нужно чтобы превью соответствовало содержимому
Сейчас это лежит целиком на плечах создателя вебмки — он может выбрать для превью тот кадр, который по его мнению лучше всего укажет на содержимое.
> Вы же для 10bit ставите плагины, в чём проблема для H.265 тоже поставить?
Их ставят единицы. А макаке, я полагаю, нужно чтобы работало у большинства.
А ещё патентные отчисления за форматы. Неизвестно, где находится хостинг, и нужно ли там их платить.
>>1397989
Скоро и нативно будет, тем более на Windows/Mac (кстати, в Safari может уже работает, они это любят). H.264 ж везде нативно, хоть и тоже патентованный. В случае Linux вообще никакой разницы не вижу, для H.264 и сейчас надо пакет ставить.
Ну и? MP4 контейнер даже более популярен, чем WebM в HTML5 video, в IE/Safari только он и поддерживается. На некоторых чанах MP4/H.264/AAC уже разрешены. Соответственно, всего лишь добавить в разрешённые ещё один видео-кодек.
Бенчмарки/сравнения читал? H.265 процентов на 15 эффективнее, чем VP9. А VP9 иногда и H.264 сливает, особенно при больших bpp.
>>1398004
И кому это надо? Ты понимаешь, что вставляя левый кадр в первую секунды видео, ты таким образом нарушаешь его визуальное восприятие? И что обычное среднее видео, сделанное без применения костылей, будет часто иметь кривое превью? Ещё раз говорю — так больше никто не делает, насколько я заню. Т.е. поддержки никакой в инструментах нет, ровно как и смысла так делать. Опять же, см. мою аналогию с обычной картинкой.
Если действительно надо и делать по-нормальному, то нужно брать первый кадр из второго видео-потока. Только что проверил — WebM с двумя видео-дорожками отлично создаются и играются в Firefox. В общем, ты меня совсем не убедил своими ретроспективными объяснениями. А ведь всё дело в лени/криворукости программера двача и ты это прекрасно понимаешь.
WebM не играются в IE и Safari. Так что как минимум MP4/H.264/AAC поддержка также должно присутствовать. H.264 иногда более оправдан, чем VP9, кстати. На больших bpp он способен намного быстрее приблизиться к pixel perfect.
Серьёзно их воспринимают только в США → https://en.wikipedia.org/wiki/Software_patent#Jurisdictions Там, где хостится двач, с учётом специфики борды, уверен, что на них уверенно кладут. Да и не тот масштаб, чтобы кто-то начал этим троллить, это ж не стриминг уровня ютуба или нетфликса.
>>1398021
Типо hot topic! Хотя, мне тоже не очень нравится, 2к-постовые треды очень тяжело ворочаются, особенно с включёнными скриптами. Много 500-постовых было бы лучше.
>Теперь для всего ставить васяноплагины?
Скоро и нативно будет, тем более на Windows/Mac (кстати, в Safari может уже работает, они это любят). H.264 ж везде нативно, хоть и тоже патентованный. В случае Linux вообще никакой разницы не вижу, для H.264 и сейчас надо пакет ставить.
>Абу пришлось бы разрешить загрузку не только вебмок, а и других контейнеров под 265
Ну и? MP4 контейнер даже более популярен, чем WebM в HTML5 video, в IE/Safari только он и поддерживается. На некоторых чанах MP4/H.264/AAC уже разрешены. Соответственно, всего лишь добавить в разрешённые ещё один видео-кодек.
>толку нихуя
Бенчмарки/сравнения читал? H.265 процентов на 15 эффективнее, чем VP9. А VP9 иногда и H.264 сливает, особенно при больших bpp.
>>1398004
>Значит, что ты не сможешь сделать вебмку с определённым превью
>Сейчас это лежит целиком на плечах создателя вебмки
И кому это надо? Ты понимаешь, что вставляя левый кадр в первую секунды видео, ты таким образом нарушаешь его визуальное восприятие? И что обычное среднее видео, сделанное без применения костылей, будет часто иметь кривое превью? Ещё раз говорю — так больше никто не делает, насколько я заню. Т.е. поддержки никакой в инструментах нет, ровно как и смысла так делать. Опять же, см. мою аналогию с обычной картинкой.
Если действительно надо и делать по-нормальному, то нужно брать первый кадр из второго видео-потока. Только что проверил — WebM с двумя видео-дорожками отлично создаются и играются в Firefox. В общем, ты меня совсем не убедил своими ретроспективными объяснениями. А ведь всё дело в лени/криворукости программера двача и ты это прекрасно понимаешь.
>А макаке, я полагаю, нужно чтобы работало у большинства
WebM не играются в IE и Safari. Так что как минимум MP4/H.264/AAC поддержка также должно присутствовать. H.264 иногда более оправдан, чем VP9, кстати. На больших bpp он способен намного быстрее приблизиться к pixel perfect.
>А ещё патентные отчисления за форматы. Неизвестно, где находится хостинг, и нужно ли там их платить.
Серьёзно их воспринимают только в США → https://en.wikipedia.org/wiki/Software_patent#Jurisdictions Там, где хостится двач, с учётом специфики борды, уверен, что на них уверенно кладут. Да и не тот масштаб, чтобы кто-то начал этим троллить, это ж не стриминг уровня ютуба или нетфликса.
>>1398021
Типо hot topic! Хотя, мне тоже не очень нравится, 2к-постовые треды очень тяжело ворочаются, особенно с включёнными скриптами. Много 500-постовых было бы лучше.
>>1397989
Скоро и нативно будет, тем более на Windows/Mac (кстати, в Safari может уже работает, они это любят). H.264 ж везде нативно, хоть и тоже патентованный. В случае Linux вообще никакой разницы не вижу, для H.264 и сейчас надо пакет ставить.
Ну и? MP4 контейнер даже более популярен, чем WebM в HTML5 video, в IE/Safari только он и поддерживается. На некоторых чанах MP4/H.264/AAC уже разрешены. Соответственно, всего лишь добавить в разрешённые ещё один видео-кодек.
Бенчмарки/сравнения читал? H.265 процентов на 15 эффективнее, чем VP9. А VP9 иногда и H.264 сливает, особенно при больших bpp.
>>1398004
И кому это надо? Ты понимаешь, что вставляя левый кадр в первую секунды видео, ты таким образом нарушаешь его визуальное восприятие? И что обычное среднее видео, сделанное без применения костылей, будет часто иметь кривое превью? Ещё раз говорю — так больше никто не делает, насколько я заню. Т.е. поддержки никакой в инструментах нет, ровно как и смысла так делать. Опять же, см. мою аналогию с обычной картинкой.
Если действительно надо и делать по-нормальному, то нужно брать первый кадр из второго видео-потока. Только что проверил — WebM с двумя видео-дорожками отлично создаются и играются в Firefox. В общем, ты меня совсем не убедил своими ретроспективными объяснениями. А ведь всё дело в лени/криворукости программера двача и ты это прекрасно понимаешь.
WebM не играются в IE и Safari. Так что как минимум MP4/H.264/AAC поддержка также должно присутствовать. H.264 иногда более оправдан, чем VP9, кстати. На больших bpp он способен намного быстрее приблизиться к pixel perfect.
Серьёзно их воспринимают только в США → https://en.wikipedia.org/wiki/Software_patent#Jurisdictions Там, где хостится двач, с учётом специфики борды, уверен, что на них уверенно кладут. Да и не тот масштаб, чтобы кто-то начал этим троллить, это ж не стриминг уровня ютуба или нетфликса.
>>1398021
Типо hot topic! Хотя, мне тоже не очень нравится, 2к-постовые треды очень тяжело ворочаются, особенно с включёнными скриптами. Много 500-постовых было бы лучше.
>Теперь для всего ставить васяноплагины?
Скоро и нативно будет, тем более на Windows/Mac (кстати, в Safari может уже работает, они это любят). H.264 ж везде нативно, хоть и тоже патентованный. В случае Linux вообще никакой разницы не вижу, для H.264 и сейчас надо пакет ставить.
>Абу пришлось бы разрешить загрузку не только вебмок, а и других контейнеров под 265
Ну и? MP4 контейнер даже более популярен, чем WebM в HTML5 video, в IE/Safari только он и поддерживается. На некоторых чанах MP4/H.264/AAC уже разрешены. Соответственно, всего лишь добавить в разрешённые ещё один видео-кодек.
>толку нихуя
Бенчмарки/сравнения читал? H.265 процентов на 15 эффективнее, чем VP9. А VP9 иногда и H.264 сливает, особенно при больших bpp.
>>1398004
>Значит, что ты не сможешь сделать вебмку с определённым превью
>Сейчас это лежит целиком на плечах создателя вебмки
И кому это надо? Ты понимаешь, что вставляя левый кадр в первую секунды видео, ты таким образом нарушаешь его визуальное восприятие? И что обычное среднее видео, сделанное без применения костылей, будет часто иметь кривое превью? Ещё раз говорю — так больше никто не делает, насколько я заню. Т.е. поддержки никакой в инструментах нет, ровно как и смысла так делать. Опять же, см. мою аналогию с обычной картинкой.
Если действительно надо и делать по-нормальному, то нужно брать первый кадр из второго видео-потока. Только что проверил — WebM с двумя видео-дорожками отлично создаются и играются в Firefox. В общем, ты меня совсем не убедил своими ретроспективными объяснениями. А ведь всё дело в лени/криворукости программера двача и ты это прекрасно понимаешь.
>А макаке, я полагаю, нужно чтобы работало у большинства
WebM не играются в IE и Safari. Так что как минимум MP4/H.264/AAC поддержка также должно присутствовать. H.264 иногда более оправдан, чем VP9, кстати. На больших bpp он способен намного быстрее приблизиться к pixel perfect.
>А ещё патентные отчисления за форматы. Неизвестно, где находится хостинг, и нужно ли там их платить.
Серьёзно их воспринимают только в США → https://en.wikipedia.org/wiki/Software_patent#Jurisdictions Там, где хостится двач, с учётом специфики борды, уверен, что на них уверенно кладут. Да и не тот масштаб, чтобы кто-то начал этим троллить, это ж не стриминг уровня ютуба или нетфликса.
>>1398021
Типо hot topic! Хотя, мне тоже не очень нравится, 2к-постовые треды очень тяжело ворочаются, особенно с включёнными скриптами. Много 500-постовых было бы лучше.
>>1397981
Лол. Я его ставил, так он здесь не заработал из-за https. Да и vp9 он играл плохо.
>типа того же VLC
Лол. Я его ставил, так он здесь не заработал из-за https. Да и vp9 он играл плохо.
>>1398025
Клепальщикам вебмок для сосача, кому ещё.
Если кадр вставляется в середину видеоряда, его восприятие нарушается значительно сильнее.
Кроме того, кадр для превью можно вставлять отдельной дорожкой, тогда его при воспроизведении вообще не будет видно.
Обычное среднее видео не влезет в лимит 6мб.
Потому что у порноблядей нет культуры лепки вебм, вестимо.
https://github.com/pituz/webm-thread/blob/master/tools/add-preview
Скрипт по ссылке выше так и делает. Используется особенность ffmpeg: он считает дефолтной видеодорожку с большим разрешением.
Ну да, надо бы перекатывать на тысячном посте где-то.
> И кому это надо?
Клепальщикам вебмок для сосача, кому ещё.
> Ты понимаешь, что вставляя левый кадр в первую секунды видео, ты таким образом нарушаешь его визуальное восприятие?
Если кадр вставляется в середину видеоряда, его восприятие нарушается значительно сильнее.
Кроме того, кадр для превью можно вставлять отдельной дорожкой, тогда его при воспроизведении вообще не будет видно.
> И что обычное среднее видео, сделанное без применения костылей, будет часто иметь кривое превью?
Обычное среднее видео не влезет в лимит 6мб.
> Ещё раз говорю — так больше никто не делает, насколько я заню.
Потому что у порноблядей нет культуры лепки вебм, вестимо.
> поддержки никакой в инструментах нет
https://github.com/pituz/webm-thread/blob/master/tools/add-preview
> Если действительно надо и делать по-нормальному, то нужно брать первый кадр из второго видео-потока.
Скрипт по ссылке выше так и делает. Используется особенность ffmpeg: он считает дефолтной видеодорожку с большим разрешением.
> 2к-постовые треды очень тяжело ворочаются, особенно с включёнными скриптами
Ну да, надо бы перекатывать на тысячном посте где-то.
>>1398026
Это зависит от фазы луны отношения к твоему айпишнику клаудфлары: если она пускает без куков и javascript-защиты, то всё работает.
А вообще да: то, что vlc не может использовать браузер для получения контента и вместо этого сам ебётся со ссылкой, портит всю малину.
> Я его ставил, так он здесь не заработал из-за https.
Это зависит от фазы луны отношения к твоему айпишнику клаудфлары: если она пускает без куков и javascript-защиты, то всё работает.
А вообще да: то, что vlc не может использовать браузер для получения контента и вместо этого сам ебётся со ссылкой, портит всю малину.
>>1398047
Не, я не предлагал так делать. Просто кадр из середине намного чаще передаёт суть видео, чем первый.
Ну не скажи. С ютуба вон можно скачать часто простые клипы в подходящем размере, если youtube-dl нужный формат задать. Или вырезать через -c copy очень ок, чтобы не было потерь от лишней перекодировки.
Я имею ввиду не сделанных специально под сосач.
Ну вот так ещё норм. Хитрый workaround, однако. А фигли тогда во всех инструкциях к началу кадр прилепляется? (Кстати, никто не пробовал ещё выебать макаку через buffer overflow в ffmpeg? Как минимум крашей полно было.)
>>1398060
Я большинство webm через mpv смотрю, почти всегда напрямую проигрывается. Вообще, странно ставить обычную статику под защиту от ботов. Отдельный домен и CDN для этого используется. Вон как на форчане. Опять всё не как у людей.
>Если кадр вставляется в середину видеоряда, его восприятие нарушается значительно сильнее.
Не, я не предлагал так делать. Просто кадр из середине намного чаще передаёт суть видео, чем первый.
>Обычное среднее видео не влезет в лимит 6мб.
Ну не скажи. С ютуба вон можно скачать часто простые клипы в подходящем размере, если youtube-dl нужный формат задать. Или вырезать через -c copy очень ок, чтобы не было потерь от лишней перекодировки.
>>поддержки никакой в инструментах нет
Я имею ввиду не сделанных специально под сосач.
>Скрипт по ссылке выше так и делает. Используется особенность ffmpeg: он считает дефолтной видеодорожку с большим разрешением.
Ну вот так ещё норм. Хитрый workaround, однако. А фигли тогда во всех инструкциях к началу кадр прилепляется? (Кстати, никто не пробовал ещё выебать макаку через buffer overflow в ffmpeg? Как минимум крашей полно было.)
>>1398060
Я большинство webm через mpv смотрю, почти всегда напрямую проигрывается. Вообще, странно ставить обычную статику под защиту от ботов. Отдельный домен и CDN для этого используется. Вон как на форчане. Опять всё не как у людей.
>>1398083
Потому что было лень написать. А ещё вторая видеодорожка — это нарушение спецификации формата: положено делать только одну.
> А фигли тогда во всех инструкциях к началу кадр прилепляется?
Потому что было лень написать. А ещё вторая видеодорожка — это нарушение спецификации формата: положено делать только одну.
>>1398266
Пруф? Я перед тем как предыдущее сообщение написать, бегло просмотрел спеки и явного запрета не нашёл:
http://www.webmproject.org/docs/container/
https://w3c.github.io/media-source/webm-byte-stream-format.html
http://wiki.webmproject.org/webm-metadata/global-metadata
Зато есть ряд вещей, подразумевающих, что так делать можно — структура Track, описания полей и т.д.:
http://www.webmproject.org/docs/container/#track
К тому же ни ffmpeg, ни Firefox никаких недовольств не выказывают от подобных файлов.
Хотя это, конечно, курам на смех, а не документация.
>А ещё вторая видеодорожка — это нарушение спецификации формата: положено делать только одну
Пруф? Я перед тем как предыдущее сообщение написать, бегло просмотрел спеки и явного запрета не нашёл:
http://www.webmproject.org/docs/container/
https://w3c.github.io/media-source/webm-byte-stream-format.html
http://wiki.webmproject.org/webm-metadata/global-metadata
Зато есть ряд вещей, подразумевающих, что так делать можно — структура Track, описания полей и т.д.:
http://www.webmproject.org/docs/container/#track
К тому же ни ffmpeg, ни Firefox никаких недовольств не выказывают от подобных файлов.
Хотя это, конечно, курам на смех, а не документация.
>>1398331
Я это встречал то ли в педивикии, то ли по первой ссылке из твоего списка, но теперь там этого нет. Нагуглилось только https://groups.google.com/a/webmproject.org/forum/#!topic/webm-discuss/J8xN-Fc2rAQ .
Наследие матрёшки же. Но похоже, действительно, от идеи ограничить кол-во дорожек разработчики ушли.
Я это встречал то ли в педивикии, то ли по первой ссылке из твоего списка, но теперь там этого нет. Нагуглилось только https://groups.google.com/a/webmproject.org/forum/#!topic/webm-discuss/J8xN-Fc2rAQ .
> Зато есть ряд вещей, подразумевающих, что так делать можно — структура Track, описания полей и т.д
Наследие матрёшки же. Но похоже, действительно, от идеи ограничить кол-во дорожек разработчики ушли.
Пацаны, а есть способ качать видео с ютуба в рам и смотреть через мплеер? прям как браузер делает.
test
ГОВНОЕДЫ СОСНУЛИ ХУЙЦА
49 Кб, Webm
>>1398988
Что ты с моей вебмкой сделал, ирод? Даже я так над ней не издевался!
Что ты с моей вебмкой сделал, ирод? Даже я так над ней не издевался!
test
>>1399041
Скорее всего ненулевой профиль у VP9. Хром на таких падает, это известный факт.
Скорее всего ненулевой профиль у VP9. Хром на таких падает, это известный факт.
>>1399050
Yе только в падении хрома было дело.
там был html вместо webm
[code] <!doctype html><html itemscope="" itemtype="http://schema.org/WebPage" lang="en-RU"><head><meta content="/images/branding/googleg/1x/googleg_standard_color_128dp.png" itemprop="image"><link href="/images/branding/product/ico/googleg_lodp.ico" rel="shortcut icon"><meta content="origin" id="mref" name="referrer"><title>Google</title> <script>(function(){window.google={kEI:'_mcAVtA9goDMA_KauJgE',kEXPI:'3700062,3700325,4029815,4031109,4031139,4032235,4032500,4032678,4033307,4033344,4034882,4036527,4037333,4037569,4037934,4037962,4037964,4038012,4038214,4039747,4040676,4041440,4041507,4041776,4041835,4041897,4042158,4042180,4043255,4043411,4043439,4043440,4043491,4043564,4043568,4043596,4044246,4044339,4044593,4044606,4044854,4044938,4045003,4045413,4045631,4045717,4045841,4045872,4046043,4046059,4046080,4046121,4046304,4046340,4046606,4046803,4046835,4046837,4046904,4047530,4047593,4047599,4047601,4047667,4047914,4048125,8300199,8300202,8501987,8501992,8502157,10200083',authuser:0,j:{en:1,bv:21,pm:'p',u:'2cca1ae4',qbp:0,rre:false},kscs:'2cca1ae4_21'};google.kHL='en-RU';})();(function(){google.lc=[];google.li=0;google.getEI=function(a){for(var b;a&&(!a.getAttribute||!(b=a.getAttribute("eid")));)a=a.parentNode;return "2048" =function(a){this.w=_.mm.R();this.o=a};_.pm.prototype.b=function(a,c){"t"==_.om(this.w)?(_.T(a,"gb_V"),c?(_.S(a,"gb_Ra"),_.T(a,"gb_Zd")):(_.S(a,"gb_Zd"),_.T(a,"gb_Ra"))):_.Rg(a, [/code]
Yе только в падении хрома было дело.
там был html вместо webm
[code] <!doctype html><html itemscope="" itemtype="http://schema.org/WebPage" lang="en-RU"><head><meta content="/images/branding/googleg/1x/googleg_standard_color_128dp.png" itemprop="image"><link href="/images/branding/product/ico/googleg_lodp.ico" rel="shortcut icon"><meta content="origin" id="mref" name="referrer"><title>Google</title> <script>(function(){window.google={kEI:'_mcAVtA9goDMA_KauJgE',kEXPI:'3700062,3700325,4029815,4031109,4031139,4032235,4032500,4032678,4033307,4033344,4034882,4036527,4037333,4037569,4037934,4037962,4037964,4038012,4038214,4039747,4040676,4041440,4041507,4041776,4041835,4041897,4042158,4042180,4043255,4043411,4043439,4043440,4043491,4043564,4043568,4043596,4044246,4044339,4044593,4044606,4044854,4044938,4045003,4045413,4045631,4045717,4045841,4045872,4046043,4046059,4046080,4046121,4046304,4046340,4046606,4046803,4046835,4046837,4046904,4047530,4047593,4047599,4047601,4047667,4047914,4048125,8300199,8300202,8501987,8501992,8502157,10200083',authuser:0,j:{en:1,bv:21,pm:'p',u:'2cca1ae4',qbp:0,rre:false},kscs:'2cca1ae4_21'};google.kHL='en-RU';})();(function(){google.lc=[];google.li=0;google.getEI=function(a){for(var b;a&&(!a.getAttribute||!(b=a.getAttribute("eid")));)a=a.parentNode;return "2048" =function(a){this.w=_.mm.R();this.o=a};_.pm.prototype.b=function(a,c){"t"==_.om(this.w)?(_.T(a,"gb_V"),c?(_.S(a,"gb_Ra"),_.T(a,"gb_Zd")):(_.S(a,"gb_Zd"),_.T(a,"gb_Ra"))):_.Rg(a, [/code]
>>1399058
весь не помещается.
весь не помещается.
180 Кб, Webm
>>1395791 (OP)
а ну ка ся
а ну ка ся
180 Кб, Webm
>>1395791 (OP)
а ну ка ся
а ну ка ся
Пасаны - https://2ch.hk/b/res/102347348.html здесь вента-опущенка говорит что пинукс спизжен у гавно-мака. обоснуйте ему плес.
Кто пробовал, что из нелинейных видео-редакторов под *nix самое вменяемое?
Слышал вот про эти, что вроде как работают:
Avidemux
Blender VSE
Cinelerra
Kdenlive
Kino
OpenShot
Pitivi
и т.д. https://en.wikipedia.org/wiki/List_of_video_editing_software#Free_and_open-source
, но интересует что-нибудь уровня Vegas хотя бы, не только простая нарезка. Была надежда на Lightworks, но они прокатили, похоже, за 5 лет так ничего и не сделали.
Слышал вот про эти, что вроде как работают:
Avidemux
Blender VSE
Cinelerra
Kdenlive
Kino
OpenShot
Pitivi
и т.д. https://en.wikipedia.org/wiki/List_of_video_editing_software#Free_and_open-source
, но интересует что-нибудь уровня Vegas хотя бы, не только простая нарезка. Была надежда на Lightworks, но они прокатили, похоже, за 5 лет так ничего и не сделали.
>>1400185
Точнее Lightworks зарелизилась под Linux недавно:
http://www.lwks.com/index.php?option=com_lwks&view=download&Itemid=206&tab=1
https://www.youtube.com/watch?v=3lG0vLQCF7k
Но без сорцов и упрощённая версия.
Точнее Lightworks зарелизилась под Linux недавно:
http://www.lwks.com/index.php?option=com_lwks&view=download&Itemid=206&tab=1
https://www.youtube.com/watch?v=3lG0vLQCF7k
Но без сорцов и упрощённая версия.
>>1400243
Ещё в ней нельзя экспортировать лосслесс, только пожатый встроенным кодеком H.264 с ограничением по разрешению. Фигня, короче.
Ещё в ней нельзя экспортировать лосслесс, только пожатый встроенным кодеком H.264 с ограничением по разрешению. Фигня, короче.
>>1396070
Подожди, помершелл ведь не умеет exe открывать из-за каких-то политик безопасности. Как ты это сделал?
Подожди, помершелл ведь не умеет exe открывать из-за каких-то политик безопасности. Как ты это сделал?
>>1400185
Что конкретно нужно? Всякие эффекты?
Бери редакторы на фреймворке MLT (kdenlive, shotcut). Если их возможностей мало — пробуй blender.
Что конкретно нужно? Всякие эффекты?
Бери редакторы на фреймворке MLT (kdenlive, shotcut). Если их возможностей мало — пробуй blender.
>>1400670
Хоспади одни негры и белые бабы с неграми. Как же американцы заебали с насаждением белых баб на черные хуи.
Хоспади одни негры и белые бабы с неграми. Как же американцы заебали с насаждением белых баб на черные хуи.
>>1400737
Ну да. Эффекты, маски, слои и т.д. Большинство программ из того списка, судя по скриншотам, что-то на уровне Movie Maker.
Вот, кстати, ещё интересно: https://en.wikipedia.org/wiki/AviSynth#AviSynth_for_non-Windows_operating_systems AviSynth с открытыми исходниками, так что зашквара нет.
Печально, что практически все гайды пишутся под платную проприетарщину типо After Effects и скрипты на AviSynth.
Ну да. Эффекты, маски, слои и т.д. Большинство программ из того списка, судя по скриншотам, что-то на уровне Movie Maker.
Вот, кстати, ещё интересно: https://en.wikipedia.org/wiki/AviSynth#AviSynth_for_non-Windows_operating_systems AviSynth с открытыми исходниками, так что зашквара нет.
Печально, что практически все гайды пишутся под платную проприетарщину типо After Effects и скрипты на AviSynth.
>>1400761
Ты не скриншоты смотри, а списки фич.
Практически все плагины из AviSynth уже портированы на AvxSynth.
> Большинство программ из того списка, судя по скриншотам, что-то на уровне Movie Maker.
Ты не скриншоты смотри, а списки фич.
> Вот, кстати, ещё интересно: https://en.wikipedia.org/wiki/AviSynth#AviSynth_for_non-Windows_operating_systems
Практически все плагины из AviSynth уже портированы на AvxSynth.
>>1400771
Так я и спросил, кто что использовал. Список фич не показатель.
Чего-то он дохлый какой-то, судя по активности. Да и поведение слегка отличается от вендового + оптимизаций мало:
https://github.com/avxsynth/avxsynth/wiki/Built-in-Functions
>Ты не скриншоты смотри, а списки фич
Так я и спросил, кто что использовал. Список фич не показатель.
>уже портированы на AvxSynth
Чего-то он дохлый какой-то, судя по активности. Да и поведение слегка отличается от вендового + оптимизаций мало:
https://github.com/avxsynth/avxsynth/wiki/Built-in-Functions
>>1400790
Тыкал я всё из твоего списка, использовал же только kdenlive и немного blender.
Другое дело, что я мувимэйкер и вегас, на которые ты ссылаешься, ни разу не видел.
С хуя ли?
> Так я и спросил, кто что использовал.
Тыкал я всё из твоего списка, использовал же только kdenlive и немного blender.
Другое дело, что я мувимэйкер и вегас, на которые ты ссылаешься, ни разу не видел.
> Список фич не показатель.
С хуя ли?
332 Кб, 818x977
Посоны, поясните за -deadline 0, какие профиты(видео кодируется оч долго,заебало)?
>>1400790
Кстати, вспомнил. Неплохой кроссплатформенный аналог AviSynth — VapourSynth. Выглядит намного живее чем AvxSynth, его даже mpv умеет. С ffmpeg, правда, только через пайп. Может пригодиться если фильтров ffmpeg не хватит (тот же dithering при PNG→YUV надо в нём проверить).
Почитал обзоры, Kdenlive, Shotcut и Blender VSE действительно выглядят самыми вменяемыми. Буду пробовать.
>>1401282
Теоретически может дать чуть лучше качество при том же битрейте, но не рекомендуется в том числе даже разработчиками.
См. http://www.webmproject.org/docs/encoder-parameters/#2-encode-quality-vs-speed
Сэнкоди с --best и с --good сам разные видео, сделай сравнение по скриншотам и метрикам, всем будет интересно (серьёзно).
Кстати, вспомнил. Неплохой кроссплатформенный аналог AviSynth — VapourSynth. Выглядит намного живее чем AvxSynth, его даже mpv умеет. С ffmpeg, правда, только через пайп. Может пригодиться если фильтров ffmpeg не хватит (тот же dithering при PNG→YUV надо в нём проверить).
Почитал обзоры, Kdenlive, Shotcut и Blender VSE действительно выглядят самыми вменяемыми. Буду пробовать.
>>1401282
Теоретически может дать чуть лучше качество при том же битрейте, но не рекомендуется в том числе даже разработчиками.
См. http://www.webmproject.org/docs/encoder-parameters/#2-encode-quality-vs-speed
Сэнкоди с --best и с --good сам разные видео, сделай сравнение по скриншотам и метрикам, всем будет интересно (серьёзно).
133 Кб, 850x888
>>1401289
frame= 77 fps=0.0 q=0.0 size= 418kB time=00:00:02.79 bitrate=1225.6kbits/s
Блеать, уже ебаных пол часа!
>Сэнкоди с --best
frame= 77 fps=0.0 q=0.0 size= 418kB time=00:00:02.79 bitrate=1225.6kbits/s
Блеать, уже ебаных пол часа!
>>1401282
Вот для примера.
Кодировались обе так (первый проход такой же, как и второй, только заменен номер потока и выходной файл):
ffmpeg -ss 25:43.125 -i input.mkv -t 128.875 -map 0:v -vf scale=1280:-1:flags=lanczos -c:v vp9 -pix_fmt +yuv420p -b:v 540k -auto-alt-ref 1 -lag-in-frames 25 -frame-parallel 0 -tile-columns 0 -pass 1 -quality good -cpu-used 0 -f null -y NULL
ffmpeg -ss 25:43.125 -i input.mkv -t 128.875 -map 0:v -vf scale=1280:-1:flags=lanczos -c:v vp9 -pix_fmt +yuv420p -b:v 540k -auto-alt-ref 1 -lag-in-frames 25 -frame-parallel 0 -tile-columns 0 -pass 1 -deadline 0 -f null -y NULL
На выходе качество внешне одинаковое, но при дедлайне 0 размер видеодорожки ощутимо меньше (в дедлайн до лимита влез -c:a libvorbis -q:a 4 и еще осталось место, а при цпуюзед 0 либворбис с 4 качеством не влез).
Выводы делай сам.
http://rghost.ru/84vXDP26S
http://rghost.ru/7L6yzp5W2
Вот для примера.
Кодировались обе так (первый проход такой же, как и второй, только заменен номер потока и выходной файл):
ffmpeg -ss 25:43.125 -i input.mkv -t 128.875 -map 0:v -vf scale=1280:-1:flags=lanczos -c:v vp9 -pix_fmt +yuv420p -b:v 540k -auto-alt-ref 1 -lag-in-frames 25 -frame-parallel 0 -tile-columns 0 -pass 1 -quality good -cpu-used 0 -f null -y NULL
ffmpeg -ss 25:43.125 -i input.mkv -t 128.875 -map 0:v -vf scale=1280:-1:flags=lanczos -c:v vp9 -pix_fmt +yuv420p -b:v 540k -auto-alt-ref 1 -lag-in-frames 25 -frame-parallel 0 -tile-columns 0 -pass 1 -deadline 0 -f null -y NULL
На выходе качество внешне одинаковое, но при дедлайне 0 размер видеодорожки ощутимо меньше (в дедлайн до лимита влез -c:a libvorbis -q:a 4 и еще осталось место, а при цпуюзед 0 либворбис с 4 качеством не влез).
Выводы делай сам.
http://rghost.ru/84vXDP26S
http://rghost.ru/7L6yzp5W2
298 Кб, 1000x724
>>1401340
Ты мерзавец.
Ты мерзавец.
38 Кб, 859x667
>>1401313
Вот я, кстати, в данный момент нулевым дедлайном, но в 4 потока с -тайл-колумнс 6, кодирую под лимит в 6 МБ.
Завтра посмотрим, что из этого получится.
Вот я, кстати, в данный момент нулевым дедлайном, но в 4 потока с -тайл-колумнс 6, кодирую под лимит в 6 МБ.
Завтра посмотрим, что из этого получится.
932 Кб, 1280x544
938 Кб, 1280x544
1106 Кб, 1280x544
1104 Кб, 1280x544
>>1401313
0:46
1:12
В каких-то случаях у --good деталей детали чуть лучше сохранились, так что тут хз даже как сравнивать. А видео-дорожка --best всего лишь 193 на килобайта меньше весит:
8046253\tbest.webm
8239733\tgood.webm
>>1401371
Кстати, тут недавно обнаружил, что некоторый софт очень не любит нечётные разрешения, а некоторые кодеки даже не поддерживают (H.264). 860x484 вроде чаще используется если нужно 480p. Или принудительно скейлить в 854x480 как на ютубе, например.
0:46
1:12
В каких-то случаях у --good деталей детали чуть лучше сохранились, так что тут хз даже как сравнивать. А видео-дорожка --best всего лишь 193 на килобайта меньше весит:
8046253\tbest.webm
8239733\tgood.webm
>>1401371
Кстати, тут недавно обнаружил, что некоторый софт очень не любит нечётные разрешения, а некоторые кодеки даже не поддерживают (H.264). 860x484 вроде чаще используется если нужно 480p. Или принудительно скейлить в 854x480 как на ютубе, например.
>>1401391
Ну это не для софта же кодируется, в софте нужно с оригиналом работать.
Кстати, на мой взгляд, делати лучше сохранились в best, так как в good над шляпой у нее размытие больше.
Да и вообще при гуд мыла побольше, как обычно при нехватке битрейта.
Вообще дедлайн 0 все же позволяет уменьшить количество квадратов при сильной нехватке битрейта, только я старые версии файлов с -cpu-used 0 не сохранил, чтобы показать в сравнении, оставил только с -deadline 0.
Ну это не для софта же кодируется, в софте нужно с оригиналом работать.
Кстати, на мой взгляд, делати лучше сохранились в best, так как в good над шляпой у нее размытие больше.
Да и вообще при гуд мыла побольше, как обычно при нехватке битрейта.
Вообще дедлайн 0 все же позволяет уменьшить количество квадратов при сильной нехватке битрейта, только я старые версии файлов с -cpu-used 0 не сохранил, чтобы показать в сравнении, оставил только с -deadline 0.
>>1401420
А засекал сколько по времени оба варианта кодируются? Я пару раз попробовал и решил что это совсем не практично. Даже tile-columns=0 на 720p всё слишком печальным делает.
>Вообще дедлайн 0 все же позволяет уменьшить количество квадратов при сильной нехватке битрейта
А засекал сколько по времени оба варианта кодируются? Я пару раз попробовал и решил что это совсем не практично. Даже tile-columns=0 на 720p всё слишком печальным делает.
>>1401452
-deadline 0 по сравнению со -speed 0 примерно в 10-20 раз дольше кодируется, в зависимости от сложности картинки и количества движения.
-deadline 0 по сравнению со -speed 0 примерно в 10-20 раз дольше кодируется, в зависимости от сложности картинки и количества движения.
Кому там нужен был AAC энкодер? Похоже встроенный ffmpeg'овский серьёзно улучшили, как это было недавно с гифками: https://www.youtube.com/watch?v=QiV60eGY11o
Уже что-то в мастере, можно собирать, тыкать.
Кстати, куча интересных видео с последнего VDD: https://www.youtube.com/playlist?list=PLQLpBN3oI7E44HIdTOovThc1MNHLchgHE
Daala, VP10, Thor, VP9 vs HEVC и т.д.
Уже что-то в мастере, можно собирать, тыкать.
Кстати, куча интересных видео с последнего VDD: https://www.youtube.com/playlist?list=PLQLpBN3oI7E44HIdTOovThc1MNHLchgHE
Daala, VP10, Thor, VP9 vs HEVC и т.д.
>>1401659
ВиртуалДаб, но я не уверен что он все еще поддерживается
ВиртуалДаб, но я не уверен что он все еще поддерживается
4185 Кб, Webm
4101 Кб, Webm
>>1401313
Первое видео без дедлайн 0. Размер видео дорожки - 3982kB.
У второго - 3898. Итого 84kB выигрыша(2.1%) за более чем 5 часов кодирования.
Первое видео без дедлайн 0. Размер видео дорожки - 3982kB.
У второго - 3898. Итого 84kB выигрыша(2.1%) за более чем 5 часов кодирования.
tst
669 Кб, 1280x720
686 Кб, 1280x720
>>1401710
Лучше в тот же размер кодируй и так, чтобы хоть в одном видео были чёткие сцены. А то и там, и там мыло, как такое сравнивать?
Впрочем, я б вообще не стал говорить, что best чем-то лучше. Вот на 1.6с, например. Да, поменьше квадратов, зато у good на волосах деталей однозначно больше. И выкладывай оригинал.
Вот, почитай: https://web.archive.org/web/20141103202912/http://x264dev.multimedia.cx/archives/472
Лучше в тот же размер кодируй и так, чтобы хоть в одном видео были чёткие сцены. А то и там, и там мыло, как такое сравнивать?
Впрочем, я б вообще не стал говорить, что best чем-то лучше. Вот на 1.6с, например. Да, поменьше квадратов, зато у good на волосах деталей однозначно больше. И выкладывай оригинал.
Вот, почитай: https://web.archive.org/web/20141103202912/http://x264dev.multimedia.cx/archives/472
>>1401731
Оригинал скачан с ютуба при помощи Savefrom plugin
https://www.youtube.com/watch?v=wVuA74sdMIw&list=PLdlYDgo7NRtb1z-viy6robuHw2Xlf75q5&index=23
MP4 720
> И выкладывай оригинал.
Оригинал скачан с ютуба при помощи Savefrom plugin
https://www.youtube.com/watch?v=wVuA74sdMIw&list=PLdlYDgo7NRtb1z-viy6robuHw2Xlf75q5&index=23
MP4 720
707 Кб, 1280x720
>>1401752
Оригинал тоже говнина полная хоть и няшечки. Но однозначно у good на волосах деталей больше осталось.
Тестируй отсюда: https://media.xiph.org/video/derf/ Или хотя бы качественные H.264 рипы бери.
Оригинал тоже говнина полная хоть и няшечки. Но однозначно у good на волосах деталей больше осталось.
Тестируй отсюда: https://media.xiph.org/video/derf/ Или хотя бы качественные H.264 рипы бери.
user agent test
user agent test 2
test user agent
1670 Кб, Webm
Есть способ посмотреть дефолтные значения параметров для установленной сборки ffmpeg?
907 Кб, 1249x1334
>>1402221
-loglevel debug добавь, большую часть напишет.
Ещё смотри https://github.com/Kagami/webm.py/wiki/Notes-on-encoding-settings#defaults и, если не хватит, раскомментируй https://chromium.googlesource.com/webm/libvpx/+/c77b1f5acd09852aff1ba09d7f371728a60634d7/vp9/vp9_cx_iface.c#492 и пересобери.
-loglevel debug добавь, большую часть напишет.
Ещё смотри https://github.com/Kagami/webm.py/wiki/Notes-on-encoding-settings#defaults и, если не хватит, раскомментируй https://chromium.googlesource.com/webm/libvpx/+/c77b1f5acd09852aff1ba09d7f371728a60634d7/vp9/vp9_cx_iface.c#492 и пересобери.
Я тут подумал, что следовало бы сравнивать -deadline 0 и -speed 0 при -b:v 0 -crf 10, например, ну и длительности пару-тройку минут.
Тогда можно было бы посмотреть сколько реально экономит дедлайн 0 при одинаковом качестве.
Тогда можно было бы посмотреть сколько реально экономит дедлайн 0 при одинаковом качестве.
>>1402267
Я это ещё в >>1401731 сказал. И в основном тестируют не при «одинаковом качестве», а при одинаковом размере, т.к. качество в двух различных энкодах будет всегда разным, это не дискретная величина как размер.
И долго не надо, Daala (и другие кодеки) тестируют на коротких (1-10 секунд) непожатых видео различного плана. Чем больше исходников, тем лучше, см. https://gist.github.com/Hupotronic/4645784#gistcomment-756444
Хромает методология совсем, короче. Можешь посмотреть записи с прошлого NetVC, там рассказывали как AWCY работает.
Я это ещё в >>1401731 сказал. И в основном тестируют не при «одинаковом качестве», а при одинаковом размере, т.к. качество в двух различных энкодах будет всегда разным, это не дискретная величина как размер.
И долго не надо, Daala (и другие кодеки) тестируют на коротких (1-10 секунд) непожатых видео различного плана. Чем больше исходников, тем лучше, см. https://gist.github.com/Hupotronic/4645784#gistcomment-756444
Хромает методология совсем, короче. Можешь посмотреть записи с прошлого NetVC, там рассказывали как AWCY работает.
Какой предел размера вебм в тематике?
Хотел сделать из .flv .webm, использовал XmediaRecode. Выставил VP9 и Opus в один проход. Проблема в том, что процесс перекодирования стопорится и не "заканчивается" практически в самом начале без явных причин. Что посоветуете?
>>1402436
Читать ОП-пост перед тем, как писать в тред
>Что посоветуете?
Читать ОП-пост перед тем, как писать в тред
>Основным обсуждаемым здесь инструментом является ffmpeg. Пердолики с мокрописечными гуями вроде xmedia recode и прочие клепальщики распидорашенного кривопиксельного говна из порнотреда со своими воплями о ненужности консоли не нужны сами — пусть сначала научатся делать качественные вебмки, а потом уже лезут сюда с советами.
>>1402442
Нужно было сделать буквально одну вебмку в /r на опознание мелодии.
Что же, как с помощью ffmpeg это сделать, причём вырезать из исходного ролика два фрагмента и слепить в один файл?
Нужно было сделать буквально одну вебмку в /r на опознание мелодии.
Что же, как с помощью ffmpeg это сделать, причём вырезать из исходного ролика два фрагмента и слепить в один файл?
>>1402442
Он где-то писал, что консолечка не нужна или поучал кого-то как кодить вебм?
Он где-то писал, что консолечка не нужна или поучал кого-то как кодить вебм?
>>1402662
Ну так тред не для него. Пусть обращается к разрабам своей мокрописьки.
Ну так тред не для него. Пусть обращается к разрабам своей мокрописьки.
Немного не в тему, а тут на дваче есть раздел или тред посвященный проге Source Filmmaker?
>>1402712
а как теперь 2ch.hk сайт называют?
Ого не ожидал, столько говна есть, а полезных тредов почти нет.
Спасибо вам хоть про ВебМки тред запилили.
а как теперь 2ch.hk сайт называют?
>нету такого треда
Ого не ожидал, столько говна есть, а полезных тредов почти нет.
Спасибо вам хоть про ВебМки тред запилили.
>>1402722
Сосач будет всё же неверным, на мой взгляд, потому что возникнет путаница с обозначением сайта в период араспоожения на 2ch.so
Сосач будет всё же неверным, на мой взгляд, потому что возникнет путаница с обозначением сайта в период араспоожения на 2ch.so
>>1402729
Как раз тогда и возник этот термин и до сих пор живёт. Сосач это прикольно. Сосать хуй это прикольно. Народу нравится.
Как раз тогда и возник этот термин и до сих пор живёт. Сосач это прикольно. Сосать хуй это прикольно. Народу нравится.
>>1402737
Мне всё же больше нравится харкач, в таком пренебрежительном сравнении с харчком на пол. И как бы олицетворение аудитории - быдлота, постоянно плюющая на пол, себе под ноги (лично меня это очень раздражает, например)
Мне всё же больше нравится харкач, в таком пренебрежительном сравнении с харчком на пол. И как бы олицетворение аудитории - быдлота, постоянно плюющая на пол, себе под ноги (лично меня это очень раздражает, например)
>>1402742
Голосую за хоркач, сосут тут мало, в основном на хуй посылают и срут везде.
Голосую за хоркач, сосут тут мало, в основном на хуй посылают и срут везде.
635 Кб, 1280x720
Набыдлокодил скрипт для mpv по типу OSD в ffdshow. Удобно для сравнения по скриншотам.
К сожалению, номер кадра и его тип так не показать, и OSC тоже не работает из-за кривости API. Накорябал небольшой враппер и для ffplay, так всё получше с доступной информацией, но сам ffplay жутко кривующий, да и скриншотить надо отдельно.
http://pastebin.com/jZKEnkkq
К сожалению, номер кадра и его тип так не показать, и OSC тоже не работает из-за кривости API. Накорябал небольшой враппер и для ffplay, так всё получше с доступной информацией, но сам ffplay жутко кривующий, да и скриншотить надо отдельно.
http://pastebin.com/jZKEnkkq
Зашел к вам в /s, почитал треды, пиздец у вас тут. Заместо политики придумали себе развлечение - сраться по поводу осей, причем в каждом ебаном треде. Я просто охуеваю с вас, люди.
>>1403279
Лолировал заливаясь хохотом от смеха с этого нового ньюфага в этом ИТТ треде.
Ты поди ещё и на сосаче не сидел, ньфажина нубская? А про тот двач вообще не слыхал? Может ты и про коробочку фотонов не в курсе, пёс шелудивый?
Лолировал заливаясь хохотом от смеха с этого нового ньюфага в этом ИТТ треде.
Ты поди ещё и на сосаче не сидел, ньфажина нубская? А про тот двач вообще не слыхал? Может ты и про коробочку фотонов не в курсе, пёс шелудивый?
>>1403283
Не на того вскукарекнул, дауненок.
Не на того вскукарекнул, дауненок.
166 Кб, 1041x595
>>1395791 (OP)
Антон, какого хуя на моем хакинтоше вместо вебма показывает вот такую поебень? Расскажи скорей, как пофиксить.
Антон, какого хуя на моем хакинтоше вместо вебма показывает вот такую поебень? Расскажи скорей, как пофиксить.
+
381 Кб, 1280x720
Забавно, не думал что VP10 хотят настолько серьёзно улучшить. Если получится, то H.265 точно хана, с его-то ценами.
364 Кб, 1280x720
>>1397652
Вот слайд.
>Кстати, говорят что в VP10 будет 12бит по умолчанию и что это таки сказывается на качестве
Вот слайд.
>>1403362
Обратитесь в сертифицированный (R) сервис (c) центр (тм)
Обратитесь в сертифицированный (R) сервис (c) центр (тм)
>>1404002
Даун репортинг ин. С большинством проблем разобрался, за исключением того, что получается музыка без картинки. Поаутирую у вас еще немного.
Даун репортинг ин. С большинством проблем разобрался, за исключением того, что получается музыка без картинки. Поаутирую у вас еще немного.
Можно ли в ffmpeg показывать только прогресс без всей этой шапки с опциями и инфой о файле?
37 Кб, 1202x706
Дрочит консоль вместо удобного интерфейса, да вы тут все ебанутые.
Xvid4psp-кун
Xvid4psp-кун
>>1404387
В консольке удобнее, быстрее и качественнее, а главное все под контролем.
В консольке удобнее, быстрее и качественнее, а главное все под контролем.
545 Кб, 1632x912
>>1404387
Чего ж не показал VP9, который наверняка с доисторической libvpx, не умеющей даже в многопоточность. Очень удобно.
Или настройки кодека на пикрелейтеда. Ты понимаешь, что здесь вообще происходит? Ты понимаешь, что он оборачивает консольный x265 хрен знает каким наобором гуёвых элементов с неизвестно насколько хорошо проставленными дефолтами? Очень удобно, наверняка, рыться за нужной опцией по сотне вкладок.
Вообще, читай >>1396973 и http://arhivach.org/thread/100617/#1243814 , уже 100 раз обсуждалось, что гуёвины неизбежно прососут, как только понадобится чуть более свежая или непредусмотренная автором возможность. И венда/линукс здесь совершенно не причём (я офигеваю с этого чёрно-белого взгляда) — все адекватные люди на венде используют консольные x264 и AviSynth и в ус не дуют. Я понимаю, что для тебя предел мечтаний это просто как-то закодировать видео, которое будет как-то проигрываться, но тред-то и не про это. Твои евангелисткие откровения здесь никого не волнуют и не удивят, все здесь постящие знакомы с наиболее популярными гуёвыми обёртками как под винду, так и под линукс, и не используют их исключительно в силу практических причин.
Вот вам, кстати, наглядный урок, как можно гуёвинами (наверняка) и небрежностью по типу предыдущего постера запороть видео:
https://github.com/mpv-player/mpv/wiki/Fixing-Simulcasts#wrong-color-range
http://screenshotcomparison.com/comparison/83071
Тоже ведь, скорее всего, в таком ключе рассуждали — зачем мне разбираться, автор гуёвины уж точно мастер своего дела и за меня всё продумал. Нажал кнопку и готово.
Чего ж не показал VP9, который наверняка с доисторической libvpx, не умеющей даже в многопоточность. Очень удобно.
Или настройки кодека на пикрелейтеда. Ты понимаешь, что здесь вообще происходит? Ты понимаешь, что он оборачивает консольный x265 хрен знает каким наобором гуёвых элементов с неизвестно насколько хорошо проставленными дефолтами? Очень удобно, наверняка, рыться за нужной опцией по сотне вкладок.
Вообще, читай >>1396973 и http://arhivach.org/thread/100617/#1243814 , уже 100 раз обсуждалось, что гуёвины неизбежно прососут, как только понадобится чуть более свежая или непредусмотренная автором возможность. И венда/линукс здесь совершенно не причём (я офигеваю с этого чёрно-белого взгляда) — все адекватные люди на венде используют консольные x264 и AviSynth и в ус не дуют. Я понимаю, что для тебя предел мечтаний это просто как-то закодировать видео, которое будет как-то проигрываться, но тред-то и не про это. Твои евангелисткие откровения здесь никого не волнуют и не удивят, все здесь постящие знакомы с наиболее популярными гуёвыми обёртками как под винду, так и под линукс, и не используют их исключительно в силу практических причин.
Вот вам, кстати, наглядный урок, как можно гуёвинами (наверняка) и небрежностью по типу предыдущего постера запороть видео:
https://github.com/mpv-player/mpv/wiki/Fixing-Simulcasts#wrong-color-range
http://screenshotcomparison.com/comparison/83071
Тоже ведь, скорее всего, в таком ключе рассуждали — зачем мне разбираться, автор гуёвины уж точно мастер своего дела и за меня всё продумал. Нажал кнопку и готово.
Насколько оправдано использование quality=best у vp9? Кодировать 30 секунд пару часов это же ебануться можно, какая будет разница с дефолтным good?
>>1404605
Ты тред вообще читаешь?
Вообще лучше всего использовать -quality good -cpu-used 0 (или -speed 0, что одно и то же).
Так и качество/размер хорошее, и кодируется не слишком долго.
Но с введением лимита в 20МБ можно, конечно, и просто -good, только битрейта побольше надо выставить, или просто -b:v 0 -crf 15 где-нибудь.
-best стоит использовать когда что-то совсем годное решил закодировать по лимиту в максимальном качестве и можешь подождать день-два-три, но такие ситуации редко возникают.
Ты тред вообще читаешь?
Вообще лучше всего использовать -quality good -cpu-used 0 (или -speed 0, что одно и то же).
Так и качество/размер хорошее, и кодируется не слишком долго.
Но с введением лимита в 20МБ можно, конечно, и просто -good, только битрейта побольше надо выставить, или просто -b:v 0 -crf 15 где-нибудь.
-best стоит использовать когда что-то совсем годное решил закодировать по лимиту в максимальном качестве и можешь подождать день-два-три, но такие ситуации редко возникают.
1653 Кб, Webm
>>1404605
Не стоит. Разница не существенна и не стоит того, чтобы кодировать вебмс часами.
Не стоит. Разница не существенна и не стоит того, чтобы кодировать вебмс часами.
647 Кб, 4000x299
>>1404621
Я всегда, кстати, со -speed 1 кодирую (и -speed 4 первый проход), даже под 6-8MiB лимит. Ждать больше чем 5x для сраной вебмки как-то не комильфо. Там всё равно разница не настолько значимая; уменьшение длительности, разрешения и FPS самые первые кандидаты при оптимизации. Париться приходится когда всё совсем плохо и там десяток кбитс от tile-columns=0, speed=0 или deadline=0 решить проблему не в состоянии.
Кстати, зацените как на самом деле аниме рисуют. -r 12 на большинстве сцен можно смело ставить.
>Но с введением лимита в 20МБ можно, конечно, и просто -good
Я всегда, кстати, со -speed 1 кодирую (и -speed 4 первый проход), даже под 6-8MiB лимит. Ждать больше чем 5x для сраной вебмки как-то не комильфо. Там всё равно разница не настолько значимая; уменьшение длительности, разрешения и FPS самые первые кандидаты при оптимизации. Париться приходится когда всё совсем плохо и там десяток кбитс от tile-columns=0, speed=0 или deadline=0 решить проблему не в состоянии.
Кстати, зацените как на самом деле аниме рисуют. -r 12 на большинстве сцен можно смело ставить.
>>1404641
Ну анимцо кодировать вообще как угодно можно, там картинка совсем простая и 8фпс.
Если все же картинка снята на камеру и много движения, то -speed 1 от -speed 0 будет сильно отличаться, гораздо сильнее, чем -speed 0 от -deadline 0, вплоть до наличия/отсутствия видимых квадратов при одинаковом битрейте.
А подождать не проблема, всегда можно оставить на ночь, проснуться и все будет закодировано, если, конечно, не -deadline 0.
Ну анимцо кодировать вообще как угодно можно, там картинка совсем простая и 8фпс.
Если все же картинка снята на камеру и много движения, то -speed 1 от -speed 0 будет сильно отличаться, гораздо сильнее, чем -speed 0 от -deadline 0, вплоть до наличия/отсутствия видимых квадратов при одинаковом битрейте.
А подождать не проблема, всегда можно оставить на ночь, проснуться и все будет закодировано, если, конечно, не -deadline 0.
>>1404621
Нафига столько, кстати? Я 23-25 для коротких клипов ставлю, там с лупой надо смотреть, чтобы отличить. 15 это дикий перерасход битрейта обычно.
В позапрошлом треде ещё проскакивала идея ставить -qmin 15, чтобы зря не расходовать битрейт. Особо не тестил, но выглядит интересно.
>или просто -b:v 0 -crf 15 где-нибудь.
Нафига столько, кстати? Я 23-25 для коротких клипов ставлю, там с лупой надо смотреть, чтобы отличить. 15 это дикий перерасход битрейта обычно.
В позапрошлом треде ещё проскакивала идея ставить -qmin 15, чтобы зря не расходовать битрейт. Особо не тестил, но выглядит интересно.
>>1404672
Но ведь не запостишь потом никуда, кроме hk/b/ нигде таких лимитов больше нет.
Я тут VapourSynth осилил. Думал какая-то неизвестная прыщавая поделка, а он чуть ли не популярнее AviSynth уже и фильтров куча крутых портировано. Было бы интересно взять какой-нибудь фиговый сорец, через flash3kyuu_deband пропустить и в 12бит VP9 закодировать.
Но ведь не запостишь потом никуда, кроме hk/b/ нигде таких лимитов больше нет.
Я тут VapourSynth осилил. Думал какая-то неизвестная прыщавая поделка, а он чуть ли не популярнее AviSynth уже и фильтров куча крутых портировано. Было бы интересно взять какой-нибудь фиговый сорец, через flash3kyuu_deband пропустить и в 12бит VP9 закодировать.
>>1404657
Проверил, действительно, даже при -b:v 0 -crf 35-40 вполне хорошее качество, по крайней мере при 960x540.
Проверил, действительно, даже при -b:v 0 -crf 35-40 вполне хорошее качество, по крайней мере при 960x540.
Блин, мне нравится эта херня. Вот так можно качественно преобразовать большую PNG-картинку в видео (на 4K с градиентным фоном будет особенно хорошо видна разница) и корректно протеггировать цветовое пространство:
import vapoursynth as vs
core = vs.get_core()
c = core.imwri.Read("pur.lossless.png")
c = core.std.AssumeFPS(c, fpsnum=1)
c = core.fmtc.matrix(c, mat="709", col_fam=vs.YUV, bits=16)
c = core.fmtc.bitdepth(c, bits=8)
c = core.std.Loop(c)
c.set_output()
vspipe pur.vpy --y4m - | ffmpeg -i - -c:v libvpx-vp9 -lossless 1 -colorspace bt709 -t 10 -y pururin.webm
import vapoursynth as vs
core = vs.get_core()
c = core.imwri.Read("pur.lossless.png")
c = core.std.AssumeFPS(c, fpsnum=1)
c = core.fmtc.matrix(c, mat="709", col_fam=vs.YUV, bits=16)
c = core.fmtc.bitdepth(c, bits=8)
c = core.std.Loop(c)
c.set_output()
vspipe pur.vpy --y4m - | ffmpeg -i - -c:v libvpx-vp9 -lossless 1 -colorspace bt709 -t 10 -y pururin.webm
>>1405084
Впрочем, я бы не сказал, что -vf format=rgb48,scale=out_color_matrix=bt709,format=yuv444p даёт результат хуже. Похоже, у ffmpeg всё же есть dithering при конвертировании с понижением битности; дефолтная конвертация 8bit RGB → 8bit YUV просто ужасна.
Зато VapourSynth погибче будет и фильтры к нему можно дописывать.
Впрочем, я бы не сказал, что -vf format=rgb48,scale=out_color_matrix=bt709,format=yuv444p даёт результат хуже. Похоже, у ffmpeg всё же есть dithering при конвертировании с понижением битности; дефолтная конвертация 8bit RGB → 8bit YUV просто ужасна.
Зато VapourSynth погибче будет и фильтры к нему можно дописывать.
3210 Кб, Webm
3219 Кб, Webm
Способ добавления превью через вторую дорожку не работает в бете лисы. Неславное грядёт время.
>>1395791 (OP)
Поцаны, не вебм но тоже фмпег.
ffmpeg -i input -c:v libx265 -preset veryslow -crf 18 -c:a aac -strict experimental -b:a 128k output.mkv/mp4
Вопрос: 1. В исходнике стерео, аудио дорожка, AAC 48000Hz, я хочу сконвертить в 41000, как?
2. На будущее, а если дорожка пятиканальная, как её конвертнуть в двухканальную?
3. Для x.265 какой лучше контейнер? А аудио, может нахуй AAC?
4. Что ещё посоветовать?
Поцаны, не вебм но тоже фмпег.
ffmpeg -i input -c:v libx265 -preset veryslow -crf 18 -c:a aac -strict experimental -b:a 128k output.mkv/mp4
Вопрос: 1. В исходнике стерео, аудио дорожка, AAC 48000Hz, я хочу сконвертить в 41000, как?
2. На будущее, а если дорожка пятиканальная, как её конвертнуть в двухканальную?
3. Для x.265 какой лучше контейнер? А аудио, может нахуй AAC?
4. Что ещё посоветовать?
>>1405290
-ar 44100
я лично делаю это в саундфорже, но в ффмпеге тоже есть такая возможность.
https://trac.ffmpeg.org/wiki/AudioChannelManipulation
не вижу причин использовать не mkv
может быть
>В исходнике стерео, аудио дорожка, AAC 48000Hz, я хочу сконвертить в 41000, как?
-ar 44100
>На будущее, а если дорожка пятиканальная, как её конвертнуть в двухканальную?
я лично делаю это в саундфорже, но в ффмпеге тоже есть такая возможность.
https://trac.ffmpeg.org/wiki/AudioChannelManipulation
>Для x.265 какой лучше контейнер?
не вижу причин использовать не mkv
>А аудио, может нахуй AAC?
может быть
>>1404264
-hide_banner -loglevel error -stats
-hide_banner -loglevel error -stats
3219 Кб, Webm
>>1405269
Есть подозрение что из-за этого: https://bugzilla.mozilla.org/show_bug.cgi?id=1148102 Недавно только смержили.
Код выглядит нормально, впрочем: https://hg.mozilla.org/mozilla-central/rev/5a780859dc1c#l3.541
Итератор по списку треков, используем для видео первый. Но в найтли почему-то используется последний (пробовал и на трёх треках).
Можно обойти, положив трек с контентом последним, но тогда плеер и стабильная лиса будут неправильно показывать (сосач всё ещё правильно, впрочем). Можно force/default=true поставить ещё попробовать втором треку. Или зарепортить в багзиллу.
Есть подозрение что из-за этого: https://bugzilla.mozilla.org/show_bug.cgi?id=1148102 Недавно только смержили.
Код выглядит нормально, впрочем: https://hg.mozilla.org/mozilla-central/rev/5a780859dc1c#l3.541
Итератор по списку треков, используем для видео первый. Но в найтли почему-то используется последний (пробовал и на трёх треках).
Можно обойти, положив трек с контентом последним, но тогда плеер и стабильная лиса будут неправильно показывать (сосач всё ещё правильно, впрочем). Можно force/default=true поставить ещё попробовать втором треку. Или зарепортить в багзиллу.
>>1405434
Бля, я не туда смотрел оказывается.
Таки баг в коде демуксера: https://hg.mozilla.org/mozilla-central/rev/5a780859dc1c#l3.260 На 272-ой строчке не проверяется, что трек уже мог быть добавлен и поэтому луп крутится до последнего видео-трека.
Можно зарепортить но мне лень.
Бля, я не туда смотрел оказывается.
Таки баг в коде демуксера: https://hg.mozilla.org/mozilla-central/rev/5a780859dc1c#l3.260 На 272-ой строчке не проверяется, что трек уже мог быть добавлен и поэтому луп крутится до последнего видео-трека.
Можно зарепортить но мне лень.
>>1405354
спс
спс
>>1405713
Ещё не заревьюили, но вроде разработчик нового демуксера согласен, что баг.
Ещё не заревьюили, но вроде разработчик нового демуксера согласен, что баг.
>>1405907
Убери лишние \
Убери лишние \
>>1405914
В твоем случае нужно вообще убрать \ - они нужны были, чтобы скрипты писать не в одну строку, а ты просто все вводишь в консолечку - в одну строку
В твоем случае нужно вообще убрать \ - они нужны были, чтобы скрипты писать не в одну строку, а ты просто все вводишь в консолечку - в одну строку
>>1406447
А может просто пофапать на эту милашку? Звучит заманчиво, а жене сказать что сегодня болит голова.
А может просто пофапать на эту милашку? Звучит заманчиво, а жене сказать что сегодня болит голова.
>>1406458
Пацаны уважать не будут.
Пацаны уважать не будут.
141 Кб, 800x800
>>1406458
Ещё можно найти пикчу на iqdb.org и смотреть другой арт этого художника. Теги авторства обозначаются на gelbooru красным цветом, а Роскомнадзор, возможно, кого-то от этого недуга спас.
Ну и не стоит забывать о том, что это тред о кодировании вебмок, а не о тохоарте, и не разводить тут не относящихся к нему дискуссий. Для touhou где-то тут была отдельная доска..
Ещё можно найти пикчу на iqdb.org и смотреть другой арт этого художника. Теги авторства обозначаются на gelbooru красным цветом, а Роскомнадзор, возможно, кого-то от этого недуга спас.
Ну и не стоит забывать о том, что это тред о кодировании вебмок, а не о тохоарте, и не разводить тут не относящихся к нему дискуссий. Для touhou где-то тут была отдельная доска..
У меня тут назрел вопрос, почему на этой доске пишут: оперативную систему и браузер или например : firefox based, это ведь некорректно правильней было бы написать Gecko.
> это ведь некорректно правильней было бы написать Gecko.
Потому что gecko -- это не браузер, вот почему.
>>1406748
Блять, я понимаю, но "Firefox based" тоже не браузер, а что-то основанное на лисе, а значит логичнее было бы писать название движка , а не самого браузера.
Блять, я понимаю, но "Firefox based" тоже не браузер, а что-то основанное на лисе, а значит логичнее было бы писать название движка , а не самого браузера.
88 Кб, 1256x922
113 Кб, 1254x917
Вышла статья со сравнением эффективности x264, libvpx-vp9 и x265, а также различных декодеров: https://blogs.gnome.org/rbultje/2015/09/28/vp9-encodingdecoding-performance-vs-hevch-264/
Левый пик: сравнение затрачиваемого на кодирование одного кадра времени с изменением битрейта относительно x264 с --preset=veryslow при том же качестве по SSIM. Менялись пресеты x26{4,5} и --cpu-used vp9.
Правый пик: декодирование видео с тем же качеством, но разным битрейтом. Libvpx (который используется в т.ч. в браузерах) соснул полностью.
Левый пик: сравнение затрачиваемого на кодирование одного кадра времени с изменением битрейта относительно x264 с --preset=veryslow при том же качестве по SSIM. Менялись пресеты x26{4,5} и --cpu-used vp9.
Правый пик: декодирование видео с тем же качеством, но разным битрейтом. Libvpx (который используется в т.ч. в браузерах) соснул полностью.
>>1407082
Потому что для этого надо тащить целый libavcodec, авторы которого клали на патенты сшп.
Потому что для этого надо тащить целый libavcodec, авторы которого клали на патенты сшп.
615 Кб, 1280x720
>>1407076
Так это просто пересказ его выступления с VDD2015, которое было чуть выше по треду: https://www.youtube.com/watch?v=_Q6J2_nvLSI
Через пару дней вот это выйдет: http://compression.ru/video/codec_comparison/call_for_codecs_15.html Там должно быть покачественнее сравнение.
Хромиум использует ffvp8 для VP8 без альфа-канала (большинство): https://chromium.googlesource.com/chromium/src.git/+/c219d1def47875bf0569c7f931620e6c9f94a801/media/filters/vpx_video_decoder.cc#328
ffvp9 почему-то по умолчанию ещё не используется, но нужно всего лишь выключить libvpx при компиляции для этого.
ff, как обычно, соснул, у него ебанутые прослойки из гстримера и либав и только libvpx для webm.
Меня на самом деле больше заинтересовал его анализатор VP9, он даже одобрительно отнёсся к идеи открыть исходники.
>>1407085
Ну вон хромиум тащит в third_party, ему похуй. А для лисы сраные прослойки в виде гстримера с его вечно глючными декодерами.
Так это просто пересказ его выступления с VDD2015, которое было чуть выше по треду: https://www.youtube.com/watch?v=_Q6J2_nvLSI
Через пару дней вот это выйдет: http://compression.ru/video/codec_comparison/call_for_codecs_15.html Там должно быть покачественнее сравнение.
>который используется в т.ч. в браузерах
Хромиум использует ffvp8 для VP8 без альфа-канала (большинство): https://chromium.googlesource.com/chromium/src.git/+/c219d1def47875bf0569c7f931620e6c9f94a801/media/filters/vpx_video_decoder.cc#328
ffvp9 почему-то по умолчанию ещё не используется, но нужно всего лишь выключить libvpx при компиляции для этого.
ff, как обычно, соснул, у него ебанутые прослойки из гстримера и либав и только libvpx для webm.
Меня на самом деле больше заинтересовал его анализатор VP9, он даже одобрительно отнёсся к идеи открыть исходники.
>>1407085
Ну вон хромиум тащит в third_party, ему похуй. А для лисы сраные прослойки в виде гстримера с его вечно глючными декодерами.
>>1407151
Ещё есть поддержка аппаратных декодеров Intel, впрочем, но только для венды: https://hg.mozilla.org/mozilla-central/file/6256ec9113c1/dom/media/webm/moz.build#l26
>и только libvpx для webm
Ещё есть поддержка аппаратных декодеров Intel, впрочем, но только для венды: https://hg.mozilla.org/mozilla-central/file/6256ec9113c1/dom/media/webm/moz.build#l26
>>1407168
Это же только для новых процессоров?
Я включил media.webm.intel_decoder.enabled, так на youtube показывает ошибку и начинает отдавать видео во флеше. haswell
Это же только для новых процессоров?
Я включил media.webm.intel_decoder.enabled, так на youtube показывает ошибку и начинает отдавать видео во флеше. haswell
>>1407173
Да, Broadwell и Skylake, причём на первый в прошлом треде жаловались как недостаточно производительный: http://arhivach.org/thread/100617/#1377625
>>1405269
>>1405647
Я тут рылся в коде и случайно нашёл wokaround: надо поставить media.format-reader.webm в false, тогда будет использоваться старый демуксер.
Можно пользоваться этим хаком, пока не пофиксили.
Да, Broadwell и Skylake, причём на первый в прошлом треде жаловались как недостаточно производительный: http://arhivach.org/thread/100617/#1377625
>>1405269
>>1405647
Я тут рылся в коде и случайно нашёл wokaround: надо поставить media.format-reader.webm в false, тогда будет использоваться старый демуксер.
Можно пользоваться этим хаком, пока не пофиксили.
5839 Кб, Webm
5933 Кб, Webm
Тест колорспейса превью на сосаче. Слева протеганный BT.709, справа протеганный BT.601.
Firefox, как оказалось, всегда показыват BT.601, несмотря ни на какие теги и вне зависимости от разрешения. В хроме не проверял. mpv корректно работает с тегами цветового пространства. Видимо, пока в браузерах поддержка видео в таком зачаточном состоянии, нужно всегда использовать BT.601 для совместимости с помощью принудительного -vf colormatrix=bt709:bt601 для всего HD.
Firefox, как оказалось, всегда показыват BT.601, несмотря ни на какие теги и вне зависимости от разрешения. В хроме не проверял. mpv корректно работает с тегами цветового пространства. Видимо, пока в браузерах поддержка видео в таком зачаточном состоянии, нужно всегда использовать BT.601 для совместимости с помощью принудительного -vf colormatrix=bt709:bt601 для всего HD.
>>1407252
Ну да, генератор превью думает, что видео всегда в BT.601. Я ебал весь этот хаос, происходящий в видео-энкодинге.
Ну да, генератор превью думает, что видео всегда в BT.601. Я ебал весь этот хаос, происходящий в видео-энкодинге.
>>1407281
Ну так ясно дело. Но ведь можно вручную поставить цветовое пространство YUV на входе с помощью -vf scale=in_color_matrix=X при генерации JPEG из WebM. Эвристики можно использовать как у mpv, так вроде все делают. От ffmpeg ждать исправления, думают, не стоит, поломает кучу всего, что сейчас завязано на такое поведение.
Хотя, я пожалуй слишком много хочу от кодеров сосача, которые даже превью брать из кадра посередине видео или yuv444p не осилили.
Ну так ясно дело. Но ведь можно вручную поставить цветовое пространство YUV на входе с помощью -vf scale=in_color_matrix=X при генерации JPEG из WebM. Эвристики можно использовать как у mpv, так вроде все делают. От ffmpeg ждать исправления, думают, не стоит, поломает кучу всего, что сейчас завязано на такое поведение.
Хотя, я пожалуй слишком много хочу от кодеров сосача, которые даже превью брать из кадра посередине видео или yuv444p не осилили.
>>1407298
Не нужно, блять, этого делать! Превью из первого кадра — стандарт имиджборд. Так делается везде — на форчане, краутчане, гелбуре, различных мелкобордах. Авторы вебм под это давно подстроились, и ставить им палки в колёса я не вижу никакого смысла.
Тут дело скорее всего в версии ffmpeg. Вангую, что на сервере стоит какой-нибудь стабильный debian или centos и ffmpeg из репозитория.
> превью брать из кадра посередине видео
Не нужно, блять, этого делать! Превью из первого кадра — стандарт имиджборд. Так делается везде — на форчане, краутчане, гелбуре, различных мелкобордах. Авторы вебм под это давно подстроились, и ставить им палки в колёса я не вижу никакого смысла.
> или yuv444p
Тут дело скорее всего в версии ffmpeg. Вангую, что на сервере стоит какой-нибудь стабильный debian или centos и ffmpeg из репозитория.
>>1407328
Хм, не знал. Но на 8chan (и всех бордах на tinyboard и infinity next соответственно) из середины.
Да ладно. Что-то не видел в форчановских вембах такого изврата с вставкой левого кадра в начало видео.
Это прежде всего ставит палки в колёсо обычным пользователям, которые привыкли к нормальной генерации превью во всём десктопном софте и вдруг встречают такой идиотизм. Притом что кто мешает использовать отдельный трек для кастомного превью, если так уж надо?
Да понятно. Особенно будет смешно макаке, когда кто-нибудь откопает RCE под древний ffmpeg. В libvpx-то вон сколько находят в каждом выпуске FF и помечают как критические, а в дефолтном ffmpeg куча форматов.
>на форчане, краутчане, гелбуре, различных мелкобордах
Хм, не знал. Но на 8chan (и всех бордах на tinyboard и infinity next соответственно) из середины.
>Авторы вебм под это давно подстроились
Да ладно. Что-то не видел в форчановских вембах такого изврата с вставкой левого кадра в начало видео.
>и ставить им палки в колёса
Это прежде всего ставит палки в колёсо обычным пользователям, которые привыкли к нормальной генерации превью во всём десктопном софте и вдруг встречают такой идиотизм. Притом что кто мешает использовать отдельный трек для кастомного превью, если так уж надо?
>какой-нибудь стабильный debian или centos и ffmpeg из репозитория
Да понятно. Особенно будет смешно макаке, когда кто-нибудь откопает RCE под древний ffmpeg. В libvpx-то вон сколько находят в каждом выпуске FF и помечают как критические, а в дефолтном ffmpeg куча форматов.
>>1395791 (OP)
Посоны, как wget'ом слить все webm'ки из треда?
Посоны, как wget'ом слить все webm'ки из треда?
>>1407346
Не умеют, наверно. В местном анимублядском это на каждом шагу.
Это которые с xmedia recode?
Десктопный софт часто сосёт на генерации превью из видеодорожек с единственным кадром. Движок доброчана — тоже.
Тащемта, во всяких debian'ах уязвимости очень быстро закрывают, часто даже быстрее апстрима.
> Что-то не видел в форчановских вембах такого изврата с вставкой левого кадра в начало видео.
Не умеют, наверно. В местном анимублядском это на каждом шагу.
> Это прежде всего ставит палки в колёсо обычным пользователям
Это которые с xmedia recode?
> Притом что кто мешает использовать отдельный трек для кастомного превью, если так уж надо?
Десктопный софт часто сосёт на генерации превью из видеодорожек с единственным кадром. Движок доброчана — тоже.
> Особенно будет смешно макаке, когда кто-нибудь откопает RCE под древний ffmpeg.
Тащемта, во всяких debian'ах уязвимости очень быстро закрывают, часто даже быстрее апстрима.
>>1407187
Пока читал код вокруг, ещё кое-что интересное нашёл: https://hg.mozilla.org/mozilla-central/file/312c68b16549/dom/media/DecoderTraits.cpp#l209
Опция выглядела очень многообещающе, поэтому вначале пришлось потратить кучу времени, чтобы разобраться как работает гстример. Кое-как накорябал несколько пайплайнов для теста с декодерами vp9dec (gst-launch-1.0 -v filesrc location=test.webm ! matroskademux ! vp9dec ! autovideosink) и avdec_vp9 (gst-launch-1.0 -v filesrc location=test.webm ! matroskademux ! avdec_vp9 ! autovideosink) через gst-launch. Первый работал (использует libvpx), а вот со вторым (использует ffvp9) вылезла куча проблем: в убунте <=15.04 оно вообще не работало, в 15.10 же сегфолтилось где-то в недрах libavcodec-ffmpeg56. Благодаря ебанутости майнтейнеров, libav теперь заменяют обратно ффмпегом, но всё ещё в процессе и, например, для вышеуказанного пакета даже дебаг-символов нет. А gst-libav теперь использует ффмпег, но продолжает называться libav. Плевать, главное чтобы работало. Начал общаться с разработчиками. У них почему-то всё работает, но сидят все на гите, ясное дело. Ну, делать нечего, собираю тоже значит всё из гита. И тут оно сегфолтится опять, а по нормальному стэктрейсу на этот раз всё равно никто ничего ответить не может. Ещё пару часов впустую.
Похуй, думаю, сразу в лисе потесчу, т.к. на fakesink не сегфолтится, значит может проблема где-то в области вывода, а не декодирования. Дальше надо было как-то повыше приоритет для avdec поставить, т.к. в urldecodebin, который использует лиса, первым выбирается vp9dec. Как оказалось, никакого другого способа кроме как удаления плагина руками (libgstvpx.so) нет. Офигеть. Я-то думал там какая-нибудь гибкая система приоритетов, вроде как у DirectShow и редактируется через реестр^W^W отдельно, а оно максимум только в самом приложении выбирается, к которому доступа нет. Лютое говно ваш гстример, в общем.
Ладно, удалил эту либу. Опцию в about:config поставил, пробую и… нихуя. Всё как раньше. И тут, сука, я таки пошёл в GStreamerDecoder::CanHandleMediaType, где выяснилось, что в лисе захардкоженный список кодеков, которые она проигрывает, используя gstreamer: https://hg.mozilla.org/mozilla-central/file/312c68b16549/dom/media/gstreamer/GStreamerFormatHelper.cpp#l64 Охуеть, всё это было зря.
В общем, если у кого тормозит видео на ютубе и линукс, то вот список действий, который по идее должен помочь (будет использоваться ffvp9 для декодирования WebM):
1) Добавить опцию media.prefer-gstreamer=true в about:config
2) Взять gstreamer, gstreamer-libav и libavcodec поновее (уровня Ubuntu 15.10)
3) Удалить/переименовать /usr/lib/gstreamer-1.0/libgstvpx.so (может в другом месте находиться)
4) Пересобрать лису, добавив VP9 в sDefaultCodecCaps (ололо)
Я, впрочем, не уверен, что сам gstreamer не даёт оверхэда и что это не вызовет другие проблемы.
Пока читал код вокруг, ещё кое-что интересное нашёл: https://hg.mozilla.org/mozilla-central/file/312c68b16549/dom/media/DecoderTraits.cpp#l209
Опция выглядела очень многообещающе, поэтому вначале пришлось потратить кучу времени, чтобы разобраться как работает гстример. Кое-как накорябал несколько пайплайнов для теста с декодерами vp9dec (gst-launch-1.0 -v filesrc location=test.webm ! matroskademux ! vp9dec ! autovideosink) и avdec_vp9 (gst-launch-1.0 -v filesrc location=test.webm ! matroskademux ! avdec_vp9 ! autovideosink) через gst-launch. Первый работал (использует libvpx), а вот со вторым (использует ffvp9) вылезла куча проблем: в убунте <=15.04 оно вообще не работало, в 15.10 же сегфолтилось где-то в недрах libavcodec-ffmpeg56. Благодаря ебанутости майнтейнеров, libav теперь заменяют обратно ффмпегом, но всё ещё в процессе и, например, для вышеуказанного пакета даже дебаг-символов нет. А gst-libav теперь использует ффмпег, но продолжает называться libav. Плевать, главное чтобы работало. Начал общаться с разработчиками. У них почему-то всё работает, но сидят все на гите, ясное дело. Ну, делать нечего, собираю тоже значит всё из гита. И тут оно сегфолтится опять, а по нормальному стэктрейсу на этот раз всё равно никто ничего ответить не может. Ещё пару часов впустую.
Похуй, думаю, сразу в лисе потесчу, т.к. на fakesink не сегфолтится, значит может проблема где-то в области вывода, а не декодирования. Дальше надо было как-то повыше приоритет для avdec поставить, т.к. в urldecodebin, который использует лиса, первым выбирается vp9dec. Как оказалось, никакого другого способа кроме как удаления плагина руками (libgstvpx.so) нет. Офигеть. Я-то думал там какая-нибудь гибкая система приоритетов, вроде как у DirectShow и редактируется через реестр^W^W отдельно, а оно максимум только в самом приложении выбирается, к которому доступа нет. Лютое говно ваш гстример, в общем.
Ладно, удалил эту либу. Опцию в about:config поставил, пробую и… нихуя. Всё как раньше. И тут, сука, я таки пошёл в GStreamerDecoder::CanHandleMediaType, где выяснилось, что в лисе захардкоженный список кодеков, которые она проигрывает, используя gstreamer: https://hg.mozilla.org/mozilla-central/file/312c68b16549/dom/media/gstreamer/GStreamerFormatHelper.cpp#l64 Охуеть, всё это было зря.
В общем, если у кого тормозит видео на ютубе и линукс, то вот список действий, который по идее должен помочь (будет использоваться ffvp9 для декодирования WebM):
1) Добавить опцию media.prefer-gstreamer=true в about:config
2) Взять gstreamer, gstreamer-libav и libavcodec поновее (уровня Ubuntu 15.10)
3) Удалить/переименовать /usr/lib/gstreamer-1.0/libgstvpx.so (может в другом месте находиться)
4) Пересобрать лису, добавив VP9 в sDefaultCodecCaps (ололо)
Я, впрочем, не уверен, что сам gstreamer не даёт оверхэда и что это не вызовет другие проблемы.
>>1407187
Пока читал код вокруг, ещё кое-что интересное нашёл: https://hg.mozilla.org/mozilla-central/file/312c68b16549/dom/media/DecoderTraits.cpp#l209
Опция выглядела очень многообещающе, поэтому вначале пришлось потратить кучу времени, чтобы разобраться как работает гстример. Кое-как накорябал несколько пайплайнов для теста с декодерами vp9dec (gst-launch-1.0 -v filesrc location=test.webm ! matroskademux ! vp9dec ! autovideosink) и avdec_vp9 (gst-launch-1.0 -v filesrc location=test.webm ! matroskademux ! avdec_vp9 ! autovideosink) через gst-launch. Первый работал (использует libvpx), а вот со вторым (использует ffvp9) вылезла куча проблем: в убунте <=15.04 оно вообще не работало, в 15.10 же сегфолтилось где-то в недрах libavcodec-ffmpeg56. Благодаря ебанутости майнтейнеров, libav теперь заменяют обратно ффмпегом, но всё ещё в процессе и, например, для вышеуказанного пакета даже дебаг-символов нет. А gst-libav теперь использует ффмпег, но продолжает называться libav. Плевать, главное чтобы работало. Начал общаться с разработчиками. У них почему-то всё работает, но сидят все на гите, ясное дело. Ну, делать нечего, собираю тоже значит всё из гита. И тут оно сегфолтится опять, а по нормальному стэктрейсу на этот раз всё равно никто ничего ответить не может. Ещё пару часов впустую.
Похуй, думаю, сразу в лисе потесчу, т.к. на fakesink не сегфолтится, значит может проблема где-то в области вывода, а не декодирования. Дальше надо было как-то повыше приоритет для avdec поставить, т.к. в urldecodebin, который использует лиса, первым выбирается vp9dec. Как оказалось, никакого другого способа кроме как удаления плагина руками (libgstvpx.so) нет. Офигеть. Я-то думал там какая-нибудь гибкая система приоритетов, вроде как у DirectShow и редактируется через реестр^W^W отдельно, а оно максимум только в самом приложении выбирается, к которому доступа нет. Лютое говно ваш гстример, в общем.
Ладно, удалил эту либу. Опцию в about:config поставил, пробую и… нихуя. Всё как раньше. И тут, сука, я таки пошёл в GStreamerDecoder::CanHandleMediaType, где выяснилось, что в лисе захардкоженный список кодеков, которые она проигрывает, используя gstreamer: https://hg.mozilla.org/mozilla-central/file/312c68b16549/dom/media/gstreamer/GStreamerFormatHelper.cpp#l64 Охуеть, всё это было зря.
В общем, если у кого тормозит видео на ютубе и линукс, то вот список действий, который по идее должен помочь (будет использоваться ffvp9 для декодирования WebM):
1) Добавить опцию media.prefer-gstreamer=true в about:config
2) Взять gstreamer, gstreamer-libav и libavcodec поновее (уровня Ubuntu 15.10)
3) Удалить/переименовать /usr/lib/gstreamer-1.0/libgstvpx.so (может в другом месте находиться)
4) Пересобрать лису, добавив VP9 в sDefaultCodecCaps (ололо)
Я, впрочем, не уверен, что сам gstreamer не даёт оверхэда и что это не вызовет другие проблемы.
Пока читал код вокруг, ещё кое-что интересное нашёл: https://hg.mozilla.org/mozilla-central/file/312c68b16549/dom/media/DecoderTraits.cpp#l209
Опция выглядела очень многообещающе, поэтому вначале пришлось потратить кучу времени, чтобы разобраться как работает гстример. Кое-как накорябал несколько пайплайнов для теста с декодерами vp9dec (gst-launch-1.0 -v filesrc location=test.webm ! matroskademux ! vp9dec ! autovideosink) и avdec_vp9 (gst-launch-1.0 -v filesrc location=test.webm ! matroskademux ! avdec_vp9 ! autovideosink) через gst-launch. Первый работал (использует libvpx), а вот со вторым (использует ffvp9) вылезла куча проблем: в убунте <=15.04 оно вообще не работало, в 15.10 же сегфолтилось где-то в недрах libavcodec-ffmpeg56. Благодаря ебанутости майнтейнеров, libav теперь заменяют обратно ффмпегом, но всё ещё в процессе и, например, для вышеуказанного пакета даже дебаг-символов нет. А gst-libav теперь использует ффмпег, но продолжает называться libav. Плевать, главное чтобы работало. Начал общаться с разработчиками. У них почему-то всё работает, но сидят все на гите, ясное дело. Ну, делать нечего, собираю тоже значит всё из гита. И тут оно сегфолтится опять, а по нормальному стэктрейсу на этот раз всё равно никто ничего ответить не может. Ещё пару часов впустую.
Похуй, думаю, сразу в лисе потесчу, т.к. на fakesink не сегфолтится, значит может проблема где-то в области вывода, а не декодирования. Дальше надо было как-то повыше приоритет для avdec поставить, т.к. в urldecodebin, который использует лиса, первым выбирается vp9dec. Как оказалось, никакого другого способа кроме как удаления плагина руками (libgstvpx.so) нет. Офигеть. Я-то думал там какая-нибудь гибкая система приоритетов, вроде как у DirectShow и редактируется через реестр^W^W отдельно, а оно максимум только в самом приложении выбирается, к которому доступа нет. Лютое говно ваш гстример, в общем.
Ладно, удалил эту либу. Опцию в about:config поставил, пробую и… нихуя. Всё как раньше. И тут, сука, я таки пошёл в GStreamerDecoder::CanHandleMediaType, где выяснилось, что в лисе захардкоженный список кодеков, которые она проигрывает, используя gstreamer: https://hg.mozilla.org/mozilla-central/file/312c68b16549/dom/media/gstreamer/GStreamerFormatHelper.cpp#l64 Охуеть, всё это было зря.
В общем, если у кого тормозит видео на ютубе и линукс, то вот список действий, который по идее должен помочь (будет использоваться ffvp9 для декодирования WebM):
1) Добавить опцию media.prefer-gstreamer=true в about:config
2) Взять gstreamer, gstreamer-libav и libavcodec поновее (уровня Ubuntu 15.10)
3) Удалить/переименовать /usr/lib/gstreamer-1.0/libgstvpx.so (может в другом месте находиться)
4) Пересобрать лису, добавив VP9 в sDefaultCodecCaps (ололо)
Я, впрочем, не уверен, что сам gstreamer не даёт оверхэда и что это не вызовет другие проблемы.
>>1408600
Можно секунд 10 с fps=1 тогда. Это будет весить всего лишь на пару сотен байт больше, чем один кадр.
Это если CVE появляется именно под программу и указано каких версий и т.д., то понятно, любой дурак сможет патчик, предоставленный экспертом, применить. (Хотя, я б посмотрел, как дебиановцы закроют что-нибудь вроде CVE-2015-2925 быстрее апстрима, ололо, где сам апстрим нихрена не знает, как исправить.)
А вот посмотрим, например, сюда https://www.mozilla.org/en-US/security/known-vulnerabilities/firefox/ на уязвимости, связанные с видео, и сюда http://metadata.ftp-master.debian.org/changelogs//main/libv/libvpx/libvpx_1.4.0-4_changelog и особой корреляции не видим. Часть багов ff-specific, конечно, но часть CVE libvpx я в чейнджлоге не вижу. Или где фикс для CVE-2015-1258 вот здесь http://metadata.ftp-master.debian.org/changelogs//main/libv/libvpx/libvpx_1.3.0-3_changelog ? А в какой-нибудь libvpx1 1.0.0-2~bpo60+1 из squeeze-backports, которая сотню лет не обновлялась, новые баги точно никак не применить? А если найду?
Если покопаться, то можно дофига интересного в старых версиях найти (и это с учётом использования адекватного дистрибутива и регулярных обновлений, заметим, что тоже часто на практике игнорируется). Окаменелости разве что пользователи RHEL могут себе позволить.
>Десктопный софт часто сосёт на генерации превью из видеодорожек с единственным кадром
Можно секунд 10 с fps=1 тогда. Это будет весить всего лишь на пару сотен байт больше, чем один кадр.
>во всяких debian'ах уязвимости очень быстро закрывают
Это если CVE появляется именно под программу и указано каких версий и т.д., то понятно, любой дурак сможет патчик, предоставленный экспертом, применить. (Хотя, я б посмотрел, как дебиановцы закроют что-нибудь вроде CVE-2015-2925 быстрее апстрима, ололо, где сам апстрим нихрена не знает, как исправить.)
А вот посмотрим, например, сюда https://www.mozilla.org/en-US/security/known-vulnerabilities/firefox/ на уязвимости, связанные с видео, и сюда http://metadata.ftp-master.debian.org/changelogs//main/libv/libvpx/libvpx_1.4.0-4_changelog и особой корреляции не видим. Часть багов ff-specific, конечно, но часть CVE libvpx я в чейнджлоге не вижу. Или где фикс для CVE-2015-1258 вот здесь http://metadata.ftp-master.debian.org/changelogs//main/libv/libvpx/libvpx_1.3.0-3_changelog ? А в какой-нибудь libvpx1 1.0.0-2~bpo60+1 из squeeze-backports, которая сотню лет не обновлялась, новые баги точно никак не применить? А если найду?
Если покопаться, то можно дофига интересного в старых версиях найти (и это с учётом использования адекватного дистрибутива и регулярных обновлений, заметим, что тоже часто на практике игнорируется). Окаменелости разве что пользователи RHEL могут себе позволить.
>>1407151
А может и используется. В хроме не тормозят вебм, а в лисе тормозят.
> ffvp9 почему-то по умолчанию ещё не используется
А может и используется. В хроме не тормозят вебм, а в лисе тормозят.
323 Кб, 742x1100
Накопилась целая папка с годными фапабельными вебмками.
Как можно сделать webm - шоу? ( по аналогии со слайд-шоу)
Хотелось бы настроить количество повторов webm, после чего должен происходить переход к другой вебмке.
Как можно сделать webm - шоу? ( по аналогии со слайд-шоу)
Хотелось бы настроить количество повторов webm, после чего должен происходить переход к другой вебмке.
5191 Кб, Webm
>>1408720
Дело не в железе и не в ОС, а в самой лисе.
Посмотри как себя ведет процесс plugin container.
Дело не в железе и не в ОС, а в самой лисе.
Посмотри как себя ведет процесс plugin container.
>>1408745
#ѕревью (отличное от первого кадра)
ffmpeg -i pic.png -c:v vp9 -b:v 0 -crf 15 -pix_fmt +yuv420p -deadline 0 preview.webm -y
#ƒобавление превью
ffmpeg -itsoffset 0.04 -i out.webm -f concat -i files.txt -map 1:v -map 0:a -c copy output.webm -y
#—клеивание c превью, файл txt:
file 'preview.webm'
file 'out.webm'
Почему-то кодировка в файле проебалась, ну да ладно.
#ѕревью (отличное от первого кадра)
ffmpeg -i pic.png -c:v vp9 -b:v 0 -crf 15 -pix_fmt +yuv420p -deadline 0 preview.webm -y
#ƒобавление превью
ffmpeg -itsoffset 0.04 -i out.webm -f concat -i files.txt -map 1:v -map 0:a -c copy output.webm -y
#—клеивание c превью, файл txt:
file 'preview.webm'
file 'out.webm'
Почему-то кодировка в файле проебалась, ну да ладно.
53 Кб, 640x637
>>1408741
Пробовал уже.
Пробовал уже.
6104 Кб, Webm
>>1405269
>>1405647
Всё, смержили в тестинг: https://hg.mozilla.org/integration/mozilla-inbound/rev/14c82d6b268c
Должны скоро смержить в mozilla-central и в найтли прилететь.
>>1408711
Зайди в chrome://media-internals, кликни на URL с видео и посмотри значение поля video_decoder. Если VpxVideoDecoder, то libvpx, очевидно.
Лиса может тормозить и по-другим причинам. Если используется неускоренный видео-вывод, например. Попробуй в фуллскрине может. Какое у видео разрешение-то? Если <=720p, то libvpx точно должен быстро декодить на любом железе.
>>1408718
Можешь сделать zoetrope. Вот пример от одного анончика, на cmd, правда: https://github.com/Kagami/webm.py/wiki/Tips-and-tricks#tiled-maps-of-videos
>>1405647
Всё, смержили в тестинг: https://hg.mozilla.org/integration/mozilla-inbound/rev/14c82d6b268c
Должны скоро смержить в mozilla-central и в найтли прилететь.
>>1408711
>А может и используется.
Зайди в chrome://media-internals, кликни на URL с видео и посмотри значение поля video_decoder. Если VpxVideoDecoder, то libvpx, очевидно.
Лиса может тормозить и по-другим причинам. Если используется неускоренный видео-вывод, например. Попробуй в фуллскрине может. Какое у видео разрешение-то? Если <=720p, то libvpx точно должен быстро декодить на любом железе.
>>1408718
Можешь сделать zoetrope. Вот пример от одного анончика, на cmd, правда: https://github.com/Kagami/webm.py/wiki/Tips-and-tricks#tiled-maps-of-videos
>>1408718
for f in *.webm; do mpv -fs -loop 5 $f; done
for f in *.webm; do mpv -fs -loop 5 $f; done
>>1408830
А что, лис умеет иначе? Я думал, что в десктопной версии он всегда рендерит в пиксмап в оперативке, который потом натягивает на веб-страницу, и о прикручивании всяких xv, vdpau, va api и прочих ускоренных интерфейсов там вообще речи не идёт.
> Если используется неускоренный видео-вывод, например.
А что, лис умеет иначе? Я думал, что в десктопной версии он всегда рендерит в пиксмап в оперативке, который потом натягивает на веб-страницу, и о прикручивании всяких xv, vdpau, va api и прочих ускоренных интерфейсов там вообще речи не идёт.
>>1408844
Через OpenGL можно, например, в том же хроме интерфейс весь через OpenGL рендерится (Aura их).
Через OpenGL можно, например, в том же хроме интерфейс весь через OpenGL рендерится (Aura их).
>>1408847
Всмысле, что я не знаю, как лиса на самом деле рендерит видео, поэтому предложил в фуллскрине попробовать. Может хотя бы фуллскрин они оптимизировали.
Всмысле, что я не знаю, как лиса на самом деле рендерит видео, поэтому предложил в фуллскрине попробовать. Может хотя бы фуллскрин они оптимизировали.
>>1408830
Всё также - тормозят.
Проверял на 720p и выше
>Попробуй в фуллскрине может.
Всё также - тормозят.
>Какое у видео разрешение-то?
Проверял на 720p и выше
>>1408857
gfx.content.azure.backends в skia поставь ололо
Я хз, надо дебажить и исключать одну проблему за другой по очереди. Зайди в about:support, посмотри что там с GPU/WebGL. Попробуй какой-нибудь лёгкое VP8 или Theora видео того же разрешения, чтобы исключить проблему на стороне декодинга. Попробуй в найтли/бете и т.д.
gfx.content.azure.backends в skia поставь ололо
Я хз, надо дебажить и исключать одну проблему за другой по очереди. Зайди в about:support, посмотри что там с GPU/WebGL. Попробуй какой-нибудь лёгкое VP8 или Theora видео того же разрешения, чтобы исключить проблему на стороне декодинга. Попробуй в найтли/бете и т.д.
978 Кб, Webm
>>1408866
Лел, но тормозит всё равно.
Вроде все неплохо:
Direct2D Enabled: true
DirectWrite Enabled: true (10.0.10240.16430)
GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC)
Supports Hardware H264 Decoding: Yes
WebGL Renderer: Google Inc. -- ANGLE (Intel(R) HD Graphics Family Direct3D11 vs_5_0 ps_5_0)
windowLayerManagerRemote: true
AzureCanvasBackend: direct2d 1.1
AzureContentBackend: direct2d 1.1
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0
Попробовал это https://www.youtube.com/watch?v=YQKgBmb2WoU
В лисе есть зависания на 1080p на секунду-две, а вхроме просто просадки фпс.
Надеюсь когда-нибудь они это исправят, а пока есть хром.
>gfx.content.azure.backends в skia
Лел, но тормозит всё равно.
>Зайди в about:support, посмотри что там с GPU/WebGL
Вроде все неплохо:
Direct2D Enabled: true
DirectWrite Enabled: true (10.0.10240.16430)
GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC)
Supports Hardware H264 Decoding: Yes
WebGL Renderer: Google Inc. -- ANGLE (Intel(R) HD Graphics Family Direct3D11 vs_5_0 ps_5_0)
windowLayerManagerRemote: true
AzureCanvasBackend: direct2d 1.1
AzureContentBackend: direct2d 1.1
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0
>VP8 или Theora видео того же разрешения
Попробовал это https://www.youtube.com/watch?v=YQKgBmb2WoU
В лисе есть зависания на 1080p на секунду-две, а вхроме просто просадки фпс.
Надеюсь когда-нибудь они это исправят, а пока есть хром.
>>1408898
libvpx, и оказалось что тестовое видео в vp9. Придется самому конвертировать, куда-то пропали все vp8 example
libvpx, и оказалось что тестовое видео в vp9. Придется самому конвертировать, куда-то пропали все vp8 example
>>1408830
В найтли уже работает.
yuv444p и 10/12bit им зарепортить что ли.
Вебмки с webvtt треком тоже работают в 41 и 44. Странно, когда они опять успели исправить, недавно только проверял.
В найтли уже работает.
yuv444p и 10/12bit им зарепортить что ли.
Вебмки с webvtt треком тоже работают в 41 и 44. Странно, когда они опять успели исправить, недавно только проверял.
test
95 Кб, 359x588
Дайте нормальную прогу, что бы без пердолизма и матана - выбрал файл и получил WebM.
тренд не читал
тренд не читал
>>1409186
ffmpeg.
ffmpeg.
>>1409186
WinFF
WinFF
http://permalink.gmane.org/gmane.comp.multimedia.webm.devel/2479
Чего-то они пиздят. В моих тестах гитовая версия была процентов на 3-5 медленнее, чем релиз 1.4.0. Как на платформе с SSE, так и без них.
Из интересного в новом релизе, пожалуй, VP9E_CONTENT_SCREEN, которая всё ещё в ffmpeg недоступна и про которую на VDD рассказывали. Правда, фиг знает, какая часть этих улучшений из VP10 попадёт в VP9.
>libvpx 1.5.0 release soon
>It's been about 6 months since the 1.4.0 release and libvpx has seen substantial improvements to vp9 encoding speed and quality
Чего-то они пиздят. В моих тестах гитовая версия была процентов на 3-5 медленнее, чем релиз 1.4.0. Как на платформе с SSE, так и без них.
Из интересного в новом релизе, пожалуй, VP9E_CONTENT_SCREEN, которая всё ещё в ffmpeg недоступна и про которую на VDD рассказывали. Правда, фиг знает, какая часть этих улучшений из VP10 попадёт в VP9.
dfsdf
28 Кб, 597x465
Как добавить субтитры без ожидания, которое при указании -ss перед -i? Это было весело, пока не потребовалось вырезать отрывок в конце 2-х часового фильма.
Не про вебм, но про ффмпег. Поясните идиоту, вот ффмпег и https://github.com/Nevcairiel/LAVFilters/releases одно и тоже? Или второе форк? Или что-то отдельное? Я пытался читать, но я видимо слишком глупый для всех этих перефоркиваний всего подряд. Или ффмпег это по сути комбайн, в который входит куча библиотек, которые разрабатывают разные люди?
>>1410085
Проект ffmpeg состоит из подкомпонент, основные из которых это libavcodec, libavformat, libavfilter, libswscale. Чаще всего их используют через CLI обёртки вроде ffmpeg, ffprobe, ffplay, которые линкуются с данными компонентами, скомпилированными в виде shared библиотек (либо статично). Но в некоторых случаях удобнее подключать библиотеки ffmpeg напрямую. Так работает, например, виндовый ffdshow или LAV Filters по твоей ссылке. Сам ffmpeg, либо его компоненты, очень много где используются, например: https://trac.ffmpeg.org/wiki/Projects Это и все обёртки из шапки этого треда, и xmedia recode, и webm-for-bakas, и все новые телевизоры и даже небо, даже аллах.
>>1410082
setpts фильтр нужен, в прошлом треде посмотри. Запилите уже FAQ в вики кто-нибудь.
Проект ffmpeg состоит из подкомпонент, основные из которых это libavcodec, libavformat, libavfilter, libswscale. Чаще всего их используют через CLI обёртки вроде ffmpeg, ffprobe, ffplay, которые линкуются с данными компонентами, скомпилированными в виде shared библиотек (либо статично). Но в некоторых случаях удобнее подключать библиотеки ffmpeg напрямую. Так работает, например, виндовый ffdshow или LAV Filters по твоей ссылке. Сам ffmpeg, либо его компоненты, очень много где используются, например: https://trac.ffmpeg.org/wiki/Projects Это и все обёртки из шапки этого треда, и xmedia recode, и webm-for-bakas, и все новые телевизоры и даже небо, даже аллах.
>>1410082
setpts фильтр нужен, в прошлом треде посмотри. Запилите уже FAQ в вики кто-нибудь.
837 Кб, 1383x808
Я тут ещё немного потестил и охуел. Короче, переделывайте все свои HD вебмки, они неправильные. Если исходник был HD, то надо делать обязательно конвертацию в BT.601, иначе цвета в браузере поедут. Верхний по вертикали — BT.709 прочитанный как BT.601, средний — BT.709 преобразованный в BT.601 и прочитанный как BT.601, нижний — оригинальный BT.709 прочитанный как BT.709.
>>1410213
Какие браузеры на каких системах и на каких видеокартах потестил? А то, знаешь ли, результаты ведь могут различаться.
Какие браузеры на каких системах и на каких видеокартах потестил? А то, знаешь ли, результаты ведь могут различаться.
3039 Кб, 3840x2160
>>1410253
От видеокарты и системы это не зависит. Разве что в хромиуме вроде правильно, но он у меня падает на таких здоровых, надо будет поменьше сделать. Да и даже если в одном из браузеров правильно, то ничего не меняет, надо под оба делать одинаково.
Открой сам оба видео из >>1407252 и сделать скриншоты. Оба видео должны быть одинаковыми и как на пикрелейтеде.
От видеокарты и системы это не зависит. Разве что в хромиуме вроде правильно, но он у меня падает на таких здоровых, надо будет поменьше сделать. Да и даже если в одном из браузеров правильно, то ничего не меняет, надо под оба делать одинаково.
Открой сам оба видео из >>1407252 и сделать скриншоты. Оба видео должны быть одинаковыми и как на пикрелейтеде.
>>1410264
Ты охуенно осведомленный, если знаешь, как устроен видеовывод в разных браузерах (в т.ч. проприетарных) на разных системах. На другой системе может оказаться другая реализация, может быть прямое скармливание потока видеосистеме, а там YUV>RGB конверсией может заняться видеокарта и ты даже не узнаешь, кто поднасрал, пока не переберешь все варианты. Более того, единого стандарта "более стольки-то пикселей - такое то кодирование цветового канала" в принципе не существует, и на вебм-ках с их разбросом в разрешениях это отражается в первую очередь.
Если уж у кого-то видео в HD, то кодировать надо по-любому в 709, уж здесь нет никаких противоречий и сомнений насчет стандарта, а кодировать HD в 601 ради того, что у одного анона его любимый браузер коряво воспроизводит видео - бред.
>От видеокарты и системы это не зависит
Ты охуенно осведомленный, если знаешь, как устроен видеовывод в разных браузерах (в т.ч. проприетарных) на разных системах. На другой системе может оказаться другая реализация, может быть прямое скармливание потока видеосистеме, а там YUV>RGB конверсией может заняться видеокарта и ты даже не узнаешь, кто поднасрал, пока не переберешь все варианты. Более того, единого стандарта "более стольки-то пикселей - такое то кодирование цветового канала" в принципе не существует, и на вебм-ках с их разбросом в разрешениях это отражается в первую очередь.
>Да и даже если в одном из браузеров правильно, то ничего не меняет, надо под оба делать одинаково.
Если уж у кого-то видео в HD, то кодировать надо по-любому в 709, уж здесь нет никаких противоречий и сомнений насчет стандарта, а кодировать HD в 601 ради того, что у одного анона его любимый браузер коряво воспроизводит видео - бред.
>>1410296
Аппаратно декодируют VP9 только Broadwell/Skylake на винде. Не понимаю, что ты тут докапываешься. Ясно дело, что я имею ввиду софтовую реализацию декодера, от видеокарты она зависеть ну никак не может. libvpx на любой системе и любой видеокарты выдаёт везде одинаковые YCbCr фреймы, далее данные преобразуются в RGB в YCbCrImageDataSerializer.cpp, который использует библиотеку из хромиума: https://hg.mozilla.org/mozilla-central/file/97e537f85183/gfx/ycbcr и в которой захардкожены коэффициенты BT.601 (вон они даже ссылаются https://chromium.googlesource.com/chromium/src.git/+/e50ca3edbcb0bb0ff6e0519597988700a827c23f/media/base/yuv_convert.cc#10 на пейпер http://lestourtereaux.free.fr/papers/data/yuvrgb.pdf в котором в сноске на 2-ой странице чёрным по белому указано, что расчёты актуальны для SDTV только). Если на какой платформе значения пикселей после конвертации и будут другими, то это баг.
Как не существует? Я в треде уже кучу раз писал про эвристики, которые используют многие плееры. Если файл HD, то с большой вероятностью он либо с HDTV, либо с бурурея, а там всегда BT.709. Апскейлы и прочие извраты картину портят, конечно, но это всё же редкость. Причём, это проблема не релизера, а твоя, т.к. тебе нужно угадать какая матрица была в оригинале. Соответственно, задача автора webm сделать так, чтобы и в браузерах всё выглядело правильно.
А в чём проблема? У фреймов VP9 можно проставить тег цветового пространства. Все вменяемые проигрыватели (браузеры в их число не входят) их понимают. И не забывай, что то же превью как минимум на двух разных бордах (а наверняка и всех) при использовании BT.709 будет неправильными.
Давай может ты сделать скриншоты, а мы посмотрим, как разные системы влияют? Толку от твоих теоретизирований?
>может быть прямое скармливание потока видеосистеме
Аппаратно декодируют VP9 только Broadwell/Skylake на винде. Не понимаю, что ты тут докапываешься. Ясно дело, что я имею ввиду софтовую реализацию декодера, от видеокарты она зависеть ну никак не может. libvpx на любой системе и любой видеокарты выдаёт везде одинаковые YCbCr фреймы, далее данные преобразуются в RGB в YCbCrImageDataSerializer.cpp, который использует библиотеку из хромиума: https://hg.mozilla.org/mozilla-central/file/97e537f85183/gfx/ycbcr и в которой захардкожены коэффициенты BT.601 (вон они даже ссылаются https://chromium.googlesource.com/chromium/src.git/+/e50ca3edbcb0bb0ff6e0519597988700a827c23f/media/base/yuv_convert.cc#10 на пейпер http://lestourtereaux.free.fr/papers/data/yuvrgb.pdf в котором в сноске на 2-ой странице чёрным по белому указано, что расчёты актуальны для SDTV только). Если на какой платформе значения пикселей после конвертации и будут другими, то это баг.
>Более того, единого стандарта "более стольки-то пикселей - такое то кодирование цветового канала" в принципе не существует
Как не существует? Я в треде уже кучу раз писал про эвристики, которые используют многие плееры. Если файл HD, то с большой вероятностью он либо с HDTV, либо с бурурея, а там всегда BT.709. Апскейлы и прочие извраты картину портят, конечно, но это всё же редкость. Причём, это проблема не релизера, а твоя, т.к. тебе нужно угадать какая матрица была в оригинале. Соответственно, задача автора webm сделать так, чтобы и в браузерах всё выглядело правильно.
>а кодировать HD в 601 ради того
А в чём проблема? У фреймов VP9 можно проставить тег цветового пространства. Все вменяемые проигрыватели (браузеры в их число не входят) их понимают. И не забывай, что то же превью как минимум на двух разных бордах (а наверняка и всех) при использовании BT.709 будет неправильными.
>у одного анона его любимый браузер коряво воспроизводит видео
Давай может ты сделать скриншоты, а мы посмотрим, как разные системы влияют? Толку от твоих теоретизирований?
>>1410296
Аппаратно декодируют VP9 только Broadwell/Skylake на винде. Не понимаю, что ты тут докапываешься. Ясно дело, что я имею ввиду софтовую реализацию декодера, от видеокарты она зависеть ну никак не может. libvpx на любой системе и любой видеокарты выдаёт везде одинаковые YCbCr фреймы, далее данные преобразуются в RGB в YCbCrImageDataSerializer.cpp, который использует библиотеку из хромиума: https://hg.mozilla.org/mozilla-central/file/97e537f85183/gfx/ycbcr и в которой захардкожены коэффициенты BT.601 (вон они даже ссылаются https://chromium.googlesource.com/chromium/src.git/+/e50ca3edbcb0bb0ff6e0519597988700a827c23f/media/base/yuv_convert.cc#10 на пейпер http://lestourtereaux.free.fr/papers/data/yuvrgb.pdf в котором в сноске на 2-ой странице чёрным по белому указано, что расчёты актуальны для SDTV только). Если на какой платформе значения пикселей после конвертации и будут другими, то это баг.
Как не существует? Я в треде уже кучу раз писал про эвристики, которые используют многие плееры. Если файл HD, то с большой вероятностью он либо с HDTV, либо с бурурея, а там всегда BT.709. Апскейлы и прочие извраты картину портят, конечно, но это всё же редкость. Причём, это проблема не релизера, а твоя, т.к. тебе нужно угадать какая матрица была в оригинале. Соответственно, задача автора webm сделать так, чтобы и в браузерах всё выглядело правильно.
А в чём проблема? У фреймов VP9 можно проставить тег цветового пространства. Все вменяемые проигрыватели (браузеры в их число не входят) их понимают. И не забывай, что то же превью как минимум на двух разных бордах (а наверняка и всех) при использовании BT.709 будет неправильными.
Давай может ты сделать скриншоты, а мы посмотрим, как разные системы влияют? Толку от твоих теоретизирований?
>может быть прямое скармливание потока видеосистеме
Аппаратно декодируют VP9 только Broadwell/Skylake на винде. Не понимаю, что ты тут докапываешься. Ясно дело, что я имею ввиду софтовую реализацию декодера, от видеокарты она зависеть ну никак не может. libvpx на любой системе и любой видеокарты выдаёт везде одинаковые YCbCr фреймы, далее данные преобразуются в RGB в YCbCrImageDataSerializer.cpp, который использует библиотеку из хромиума: https://hg.mozilla.org/mozilla-central/file/97e537f85183/gfx/ycbcr и в которой захардкожены коэффициенты BT.601 (вон они даже ссылаются https://chromium.googlesource.com/chromium/src.git/+/e50ca3edbcb0bb0ff6e0519597988700a827c23f/media/base/yuv_convert.cc#10 на пейпер http://lestourtereaux.free.fr/papers/data/yuvrgb.pdf в котором в сноске на 2-ой странице чёрным по белому указано, что расчёты актуальны для SDTV только). Если на какой платформе значения пикселей после конвертации и будут другими, то это баг.
>Более того, единого стандарта "более стольки-то пикселей - такое то кодирование цветового канала" в принципе не существует
Как не существует? Я в треде уже кучу раз писал про эвристики, которые используют многие плееры. Если файл HD, то с большой вероятностью он либо с HDTV, либо с бурурея, а там всегда BT.709. Апскейлы и прочие извраты картину портят, конечно, но это всё же редкость. Причём, это проблема не релизера, а твоя, т.к. тебе нужно угадать какая матрица была в оригинале. Соответственно, задача автора webm сделать так, чтобы и в браузерах всё выглядело правильно.
>а кодировать HD в 601 ради того
А в чём проблема? У фреймов VP9 можно проставить тег цветового пространства. Все вменяемые проигрыватели (браузеры в их число не входят) их понимают. И не забывай, что то же превью как минимум на двух разных бордах (а наверняка и всех) при использовании BT.709 будет неправильными.
>у одного анона его любимый браузер коряво воспроизводит видео
Давай может ты сделать скриншоты, а мы посмотрим, как разные системы влияют? Толку от твоих теоретизирований?
>>1410371
Ну и ладно бы там HD→HD. Так ведь скейлинг HD→SD, как это часто бывает, даёт неправильный результат вообще везде.
Ну и ладно бы там HD→HD. Так ведь скейлинг HD→SD, как это часто бывает, даёт неправильный результат вообще везде.
>>1410371
Да почему ты так уверен-то? Могут взять, да направить поток на системный медиафреймворк, это было бы самым рациональным решением. Тут https://en.wikipedia.org/wiki/HTML5_video#Browser_support этот вариант вообще как будто дефолтный преподносят, хотя это может быть устаревшая информация. Собственно, декодинг видео нам не важно где произведен, аппаратно или программно, даже программно декодированные YUV кадры рациональнее всего посылать на VMR/EVR/рандомнойсистемыотрисовщик/, а тот, соответственно, может делегировать конверсию в RGB драйверу видеокарты, а там уж как бог на душу пошлет, так и отконвертирует, и уж точно беспардонно насрет на все теги (их вообще кроме madVR на винде кто-нибудь почитает?). Вот такого подхода и стоит ожидать, по крайней мере, от браузеров Майкрософта и Эппл.
Эвристика сводится к упованию, что отрисовщик и драйвер не обосрутся, а я лично видел, как релизы 848х480 рисовались то в 601, то в 709 в зависимости от версии драйвера Nvidia, и ведь тут даже предъяв не может быть: стандарта нет, на тэги отрисовка у большинства юзеров обычно срет, да даже кодеры в релизах, сейчас проверил, даже утянутый с баки "лучший" релиз одного бдрипа от сраных coalgirls - тэга не имеет, только половина из оказавшихся на винте нескольких бдрипов имеют тэг, а с твшками все наверняка будет еще печальнее.
Пока под рукой только хром и лиса на XP, результаты как и у тебя - лиса обосралась, хром молодец, а значит ничего городить с подгонкой стандартов не нужно. Хотя и тут фиг знает, вдруг хром все гонит в 709, нужно же проверять и SD.
>Ясно дело, что я имею ввиду софтовую реализацию декодера, от видеокарты она зависеть ну никак не может. libvpx
Да почему ты так уверен-то? Могут взять, да направить поток на системный медиафреймворк, это было бы самым рациональным решением. Тут https://en.wikipedia.org/wiki/HTML5_video#Browser_support этот вариант вообще как будто дефолтный преподносят, хотя это может быть устаревшая информация. Собственно, декодинг видео нам не важно где произведен, аппаратно или программно, даже программно декодированные YUV кадры рациональнее всего посылать на VMR/EVR/рандомнойсистемыотрисовщик/, а тот, соответственно, может делегировать конверсию в RGB драйверу видеокарты, а там уж как бог на душу пошлет, так и отконвертирует, и уж точно беспардонно насрет на все теги (их вообще кроме madVR на винде кто-нибудь почитает?). Вот такого подхода и стоит ожидать, по крайней мере, от браузеров Майкрософта и Эппл.
>Я в треде уже кучу раз писал про эвристики, которые используют многие плееры
Эвристика сводится к упованию, что отрисовщик и драйвер не обосрутся, а я лично видел, как релизы 848х480 рисовались то в 601, то в 709 в зависимости от версии драйвера Nvidia, и ведь тут даже предъяв не может быть: стандарта нет, на тэги отрисовка у большинства юзеров обычно срет, да даже кодеры в релизах, сейчас проверил, даже утянутый с баки "лучший" релиз одного бдрипа от сраных coalgirls - тэга не имеет, только половина из оказавшихся на винте нескольких бдрипов имеют тэг, а с твшками все наверняка будет еще печальнее.
>Давай может ты сделать скриншоты, а мы посмотрим, как разные системы влияют
Пока под рукой только хром и лиса на XP, результаты как и у тебя - лиса обосралась, хром молодец, а значит ничего городить с подгонкой стандартов не нужно. Хотя и тут фиг знает, вдруг хром все гонит в 709, нужно же проверять и SD.
>Да почему ты так уверен-то? Могут взять, да направить поток на системный медиафреймворк
Ну потому что я смотрю в DecoderTraits.cpp и не вижу, чтобы webm в лисе декодировалось чем-то кроме встроенной libvpx. У меня тоже была идея в gstreamer это загнать в >>1408605 но как оказалось фиг там. И у DirectShow тоже меньший приоритет. Разве что на андроиде оно таки через OMX идёт.
>а тот, соответственно, может делегировать конверсию в RGB драйверу видеокарты
Я нашёл только какие-то фигово поддерживаемые расширения GL_SGIX_ycrcb, GL_APPLE_ycbcr_422 и GL_MESA_ycbcr_texture, которые позволяют текстуру в YCbCr формате загрузить (в случае OpenGL). Не похоже, чтобы им активно пользовались, все на шейдерах сами пишут. Да и на них в любом случае спецификация есть, я не знаю откуда у тебя неизвестные берутся. В вышеперечисленных BT.601, как я понял.
>я лично видел, как релизы 848х480 рисовались то в 601, то в 709 в зависимости от версии драйвера Nvidia
Ну так там небось аппаратно декодируемый H.264. Ты попробуй в софтварных реализациях декодеров такое найти.
>на тэги отрисовка у большинства юзеров обычно срет
Значит это плохой и испорченный плеер. Не понимаю зачем к ним апеллировать.
>только половина из оказавшихся на винте нескольких бдрипов имеют тэг
Аналогично, я буквально единичные релизы у себя откопал протегированные. А сейчас BT.2020 появится с 4K, вообще весело будет. Поэтому нужно начинать теггировать все энкоды.
>а значит ничего городить с подгонкой стандартов не нужно
Тогда и -sn ставить не нужно, в стандарте ж есть webvtt трек. И -pix_fmt yuv420p не нужно, фигли хром крэшит таб с абсолютно валидным VP9? А в лисе yuv444p с разводами. Ну дела, ничего не работает, нахуй эти webm!
>>1410492
-vf colormatrix=bt709:bt601 -colorspace bt470bg и всего делов. И везде работает. Как все годами сидят в кривыми цветами в webm и ничего не замечают — я хз. Я вот как начал проверять, так охуел от всего бардака.
>>1410463
Если оба видео одинаково выглядят, то нет, т.к. правое BT.601.
>Хотя и тут фиг знает, вдруг хром все гонит в 709
Если оба видео одинаково выглядят, то нет, т.к. правое BT.601.
>>1410540
Надо просто долбить лисоделов этой проблемой, в хроме же вроде норм. Твой вариант сделает нормальные цвета на лисе, но может их поломать на других не-хром браузерах или на мобильных устройствах, и это надо пробовать, а не безосновательно полагать, что их кодят так же как лису.
>Ну дела, ничего не работает, нахуй эти webm!
Надо просто долбить лисоделов этой проблемой, в хроме же вроде норм. Твой вариант сделает нормальные цвета на лисе, но может их поломать на других не-хром браузерах или на мобильных устройствах, и это надо пробовать, а не безосновательно полагать, что их кодят так же как лису.
>>1410569
В случае игнорирования тегов согласен. В случае эвристики по разрешению могут и послать, так что как минимум тег BT.709 на HD надо ставить. Всегда правильно в апстрим долбить, конечно, тут ты прав. У меня штук 5 багов к ним уже накопилось. Просто здоровый апстрим это такая непоротливая махина, что всегда проще вокрэраундом заделать. Да и возни сколько, и когда это задеплоят только. В случае с многодорожечными webm просто повезло выйти сразу на разработчика, поэтому быстро исправили. А обычный баг они фиг знает сколько мариновать будут, у них там десятилетние открытые ишью в багзилле не редкость. Может как-нибудь и зашлю, если не лень будет.
Есть эвристика по разрешению, но не воспринимает теги? Как-то сомнительно.
Кстати, я тут глянул на свежем релизе Shimoneta от SallySubs и таки тег стоит. И цветовая матрица, и tv levels.
>Надо просто долбить лисоделов этой проблемой
В случае игнорирования тегов согласен. В случае эвристики по разрешению могут и послать, так что как минимум тег BT.709 на HD надо ставить. Всегда правильно в апстрим долбить, конечно, тут ты прав. У меня штук 5 багов к ним уже накопилось. Просто здоровый апстрим это такая непоротливая махина, что всегда проще вокрэраундом заделать. Да и возни сколько, и когда это задеплоят только. В случае с многодорожечными webm просто повезло выйти сразу на разработчика, поэтому быстро исправили. А обычный баг они фиг знает сколько мариновать будут, у них там десятилетние открытые ишью в багзилле не редкость. Может как-нибудь и зашлю, если не лень будет.
>но может их поломать на других не-хром браузерах или на мобильных устройствах
Есть эвристика по разрешению, но не воспринимает теги? Как-то сомнительно.
Кстати, я тут глянул на свежем релизе Shimoneta от SallySubs и таки тег стоит. И цветовая матрица, и tv levels.
>>1410569
Да, лол, долбить тогда заодно и админов имиджборд, т.к. для превью всегда BT.601 используется. В общем, ты охуеешь делать всё по-нормальному.
Да, лол, долбить тогда заодно и админов имиджборд, т.к. для превью всегда BT.601 используется. В общем, ты охуеешь делать всё по-нормальному.
>>1410578
А ты не заметил, что концепция борд протухла и все это устарело? Поэтому этим говном серьезно никто не знаимается, на самом деле все протухло и требует принципиальной смены идей.
>2015г
>борды
А ты не заметил, что концепция борд протухла и все это устарело? Поэтому этим говном серьезно никто не знаимается, на самом деле все протухло и требует принципиальной смены идей.
126 Кб, Webm
116 Кб, Webm
57 Кб, Webm
116 Кб, Webm
>>1410569
Проверил — хром без тега HD показывает как BT.601. Теги правильно интерпретирует.
Вот для теста: HD BT.601 с тегом | HD BT.709 с тегом | SD BT.601 без тега | HD BT.709 без тега
Все должны выглядеть одинаково. VP8 всегда BT.601, кстати, тоже надо делать конвертацию, если на входе был BT.709.
Проверил — хром без тега HD показывает как BT.601. Теги правильно интерпретирует.
Вот для теста: HD BT.601 с тегом | HD BT.709 с тегом | SD BT.601 без тега | HD BT.709 без тега
Все должны выглядеть одинаково. VP8 всегда BT.601, кстати, тоже надо делать конвертацию, если на входе был BT.709.
799 Кб, 1280x720
>>1411030
В таком расположении плохо заметно просто. По пробелу в просмотрщике изображений сразу в глаза бросается. А на огромных 4K с градиентами вообще косяк очевиден → >>1407252
Средненький Dell на AH-IPS, ещё недостаточно упоролся, чтобы EIZO брать. Есть поддержка аппаратной калибровки через i1Display Pro, но пока заводской профиль sRGB использую, который должен быть более-менее точен. Сраные вебмки, из-за них пришлось новый монитор покупать и упарываться по color management…
В таком расположении плохо заметно просто. По пробелу в просмотрщике изображений сразу в глаза бросается. А на огромных 4K с градиентами вообще косяк очевиден → >>1407252
Средненький Dell на AH-IPS, ещё недостаточно упоролся, чтобы EIZO брать. Есть поддержка аппаратной калибровки через i1Display Pro, но пока заводской профиль sRGB использую, который должен быть более-менее точен. Сраные вебмки, из-за них пришлось новый монитор покупать и упарываться по color management…
>>1410371
Олсо, в структуре YCbCrBuffer у FF, которая содержит данные декодированного кадра, даже поля с цветовым пространством не предусмотрено. Мне интересно посмотреть, как они это фиксить будут.
Олсо, в структуре YCbCrBuffer у FF, которая содержит данные декодированного кадра, даже поля с цветовым пространством не предусмотрено. Мне интересно посмотреть, как они это фиксить будут.
>>1411154
Самое простое — экспортировать в коллекцию png и импортировать обратно с флагом -loop 1.
Самое простое — экспортировать в коллекцию png и импортировать обратно с флагом -loop 1.
>>1411154
Узнаешь фреймрейт и длительность гифки, разбираешь гифку на отдельные картинки, собираешь в вебэмку подстроив фреймрейт под длительность музыки или обрезав мукыку в нужном месте.
http://pastebin.com/VmJ0tFeG
Узнаешь фреймрейт и длительность гифки, разбираешь гифку на отдельные картинки, собираешь в вебэмку подстроив фреймрейт под длительность музыки или обрезав мукыку в нужном месте.
http://pastebin.com/VmJ0tFeG
>>1411192
Смотря для чего. См. https://git.videolan.org/?p=ffmpeg.git;a=blob;f=Changelog;h=515d649d85ee2d63aecdc6a384ad552d82329dd8;hb=HEAD
Лето было много фиксов в ffvp9; если версия старая, то будет сегфолтиться на некоторых VP9 видео. Ещё не было поддержки дополнительных профилей VP9 в декодере вообще. Из последнего интересного это улучшения встроенного энкодера AAC. Ну и VP9/Opus сделали дефолтными кодеками для формата WebM, но это так, мелочи.
И libvpx тоже лучше гитовый использовать, в котором декларируют увеличение производительности и качестве для VP9, но в Zeranoe билдах используется релизный 1.4.0.
Смотря для чего. См. https://git.videolan.org/?p=ffmpeg.git;a=blob;f=Changelog;h=515d649d85ee2d63aecdc6a384ad552d82329dd8;hb=HEAD
Лето было много фиксов в ffvp9; если версия старая, то будет сегфолтиться на некоторых VP9 видео. Ещё не было поддержки дополнительных профилей VP9 в декодере вообще. Из последнего интересного это улучшения встроенного энкодера AAC. Ну и VP9/Opus сделали дефолтными кодеками для формата WebM, но это так, мелочи.
И libvpx тоже лучше гитовый использовать, в котором декларируют увеличение производительности и качестве для VP9, но в Zeranoe билдах используется релизный 1.4.0.
>>1411263
У меня медиа плеер классик крашится при просмотре моих вебмок.
У меня медиа плеер классик крашится при просмотре моих вебмок.
1769 Кб, Webm
test
Нихуя не понял как запустить 10bit в хроме, плагин плагин vlc скачал установил, но, всё равно нихуя не работает
>>1411289
Делаешь раз:
// ==UserScript==
// @name set webm proto
// @namespace https://2ch.hk/webm-proto
// @include https://2ch.hk/*
// @version 1
// @grant none
// ==/UserScript==
[].forEach.call(document.querySelectorAll("a[href$='.webm']"),function(a){a.protocol="snews"})
Делаешь два:
cat >~/mpv-wrap <<EOF
#!/bin/bash
exec mpv "${1/snews/https}"
EOF
chmod +x ~/mpv-wrap
Кликаешь на webm и устанавливаешь /home/user/mpv-wrap в качестве обработчика протокола snews. Дикий костыль, но идею ты понел. Главное — работает.
Делаешь раз:
// ==UserScript==
// @name set webm proto
// @namespace https://2ch.hk/webm-proto
// @include https://2ch.hk/*
// @version 1
// @grant none
// ==/UserScript==
[].forEach.call(document.querySelectorAll("a[href$='.webm']"),function(a){a.protocol="snews"})
Делаешь два:
cat >~/mpv-wrap <<EOF
#!/bin/bash
exec mpv "${1/snews/https}"
EOF
chmod +x ~/mpv-wrap
Кликаешь на webm и устанавливаешь /home/user/mpv-wrap в качестве обработчика протокола snews. Дикий костыль, но идею ты понел. Главное — работает.
>>1411777
Кастомный протокол отдельно регестрировать надо, в FF по крайней мере. Лень было заморачиваться и вфигачил первый попавшийся устаревший.
Кастомный протокол отдельно регестрировать надо, в FF по крайней мере. Лень было заморачиваться и вфигачил первый попавшийся устаревший.
>>1408421
Посмотри на путь до вебм, а дальше сам догадаешься.
Посмотри на путь до вебм, а дальше сам догадаешься.
test
https://bugzilla.mozilla.org/show_bug.cgi?id=1210219
Ну вот, всё понемногу исправляется. Цветовые пространства бы ещё пофиксили.
>(ffvp9) [meta] Ship ffpv9 on all desktop platforms
Ну вот, всё понемногу исправляется. Цветовые пространства бы ещё пофиксили.
>>1410971
Таки да: https://chromium.googlesource.com/chromium/src.git/+/31bc5867e1112af8b82d780b47fcb3a6f337a8a0/media/filters/vpx_video_decoder.cc#548
FF, как обычно, соснул.
>Проверил — хром без тега HD показывает как BT.601. Теги правильно интерпретирует.
Таки да: https://chromium.googlesource.com/chromium/src.git/+/31bc5867e1112af8b82d780b47fcb3a6f337a8a0/media/filters/vpx_video_decoder.cc#548
FF, как обычно, соснул.
799 Кб, 1280x720
>>1412887
Но хром тоже на BT.2020 соснёт.
Кстати, интересно что на ютубе у видео нет тегов цветового пространства → вероятно все кроме десктопных плееров отображают их неправильно.
Но хром тоже на BT.2020 соснёт.
Кстати, интересно что на ютубе у видео нет тегов цветового пространства → вероятно все кроме десктопных плееров отображают их неправильно.
771 Кб, 1280x720
>>1410971
>>1412937
Ха, фф теперь точно соснул: https://chromium.googlesource.com/chromium/src.git/+/7cb4525761b68e41671af9006920d568be3c5405
Я на стабильной версии тестировал, а на 46+ уже починил. Есть и эвристика по разрешению, и BT.709 предпочитается.
Ну что, ффлюбы, как вам с неправильными цветами в видосах на ютубе живётся? :3
>>1412937
Ха, фф теперь точно соснул: https://chromium.googlesource.com/chromium/src.git/+/7cb4525761b68e41671af9006920d568be3c5405
Я на стабильной версии тестировал, а на 46+ уже починил. Есть и эвристика по разрешению, и BT.709 предпочитается.
Ну что, ффлюбы, как вам с неправильными цветами в видосах на ютубе живётся? :3
>>1413055
У 90% людей мониторы в принципе показывают левые цвета, а ты с браузерами хуйню развел. Будто ты эти вебмки смотришь в браузерах круглые сутки.
У 90% людей мониторы в принципе показывают левые цвета, а ты с браузерами хуйню развел. Будто ты эти вебмки смотришь в браузерах круглые сутки.
>>1413082
Причём здесь вебмки. Половина VP9 (дефолтный формат на ютубе) и софтвартно декодируемых H.264 видео в фаерфоксе отображается неправильно вообще на любом сайте. Хоть вебмка, хоть ютуб, хоть вконтакт. Аргумент дурацкий, неправильные цвета с фиговым монитором в правильные не превратятся. Это косяк и его надо исправлять.
Причём здесь вебмки. Половина VP9 (дефолтный формат на ютубе) и софтвартно декодируемых H.264 видео в фаерфоксе отображается неправильно вообще на любом сайте. Хоть вебмка, хоть ютуб, хоть вконтакт. Аргумент дурацкий, неправильные цвета с фиговым монитором в правильные не превратятся. Это косяк и его надо исправлять.
>>1412832
А количество голосов vote на что-нибудь влияет?
>Assigned To:\tNobody;
>Importance:\t-- normal
А количество голосов vote на что-нибудь влияет?
>>1395791 (OP)
котики христом аллахом прошу!!! срочно! где скачать autocad без смс и прочей хуйни. я в отчаянии анончик.
котики христом аллахом прошу!!! срочно! где скачать autocad без смс и прочей хуйни. я в отчаянии анончик.
>>1413354
Голосуй, хуже не будет.
Голосуй, хуже не будет.
7 Кб, 640x96
>>1395791 (OP)
Я не очень понимаю, ffmpeg не доволен размером видео или что?
Я не очень понимаю, ffmpeg не доволен размером видео или что?
3934 Кб, Webm
>>1413403
Нет. Он недоволен тем, что ты ему в subtitles подсунул. Показывай, что написал.
Нет. Он недоволен тем, что ты ему в subtitles подсунул. Показывай, что написал.
>>1413408
ffmpeg -i c:/space/1.mkv -ss 11:50 -t 95 -map 0:0 -map 0:6 -c:a libvorbis -vf subtitles=0:7 -pass 1 c:/space/1.webm
Причем когда я первый раз вместо дорожки видео(0:0) случайно написал 0:1(аудио), то он спокойно начал обрабатывать все, а как пофиксил начал выдавать этот эррор
ffmpeg -i c:/space/1.mkv -ss 11:50 -t 95 -map 0:0 -map 0:6 -c:a libvorbis -vf subtitles=0:7 -pass 1 c:/space/1.webm
Причем когда я первый раз вместо дорожки видео(0:0) случайно написал 0:1(аудио), то он спокойно начал обрабатывать все, а как пофиксил начал выдавать этот эррор
5025 Кб, Webm
>>1413411
Потому что проигнорировал -vf, ибо не было видеопотока
У тебя несколько сабов в файле?
Если нет, то напиши:
subtitles='c\:\\space\\1.mkv'
и добавь
-sn
чтобы софтсаба в вебм не было.
> случайно написал 0:1(аудио)
Потому что проигнорировал -vf, ибо не было видеопотока
У тебя несколько сабов в файле?
Если нет, то напиши:
subtitles='c\:\\space\\1.mkv'
и добавь
-sn
чтобы софтсаба в вебм не было.
21 Кб, 641x118
>>1413417
ffmpeg -i c:/space/1.mkv -ss 11:50 -t 95 -map 0:0 -map 0:6 -c:a libvorbis -sn -vf subtitles=c:/space/1.mkv -pass 1 c:/space/1.webm
Теперь вот это выпадает:
ffmpeg -i c:/space/1.mkv -ss 11:50 -t 95 -map 0:0 -map 0:6 -c:a libvorbis -sn -vf subtitles=c:/space/1.mkv -pass 1 c:/space/1.webm
Теперь вот это выпадает:
224 Кб, Webm
>>1413420
С таким мне не приходилось иметь дело.
Попробуй сделать
ffmpeg -i c:/space/1.mkv -map 0:7 c:/space/1.ass
Если получится то измени оригинал
на
vf ass='c\:\\space\\1.ass'
>>1413427
Потому что : и \ нужно экранировать с помощью \ смотри внимательней >>1413417
И почему у тебя вообще прямые слеши вместо обратных, ты же на линукс?
С таким мне не приходилось иметь дело.
Попробуй сделать
ffmpeg -i c:/space/1.mkv -map 0:7 c:/space/1.ass
Если получится то измени оригинал
на
vf ass='c\:\\space\\1.ass'
>>1413427
Потому что : и \ нужно экранировать с помощью \ смотри внимательней >>1413417
И почему у тебя вообще прямые слеши вместо обратных, ты же на линукс?
>>1413430
Субтитры норм получились, проверил, работают, изменил, но выдает все ту же ошибку, не хочет кушать, ладно, обойдусь без них, спасибо что пытался
Субтитры норм получились, проверил, работают, изменил, но выдает все ту же ошибку, не хочет кушать, ладно, обойдусь без них, спасибо что пытался
4512 Кб, Webm
>>1413435
Последний совет
в vf ass и vf subititles
нужно указывать не двойные кавычки "", а одинарные ''
Последний совет
в vf ass и vf subititles
нужно указывать не двойные кавычки "", а одинарные ''
>>1413476
КАК
КАК
>>1413476
Не хватает только кости вверх подброшенной.
Не хватает только кости вверх подброшенной.
>>1413491
ага
ага
>>1413493
долбоеб вкрутил две видеодорожки туда
долбоеб вкрутил две видеодорожки туда
6144 Кб, Webm
6144 Кб, Webm
6144 Кб, Webm
115 Кб, 2578x684
Короче потестил -qmin -qmax немного.
Указывание -qmin позволяет существенно (очень существенно) экономить битрейт при кодировании с указанием битрейта, -qmax позволяет избавиться от квадратов, но при этом может сильно выше указанного битрейта получиться, надо подбирать.
Если в лимит заведомо влезает, то лучше, конечно, использовать -b:v 0 -crf ..., но если кодировать по лимиту, то если указать, например, -b:v 300k -qmin 30 -qmax 45 (qmin-qmax надо менять в зависимости от видео, чтобы соответствовало битрейту), то результат будет лучше, чем если просто ставить -b:v 300k.
Ну если кодировать с указанием битрейта не по лимиту, то можно указать, например, -qmin 25 и размер итоговый будет меньше без видимого ухудшения качества.
Указывание -qmin позволяет существенно (очень существенно) экономить битрейт при кодировании с указанием битрейта, -qmax позволяет избавиться от квадратов, но при этом может сильно выше указанного битрейта получиться, надо подбирать.
Если в лимит заведомо влезает, то лучше, конечно, использовать -b:v 0 -crf ..., но если кодировать по лимиту, то если указать, например, -b:v 300k -qmin 30 -qmax 45 (qmin-qmax надо менять в зависимости от видео, чтобы соответствовало битрейту), то результат будет лучше, чем если просто ставить -b:v 300k.
Ну если кодировать с указанием битрейта не по лимиту, то можно указать, например, -qmin 25 и размер итоговый будет меньше без видимого ухудшения качества.
>>1413922
А что происходит, если указывать -qmin и -qmax с ненулевым битрейтом? У меня они игнорировались вроде как
кодирую через -qmin + -crf + -b:v 0
А что происходит, если указывать -qmin и -qmax с ненулевым битрейтом? У меня они игнорировались вроде как
кодирую через -qmin + -crf + -b:v 0
>>1413930
Если у тебя -b:v 0 и указан -crf, то -qmin не нужен, будет кодироваться с постоянным качеством.
Если у тебя -b:v 0 и указан -crf, то -qmin не нужен, будет кодироваться с постоянным качеством.
>>1413932
Не совсем, у -crf тоже есть некая свобода действий. Особенно заметно на простых видео — даже очень маленький -crf без -qmax может дать на выходе плохое качество.
Тем временем новый быдлокод: http://pastebin.com/YVgFxi4Z
Нарезка в uncompressed RGB, под впечатлением от http://amvnews.ru/index.php?go=Pages&in=view&id=33
Не тормозит в редакторе + тот же блендер использует BT.601 при конвертации при закидывании YCbCr, что даёт неправильные цвета для большинства видео. Вначале avidemux поставил, но он такое убогое говно, что пользоваться просто невозможно, да и uncompressed из него почему-то не вытащить, только lossless (впрочем, я особо не копался, он просто убог).
Не совсем, у -crf тоже есть некая свобода действий. Особенно заметно на простых видео — даже очень маленький -crf без -qmax может дать на выходе плохое качество.
Тем временем новый быдлокод: http://pastebin.com/YVgFxi4Z
Нарезка в uncompressed RGB, под впечатлением от http://amvnews.ru/index.php?go=Pages&in=view&id=33
Не тормозит в редакторе + тот же блендер использует BT.601 при конвертации при закидывании YCbCr, что даёт неправильные цвета для большинства видео. Вначале avidemux поставил, но он такое убогое говно, что пользоваться просто невозможно, да и uncompressed из него почему-то не вытащить, только lossless (впрочем, я особо не копался, он просто убог).
Я может немножко не по теме, но вроде как и по теме. В общем решил запилить вебмку небольшую, в смысле маленькую. Записал видос бандикамом, порезал его в Sony Vegas Pro 13.0, отрендил, получил файл 33 секунды продолжительностью и размером в 518 ЕБАНЫХ МЕГАБАЙТ. Как так-то? Я даже разрешение поставил меньше. Почему такой объем? Откуда бледь?
>>1413946
Выводи в uncompressed AVI и сжимай затем нормально ffmpeg'ом. Редакторы традиционно не умеют нормально транскодить, да и не их работа как бы.
Выводи в uncompressed AVI и сжимай затем нормально ffmpeg'ом. Редакторы традиционно не умеют нормально транскодить, да и не их работа как бы.
>>1413948
Оу. То есть это нормальная ситуация? Я думал я просто очень неочень.
Оу. То есть это нормальная ситуация? Я думал я просто очень неочень.
Аноны, у меня наитупейший вопрос, в какую директорию нужно положить видео, чтобы ffmpeg его нашел?
>>1413974
Либо указывай директорию полностью, либо сначала переходи в директорию из консоли и указывай имена файлов внутри.
Либо указывай директорию полностью, либо сначала переходи в директорию из консоли и указывай имена файлов внутри.
>>1413986
Спасибо
Спасибо
5914 Кб, Webm
Есть какие-нибудь, хм, гайды по подбору -crf? Или рекомендуемые значения. Например, для h264 указывается промежуток 18-28, для vp9 есть такое?
Вот это 32, 31 уже не влезает. Для vp9 такое значение нормально?
Вот это 32, 31 уже не влезает. Для vp9 такое значение нормально?
>>1414126
30-35 это весьма хорошее качество.
В вики вроде рекомендовали 20, но это излишний расход битрейта, разницу с 30 очень трудно заметить.
30-35 это весьма хорошее качество.
В вики вроде рекомендовали 20, но это излишний расход битрейта, разницу с 30 очень трудно заметить.
>>1414126
Сам смотри же, насколько видео распидорашивает.
Значение 30 я бы назвал умеренным распидорашиванием: если ставить на паузу, то небольшие артефакты можно разглядеть без сравнения с соусом почти всегда.
Сам смотри же, насколько видео распидорашивает.
Значение 30 я бы назвал умеренным распидорашиванием: если ставить на паузу, то небольшие артефакты можно разглядеть без сравнения с соусом почти всегда.
>>1414155
Я бы сказал, если ставить на паузу и охуенно приближать.
При просмотре на харкаче разницы между 10 и 30 никто не увидит.
Я бы сказал, если ставить на паузу и охуенно приближать.
При просмотре на харкаче разницы между 10 и 30 никто не увидит.
>>1414165
От исходника зависит. С большим числом деталей или быстрым движением сразу в квадраты распидорасит. Даже 25 по сравению с 23 уже плохо. Попробуй какой-нибудь parkjoy в -crf 30 и охуеешь. Или, я не знаю, сцену в GIRL когда всё взрывается.
От исходника зависит. С большим числом деталей или быстрым движением сразу в квадраты распидорасит. Даже 25 по сравению с 23 уже плохо. Попробуй какой-нибудь parkjoy в -crf 30 и охуеешь. Или, я не знаю, сцену в GIRL когда всё взрывается.
>>1414176
Если -b:v 0 -crf 30, то никаких квадратов не будет.
При большом количестве движения просто битрейта больше сожрет.
Если -b:v 0 -crf 30, то никаких квадратов не будет.
При большом количестве движения просто битрейта больше сожрет.
5826 Кб, Webm
>>1414181
Больше похоже на то, что >>1414176 прав. Анимешные опенинги длиной в полторы минуты кодируются примерно с одинаковым crf (около 30).
Релейтед кодировался с -qmin 27 -crf 30. Обрати внимание на воду и увидишь, что квадраты завезли.
особой разницы по качеству с qmin или без я не замечал.
Больше похоже на то, что >>1414176 прав. Анимешные опенинги длиной в полторы минуты кодируются примерно с одинаковым crf (около 30).
>никаких квадратов не будет
Релейтед кодировался с -qmin 27 -crf 30. Обрати внимание на воду и увидишь, что квадраты завезли.
особой разницы по качеству с qmin или без я не замечал.
>>1414239
Дай ссылку на исхдник и время.
Более чем уверен, что если правильно кодировать (а не с указанием каких-то левых -qmin 27 и других левых настроек), то такой размытой картинки не будет при -b:v 0 -crf 30 в этом же примере.
Дай ссылку на исхдник и время.
Более чем уверен, что если правильно кодировать (а не с указанием каких-то левых -qmin 27 и других левых настроек), то такой размытой картинки не будет при -b:v 0 -crf 30 в этом же примере.
3636 Кб, Webm
>>1414248
Вот http://goo.gl/Beh5kj https://goo.gl/pgPfuI Качай OP2 clean, если сможешь. Звук в исходнике возможно будет спешить на 1.5 секунды.
Целый файл
Никаких кволити бест и speed 0/cpu_used 0, я могу себе позволить онли гуд + speed 1.
Звук: libopus -b:a 80k -vbr on -ac 2. В ином случае мне будет неинтересно, что там у тебя получится.
На остальные настройки ограничений нет.
>Дай ссылку на исхдник
Вот http://goo.gl/Beh5kj https://goo.gl/pgPfuI Качай OP2 clean, если сможешь. Звук в исходнике возможно будет спешить на 1.5 секунды.
>время
Целый файл
>правильно кодировать
Никаких кволити бест и speed 0/cpu_used 0, я могу себе позволить онли гуд + speed 1.
Звук: libopus -b:a 80k -vbr on -ac 2. В ином случае мне будет неинтересно, что там у тебя получится.
На остальные настройки ограничений нет.
1856 Кб, Webm
800 Кб, 1280x544
757 Кб, 1280x544
>>1414181
Так без жёсткого лимита он может меньше взять, всё правильно.
Вот сложная сцена из GIRL (6:44), с crf30 все детали и контуры размыты нафиг. Скриншоты crf10 и crf30 для сравнения. Хотя квадратов почти нет, мылит в основном. Надо на других типах сцен попробовать, что-нибудь вроде быстрых движений градиентов.
>а не с указанием каких-то левых -qmin 27
Так без жёсткого лимита он может меньше взять, всё правильно.
Вот сложная сцена из GIRL (6:44), с crf30 все детали и контуры размыты нафиг. Скриншоты crf10 и crf30 для сравнения. Хотя квадратов почти нет, мылит в основном. Надо на других типах сцен попробовать, что-нибудь вроде быстрых движений градиентов.
>>1414276
Закодирую, посмотрим.
Ну я всегда со -speed 0 кодирую, но посмотрим и со -speed 1.
Звук роли никакой не играет.
Закодирую, посмотрим.
Ну я всегда со -speed 0 кодирую, но посмотрим и со -speed 1.
Звук роли никакой не играет.
>>1414279
Я серьезно мало представляю, как можно при просмотре этой вебмки различить первый и второй скрины.
А квадратов нет, мыла совсем немного, но на такой скорости оно незаметно в любом случае.
Ну и понятно, что -crf 30 это не лосслес, поэтому разница с оригиналом, конечно, будет.
Но чтобы заметить ее надо специально вглядываться в различия.
Квадраты заметить легко, а то, что тут что-то сгладилось слишком сильно, заметить при просмотре нельзя.
Я серьезно мало представляю, как можно при просмотре этой вебмки различить первый и второй скрины.
А квадратов нет, мыла совсем немного, но на такой скорости оно незаметно в любом случае.
Ну и понятно, что -crf 30 это не лосслес, поэтому разница с оригиналом, конечно, будет.
Но чтобы заметить ее надо специально вглядываться в различия.
Квадраты заметить легко, а то, что тут что-то сгладилось слишком сильно, заметить при просмотре нельзя.
>>1414286
Если учесть, что он отнимает от лимита в 20M ~900кб, то можно и без звука вообще.
> Звук роли никакой не играет.
Если учесть, что он отнимает от лимита в 20M ~900кб, то можно и без звука вообще.
>>1414295
При просмотри сцены целиком в глаза сразу всё мыло бросается. Кодеки на подобных сценах в режиме VBR уйму битрейта тратят.
При просмотри сцены целиком в глаза сразу всё мыло бросается. Кодеки на подобных сценах в режиме VBR уйму битрейта тратят.
38 Кб, 859x649
Ну вот у меня при -crf 30 вполне приемлемо получилось даже со -speed 1.
Квадраты на воде значительно менее заметны и цветочки без говна.
И битрейт почему-то больше, чем у тебя, так что неправильный у тебя какой-то -crf 30 в той вебм.
Посмотрим еще, что со -speed 0 будет, когда докодируется.
https://2ch.hk/media/src/9670/14439718875060.webm
Квадраты на воде значительно менее заметны и цветочки без говна.
И битрейт почему-то больше, чем у тебя, так что неправильный у тебя какой-то -crf 30 в той вебм.
Посмотрим еще, что со -speed 0 будет, когда докодируется.
https://2ch.hk/media/src/9670/14439718875060.webm
>>1414348
Нет, обсуждали мы -b:v 0 -crf 30 -speed 1, как я и закодировал, сам все видишь.
Под лимит кодируется с указыванием битрейта, а там уже далеко не -b:v 0 -crf 30.
Нет, обсуждали мы -b:v 0 -crf 30 -speed 1, как я и закодировал, сам все видишь.
Под лимит кодируется с указыванием битрейта, а там уже далеко не -b:v 0 -crf 30.
>>1414355
Ну ладно.
Я уже пару месяцев не кодирую через битрейт, только -crf, иногда с добавлением -qmin -qmax.
Ну ладно.
> Под лимит кодируется с указыванием битрейта
Я уже пару месяцев не кодирую через битрейт, только -crf, иногда с добавлением -qmin -qmax.
>>1414365
Может быть, а может и нет.
Почему ты прописываешь такие дефолты, как auto-alt-ref, lag-in-frames и c:v vp9? Обнови ffmpeg чтоли.
>Ты неправильно кодируешь
Может быть, а может и нет.
>последний скрин
Почему ты прописываешь такие дефолты, как auto-alt-ref, lag-in-frames и c:v vp9? Обнови ffmpeg чтоли.
>>1414369
Чтобы при
Ничего не менять и все работало как до обновления.
Хуже от прописывания дефолтов не становится.
> Почему ты прописываешь такие дефолты
Чтобы при
>Обнови ffmpeg
Ничего не менять и все работало как до обновления.
Хуже от прописывания дефолтов не становится.
>>1414369
Этот вопрос может только мамкин модератор решить, видать в универе на факультете пердоления ffmpeg учится, так что выложи исходники видоса, параметры кодирования и жди его решения о том правильно или нет ты всё делаешь
>Ты неправильно кодируешь, все, что я могу сказать.
>Может быть, а может и нет.
Этот вопрос может только мамкин модератор решить, видать в универе на факультете пердоления ffmpeg учится, так что выложи исходники видоса, параметры кодирования и жди его решения о том правильно или нет ты всё делаешь
>>1395791 (OP)
С недавних пор зацикливается нормально. Конкретно на текущей 41.0.1 точно как надо.
> — ролики с opus'ом в firefox зацикливаются не с начала, а с последнего ключевого кадра.
С недавних пор зацикливается нормально. Конкретно на текущей 41.0.1 точно как надо.
38 Кб, 859x647
>>1414343
-speed 0 сэкономил 461 килобайт, то есть примерно 7% битрейта при том же качестве картинки.
https://2ch.hk/media/src/9670/14439743185370.webm
-speed 0 сэкономил 461 килобайт, то есть примерно 7% битрейта при том же качестве картинки.
https://2ch.hk/media/src/9670/14439743185370.webm
>>1400809
А какие форматы с ним использовал на входе и выходе? Я вот не понимаю — то ли я криворкий, то ли действительно всё так через жопу сделано, но при скармливании ему YUV клипов (любой обычный исходник), используются только BT.601 коэффициенты. В настройках ничего похожего не нашёл, в гугле только какой-то дохлый патч и всё. Если рендерить этот отредактированный YUV в AVI Raw, то цвета все поедут, разумеется. Если отрендерить в H.264 Lossless YUV, то цвета вроде на месте (т.к. при обратной конвертации та же матрица используется), но какого-то хуя картинка мылится. Декодер H.264 там кривой какой-то что ли.
Пока ничего лучше не придумал, кроме как работать только с uncompressed RGB. Единственное, что больше 8бит на цвет AVI не поддерживает. Можно с помощью 16-битных PNG обойти, но они медленее сохраняются/обрабатываются.
>использовал же <…> и немного blender.
А какие форматы с ним использовал на входе и выходе? Я вот не понимаю — то ли я криворкий, то ли действительно всё так через жопу сделано, но при скармливании ему YUV клипов (любой обычный исходник), используются только BT.601 коэффициенты. В настройках ничего похожего не нашёл, в гугле только какой-то дохлый патч и всё. Если рендерить этот отредактированный YUV в AVI Raw, то цвета все поедут, разумеется. Если отрендерить в H.264 Lossless YUV, то цвета вроде на месте (т.к. при обратной конвертации та же матрица используется), но какого-то хуя картинка мылится. Декодер H.264 там кривой какой-то что ли.
Пока ничего лучше не придумал, кроме как работать только с uncompressed RGB. Единственное, что больше 8бит на цвет AVI не поддерживает. Можно с помощью 16-битных PNG обойти, но они медленее сохраняются/обрабатываются.
>>1395791 (OP)
Здесь хорошо разбираются в ffmpeg, поэтому вопрос вне webm.
Нужно перекодировать flac в lame mp3.
https://ffmpeg.org/ffmpeg-all.html#libmp3lame-1
Это все доступные опции lame? Ему нельзя скармливать те опции, которые есть в обычном lame (типа --noreplaygain)?
Здесь хорошо разбираются в ffmpeg, поэтому вопрос вне webm.
Нужно перекодировать flac в lame mp3.
https://ffmpeg.org/ffmpeg-all.html#libmp3lame-1
Это все доступные опции lame? Ему нельзя скармливать те опции, которые есть в обычном lame (типа --noreplaygain)?
>>1414674
Видимо, не стали добавлять, т.к. у фильтра volume есть своя реализация replaygain: https://ffmpeg.org/ffmpeg-all.html#volume
По умолчанию в библиотеке он выключен: https://github.com/rbrito/lame/blob/7d3e1a652281952f20c7e11806aef3f837f9b51d/include/lame.h#L295
Если нужна реализация именно из LAME, то сэнкоди ей отдельно, потом этот трек в FFmpeg используй. UNIX-way же.
Видимо, не стали добавлять, т.к. у фильтра volume есть своя реализация replaygain: https://ffmpeg.org/ffmpeg-all.html#volume
По умолчанию в библиотеке он выключен: https://github.com/rbrito/lame/blob/7d3e1a652281952f20c7e11806aef3f837f9b51d/include/lame.h#L295
Если нужна реализация именно из LAME, то сэнкоди ей отдельно, потом этот трек в FFmpeg используй. UNIX-way же.
>>1395791 (OP)
Антонус, у меня пара вопросов, вебм рилейтед:
Есть один premiere pro и свои смехохуечки отснятые с андроида.
Но вот беда примьера не дружит с вебм и, с алсо, половиной порно.flv'шек с интернета. Что плохо т.к. хочеться пиздить от туда контент.
Вопрос во что мне такое ффмпегом конвертнуть так что бы максимум быстро и без потерь, что потом мог бы импортнуть в premiere pro? На размер похуй.
Второе, алсо, есть один диск блу рей, чем его рипнуть со снятием зашит и всего такого. Помню давно делал это в AnyDVD HD. Но может за время появилось что швабодное или не настолько мокрописечное?
Антонус, у меня пара вопросов, вебм рилейтед:
Есть один premiere pro и свои смехохуечки отснятые с андроида.
Но вот беда примьера не дружит с вебм и, с алсо, половиной порно.flv'шек с интернета. Что плохо т.к. хочеться пиздить от туда контент.
Вопрос во что мне такое ффмпегом конвертнуть так что бы максимум быстро и без потерь, что потом мог бы импортнуть в premiere pro? На размер похуй.
Второе, алсо, есть один диск блу рей, чем его рипнуть со снятием зашит и всего такого. Помню давно делал это в AnyDVD HD. Но может за время появилось что швабодное или не настолько мокрописечное?
>>1414697
Uncompressed AVI RGB. Вот статья как раз целиком про это: http://amvnews.ru/index.php?go=Pages&in=view&id=33
Отсос только если надо >8бит. Самое простое, по идее, через пнгшки в таком случае.
>Вопрос во что мне такое ффмпегом конвертнуть так что бы максимум быстро и без потерь, что потом мог бы импортнуть в premiere pro? На размер похуй.
Uncompressed AVI RGB. Вот статья как раз целиком про это: http://amvnews.ru/index.php?go=Pages&in=view&id=33
Отсос только если надо >8бит. Самое простое, по идее, через пнгшки в таком случае.
>>1414701
Кстати, это справедливо вообще для любого видео-редактора, даже если формат исходного видео поддерживается. См., например, >>1414649 Косяки с неправильными цветовыми пространствами YUV, тормоза, странные артефакты. Да и редакторы, как я понимаю, только в RGB оперируют со всеми эффектами и цветом.
Если целевые клипы короткие, то вообще никаких проблем с занимаемым пространством нет. Купить 2 2TB винта, в RAID0 их и всю нарезку туда. Если винт отвалится, то пофиг вообще, ничего кроме временных непожатых фрагментов там не хранить.
Кстати, это справедливо вообще для любого видео-редактора, даже если формат исходного видео поддерживается. См., например, >>1414649 Косяки с неправильными цветовыми пространствами YUV, тормоза, странные артефакты. Да и редакторы, как я понимаю, только в RGB оперируют со всеми эффектами и цветом.
Если целевые клипы короткие, то вообще никаких проблем с занимаемым пространством нет. Купить 2 2TB винта, в RAID0 их и всю нарезку туда. Если винт отвалится, то пофиг вообще, ничего кроме временных непожатых фрагментов там не хранить.
>>1414739
А смысл?
1. Не умеет >8бит (ффмпеговский вариант ffvhuv плохо поддерживается).
2. Тормознее несжатого, а места не так уж и много экономит.
3. Твоя команда даст на выходе YUV, который не желателен.
4. Самое главное: не поддерживает сабсэмплинг выше 4:2:2 при использовании YUV, значит как раз-таки есть шанс похерить цвета.
>>1414740
Ты думаешь редактор в YUV работает при накладывании эффектов? Преобразование цветового пространства в любом случае будет и поэтому надо сделать это правильно заранее. Вначале сабсэмплинг осиль.
А смысл?
1. Не умеет >8бит (ффмпеговский вариант ffvhuv плохо поддерживается).
2. Тормознее несжатого, а места не так уж и много экономит.
3. Твоя команда даст на выходе YUV, который не желателен.
4. Самое главное: не поддерживает сабсэмплинг выше 4:2:2 при использовании YUV, значит как раз-таки есть шанс похерить цвета.
>>1414740
>цвета херит
Ты думаешь редактор в YUV работает при накладывании эффектов? Преобразование цветового пространства в любом случае будет и поэтому надо сделать это правильно заранее. Вначале сабсэмплинг осиль.
>>1414742
https://helpx.adobe.com/after-effects/using/color-basics.html#color_models_and_color_spaces
http://www.dvxuser.com/V6/showthread.php?9760-Render-in-RGB-or-YUV-difference-MB-probs
Внутренне использует RGB, фильтры работают в RGB. При любой обработке видео будут преобразования цветового пространства. А то, что ты потенциально проебал половину цветовой информации на дискретизации и цвета на популярных 10-битных релизах, тебя почему-то не волнует.
>>1414743
Ты понимаешь о чём вообще говоришь? Какое-то бессвязный набор баззвордов. H.264, в отличии от HuffYUV, и 4:4:4 поддерживает, и 10 бит умеет. Я уже не говорю о том, что работать с пожатым видео в редакторе — это идиотизм.
>Adobe After Effects
https://helpx.adobe.com/after-effects/using/color-basics.html#color_models_and_color_spaces
http://www.dvxuser.com/V6/showthread.php?9760-Render-in-RGB-or-YUV-difference-MB-probs
Внутренне использует RGB, фильтры работают в RGB. При любой обработке видео будут преобразования цветового пространства. А то, что ты потенциально проебал половину цветовой информации на дискретизации и цвета на популярных 10-битных релизах, тебя почему-то не волнует.
>>1414743
Ты понимаешь о чём вообще говоришь? Какое-то бессвязный набор баззвордов. H.264, в отличии от HuffYUV, и 4:4:4 поддерживает, и 10 бит умеет. Я уже не говорю о том, что работать с пожатым видео в редакторе — это идиотизм.
976 Кб, 3840x2160
1386 Кб, 3840x2160
>>1414760
Это интересно, похоже действительно возможно без конвертации: https://forums.adobe.com/thread/825920
Они, впрочем, неточности нивелируют использованием 32bpp, как я понял. А какое процентное соотношение между эффектами с YUV пометкой и без? Что-то нигде не указано.
Если есть возможность работать только в YUV на всех этапах, то так лучше, конечно. Можно использовать yuv444p16 с Y4M, FFV1 и FFVHUFF, если их AE поддерживает. Или yuv444p10 H.264 lossless в крайнем случае. Вообще странно, что так мало >8битных форматов без потерь.
Наркоман? Я уже не говорю о том, что ты даже нужный модуль найти не в состоянии.
В AE своя особая математика? Запатентовали хоть?
Ну давай посравниваем. Вот тебе оригинал RGB 8бит и скриншот с YUV 4:4:4 BT.709 limited range 8бит, сделанного с помощью ffmpeg одной командой. Покажи мощь проприетарных мокрописек на бандинге.
Чем ты гордишься-то вообще? Ты ж наверняка даже AE в аренду не взял. Типо здесь все такие тупые и никто кроме тебя не осилил зайти на трекер и скачать сборочку от васяна с кряком?
>Работает он в YUV, не все эффекты правда
Это интересно, похоже действительно возможно без конвертации: https://forums.adobe.com/thread/825920
Они, впрочем, неточности нивелируют использованием 32bpp, как я понял. А какое процентное соотношение между эффектами с YUV пометкой и без? Что-то нигде не указано.
Если есть возможность работать только в YUV на всех этапах, то так лучше, конечно. Можно использовать yuv444p16 с Y4M, FFV1 и FFVHUFF, если их AE поддерживает. Или yuv444p10 H.264 lossless в крайнем случае. Вообще странно, что так мало >8битных форматов без потерь.
>написанной в майкрософте
Наркоман? Я уже не говорю о том, что ты даже нужный модуль найти не в состоянии.
>с помощью пиздатых пипиетарных мокрописек
В AE своя особая математика? Запатентовали хоть?
>оптимизирующих цвета
Ну давай посравниваем. Вот тебе оригинал RGB 8бит и скриншот с YUV 4:4:4 BT.709 limited range 8бит, сделанного с помощью ffmpeg одной командой. Покажи мощь проприетарных мокрописек на бандинге.
>как не снилось обосанным пердоликам
Чем ты гордишься-то вообще? Ты ж наверняка даже AE в аренду не взял. Типо здесь все такие тупые и никто кроме тебя не осилил зайти на трекер и скачать сборочку от васяна с кряком?
>>1410569
Через 4 дня. Всем похуй. Тем временем, большая часть новых видосов на любом сайте продолжает отображаться неправильно.
>Надо просто долбить лисоделов этой проблемой
>Yeah, that looks to be the problem.
>In general our handling of different colourspaces is pretty bad.
>We'll need to fix that library to support both (or find/make a replacement), and then wire it up so that we use it correctly.
>UNCONFIRMED
Через 4 дня. Всем похуй. Тем временем, большая часть новых видосов на любом сайте продолжает отображаться неправильно.
>>1414964
Вообще, там есть потери, но не такие значительные и можно использовать больший bpp на выходе/dithering для уменьшения ошибок округления/артефактов.
Это да, там дофига подводных камней → >>1397217
И это ещё я не до конца осилил гамму и гамут. Может быть ещё веселее.
Вообще, там есть потери, но не такие значительные и можно использовать больший bpp на выходе/dithering для уменьшения ошибок округления/артефактов.
>чтоб сделать пикрилейтед из RGB картинки
Это да, там дофига подводных камней → >>1397217
И это ещё я не до конца осилил гамму и гамут. Может быть ещё веселее.
>>1414701
Внезапно: OpenEXR охуенен. Компиляем ImageMagick с --enable-hdri и --wth-openexr, используем офигенный VapourSynth:
import vapoursynth as vs
core = vs.get_core()
c = core.ffms2.Source("in.mkv")[0]
c = core.fmtc.resample(c, css="444")
c = core.fmtc.bitdepth(c, bits=32)
c = core.fmtc.matrix(c, mat="709", col_fam=vs.RGB)
c = core.imwri.Write(c, "EXR", "out%06d.exr")
c.set_output()
и получаем 16-битные RGB с плаващей точкей из YUV с минимальной погрешностью. Жаль, что в imwri пока нет поддержки quantum-depth=32, но зато fmtconv с 32bit float отлично работает. В блендере internal working space тоже RGBS, как я понял.
>Самое простое, по идее, через пнгшки в таком случае.
Внезапно: OpenEXR охуенен. Компиляем ImageMagick с --enable-hdri и --wth-openexr, используем офигенный VapourSynth:
import vapoursynth as vs
core = vs.get_core()
c = core.ffms2.Source("in.mkv")[0]
c = core.fmtc.resample(c, css="444")
c = core.fmtc.bitdepth(c, bits=32)
c = core.fmtc.matrix(c, mat="709", col_fam=vs.RGB)
c = core.imwri.Write(c, "EXR", "out%06d.exr")
c.set_output()
и получаем 16-битные RGB с плаващей точкей из YUV с минимальной погрешностью. Жаль, что в imwri пока нет поддержки quantum-depth=32, но зато fmtconv с 32bit float отлично работает. В блендере internal working space тоже RGBS, как я понял.
Сап, софтач! Пишу с первого смартфона в моей жизни - Nokia X2. Спрашивайте свои ответы.
2 Кб, 573x22
Аноны, я новичок в создании webm, почему при первом проходе ffmpeg нихрена не кодирует? Делаю все по первой фотке треда. Я идиот?
>>1415293
В первом проходе время не пишется. На frame смотри. Примерное общее количество кадров можешь узнать через fpsduration (оба значения отображаются в первых строчках вывода). Процент выполнения: frame/total_frames100. Общий прогресс ≈ pass1percent/2.5, т.к. первый проход чуть быстрее.
В первом проходе время не пишется. На frame смотри. Примерное общее количество кадров можешь узнать через fpsduration (оба значения отображаются в первых строчках вывода). Процент выполнения: frame/total_frames100. Общий прогресс ≈ pass1percent/2.5, т.к. первый проход чуть быстрее.
>>1415312
Я ебал разметку.
Я ебал разметку.
>Примерное общее количество кадров можешь узнать через fps×duration (оба значения отображаются в первых строчках вывода). Процент выполнения: frame/total_frames×100.
>>1415461
- treads 8 -speed 1 -frame-parallel 1 будет 7-10fps хуяриться даже на деревянном двухядернике, -speed 0 раза в 2 медленней
- treads 8 -speed 1 -frame-parallel 1 будет 7-10fps хуяриться даже на деревянном двухядернике, -speed 0 раза в 2 медленней
>>1415496
Да пох как оно пишется, все поняли о чем идет речь.
Да пох как оно пишется, все поняли о чем идет речь.
>>1415448
Зависит от длины видео же. Сейчас засёк, 1:36 на 29 секунд видео.
Зависит от длины видео же. Сейчас засёк, 1:36 на 29 секунд видео.
137 Кб, 1350x977
http://forum.doom9.org/showthread.php?p=1740028#post1740028
Тем временем предварительные результаты с MSU. Лучшая реализация хвалёного HEVC всего лишь на 3% лучше открыто-швободного VP9.
>>1415615
Лол, настолько охуенный энкодер, что даже в табличку не влезло. Я с таким же успехом могу в rawvideo с 9000fps энкодить. Ну да ладно, мы подождём пару дней до релиза полного обзора, чтобы не было обидно за пердолей.
Тем временем предварительные результаты с MSU. Лучшая реализация хвалёного HEVC всего лишь на 3% лучше открыто-швободного VP9.
>>1415615
Лол, настолько охуенный энкодер, что даже в табличку не влезло. Я с таким же успехом могу в rawvideo с 9000fps энкодить. Ну да ладно, мы подождём пару дней до релиза полного обзора, чтобы не было обидно за пердолей.
>>1415624
Как нет? А интелловский? А иттиам? В описании указано, что они в основном GPU энкодеры и оценивали. Тестировали и nvidia, просто в предварительных результатах нет почему-то, видимо всё совсем плохо. Одно ясно — nvenc соснул у x265 с проглотом, сколько бы дутых fps у тебя там не отображалось.
Генту-господа пожали плечами, скопировали ебилд в локальный оверлей, добавили ключик и привычно скомандовали emerge. Это тебе не cygwin в убогой консоли пердолить, рискуя словить ошибку компиляции из-за отличающейся среды.
>>1415632
Ну так считай SSIM, строй графики сам, если хочешь, чтобы эту поделку кто-то серьёзно воспринимал. А обычным людям достаточно сравнения от специалистов, которые показывают, что HEVC, в общем-то, провален, даже в лучшей реализации.
На минуточку, «x265 на 3% лучше libvpx-vp9» означает, что VP10 уже делает HEVC.
Как нет? А интелловский? А иттиам? В описании указано, что они в основном GPU энкодеры и оценивали. Тестировали и nvidia, просто в предварительных результатах нет почему-то, видимо всё совсем плохо. Одно ясно — nvenc соснул у x265 с проглотом, сколько бы дутых fps у тебя там не отображалось.
>пока господин не изволит собрать пакет
Генту-господа пожали плечами, скопировали ебилд в локальный оверлей, добавили ключик и привычно скомандовали emerge. Это тебе не cygwin в убогой консоли пердолить, рискуя словить ошибку компиляции из-за отличающейся среды.
>>1415632
Ну так считай SSIM, строй графики сам, если хочешь, чтобы эту поделку кто-то серьёзно воспринимал. А обычным людям достаточно сравнения от специалистов, которые показывают, что HEVC, в общем-то, провален, даже в лучшей реализации.
На минуточку, «x265 на 3% лучше libvpx-vp9» означает, что VP10 уже делает HEVC.
Test
test
хуй
Анон, помогай. Хочу загрузить webm в тематику, делаю файл из mp4 вот такой командой в этих своих линупсах (ubuntu 14.04):
avconv -i video.mp4 -vf scale=-1:240 -c:v vp8 -b:v 1.8M -c:a libvorbis video.webm
avconv там - это имя бинарника ffmpeg. Результурующий webm файл получается меньше 7Mb. При попытке запостить получаю сообщение файл слишком большой. До этого пробовал постить тот же файл, меньше пожатый 26, 18 и 9Mb. Всегда одна и та же ошибка. Что я делаю не так?
avconv -i video.mp4 -vf scale=-1:240 -c:v vp8 -b:v 1.8M -c:a libvorbis video.webm
avconv там - это имя бинарника ffmpeg. Результурующий webm файл получается меньше 7Mb. При попытке запостить получаю сообщение файл слишком большой. До этого пробовал постить тот же файл, меньше пожатый 26, 18 и 9Mb. Всегда одна и та же ошибка. Что я делаю не так?
>>1416050
Длительность 37 секунд (мало ли в ней дело)
Длительность 37 секунд (мало ли в ней дело)
>>1416056
Спасибо, анон, сделал < 6м, всё запостилось!
Спасибо, анон, сделал < 6м, всё запостилось!
8 Кб, 644x60
6 Кб, 332x166
ffmpeg -ss 00:00:10 -i 1.mp4 -to 00:00:15 -c:v libx264 -crf 23 -preset medium -profile:v high -level 4.1 -movflags +faststart -c:a aac -strict experimental -vbr 3 -ar 44100 -ac 2 -sn -y 2.mp4
1. Чё ему не так?
2. Почему сука констант бит рейт, я же пишу -vbr 3?
1. Чё ему не так?
2. Почему сука констант бит рейт, я же пишу -vbr 3?
>>1416780
Вероятно, ты выбрал не самый лучший энкодер. Попробуй libfdk_aac.
Вероятно, ты выбрал не самый лучший энкодер. Попробуй libfdk_aac.
Тест
Чем вообще могут быть полезны эти ваши вебемки кроме как выкладывания в тредах на харкаче?
>>1417423
Крупшейние видеохостинги вроде ютуба используют WebM в качестве основного формата хранения и распространения видео. Доброе утро.
Крупшейние видеохостинги вроде ютуба используют WebM в качестве основного формата хранения и распространения видео. Доброе утро.
А гугл где-нибудь публиковал как он кодирует вебм? Настройки там. Или все каштомное и скрытое?
Пацаны, а как напердолить гифочку? Я вот почитал, ну естественно с переделкой под винду
#!/bin/sh
palette="/tmp/palette.png"
filters="fps=15,scale=320:-1:flags=lanczos"
ffmpeg -v warning -i $1 -vf "$filters,palettegen" -y $palette
ffmpeg -v warning -i $1 -i $palette -lavfi "$filters [x]; [x][1:v] paletteuse" -y $2
это охуительно и оно работает, но вот palette.png получается килобайт с несколькими квадратами, и итоговая гифка 3 секунды - 5мб при 10фпс.
#!/bin/sh
palette="/tmp/palette.png"
filters="fps=15,scale=320:-1:flags=lanczos"
ffmpeg -v warning -i $1 -vf "$filters,palettegen" -y $palette
ffmpeg -v warning -i $1 -i $palette -lavfi "$filters [x]; [x][1:v] paletteuse" -y $2
это охуительно и оно работает, но вот palette.png получается килобайт с несколькими квадратами, и итоговая гифка 3 секунды - 5мб при 10фпс.
>>1417495
А ты как хотел?
Вот здесь есть некоторые советы по уменьшению размера/увеличению качества: http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html
Ну и уменьшай разрешение и fps. В аниме, например, реальный fps=8, часто можно до 5 уменьшить безболезненно.
А ты как хотел?
Вот здесь есть некоторые советы по уменьшению размера/увеличению качества: http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html
Ну и уменьшай разрешение и fps. В аниме, например, реальный fps=8, часто можно до 5 уменьшить безболезненно.
>>1417503
Какими аппаратными, если таких в природе не существует? Netflix говорят тоже на обычных CPU энкодит, например.
Какими аппаратными, если таких в природе не существует? Netflix говорят тоже на обычных CPU энкодит, например.
>>1417503
Поэтому в метаданных его вебмок указано:
Поэтому в метаданных его вебмок указано:
> Writing application : Lavf55.48.100
> Writing library : Lavf55.48.100
>>1417527
Но это же для потокового кодирования в реальном времени. То, что libvpx при таком использовании сосёт из-за скорости, ни для кого не секрет.
Покажи лучше железяку, которая обойдёт по качеству libvpx в двухпроходном режиме (а не по соотношению скорость/качество, которое вряд ли для ютуба сильно роляет).
Но это же для потокового кодирования в реальном времени. То, что libvpx при таком использовании сосёт из-за скорости, ни для кого не секрет.
Покажи лучше железяку, которая обойдёт по качеству libvpx в двухпроходном режиме (а не по соотношению скорость/качество, которое вряд ли для ютуба сильно роляет).
>>1417527
А ты с хакерньюз/реддита? Нашёл чем гордиться. Люди, интересующиеся темой, берут новости из мэйллистов и чатов с разработчиками.
Интересно, не знал. Только вот он как бы совсем не для VOD, это для real-time. Попробуй читать ссылки перед тем, как их постить.
>>1417530
Это что за такой вид троллинга винить пердоликов (кто это вообще в твоей классификации?) за низкое качество аппаратных энкодеров?
А ты с хакерньюз/реддита? Нашёл чем гордиться. Люди, интересующиеся темой, берут новости из мэйллистов и чатов с разработчиками.
Интересно, не знал. Только вот он как бы совсем не для VOD, это для real-time. Попробуй читать ссылки перед тем, как их постить.
>>1417530
Это что за такой вид троллинга винить пердоликов (кто это вообще в твоей классификации?) за низкое качество аппаратных энкодеров?
>>1417543
Нет ты. Вопрос был в том, что использует ютуб для энкодинга. Ответ: libvpx. Это, как бы, очевидно.
>ты не понимаешь суть железяк и их предназначение
Нет ты. Вопрос был в том, что использует ютуб для энкодинга. Ответ: libvpx. Это, как бы, очевидно.
>>1417529
В новых VP9, кстати:
Касательно настроек, там по всей логике CQ должен быть. Может в этом треде более точная информация есть:
http://forum.doom9.org/showthread.php?t=170682
В новых VP9, кстати:
>| + Muxing application: google
>| + Writing application: google
Касательно настроек, там по всей логике CQ должен быть. Может в этом треде более точная информация есть:
http://forum.doom9.org/showthread.php?t=170682
11 Кб, 1064x318
>>1417598
Я ебал этот дебилизм, когда пост не отправляется из-за слова в спамлисте, а какое именно слово — не говорится.
Я ебал этот дебилизм, когда пост не отправляется из-за слова в спамлисте, а какое именно слово — не говорится.
Помогите мне разобраться с ffmpeg.
ffmpeg -i 1234.mkv -i video.webm -map 0:a -c:a libopus -b:a 64k -map 1:v -c:v copy out.webm
Жирным выделен аудиоканал у исходника? Как мне взять из матрешки 4-ую дорожку (Stream #0:4)?
ffmpeg -i 1234.mkv -i video.webm -map 0:a -c:a libopus -b:a 64k -map 1:v -c:v copy out.webm
Жирным выделен аудиоканал у исходника? Как мне взять из матрешки 4-ую дорожку (Stream #0:4)?
>>1417889
Это пятая дорожка, лел.
Пиши -map 0:4
И пиши map с видеодорожкой перед map с аудио, чтобы лишних проблем не было:
-map 1:v -map 0:4
Это пятая дорожка, лел.
Пиши -map 0:4
И пиши map с видеодорожкой перед map с аудио, чтобы лишних проблем не было:
-map 1:v -map 0:4
>>1417889
-vbr on еще добавь, чтобы opus был с переменным битрейтом - так звук лучше будет.
-vbr on еще добавь, чтобы opus был с переменным битрейтом - так звук лучше будет.
>>1417940
Да, я уже разобрался. Но теперь другая проблема: вытаскиваются все 25 минут звука, не догоняю как вырезать нужный участок и запихать их в webm. Создавать отдельный аудиофайл, а потом склеивать?
Да, я уже разобрался. Но теперь другая проблема: вытаскиваются все 25 минут звука, не догоняю как вырезать нужный участок и запихать их в webm. Создавать отдельный аудиофайл, а потом склеивать?
>>1417946
То есть нельзя сделать что-то вроде -ss 00:05 -i 1234.mkv -t 15 -i blabla.webm -map 0:4 -c:a libopus -b:a 64k -map 1:v -c:v copy out.webm?
То есть нельзя сделать что-то вроде -ss 00:05 -i 1234.mkv -t 15 -i blabla.webm -map 0:4 -c:a libopus -b:a 64k -map 1:v -c:v copy out.webm?
>>1417960
Благодарю.
Благодарю.
35 Кб, 703x304
37 Кб, 652x261
Научите делать хардсаб.
Что именно нужно дописать чтоб добавить выделенные сабы в вырезанный отрывок (они идут 4 потоком как я понял)?
ffmpeg -i "C:\koko.mkv" -ss 00:16:00 -to 00:16:30 -vcodec vp9 -b:v 1200k -acodec libopus -b:a 256k -map 0:0 -map 0:2 -vf subtitles c:\inaba.webm -fs 10240k
Что именно нужно дописать чтоб добавить выделенные сабы в вырезанный отрывок (они идут 4 потоком как я понял)?
ffmpeg -i "C:\koko.mkv" -ss 00:16:00 -to 00:16:30 -vcodec vp9 -b:v 1200k -acodec libopus -b:a 256k -map 0:0 -map 0:2 -vf subtitles c:\inaba.webm -fs 10240k
>>1417987
ffmpeg -i "C:\koko.mkv" -ss 00:16:00 -to 00:16:30 -vcodec vp9 -b:v 1200k -acodec libopus -b:a 256k -map 0:0 -map 0:2 -vf "subtitles=C\\:/kokoko.mkv:si=1" c:\inaba.webm -fs 10240k
Можно ещё -ss перед -i для ускорения, тогда надо будет setpts перед subtitles ещё добавить.
ffmpeg -i "C:\koko.mkv" -ss 00:16:00 -to 00:16:30 -vcodec vp9 -b:v 1200k -acodec libopus -b:a 256k -map 0:0 -map 0:2 -vf "subtitles=C\\:/kokoko.mkv:si=1" c:\inaba.webm -fs 10240k
Можно ещё -ss перед -i для ускорения, тогда надо будет setpts перед subtitles ещё добавить.
>>1417987
Они идут 5-м потоком, который под номером 4
Ну я бы сделал так:
ffmpeg -i "C:\koko.mkv" -map 0:4 C:\koko.ass
ffmpeg -i "C:\koko.mkv" -ss 00:16:00 -to 00:16:30 -c:v vp9 -b:v 1200k -c:a libopus -b:a 256k -map 0:0 -map 0:2 -vf ass='C\:\\koko.mkv' -sn -y -an -pass 1 c:\inaba.webm
ffmpeg -i "C:\koko.mkv" -ss 00:16:00 -to 00:16:30 -c:v vp9 -b:v 1200k -c:a libopus -b:a 256k -map 0:0 -map 0:2 -vf ass='C\:\\koko.mkv' -sn -y -pass 2 c:\inaba.webm
Они идут 5-м потоком, который под номером 4
Ну я бы сделал так:
ffmpeg -i "C:\koko.mkv" -map 0:4 C:\koko.ass
ffmpeg -i "C:\koko.mkv" -ss 00:16:00 -to 00:16:30 -c:v vp9 -b:v 1200k -c:a libopus -b:a 256k -map 0:0 -map 0:2 -vf ass='C\:\\koko.mkv' -sn -y -an -pass 1 c:\inaba.webm
ffmpeg -i "C:\koko.mkv" -ss 00:16:00 -to 00:16:30 -c:v vp9 -b:v 1200k -c:a libopus -b:a 256k -map 0:0 -map 0:2 -vf ass='C\:\\koko.mkv' -sn -y -pass 2 c:\inaba.webm
>>1418006
Так встроенные шрифты не будут использоваться.
Так встроенные шрифты не будут использоваться.
>>1418002
Получилось, спасибо.
А где именно в этом отрезке происходит выбор дорожки субтитров -vf "subtitles=C\\:/kokoko.mkv:si=1"?
Получилось, спасибо.
А где именно в этом отрезке происходит выбор дорожки субтитров -vf "subtitles=C\\:/kokoko.mkv:si=1"?
>>1418025
si же, читай ман. Кстати, ссу на ValdikSS, который додумался сделать индекс субтитров относительным, а не абсолютным номером стрима.
si же, читай ман. Кстати, ссу на ValdikSS, который додумался сделать индекс субтитров относительным, а не абсолютным номером стрима.
>>1418028
Благодарю.
Благодарю.
А если субтитры лежат отдельным ass-файлом, то как их тогда вшивать в уже готовую webm?
-vf "ass=s\\:/1313.ass", тремя постами выше пример же, ёпт.
>>1395791 (OP)
Я хуею просто и у меня неимоверно печет.
Чтобы сделать сраное видео нужно блядь заниматься таким пердолингом, но я не собираюсь становится ПОГРОМИСТОМ и вообще даже вникать в эту муть. Уже перекачал с десяток программ, все какие-то ЗАУМНЫЕ пиздец, питоны, скрипты, хуитоны.. вы охуели блядь?? Это блядь ВИДЕО!!! Я вам не пентагон тут взламавать собираюсь!!! СУУУКИ!!!
И главное, все сраные видеоредакторы тоже отказываются конвентировать, ну что за скотство?
Есть же наверняка какой-то вариант без пердолинга? или хотите сказать школьники из бэ вот это вот все дрочат, клепая свои высеры?
Я хуею просто и у меня неимоверно печет.
Чтобы сделать сраное видео нужно блядь заниматься таким пердолингом, но я не собираюсь становится ПОГРОМИСТОМ и вообще даже вникать в эту муть. Уже перекачал с десяток программ, все какие-то ЗАУМНЫЕ пиздец, питоны, скрипты, хуитоны.. вы охуели блядь?? Это блядь ВИДЕО!!! Я вам не пентагон тут взламавать собираюсь!!! СУУУКИ!!!
И главное, все сраные видеоредакторы тоже отказываются конвентировать, ну что за скотство?
Есть же наверняка какой-то вариант без пердолинга? или хотите сказать школьники из бэ вот это вот все дрочат, клепая свои высеры?
>>1418908
Неужели тебе трудно скопировать один файл в какую-нибудь папку и создать батник с двумя строчками в этой же папке?
Неужели тебе трудно скопировать один файл в какую-нибудь папку и создать батник с двумя строчками в этой же папке?
>>1418909
У меня аллергия на консоли.
Да и как я в ней укажу точный тайминг обрезки, чтобы прям кадр в кадр?
Я скачал какой-то webm conveter, вот там все годно, по кадрам можно быстро отметить начало и конец, но он почему-то нихрена не сохраняет, а пишет следующее: ffmpeg.exe exited with exit code 1.
У меня аллергия на консоли.
Да и как я в ней укажу точный тайминг обрезки, чтобы прям кадр в кадр?
Я скачал какой-то webm conveter, вот там все годно, по кадрам можно быстро отметить начало и конец, но он почему-то нихрена не сохраняет, а пишет следующее: ffmpeg.exe exited with exit code 1.
>>1418908
Ввести команду в консоль это даже не уровень программиста-8миклассника, ведь программа уже написана за тебя.
Ввести команду в консоль это даже не уровень программиста-8миклассника, ведь программа уже написана за тебя.
>>1418908
Вот именно. Люди выдрачивают фильтры AviSynth, а то и свои пишут, оптимизируя под конкретную архитектуру до последнего такта. И о x264 ключах в многосотстраничных темах срутся. А тут какой-то быдлан решил, что это всё можно свести до нажатия одной кнопки в гуёвине.
>Это блядь ВИДЕО!!!
Вот именно. Люди выдрачивают фильтры AviSynth, а то и свои пишут, оптимизируя под конкретную архитектуру до последнего такта. И о x264 ключах в многосотстраничных темах срутся. А тут какой-то быдлан решил, что это всё можно свести до нажатия одной кнопки в гуёвине.
>>1418908
Именно. Изучай ffmpeg - это стильно, модно, молодежно. Он тебе всегда пригодится.
>хотите сказать школьники из бэ вот это вот все дрочат, клепая свои высеры
Именно. Изучай ffmpeg - это стильно, модно, молодежно. Он тебе всегда пригодится.
>>1419228
Разве что в твоих влажных фантазия.
Если бы абдуль был бы не корявой обезьяной и впилил бы поддержку h264 который сраным вебм ссал на рот, двачаю двач бы стал самым популярным видеохостингом рунета ибо нормальные кодеры уже давно обходятся двумя кнопками битрейт видио\качество аудио. А так нормальный человек с этим вашим вебм и фмпегом возиться не будет. Что мы и видим, в бэ треды с одни и теми же вебм месяцами.
Но пердодибилы, как и бюрократы, любят превращать в работу то что ей не являеться и создавать себе проблемы на ровном месте.
Гдеж он мне блять пригодиться то а? О нем блять и не услышал если бы не двачепомойка.
Разве что в твоих влажных фантазия.
Если бы абдуль был бы не корявой обезьяной и впилил бы поддержку h264 который сраным вебм ссал на рот, двачаю двач бы стал самым популярным видеохостингом рунета ибо нормальные кодеры уже давно обходятся двумя кнопками битрейт видио\качество аудио. А так нормальный человек с этим вашим вебм и фмпегом возиться не будет. Что мы и видим, в бэ треды с одни и теми же вебм месяцами.
Но пердодибилы, как и бюрократы, любят превращать в работу то что ей не являеться и создавать себе проблемы на ровном месте.
>Он тебе всегда пригодится.
Гдеж он мне блять пригодиться то а? О нем блять и не услышал если бы не двачепомойка.
1794 Кб, Webm
>>1419228
Пруф или проект без лидера и с неясным будущем, попирающий diversity и не проводящий программ по привлечению женщин и трансов к разработке. Настоящие SJW выбирают libav! Встречайте во всех дистрибутивах Linux ToleranUX.
>>1419383
Вембрелейтед. Подобное беспощное кукареканье уже столько раз разбиралось, в том числе в этом треде, что даже нечего добавить. Но ты, конечно, можешь воображать, как нам всем тут суть вещей показал.
Пруф или проект без лидера и с неясным будущем, попирающий diversity и не проводящий программ по привлечению женщин и трансов к разработке. Настоящие SJW выбирают libav! Встречайте во всех дистрибутивах Linux ToleranUX.
>>1419383
Вембрелейтед. Подобное беспощное кукареканье уже столько раз разбиралось, в том числе в этом треде, что даже нечего добавить. Но ты, конечно, можешь воображать, как нам всем тут суть вещей показал.
>>1418908
У меня для тебя плохие новости. Так с любой хуйней, в которой ты хочешь преуспеть. NO PAIN, NO GAIN
У меня для тебя плохие новости. Так с любой хуйней, в которой ты хочешь преуспеть. NO PAIN, NO GAIN
>>1419383
Зато уже четвёртый год смотришь его на Ютубе, лол.
>О нем блять и не услышал если бы не двачепомойка.
Зато уже четвёртый год смотришь его на Ютубе, лол.
>>1419383
ты совсем чтоли ебнутый, тупая мартышка? Кто ж ему даст столько ресурсов, гения ты инторнета? Абу всего лишь мелкая шавкапросто микроб среди господ видео-порнодельцов.
>двачаю двач бы стал самым популярным видеохостингом рунета
>видеохостинг
ты совсем чтоли ебнутый, тупая мартышка? Кто ж ему даст столько ресурсов, гения ты инторнета? Абу всего лишь мелкая шавкапросто микроб среди господ видео-порнодельцов.
Как в ffmpeg сделать кроп с разными значениями? С одной стороны надо обрезать чуть больше, чем с другой. Я сколько не гуглю, то везде нахожу только варианты с указанием одного значения для обрезки с двух сторон.
>>1419520
Ну вот есть видео формата 1280х720, надо обрезать 150 слева и 154 справа (точные цифры знаю из ковыряния через гуёвину). Как?
Ну вот есть видео формата 1280х720, надо обрезать 150 слева и 154 справа (точные цифры знаю из ковыряния через гуёвину). Как?
>>1419527
Я что-то затупил и ковырял не в том направлении, а оказалось всё проще. Спасибо.
Я что-то затупил и ковырял не в том направлении, а оказалось всё проще. Спасибо.
>>1395791 (OP)
MPC-HC крашится при попытке воспроизвести webm, что делать?
MPC-HC крашится при попытке воспроизвести webm, что делать?
>>1395791 (OP)
Делюсь ссылкой на скрипт для скачивания всех webm треда пока только для /b/ раздела:
http://ad-file.com/7ttjC8zMr
Можете добавить в шапку треда.
Делюсь ссылкой на скрипт для скачивания всех webm треда пока только для /b/ раздела:
http://ad-file.com/7ttjC8zMr
Можете добавить в шапку треда.
>>1419707
Сделай скрипт для скачивания всего треда с полноразмерными картинками и вебэмками. Чтоб было удобно сохранять интересные треды.
Сделай скрипт для скачивания всего треда с полноразмерными картинками и вебэмками. Чтоб было удобно сохранять интересные треды.
>>1419707
Лол, да ты охуел брать деньги за кривую версию wget -r -nd -I '∗/src' -A '∗.webm' -e robots=off, да ещё и без исходников GNU-утилит.
Пошёл писать Штуллману на gpl-violations.
>>1419736
Также однострочник на wget с опцией -k, сто лет как уже всё написано, я ещё на викентивскем двоще так треды сохранял. Это всё не очень пригодно, потому что ебанутый абу кладёт статику под защиту от дидоса, в результате чего простые UserAgent, не умеющие JavaScript, периодически получают 503. У меня вот сейчас два совершенно валидных IP блочатся, а постить так вообще теперь только с русского можно.
Есть же браузерные расширения для этого вроде DownThemAll и т.д.
Лол, да ты охуел брать деньги за кривую версию wget -r -nd -I '∗/src' -A '∗.webm' -e robots=off, да ещё и без исходников GNU-утилит.
Пошёл писать Штуллману на gpl-violations.
>>1419736
Также однострочник на wget с опцией -k, сто лет как уже всё написано, я ещё на викентивскем двоще так треды сохранял. Это всё не очень пригодно, потому что ебанутый абу кладёт статику под защиту от дидоса, в результате чего простые UserAgent, не умеющие JavaScript, периодически получают 503. У меня вот сейчас два совершенно валидных IP блочатся, а постить так вообще теперь только с русского можно.
Есть же браузерные расширения для этого вроде DownThemAll и т.д.
Платина наверное, но у меня в вебмках нет звука. Вообще ни в каких. Что надо сделать?
>>1419747
А, нет, есть вокрэраунд оказывается. Надо cf_clearance и правильный юзерагент поставить. Вот так работает:
wget -r -nd -I '∗/src/∗' -A '∗.webm' -e robots=off -U '<value>' --header 'Cookie: cf_clearance=<value>' <thread_url>
Нужные значения из вкладки Network по F12 можно достать. Юзерагент должен в точности совпадать, просто Mozilla/5.0 не катит. И звёздочки заменить на нормальные.
А, нет, есть вокрэраунд оказывается. Надо cf_clearance и правильный юзерагент поставить. Вот так работает:
wget -r -nd -I '∗/src/∗' -A '∗.webm' -e robots=off -U '<value>' --header 'Cookie: cf_clearance=<value>' <thread_url>
Нужные значения из вкладки Network по F12 можно достать. Юзерагент должен в точности совпадать, просто Mozilla/5.0 не катит. И звёздочки заменить на нормальные.
Поясните ньюфагу за скрипт по добавлению превью отдельной дорожкой по этой ссылке.
https://github.com/pituz/webm-thread/blob/master/tools/add-preview
Я с трудом понимаю отдельные куски.
https://github.com/pituz/webm-thread/blob/master/tools/add-preview
Я с трудом понимаю отдельные куски.
Проект Бесконечный Сосач©®™
Never stop watching WebM threads from 2ch.hk.
This script searches for WebM threads on a popular Russian imageboard 2ch.hk (formely 2ch.so, sosuch) and plays all the video files found. Usual porn and child porn, John Sena, Everybody knows shit's fucked, † CΛIN † - ama ama ama, Primo Victoria spinnings, kokovin93, Imya 505, Alexander Pistoletov, Green Elephant, My Little Pony, Korean PVs and MVs now on your desktop, endlessly! All played files could be saved in a directory.
https://github.com/ValdikSS/endless-sosuch
Never stop watching WebM threads from 2ch.hk.
This script searches for WebM threads on a popular Russian imageboard 2ch.hk (formely 2ch.so, sosuch) and plays all the video files found. Usual porn and child porn, John Sena, Everybody knows shit's fucked, † CΛIN † - ama ama ama, Primo Victoria spinnings, kokovin93, Imya 505, Alexander Pistoletov, Green Elephant, My Little Pony, Korean PVs and MVs now on your desktop, endlessly! All played files could be saved in a directory.
https://github.com/ValdikSS/endless-sosuch
>>1419782
Ага, спасибо. Я это вроде всё даже в анимублядском треде видел, но начисто забыл.
Вот так можно в mpv играть, когда защита включена (можно даже в конфиг добавить):
mpv --user-agent '<value>' --http-header-fields 'Cookie: cf_clearance=<value>' <url>
Вот так можно из профиля лисы текущую куку достать (можно поставить, чтобы по крону меняло соответствующее значение в конфиге mpv):
sqlite3 ~/.mozilla/firefox/∗.default/cookies.sqlite 'SELECT value FROM moz_cookies WHERE baseDomain="2ch.hk" AND name="cf_clearance"'
Если vlc plugin читает конфиг VLC, то можно и его заставить правильный user agent/куку посылать. Лень проверять, NPAPI в любом случае не нужен.
Вот с этого специалиста по безопасности проиграл: https://trac.videolan.org/vlc/ticket/56#comment:11
>>1419814
Ну ты понел. Почему не скрипт на Lua к mpv с нормальным управлением и декодерами? Или даже впилить поддержку в youtube-dl, mpv подхватит автоматом.
Олсо, почему не залил на PYPI с проставленными зависимостями, чтобы устанавливать одной командой нормальный симлинк в PATH, как все нормальные пацаны делают? И сборочку через py2exe для вендузятников.
Ага, спасибо. Я это вроде всё даже в анимублядском треде видел, но начисто забыл.
Вот так можно в mpv играть, когда защита включена (можно даже в конфиг добавить):
mpv --user-agent '<value>' --http-header-fields 'Cookie: cf_clearance=<value>' <url>
Вот так можно из профиля лисы текущую куку достать (можно поставить, чтобы по крону меняло соответствующее значение в конфиге mpv):
sqlite3 ~/.mozilla/firefox/∗.default/cookies.sqlite 'SELECT value FROM moz_cookies WHERE baseDomain="2ch.hk" AND name="cf_clearance"'
Если vlc plugin читает конфиг VLC, то можно и его заставить правильный user agent/куку посылать. Лень проверять, NPAPI в любом случае не нужен.
Вот с этого специалиста по безопасности проиграл: https://trac.videolan.org/vlc/ticket/56#comment:11
>>1419814
>gstreamer
Ну ты понел. Почему не скрипт на Lua к mpv с нормальным управлением и декодерами? Или даже впилить поддержку в youtube-dl, mpv подхватит автоматом.
Олсо, почему не залил на PYPI с проставленными зависимостями, чтобы устанавливать одной командой нормальный симлинк в PATH, как все нормальные пацаны делают? И сборочку через py2exe для вендузятников.
>>1419831
Dunno, не думал, было бы неплохо. Можно и реализовать.
Не успел, будет.
>Почему не скрипт на Lua к mpv с нормальным управлением и декодерами?
Dunno, не думал, было бы неплохо. Можно и реализовать.
>Олсо, почему не залил на PYPI с проставленными зависимостями, чтобы устанавливать одной командой нормальный симлинк в PATH, как все нормальные пацаны делают? И сборочку через py2exe для вендузятников.
Не успел, будет.
wget -c -k -p -r -l1 -I "∗/src/∗,∗/images/∗,∗/makaba/∗,∗/thumb/∗" --no-check-certificate https://2ch.hk/s/res/1418674.html
Почему папки images и makaba не грузятся?
Почему папки images и makaba не грузятся?
>>1419971
Звёздочек, скорее всего, не хватает. Вот так криво, зато проще:
mkdir saved-thread && cd saved-thread
wget -nd -c -r -I '∗/src/∗' <url>
wget -nd -c -p -k <url>
sed -i 's# href="http[^"]∗/src/[^"]∗/# href="#g' ∗.html
Звёздочек, скорее всего, не хватает. Вот так криво, зато проще:
mkdir saved-thread && cd saved-thread
wget -nd -c -r -I '∗/src/∗' <url>
wget -nd -c -p -k <url>
sed -i 's# href="http[^"]∗/src/[^"]∗/# href="#g' ∗.html
https://github.com/mpv-player/mpv/commit/78caf6ae8634b9fe9589187d8febb927dce2ddeb
Вот это круто. Наконец-то ffmpeg починили.
Вот это круто. Наконец-то ffmpeg починили.
>>1420219
Исправляет ссылки на полные версии изображений, которые были скачаны первым вгетом.
Исправляет ссылки на полные версии изображений, которые были скачаны первым вгетом.
>>1419751
Бамп вопросу.
> Платина наверное, но у меня в вебмках нет звука. Вообще ни в каких. Что надо сделать?
Бамп вопросу.
>>1420355
Если у тебя во всех вебм нет звука, то может стоит начать с себя? Давно у ЛОРа был? Долго на форчане сидел?
Если у тебя во всех вебм нет звука, то может стоит начать с себя? Давно у ЛОРа был? Долго на форчане сидел?
А чем видево захватывать в игрулях и винде, собственно? Бесплатно, свободно, люче всего.
Какие ограничения чтобы сюда залит ?
Тест
>>1420359
В видео с ютуба звук есть, в игорах тоже, на форчанах не сидел
В видео с ютуба звук есть, в игорах тоже, на форчанах не сидел
Куда нужно запердолиться, чтобы этот говносайт разместил не битые ссылки? http://ffmpeg.zeranoe.com/builds/
404 /builds/win64/static/ffmpeg-20151011-git-f05ff05-win64-static.7z Not found
404 /builds/win64/static/ffmpeg-20151011-git-f05ff05-win64-static.7z Not found
>>1419736
Если прога наберет 100 рублей, перепишу через busybox. Если 500 руб. наберет, то сделаю и для других разделов. А для тебя и с картинками и с webm контентом.
Нужно мотивировать разработчиков.
Если прога наберет 100 рублей, перепишу через busybox. Если 500 руб. наберет, то сделаю и для других разделов. А для тебя и с картинками и с webm контентом.
Нужно мотивировать разработчиков.
>>1420668
Сосни хуйцы
Сосни хуйцы
463 Кб, 1920x1080
>>1420668
Чот в шепот с мамкиного предпринимателя.
Чот в шепот с мамкиного предпринимателя.
Переписал скрипт для скачивания всех webm треда из любого раздела:
http://ad-file.com/8MvFlfGWg
Добавил busybox. Но sed там кривой.
http://ad-file.com/8MvFlfGWg
Добавил busybox. Но sed там кривой.
>>1421042
Они там очень фиговые. В GNU sed есть ключик -r, который немного помогает, будет что-то на уровне греповского ERE. Но до нормального PCRE всё равно не дотягивает.
>но пока никак не осилю регэкспы в sed
Они там очень фиговые. В GNU sed есть ключик -r, который немного помогает, будет что-то на уровне греповского ERE. Но до нормального PCRE всё равно не дотягивает.
>>1421049
Бля. Думал воровать фрапс с кучей нинужных фич, чтобы писать реплеи танчиков, а тут так всё просто. Сукпздц. (((
Бля. Думал воровать фрапс с кучей нинужных фич, чтобы писать реплеи танчиков, а тут так всё просто. Сукпздц. (((
Написал себе двощ-загрузчик тредов и картинок с вебмками. Если вам тоже надо то кочайте: http://rghost.ru/8VtxPTXFS
Инструкция:
Содержимое архива закинуть в любую PATH-папку.
Лучше работать через тотал коммандер - там внизу есть удобная консолька.
Чтобы скачать тред целиком, создашь для него папку, заходишь в нее и пишешь в консольку: 2ch-dl https://2ch.hk/доска/res/тред.html
Чтобы скочать только картинки-вебэмки, создашь для них папку, заходишь в нее и пишешь в консольку: 2ch-mm https://2ch.hk/доска/res/тред.html
Советы по улучшению говноскрипта приветствуются.
Инструкция:
Содержимое архива закинуть в любую PATH-папку.
Лучше работать через тотал коммандер - там внизу есть удобная консолька.
Чтобы скачать тред целиком, создашь для него папку, заходишь в нее и пишешь в консольку: 2ch-dl https://2ch.hk/доска/res/тред.html
Чтобы скочать только картинки-вебэмки, создашь для них папку, заходишь в нее и пишешь в консольку: 2ch-mm https://2ch.hk/доска/res/тред.html
Советы по улучшению говноскрипта приветствуются.
Тут были ссылки на презентации, где умные дядьки рассказывали умные вещи. Накидайте подобного в тред, я с канала vlc посмотрел все.
>>1421442
Статьи Monty отсюда https://xiph.org/~xiphmont/demo/
особенно по Daala,
это https://xiph.org/~xiphmont/demo/neil-young.html
это https://xiph.org/video/vid1.shtml
и это https://xiph.org/video/vid2.shtml
(У него в ЖЖ ещё бывает интересно - http://xiphmont.livejournal.com/ )
Все презентации и слайды по Daala:
https://wiki.xiph.org/Daala#Presentations
Тамже см. ссылку на записи и слайды NetVC WG с прошлого IETF.
Презентация VP9 от гугля:
https://www.youtube.com/watch?v=K6JshvblIcM
Хорошая книга по H.264:
https://books.google.com/books?id=k7nOAiIUo9IC
Доки по Dirac:
http://dirac.sourceforge.net/documentation/algorithm/algorithm/toc.htm
Большинство современных кодеков работают почти одинаково.
Статейки по VP9/HEVC:
https://www.academia.edu/5893478/Intra_Compression_Efficiency_in_VP9_and_HEVC
http://forum.doom9.org/showthread.php?t=168947
http://files.meetup.com/9842252/Overview-VP9.pdf
https://www.ietf.org/proceedings/85/slides/slides-85-videocodec-4.pdf
Статьи Monty отсюда https://xiph.org/~xiphmont/demo/
особенно по Daala,
это https://xiph.org/~xiphmont/demo/neil-young.html
это https://xiph.org/video/vid1.shtml
и это https://xiph.org/video/vid2.shtml
(У него в ЖЖ ещё бывает интересно - http://xiphmont.livejournal.com/ )
Все презентации и слайды по Daala:
https://wiki.xiph.org/Daala#Presentations
Тамже см. ссылку на записи и слайды NetVC WG с прошлого IETF.
Презентация VP9 от гугля:
https://www.youtube.com/watch?v=K6JshvblIcM
Хорошая книга по H.264:
https://books.google.com/books?id=k7nOAiIUo9IC
Доки по Dirac:
http://dirac.sourceforge.net/documentation/algorithm/algorithm/toc.htm
Большинство современных кодеков работают почти одинаково.
Статейки по VP9/HEVC:
https://www.academia.edu/5893478/Intra_Compression_Efficiency_in_VP9_and_HEVC
http://forum.doom9.org/showthread.php?t=168947
http://files.meetup.com/9842252/Overview-VP9.pdf
https://www.ietf.org/proceedings/85/slides/slides-85-videocodec-4.pdf
Лол, у VLC на канале видео с сексисткими шуточками: https://www.youtube.com/watch?v=ZRM6-PrOfZE
А сами на конференциях просят не выходить за рамки одобренного SJW новояза: https://www.youtube.com/watch?v=fgeZkIfIxqs&t=2m55s
Я фигею с лицемерия западных товарищей белой расы. И всё с чистой совестью! То, что их показушная политкорректность может являться оскорбительной для жителей третьего мира, господ феминистов не волнует:
https://bugzilla.mozilla.org/show_bug.cgi?id=366559#c165
А сами на конференциях просят не выходить за рамки одобренного SJW новояза: https://www.youtube.com/watch?v=fgeZkIfIxqs&t=2m55s
Я фигею с лицемерия западных товарищей белой расы. И всё с чистой совестью! То, что их показушная политкорректность может являться оскорбительной для жителей третьего мира, господ феминистов не волнует:
https://bugzilla.mozilla.org/show_bug.cgi?id=366559#c165
Если кому-то что-то не нравится в ffmpeg, то вот здесь можно заполнить формочку:
https://fr.surveymonkey.com/r/QCP7JSS
https://fr.surveymonkey.com/r/QCP7JSS
>>1421516
А где ты лицемерие увидел? На канале они сами себе хозяева, а конфа — публичное мероприятие. У пидарков-неженок нормальная практика отказ от посещения только потому, что в правилах не упомянут какой-нибудь пидорский Code of Conduct. Вот и приходится подстраиваться.
Пиздец просто, ёбаный петушиный барак.
А где ты лицемерие увидел? На канале они сами себе хозяева, а конфа — публичное мероприятие. У пидарков-неженок нормальная практика отказ от посещения только потому, что в правилах не упомянут какой-нибудь пидорский Code of Conduct. Вот и приходится подстраиваться.
Пиздец просто, ёбаный петушиный барак.
test
Венду переставил, теперь вебм ужасно выглядеть стали. Там надо что-то из кодеков ставить? Не помню, чтобы на прошлой что-то ставил, но таких квадратов не было.
>>1421889
В этом-то и дело. Тогда не ставил, было заебись, в этот раз не ставил, ебаные квадраты.
В этом-то и дело. Тогда не ставил, было заебись, в этот раз не ставил, ебаные квадраты.
Задаю битрейт в 680, на выходе получаю битрейт в 593. Это нормально или просто у меня руки из жопы?
>>1422060
Нормально.
Нормально.
>>1422060
Используй crf, что ты как этот.
Используй crf, что ты как этот.
>>1421203
Обновление.
http://rghost.ru/8mjjTDXGV
Теперь все функции в одном скрипте.
2ch-dl https://2ch.hk/доска/res/тред.html - загружает весь тред полностью в пригодном для оффлайнового чтения виде вместе с полноразмерными картинками и вебмками,
2ch-dl -m https://2ch.hk/доска/res/тред.html - загружает все картинки и вебмки треда,
2ch-dl -i https://2ch.hk/доска/res/тред.html - загружает только картинки,
2ch-dl -w https://2ch.hk/доска/res/тред.html - загружает только вебмки,
2ch-dl -h - инструкция.
Обновление.
http://rghost.ru/8mjjTDXGV
Теперь все функции в одном скрипте.
2ch-dl https://2ch.hk/доска/res/тред.html - загружает весь тред полностью в пригодном для оффлайнового чтения виде вместе с полноразмерными картинками и вебмками,
2ch-dl -m https://2ch.hk/доска/res/тред.html - загружает все картинки и вебмки треда,
2ch-dl -i https://2ch.hk/доска/res/тред.html - загружает только картинки,
2ch-dl -w https://2ch.hk/доска/res/тред.html - загружает только вебмки,
2ch-dl -h - инструкция.
Сап анон. Решил научиться пилить шебмки. Читнул гайдца, всё вроде получилось с первого раза, и я решил "совместить" руководство 1 (как просто вырвать кусок из видео) с руководством 2 (там предлагается сделать видео в два прохода из готового файла). Так вот, я хотел в два прохода сделать вырезку из мультфильма, первый проход прошёл нормально, второй тоже, но при совмещении видео и звука возникла проблема:
Писал так:
ffmpeg -ss 1:04:35 -i filename.mkv -t 201 -i video.webm -map 0:a -c:a libopus -t -201 -b:a 64k -map 1:v -c:v copy out.webm
И вот то, что выделил вероятнее всего неправильно. Либо стоит в неправильном месте, либо параметр неверен.
Подскажите как совместить звук из фильма и видео из обрезка. Спасибо.
Писал так:
ffmpeg -ss 1:04:35 -i filename.mkv -t 201 -i video.webm -map 0:a -c:a libopus -t -201 -b:a 64k -map 1:v -c:v copy out.webm
И вот то, что выделил вероятнее всего неправильно. Либо стоит в неправильном месте, либо параметр неверен.
Подскажите как совместить звук из фильма и видео из обрезка. Спасибо.
>>1422181
А, не сказал. На выходе получается вебм-ка длинна видеодорожки которой составляет 201 секунду (ну естественно, видео же обрезанное), а аудиодорожка с момента 1:04:35 до конца фильма (~13 минут). Т.е. нужно указать конечное время аудиофайла.
А, не сказал. На выходе получается вебм-ка длинна видеодорожки которой составляет 201 секунду (ну естественно, видео же обрезанное), а аудиодорожка с момента 1:04:35 до конца фильма (~13 минут). Т.е. нужно указать конечное время аудиофайла.
>>1422181
А не проще сразу все сделать? Я до сих пор не понимаю сокральный смысл соединять видео со звуком отдельно.
А не проще сразу все сделать? Я до сих пор не понимаю сокральный смысл соединять видео со звуком отдельно.
>>1395791 (OP)
test
test
>>1422186
Не думай, что я понимаю, что я делаю и о чём ты говоришь. Скопировать пару строк в терминал не есть понимание происходящего.
Ну попробую читнуть гайдец из первого поста, может там написано как сразу со звуком делать.
Не думай, что я понимаю, что я делаю и о чём ты говоришь. Скопировать пару строк в терминал не есть понимание происходящего.
Ну попробую читнуть гайдец из первого поста, может там написано как сразу со звуком делать.
>>1422192
ffmpeg -ss время -i файл -to время параметры видео -an -sn pass 1 -f webm NULL
ffmpeg -ss время -i файл -to время параметры видео -c:a opus параметры аудио -sn pass 2 -f webm имя.webm
Как-то так.
ffmpeg -ss время -i файл -to время параметры видео -an -sn pass 1 -f webm NULL
ffmpeg -ss время -i файл -to время параметры видео -c:a opus параметры аудио -sn pass 2 -f webm имя.webm
Как-то так.
>>1422099
Чето я как даун-аутист, анон.
Запускаю твою поделку, не из ТК, а просто из консолечки, скрипт начинает работать и консолечка схлопывается. Как логи-то глянуть?
Чето я как даун-аутист, анон.
Запускаю твою поделку, не из ТК, а просто из консолечки, скрипт начинает работать и консолечка схлопывается. Как логи-то глянуть?
>>1422201
Это потому что я не указал /b везде после exit
Исправлено.
http://rghost.ru/6MjWDtDVB
>консолечка схлопывается
Это потому что я не указал /b везде после exit
Исправлено.
http://rghost.ru/6MjWDtDVB
118 Кб, 839x803
>>1422218
Да это один из вариантов который я пробовал, видимо забыл стереть. Я сначала в блокноте пишу потом в соснолечку копирую.
Да это один из вариантов который я пробовал, видимо забыл стереть. Я сначала в блокноте пишу потом в соснолечку копирую.
Подскажите, что можно поправить/добавить для "помедленее, покачественее":
ffmpeg -ss 1:02 -i file.mp4 -t 32 ^
\t-map 0:v -vf "scale=-1:540" -c:v libvpx-vp9 -pix_fmt yuv420p ^
\t-threads 4 -speed 0 -quality good ^
\t-slices 2 -tile-rows 0 -frame-parallel 0 -tile-columns 0 -lag-in-frames 25 -auto-alt-ref 1 -pass 2 ^
\t-qmin 30 -crf 35 -qmax 45 -qcomp 1 -b:v 0 out.webm
Инбифо deadline=0
ffmpeg -ss 1:02 -i file.mp4 -t 32 ^
\t-map 0:v -vf "scale=-1:540" -c:v libvpx-vp9 -pix_fmt yuv420p ^
\t-threads 4 -speed 0 -quality good ^
\t-slices 2 -tile-rows 0 -frame-parallel 0 -tile-columns 0 -lag-in-frames 25 -auto-alt-ref 1 -pass 2 ^
\t-qmin 30 -crf 35 -qmax 45 -qcomp 1 -b:v 0 out.webm
Инбифо deadline=0
>>1422272
Я это не смогу обойти, только если ты напишешь сразу в скрипт или подробно расскажешь как обойти. А какие разделы вообще считаются закрытыми?
Я это не смогу обойти, только если ты напишешь сразу в скрипт или подробно расскажешь как обойти. А какие разделы вообще считаются закрытыми?
>>1422289
Моя ошибка. best нигде не всплывал, я почему-то посчитал, что управляется все через speed, а good там дефалтом стоит, я никогда его и не менял.
Моя ошибка. best нигде не всплывал, я почему-то посчитал, что управляется все через speed, а good там дефалтом стоит, я никогда его и не менял.
>>1422304
А ты попробуй поставить best, тебя будут ждать незабываемые часов десять ради пары минут видео.
А ты попробуй поставить best, тебя будут ждать незабываемые часов десять ради пары минут видео.
>>1422289
-aq-mode т.е. У него 4 варианта значения, по умолчанию 0. Теоретически, может как-то улучшить качество.
Есть --tune-content=screen (доступно только через vpxenc), должно помочь в случае скринкастов.
Ну и очевидный sws_flags=lanczos или spline для улучшения качества ресайза вместо дефолтного bicubic. Или ёба ewa_lanczossharp из mpv, ололо.
>>1422300
Со всяким непотребством, очевидно.
Я не автор того скрипта, если что. А вообще, взять куку из текущего браузерного профиля (в лисе: «настройки→приватность→show cookies→2ch.hk») и добавить параметр вгету --header 'Cookie: usercode_auth=<value>'
-aq-mode т.е. У него 4 варианта значения, по умолчанию 0. Теоретически, может как-то улучшить качество.
Есть --tune-content=screen (доступно только через vpxenc), должно помочь в случае скринкастов.
Ну и очевидный sws_flags=lanczos или spline для улучшения качества ресайза вместо дефолтного bicubic. Или ёба ewa_lanczossharp из mpv, ололо.
>>1422300
>А какие разделы вообще считаются закрытыми?
Со всяким непотребством, очевидно.
>как обойти
Я не автор того скрипта, если что. А вообще, взять куку из текущего браузерного профиля (в лисе: «настройки→приватность→show cookies→2ch.hk») и добавить параметр вгету --header 'Cookie: usercode_auth=<value>'
>>1422181
У тебя -t указано перед -i, т.е. для входа. А надо для выхода.
У тебя -t указано перед -i, т.е. для входа. А надо для выхода.
>>1422322
Сейчас пробовал на герлаче - ничего не грузит.
>добавить параметр вгету --header 'Cookie: usercode_auth=<value>'
Сейчас пробовал на герлаче - ничего не грузит.
>>1422328
Юзерагент ещё свой полный. Вот так проверяй:
wget https://2ch.hk/gg/ --header "Cookie: usercode_auth=<cookie_value>" -U "<useragent_value>"
Юзерагент ещё свой полный. Вот так проверяй:
wget https://2ch.hk/gg/ --header "Cookie: usercode_auth=<cookie_value>" -U "<useragent_value>"
>>1422322
Ещё кое-какие интересные флаги из хелпа vpxenc:
--sharpness=<arg> \tLoop filter sharpness (0..7)
--static-thresh=<arg> \tMotion detection threshold
--arnr-maxframes=<arg> \tAltRef max frames (0..15)
--arnr-strength=<arg> \tAltRef filter strength (0..6)
--arnr-type=<arg> \tAltRef type
--max-intra-rate=<arg> \tMax I-frame bitrate (pct)
--max-inter-rate=<arg> \tMax P-frame bitrate (pct)
--gf-cbr-boost=<arg> \tBoost for Golden Frame in CBR mode (pct)
--frame-boost=<arg> \tEnable frame periodic boost (0: off (default), 1: on)
--noise-sensitivity=<arg> \tNoise sensitivity (frames to blur)
Часть доступна через ffmpeg, часть — нет.
Ещё кое-какие интересные флаги из хелпа vpxenc:
--sharpness=<arg> \tLoop filter sharpness (0..7)
--static-thresh=<arg> \tMotion detection threshold
--arnr-maxframes=<arg> \tAltRef max frames (0..15)
--arnr-strength=<arg> \tAltRef filter strength (0..6)
--arnr-type=<arg> \tAltRef type
--max-intra-rate=<arg> \tMax I-frame bitrate (pct)
--max-inter-rate=<arg> \tMax P-frame bitrate (pct)
--gf-cbr-boost=<arg> \tBoost for Golden Frame in CBR mode (pct)
--frame-boost=<arg> \tEnable frame periodic boost (0: off (default), 1: on)
--noise-sensitivity=<arg> \tNoise sensitivity (frames to blur)
Часть доступна через ffmpeg, часть — нет.
>>1422336
Работает. Если я запишу в скрипт свою куку, то она будет работать у всех? Как долго? Что зашифровано в этой куке?
Работает. Если я запишу в скрипт свою куку, то она будет работать у всех? Как долго? Что зашифровано в этой куке?
>>1422374
Вот спорно. Я в endless sosuch засунул свою куку, работает у 7 людей, так что, как минимум, на IP она не завязана.
>Нет.
Вот спорно. Я в endless sosuch засунул свою куку, работает у 7 людей, так что, как минимум, на IP она не завязана.
>>1422475
cf_clearance завязана на IP и UA - думал, эта тоже. Вообще сейчас же посты без капчи работают, т.ч. можно ее получать постом в /test/, например.
cf_clearance завязана на IP и UA - думал, эта тоже. Вообще сейчас же посты без капчи работают, т.ч. можно ее получать постом в /test/, например.
>>1422475
Похоже на md5sum от юзерагента с солью. У меня вот:
UA = Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0
userauth_code = fe94019220ab962647f9c131c6ed09c1
При изменении юзерагента хоть на байт, возвращает 404 на закрытом разделе. На другом айпи работает. Вряд ли там подпись, 128-битные никто не использует сейчас.
>так что, как минимум, на IP она не завязана
Похоже на md5sum от юзерагента с солью. У меня вот:
UA = Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0
userauth_code = fe94019220ab962647f9c131c6ed09c1
При изменении юзерагента хоть на байт, возвращает 404 на закрытом разделе. На другом айпи работает. Вряд ли там подпись, 128-битные никто не использует сейчас.
Вообще, костыли с wget нинужны. Сосач же в JSON умеет треды отдавать. Надо собраться да написать грамотную сохранялку, учитыающую удаленные посты, но все лень.
>>1422513
На питоне такое пишется за максимум пару часов. Думаю половина тутошних анонов просто не умеет в программирование или им лень.
На питоне такое пишется за максимум пару часов. Думаю половина тутошних анонов просто не умеет в программирование или им лень.
>>1422521
Надо же еще попапы для рефлинков прикрутить и всякие развороты картинок.
Надо же еще попапы для рефлинков прикрутить и всякие развороты картинок.
>>1422475
Тогда держите обновление костыля. Проверьте, качает с закрытых или нет?
http://rghost.ru/7n6B2FcTP
>>1422513
Я даже не знаю что это, лол.
>>1422521
В несложное прогроммировоне могу только на яваскриптах.
Тогда держите обновление костыля. Проверьте, качает с закрытых или нет?
http://rghost.ru/7n6B2FcTP
>>1422513
>Сосач же в JSON умеет треды отдавать.
Я даже не знаю что это, лол.
>>1422521
В несложное прогроммировоне могу только на яваскриптах.
>>1422535
Слушай, не мог бы ты не засирать нерелэйтедом прикреплённый тред?
Создай отдельный, тогда мы мб там ещё письками померяемся: когда-то давно я писал аналог твоей хуитки, и год назад он ещё работал.
Слушай, не мог бы ты не засирать нерелэйтедом прикреплённый тред?
Создай отдельный, тогда мы мб там ещё письками померяемся: когда-то давно я писал аналог твоей хуитки, и год назад он ещё работал.
>>1422545
Что в новом теде на сотни постов обсуждать-то? Тут хоть я чуть посветил своей поделкой и убёг, может кому из читающих ffmpeg-богов, не страшашихся консольки, пригодится. Ты не переживай так.
Что в новом теде на сотни постов обсуждать-то? Тут хоть я чуть посветил своей поделкой и убёг, может кому из читающих ffmpeg-богов, не страшашихся консольки, пригодится. Ты не переживай так.
198 Кб, 1411x547
>>1422565
Вот это. Не устраивай из этого треда помойку, он создавался не для этого.
> Что в новом теде на сотни постов обсуждать-то?
Вот это. Не устраивай из этого треда помойку, он создавался не для этого.
>>1422554
Меня начинает пугать, что аниме-девочки меня стали возбуждать больше 3д. Кажется это край.
Меня начинает пугать, что аниме-девочки меня стали возбуждать больше 3д. Кажется это край.
>>1395791 (OP)
залейте тот отрезок аватара в 60 фпс чо
залейте тот отрезок аватара в 60 фпс чо
980 Кб, 2560x1440
>>1400809
Немного осилил блендер. Хороший редактор, но уже успел поспотыкаться о как минимум 4 неприятные особенности:
1. Рабочее цветовая модель — RGB, Y'CbCr импортирует всегда используя матрицу BT.601. При вводе Y'CbCr и выводе в H.264 lossless почему-то появляется мыло. Рабочий костыль — конвертировать нарезку в RGB вручную, но это неизбежно приводит к потерям на преобразованиях цветовых пространств. 16bit PNG/32 bit OpenEXR в качестве промежуточных форматов помогают, но места на диске жрут ещё больше. Многочасовые фильмы так не помонтируешь.
2. Текущая версия почему-то любит добавлять пустой кадр в конце импортируемого стрипа. Хотя с исходником всё в порядке.
3. Hard cut работает криво — последний кадр правильно повторяется только со второго раза (после Ctrl-z).
4. Иногда предпросмотр подлагивает при умеренном числе стрипов и один раз откуда-то левый кадр в итоговом рендере появился.
Немного осилил блендер. Хороший редактор, но уже успел поспотыкаться о как минимум 4 неприятные особенности:
1. Рабочее цветовая модель — RGB, Y'CbCr импортирует всегда используя матрицу BT.601. При вводе Y'CbCr и выводе в H.264 lossless почему-то появляется мыло. Рабочий костыль — конвертировать нарезку в RGB вручную, но это неизбежно приводит к потерям на преобразованиях цветовых пространств. 16bit PNG/32 bit OpenEXR в качестве промежуточных форматов помогают, но места на диске жрут ещё больше. Многочасовые фильмы так не помонтируешь.
2. Текущая версия почему-то любит добавлять пустой кадр в конце импортируемого стрипа. Хотя с исходником всё в порядке.
3. Hard cut работает криво — последний кадр правильно повторяется только со второго раза (после Ctrl-z).
4. Иногда предпросмотр подлагивает при умеренном числе стрипов и один раз откуда-то левый кадр в итоговом рендере появился.
367 Кб, 1310x522
Предлагаю потестить Бесконечный Сосач©®™. Это скрипт, который воспроизводит видео из WebM-тредов в отдельном окне. Может еще и сохранять их попутно.
Есть глушилка Джона Сины!
Больше информации: https://github.com/ValdikSS/endless-sosuch/
Билд для Windows: https://github.com/ValdikSS/endless-sosuch/releases/download/v0.0.1/endless_sosuch_win_vlc_0.0.1.rar (требуется установленный VLC, перед запуском засуньте любую вебм-ку в директорию webm).
Есть глушилка Джона Сины!
Больше информации: https://github.com/ValdikSS/endless-sosuch/
Билд для Windows: https://github.com/ValdikSS/endless-sosuch/releases/download/v0.0.1/endless_sosuch_win_vlc_0.0.1.rar (требуется установленный VLC, перед запуском засуньте любую вебм-ку в директорию webm).
>>1422849
Но ведь я ещё два дня назад сказал, что реализация — отстой. Вот нафиг ты тратишь столько времени на велосипединг графов gstreamer, переизобретение кэширования и костыльное прикручивание аудио-фильтров, если на выходе всё равно получится урезанный недоплеер с неудобным управлением и убогими декодерами? Почему не взять хороший современный плеер и минимальными усилиями реализовать значительно лучший и удобный для конечного пользователя продукт в виде Lua-скрипта, который устанавливается простым копированием? Ты это пишешь просто чтобы Gstreamer с питоном выучить или как?
Я уже не говорю про особенности твоей реализации в виде кривого конфига на питоне с вынесенными 2.5 настройками в виде выбора драйвера вывода (лол, теперь посмотри на конфигурацию какого-нибудь vo=opengl в mpv), жёсткой завязки на Python 3 и отсутствие какого-либо подобия автоматизации установки.
Но ведь я ещё два дня назад сказал, что реализация — отстой. Вот нафиг ты тратишь столько времени на велосипединг графов gstreamer, переизобретение кэширования и костыльное прикручивание аудио-фильтров, если на выходе всё равно получится урезанный недоплеер с неудобным управлением и убогими декодерами? Почему не взять хороший современный плеер и минимальными усилиями реализовать значительно лучший и удобный для конечного пользователя продукт в виде Lua-скрипта, который устанавливается простым копированием? Ты это пишешь просто чтобы Gstreamer с питоном выучить или как?
Я уже не говорю про особенности твоей реализации в виде кривого конфига на питоне с вынесенными 2.5 настройками в виде выбора драйвера вывода (лол, теперь посмотри на конфигурацию какого-нибудь vo=opengl в mpv), жёсткой завязки на Python 3 и отсутствие какого-либо подобия автоматизации установки.
>>1422854
В конечном итоге, я это все буду вещать в интернет, а не воспроизводить локально, поэтому мне и не подходит просто дополнение к какому-то из видеоплееров.
Ну и да, хочу еще немного с gstreamer повозиться.
В конечном итоге, я это все буду вещать в интернет, а не воспроизводить локально, поэтому мне и не подходит просто дополнение к какому-то из видеоплееров.
Ну и да, хочу еще немного с gstreamer повозиться.
>>1422857
Что мешает вещать в интернет при помощи того же mpv? См. mpv -of help и https://github.com/mpv-player/mpv/blob/master/DOCS/encoding.rst
Что мешает вещать в интернет при помощи того же mpv? См. mpv -of help и https://github.com/mpv-player/mpv/blob/master/DOCS/encoding.rst
>>1422858
MPV, к сожалению, все еще не умеет вещать без транскодинга. А мне надо вещать без транскодинга, это вполне реализуемо тем же mpegts с несколькими pid-ами.
MPV, к сожалению, все еще не умеет вещать без транскодинга. А мне надо вещать без транскодинга, это вполне реализуемо тем же mpegts с несколькими pid-ами.
>>1422863
Т.е. слушателям будет приходить оригинальный VP8/VP9 байстрим что ли? И как ты себе это представляешь? Они ж все разного разрешения + надо декодер постоянно переинициализировать, равносильно открытию нового файла. Ну и mpegts как бы VPx не поддерживает.
>вещать без транскодинга
Т.е. слушателям будет приходить оригинальный VP8/VP9 байстрим что ли? И как ты себе это представляешь? Они ж все разного разрешения + надо декодер постоянно переинициализировать, равносильно открытию нового файла. Ну и mpegts как бы VPx не поддерживает.
>>1422866
Это достаточно костыльно, и работает нормально только в VLC, а в ffmpeg-based плеерах нужно вручную переключать видеодорожку, но для H.264 точно работает, с VP8 и VP9 не пробовал, вероятнее всего не заработает.
Да, я хочу вещать оригинальный битстрим.
Это достаточно костыльно, и работает нормально только в VLC, а в ffmpeg-based плеерах нужно вручную переключать видеодорожку, но для H.264 точно работает, с VP8 и VP9 не пробовал, вероятнее всего не заработает.
Да, я хочу вещать оригинальный битстрим.
98 Кб, 1285x607
Пытаюсь сделать вебмку, вот тока чет медленно кодирует. Так и должно быть?
>>1422903
А вот и жертва маркетинга пожаловала.
С мультилибом напердолился?
Program Files (x86) почистил?
Все свои 32Гб памяти говнокодом забил?
А вот и жертва маркетинга пожаловала.
С мультилибом напердолился?
Program Files (x86) почистил?
Все свои 32Гб памяти говнокодом забил?
198 Кб, 1411x547
>>1422927
Пердолик, плиз. Приличные люди вообще 32-битного кода на машинах не имеют. Только спермобляди обязаны тащить тонну legacy-говна, которое им забивает всю оперативку.
Пердолик, плиз. Приличные люди вообще 32-битного кода на машинах не имеют. Только спермобляди обязаны тащить тонну legacy-говна, которое им забивает всю оперативку.
>>1422965
Но ведь 64 бит - это костыль для того что бы оправдать неоптимизированный говнокод который жрет память
Но ведь 64 бит - это костыль для того что бы оправдать неоптимизированный говнокод который жрет память
>>1422977
амд64 это название архитектуры процессора, способного выполнять 64 битный код, и отношения к памяти никакого не имеет. А ты позорная спермоблядь.
амд64 это название архитектуры процессора, способного выполнять 64 битный код, и отношения к памяти никакого не имеет. А ты позорная спермоблядь.
>>1422958
Ничего что у x86-64 больше регистров, следовательно можно сгенирировать более эффективный и производительный код? Ты бы ещё версию без SIMD использовал. Это видео, чувак, и здесь каждый процент прироста важен. Ты ещё не видел как авторы AviSynth/VapourSynth/кодеков каждый такт процессора и asm задротят.
А между тем, никто так и не заметил, что у >>1422887 мультитрединг выключен.
>x86_32 бога
Ничего что у x86-64 больше регистров, следовательно можно сгенирировать более эффективный и производительный код? Ты бы ещё версию без SIMD использовал. Это видео, чувак, и здесь каждый процент прироста важен. Ты ещё не видел как авторы AviSynth/VapourSynth/кодеков каждый такт процессора и asm задротят.
А между тем, никто так и не заметил, что у >>1422887 мультитрединг выключен.
>>1422991
Хорошо, перефразирую для пердолика:
амд64 это архитектура-костыль, необходимая для того, что бы запускать неоптимизированный говнокод.
Хорошо, перефразирую для пердолика:
амд64 это архитектура-костыль, необходимая для того, что бы запускать неоптимизированный говнокод.
>>1423000
Сложно понимаю птичий язык, но похоже суть я уловил.
>кукареку менеджер коко сказал кудах купить 16гб я купил коко
Сложно понимаю птичий язык, но похоже суть я уловил.
238 Кб, 889x1447
Тем временем лисодевы демонстрируют просто мастерклассы в написании высокопроизводительного кода:
https://bugzilla.mozilla.org/show_bug.cgi?id=1193614#c5
Не удивительно, что у >>1408739 тормозило. Накатывай https://bug1193614.bmoattachments.org/attachment.cgi?id=8668280 @ проверяй.
https://bugzilla.mozilla.org/show_bug.cgi?id=1193614#c5
>You can see that they set the number of threads to use when calling vpx_codec_dec_init.
>We don't
Не удивительно, что у >>1408739 тормозило. Накатывай https://bug1193614.bmoattachments.org/attachment.cgi?id=8668280 @ проверяй.
>>1422958
Пердолик, ты уже сам себя обоссал.
Я же тебя прошу прекратить это делать в этом треде — воняет. Иди этим заниматься в спермотред, туда я обычно не захожу.
Архитектура amd64 (x86-64) позволяет писать более производительный код за счёт своих объективных особенностей, в т.ч. увеличения длины и количества регистров, о чём было написано в >>1423023 и что было подтверждено на практике сравнением производительности libvpx-vp9 >>1422945. Незначительное увеличение потребления памяти (машинный код весит на 20% больше) не является для задачи кодирования видео значимым фактором.
Дальнейшее излияние здесь религиозных страхов спермоблядей перед новой архитектурой (не смотря на наличие для них оснований) не считаю уместным. Вопрос закрыт.
>>1423089
Поставь прыщеchroot с ffmpeg'ом, ололо. Только не удивляйся, что кодирование видео будет в момент сажать батарею.
Ещё неплохой вариант — ssh-клиент и прыщесервер за копейки.
> Что ты у меня просишь? Обоссать?
Пердолик, ты уже сам себя обоссал.
Я же тебя прошу прекратить это делать в этом треде — воняет. Иди этим заниматься в спермотред, туда я обычно не захожу.
Архитектура amd64 (x86-64) позволяет писать более производительный код за счёт своих объективных особенностей, в т.ч. увеличения длины и количества регистров, о чём было написано в >>1423023 и что было подтверждено на практике сравнением производительности libvpx-vp9 >>1422945. Незначительное увеличение потребления памяти (машинный код весит на 20% больше) не является для задачи кодирования видео значимым фактором.
Дальнейшее излияние здесь религиозных страхов спермоблядей перед новой архитектурой (не смотря на наличие для них оснований) не считаю уместным. Вопрос закрыт.
>>1423089
Поставь прыщеchroot с ffmpeg'ом, ололо. Только не удивляйся, что кодирование видео будет в момент сажать батарею.
Ещё неплохой вариант — ssh-клиент и прыщесервер за копейки.
>>1423149
Я так и делал, кстати. В полевых условиях сойдет, ничего в момент не село. Но медленно, естественно.
>Поставь прыщеchroot с ffmpeg'ом, ололо.
Я так и делал, кстати. В полевых условиях сойдет, ничего в момент не село. Но медленно, естественно.
>>1423160
С --cpu=cortex-a8 и кодеки с оптимизациями под NEON собирал? У меня даже в яваскрипте без всякого SIMD всего в 8 раз медленнее было. С NEON не должно сильнее, чем в 2-3 раза проседать.
>Но медленно, естественно
С --cpu=cortex-a8 и кодеки с оптимизациями под NEON собирал? У меня даже в яваскрипте без всякого SIMD всего в 8 раз медленнее было. С NEON не должно сильнее, чем в 2-3 раза проседать.
>>1423149
Не равняй одного поехавшего с нормальными спермоблядями.
Не равняй одного поехавшего с нормальными спермоблядями.
Ребят, а почему никто не рассказывает в туториалах об опции -g? vp9 (vp8 не пользуюсь, возможно, он тоже) по умолчанию не имеет ограничения на размер GOP, и ключевой кадр вполне может быть один на две минуты, что очень ограничивает, например, перемотку, т.к. нужно дохрена декодировать каждый раз.
Я обычно ставлю -g 250, этого хватает.
Увидеть ключевые кадры можно вот этим вот однострочником:
[code]ffprobe -of xml -select_streams v -show_entries packet=pts_time,flags -v quiet videofile.webm | grep -v 'flags="_"'[/code]
Я обычно ставлю -g 250, этого хватает.
Увидеть ключевые кадры можно вот этим вот однострочником:
[code]ffprobe -of xml -select_streams v -show_entries packet=pts_time,flags -v quiet videofile.webm | grep -v 'flags="_"'[/code]
>>1423238
Размер экономит, а мы здесь в основном на размер оптимизируем. Кому нужна быстрая перемотка, тот -g поменьше поставит. (В libvpx-vp8 128 по умолчанию.)
Да и есть это всё в вики.
Размер экономит, а мы здесь в основном на размер оптимизируем. Кому нужна быстрая перемотка, тот -g поменьше поставит. (В libvpx-vp8 128 по умолчанию.)
Да и есть это всё в вики.
>>1423282
https://github.com/archlinuxarm/PKGBUILDs/blob/3c66d9f/extra/libvpx/PKGBUILD#L40
Ну ты понел. У них там в 2013-ом году не собиралось под ARM, они и вырубили, обратно включить ещё не успели. Ну и гитовый libvpx говорят что быстрее, чем релиз.
А потом ещё заявляют, что арч быстрый и оптимизированный, ололо.
https://github.com/archlinuxarm/PKGBUILDs/blob/3c66d9f/extra/libvpx/PKGBUILD#L40
Ну ты понел. У них там в 2013-ом году не собиралось под ARM, они и вырубили, обратно включить ещё не успели. Ну и гитовый libvpx говорят что быстрее, чем релиз.
А потом ещё заявляют, что арч быстрый и оптимизированный, ололо.
Возможно ли создать каким-то образом флешку или диск для восстановления проблем при загрузке вин10, находясь в вин7 с помощью каких-то программ, не имея образа системы?
>>1423337
Спермоклоуны как всегда.
>Тред про кодирование вебмок.
>Возможно ли создать каким-то образом флешку или диск для восстановления проблем при загрузке вин10
Спермоклоуны как всегда.
>>1423337
Смотри, в какой тред пишешь.
Это вроде первый за тред, да? Раньше их намного больше было почему-то.
Смотри, в какой тред пишешь.
Это вроде первый за тред, да? Раньше их намного больше было почему-то.
Например, чисто для себя, я нормально делаю в 6 мбайт 75 секунд при 768х432, crf, вроде, 31, good, speed 0. Насколько speed 0 quality best сделает лучше? Ну т.е. поставить на ночь кодировать не проблема, но с такими же параметрами не интересно, чтобы посмотреть разницу.
>>1423571
test
test
43 Кб, 550x556
Погомите настроить пикрилейтид. Чем лучше записывать долгие видео (10-30минут) чтобы был минимальный размер и более-менее качество без мыла и шакальства.
>>1424213
Впервые слышу о нём.
Впервые слышу о нём.
>>1423039
Ещё логику префетчера немного поправили: https://hg.mozilla.org/integration/mozilla-inbound/rev/ebf348f1e465
Скорее должно в найтли прилететь. Впрочем, кто будет смотреть вебмки в лисе, которая в половине случаев кривые цвета отображает?
Ещё логику префетчера немного поправили: https://hg.mozilla.org/integration/mozilla-inbound/rev/ebf348f1e465
Скорее должно в найтли прилететь. Впрочем, кто будет смотреть вебмки в лисе, которая в половине случаев кривые цвета отображает?
>>1424290
И как я этим консолепердольным говном захватывать буду? Там можно забиндить кнопку на старт/паузу/стоп записи?
И как я этим консолепердольным говном захватывать буду? Там можно забиндить кнопку на старт/паузу/стоп записи?
>>1424317
Парашливыйобмазанный в говне обосранный в говнецо спермопитуххуесоска шиндозная спидозная проблядь уебывайнахуй иди на куканец своей раздроченной сракой из этого ИТТОФИЦИАЛЬНОГО КОНФЕССИАЛЬНОГО ТРЕДА ХАРДКОРНЫХ ПОСОНОВ треда.
Парашливыйобмазанный в говне обосранный в говнецо спермопитуххуесоска шиндозная спидозная проблядь уебывайнахуй иди на куканец своей раздроченной сракой из этого ИТТОФИЦИАЛЬНОГО КОНФЕССИАЛЬНОГО ТРЕДА ХАРДКОРНЫХ ПОСОНОВ треда.
>>1424578
короч я направил зарание сраку в сторону ИГИЛ и ждал пока спермоблядт напишет лично мне оскобляющий мое достоинство пост. И короч, я заправил предверие ануса хорошей такой боеголовкой из тяжелого куска засохшего говна, и вот спермач написал свой легендарный пост, и мой пукан бабахнул! Силы бабаха хватило на то, чтобы прорвать систему ПРО всех государств и по бпллистической траектории кусок нагретого трением 3000 по цельсию, воотщем удетел прямсо в бункер ИГИЛ. И упал, столкнувшись о твердь, что детонировало игиловцев.
короч я направил зарание сраку в сторону ИГИЛ и ждал пока спермоблядт напишет лично мне оскобляющий мое достоинство пост. И короч, я заправил предверие ануса хорошей такой боеголовкой из тяжелого куска засохшего говна, и вот спермач написал свой легендарный пост, и мой пукан бабахнул! Силы бабаха хватило на то, чтобы прорвать систему ПРО всех государств и по бпллистической траектории кусок нагретого трением 3000 по цельсию, воотщем удетел прямсо в бункер ИГИЛ. И упал, столкнувшись о твердь, что детонировало игиловцев.
11 Кб, 1847x154
>>1424624
Во-первых можно в кукле врубить показ текста под спойлером под умолчанию.
Во-вторых если ты сам не очень смышлёный, то держи лайфхак.
Во-первых можно в кукле врубить показ текста под спойлером под умолчанию.
Во-вторых если ты сам не очень смышлёный, то держи лайфхак.
Как в mpc-hc настроить вывод времени с точностью до миллисекунд?
https://bugzilla.mozilla.org/show_bug.cgi?id=1207429
Ну теперь заживём! В найтли уже по умолчанию ffmpeg для вебмок используется, даже профиль 3 проигрывает. Криво, правда.
>Enable FFMpeg by default
Ну теперь заживём! В найтли уже по умолчанию ffmpeg для вебмок используется, даже профиль 3 проигрывает. Криво, правда.
>>1424781
Да, хотят на всех платформах использовать: https://bugzilla.mozilla.org/show_bug.cgi?id=1210219
Но пока только лисо-линуксоняши могут наслаждаться невероятной скоростью декодирования VP9 вебмок!
Да, хотят на всех платформах использовать: https://bugzilla.mozilla.org/show_bug.cgi?id=1210219
Но пока только лисо-линуксоняши могут наслаждаться невероятной скоростью декодирования VP9 вебмок!
>>1424794
Они и сейчас тормозят.
Они и сейчас тормозят.
57 Кб, 1256x914
>>1424794
Ну как бы пикрелейтед. Ты 4K 60fps какой-нибудь открой, сразу заметишь.
Ну как бы пикрелейтед. Ты 4K 60fps какой-нибудь открой, сразу заметишь.
>>1424802
Побольше маркетингового буллшита слушай. Это самый правильный способ декодирования с точки зрения конечного результата. Читай http://arhivach.org/thread/100617/#1377676
Побольше маркетингового буллшита слушай. Это самый правильный способ декодирования с точки зрения конечного результата. Читай http://arhivach.org/thread/100617/#1377676
>>1424809
Хуйни не пори, при декодинге через ГПУ нагрузка на систему минимальная, через ЦПУ только ревут кулеры и процессор под под потолок нагружен - результат тот же, но с гораздо более низким уровнем энергоэффективности.
Хуйни не пори, при декодинге через ГПУ нагрузка на систему минимальная, через ЦПУ только ревут кулеры и процессор под под потолок нагружен - результат тот же, но с гораздо более низким уровнем энергоэффективности.
>>1424801
Ну скинь - открою. Вообще искуственный юзкейс какой-то. Вывод 4K@60FPS сейчас поддерживают 1.5 видеокарты. Имеется в виду конечно же HDMI 2.0 для телевизоров. Даунята с милипиздрическими 4K-мониторами обоссаны автоматически.
Ну скинь - открою. Вообще искуственный юзкейс какой-то. Вывод 4K@60FPS сейчас поддерживают 1.5 видеокарты. Имеется в виду конечно же HDMI 2.0 для телевизоров. Даунята с милипиздрическими 4K-мониторами обоссаны автоматически.
>>1424835
Почему у меня на 8K ничего не ревёт, загрузка в районе 200%, а боттлнек вообще в видео-выводе оказался?
Ну т.е. ты ничего не читал из того, на что я сослался.
Действительно, когда у тебя просто чёрный экран на половине современных форматов, нагрузка будет минимальна.
>>1424848
На ютубе полно. Вот, например: https://www.youtube.com/watch?v=7zgrAfq5wDc
Так-то вон жалуются, что даже 1080p60 тормозит: https://bugzilla.mozilla.org/show_bug.cgi?id=1193614
Любая затычка с поддержкой DisplayPort 1.2.
>через ЦПУ только ревут кулеры и процессор под под потолок нагружен
Почему у меня на 8K ничего не ревёт, загрузка в районе 200%, а боттлнек вообще в видео-выводе оказался?
>при декодинге через ГПУ
Ну т.е. ты ничего не читал из того, на что я сослался.
>нагрузка на систему минимальная
Действительно, когда у тебя просто чёрный экран на половине современных форматов, нагрузка будет минимальна.
>>1424848
На ютубе полно. Вот, например: https://www.youtube.com/watch?v=7zgrAfq5wDc
Так-то вон жалуются, что даже 1080p60 тормозит: https://bugzilla.mozilla.org/show_bug.cgi?id=1193614
>Вывод 4K@60FPS сейчас поддерживают 1.5 видеокарты
Любая затычка с поддержкой DisplayPort 1.2.
>>1424876
кек, а у меня 15% на 1080p 15000kbit/s
Говноедов полон тред.
форматов
х264 хватает для всего, а остальное - сырое говно и велосипеды от гугла и оно не нужно.
>200%
кек, а у меня 15% на 1080p 15000kbit/s
>8k
Говноедов полон тред.
>чёрный экран на половине современных
форматов
х264 хватает для всего, а остальное - сырое говно и велосипеды от гугла и оно не нужно.
А при использовании -crf битрейт результата зависит от битрейта оригинала?
Был исходник 3Mbps и на -crf 32 битрейт ~1.3M
А с исходником 14Mbps при -crf 36 битрейт ~2.5M
Был исходник 3Mbps и на -crf 32 битрейт ~1.3M
А с исходником 14Mbps при -crf 36 битрейт ~2.5M
Лисодевки такие тормоза, конечно. Вначале с теорой 4 года всем похуй:
https://bugzilla.mozilla.org/show_bug.cgi?id=640073
Теперь полгода с VP9:
https://bugzilla.mozilla.org/show_bug.cgi?id=1190939
>>1424962
Картинки ж разные. Видимо, на версии с большим битрейтом, больше деталей, которые раздувают битрейт и у vpx.
https://bugzilla.mozilla.org/show_bug.cgi?id=640073
Теперь полгода с VP9:
https://bugzilla.mozilla.org/show_bug.cgi?id=1190939
>>1424962
Картинки ж разные. Видимо, на версии с большим битрейтом, больше деталей, которые раздувают битрейт и у vpx.
>>1424809
Это относится только в vp9 или вообще? Ты рекомендуешь выключить dxva в плеерах и все будет заебись?
Это относится только в vp9 или вообще? Ты рекомендуешь выключить dxva в плеерах и все будет заебись?
>>1424979
Использую --vo=opengl --hwdec=no с mpv больше двух лет и никаких проблем. Любые разрешения, любые форматы, 10bit, цветокоррекция и т.д. hwdec=auto, конечно, хуже не сделает, просто вот у меня, например, аппаратно поддерживаются разрешения только до 2048x2048, а такое и CPU совсем не грузит.
Единственное что на 4K и 8K приходится переключать на vo=xv, т.к. моя затычка офигеваеет от таких громадных текстур. Именно на стороне декодирования ни разу не встречал проблем. Если использовать нормальные многопоточные декодеры от ffmpeg, конечно.
>Ты рекомендуешь выключить dxva в плеерах и все будет заебись?
Использую --vo=opengl --hwdec=no с mpv больше двух лет и никаких проблем. Любые разрешения, любые форматы, 10bit, цветокоррекция и т.д. hwdec=auto, конечно, хуже не сделает, просто вот у меня, например, аппаратно поддерживаются разрешения только до 2048x2048, а такое и CPU совсем не грузит.
Единственное что на 4K и 8K приходится переключать на vo=xv, т.к. моя затычка офигеваеет от таких громадных текстур. Именно на стороне декодирования ни разу не встречал проблем. Если использовать нормальные многопоточные декодеры от ffmpeg, конечно.
>>1425017
А как же madvr? Или виндой вообще не пользуешься и места для madvr в твоем мире нет?
>Использую --vo=opengl --hwdec=no с mpv больше двух лет и никаких проблем.
А как же madvr? Или виндой вообще не пользуешься и места для madvr в твоем мире нет?
>>1425024
This. Хотя, madVR вроде крутой, но на линуксах ничего лучше чем mpv нет. Он ещё и отлично скриптуется к тому же.
Так-то я ничего против аппаратного декодирования не имею, когда конкретный формат поддерживается и без косяков (программную реализацию-то всегда поправить можно, а как ты железку чинить будешь?), просто надоело, что его выставляют как единственно возможный метод декодирования, тогда как на практике то 10бит нет, то ограничения по разрешению, то новые форматы не завезли.
>Или виндой вообще не пользуешься
This. Хотя, madVR вроде крутой, но на линуксах ничего лучше чем mpv нет. Он ещё и отлично скриптуется к тому же.
Так-то я ничего против аппаратного декодирования не имею, когда конкретный формат поддерживается и без косяков (программную реализацию-то всегда поправить можно, а как ты железку чинить будешь?), просто надоело, что его выставляют как единственно возможный метод декодирования, тогда как на практике то 10бит нет, то ограничения по разрешению, то новые форматы не завезли.
49 Кб, 676x339
Пришёл ньюфаг и задаёт тупые вопросы. После команды из пункта 3.4 гайда с картинки >>1395795 выдает пикрилейтед. Спросил в вебм-треде, но отлучился, и его смыло. Почему это происходит, как чинить, почему нужно чинить именно так?
1 Кб, 528x19
>>1425103
Команда. По отдельности видео и звук из out-v.webm и out-a.ogg воспроизводятся.
Команда. По отдельности видео и звук из out-v.webm и out-a.ogg воспроизводятся.
я ебал
89 Кб, 1920x1080
87 Кб, 1920x1080
102 Кб, 1920x1080
http://www.compression.ru/video/codec_comparison/hevc_2015/
Опубликовали сравнения энкодеров. Так и нет нвидиевского, x265 адовый слоупок, а libvpx-vp9 рвёт практически всех, отставая на пару процентов от лучшей реализации HEVC. Таким образом, VP9 сейчас это можно сказать лучшее решение в категории скорость/качество. H.264/H.265-бляди, как обычно, соснули хуйца у VP9-богов :3
Опубликовали сравнения энкодеров. Так и нет нвидиевского, x265 адовый слоупок, а libvpx-vp9 рвёт практически всех, отставая на пару процентов от лучшей реализации HEVC. Таким образом, VP9 сейчас это можно сказать лучшее решение в категории скорость/качество. H.264/H.265-бляди, как обычно, соснули хуйца у VP9-богов :3
>>1425456
Помогло удаление старой версии, спасибо.
Помогло удаление старой версии, спасибо.
>>1425482
Пердоля, плиз.
Не вижу там ничего про аппаратную поддержку. Особенно в мобильных устройствах.
>>А теперь давай сравнение декодеров
>ffhevc
Пердоля, плиз.
>>И аппаратной поддержки
Не вижу там ничего про аппаратную поддержку. Особенно в мобильных устройствах.
>>1425510
Никак )0))
Никак )0))
Облазил все доски, так и не придумал куда написать, кроме как здесь:
Конвертации вопрос.
Есть видео, снятое на miniDV камеру.
Обьем его - 12 Гб, по причине нахуй ненужного аудиобитрейта в 2500кбс.
Чем понятно, а вот как конвертировать без изменения кач-ва изображения, но с ужимом битрейта до 320ти?
Спасибо за внимание.
Конвертации вопрос.
Есть видео, снятое на miniDV камеру.
Обьем его - 12 Гб, по причине нахуй ненужного аудиобитрейта в 2500кбс.
Чем понятно, а вот как конвертировать без изменения кач-ва изображения, но с ужимом битрейта до 320ти?
Спасибо за внимание.
>>1425524
Используй кодеки, способные сжимать без потерь. H.264, VP9, FFV1, HuffYUV, FFVHuff, Lagarith и т.д. Хорошее сжатие, скорее всего, только первые 2 обеспечат с самыми ресурсозатратными пресетами.
Используй кодеки, способные сжимать без потерь. H.264, VP9, FFV1, HuffYUV, FFVHuff, Lagarith и т.д. Хорошее сжатие, скорее всего, только первые 2 обеспечат с самыми ресурсозатратными пресетами.
>>1425525
Есть условный Вегас, и есть я, у которого мало времени на тесты всевозможных комбинаций галочек и пунктиков в этом самом вегасе. Какой набор настроек мне требуется для достижения цели?
Спасибо.
Есть условный Вегас, и есть я, у которого мало времени на тесты всевозможных комбинаций галочек и пунктиков в этом самом вегасе. Какой набор настроек мне требуется для достижения цели?
Спасибо.
>>1425525
Или, если я правильно понял, то тебе нужно просто:
ffmpeg -i in.mp4 -c:v copy -c:a libmp3lame -b:a 320k out.mp4
Или, если я правильно понял, то тебе нужно просто:
ffmpeg -i in.mp4 -c:v copy -c:a libmp3lame -b:a 320k out.mp4
>>1425531
Видимо неправильно понял, увы.
Видимо неправильно понял, увы.
57 Кб, 564x592
Как повысить резкость у webm? Постоянно натыкаюсь на то, что оригиналы в mp4 дают более четкое изображение, даже при одинаковом битрейте, по сравнению с webm. Изображение в webm получается слишком размытым. Есть способы этого избежать?
Здравствуйте, подскажите пожалуйста, был вебм , где показывали как пользоваться программой, Decoder что-то там. В основном действия строились на выставлении конечного формата. Добавить > Декодировать
>>1425572
Здесь только про ффмпег тред. Тебе в порнотред надо.
Здесь только про ффмпег тред. Тебе в порнотред надо.
>>1425572
Здесь тебе ничего не подскажут, тут сидят какие-то злобные анимешники-линуксоиды.
Вообще непонятно что этот тред делает в /s, да ещё и закреплён, его следует пидорнуть куда-нибудь в /media
Здесь тебе ничего не подскажут, тут сидят какие-то злобные анимешники-линуксоиды.
Вообще непонятно что этот тред делает в /s, да ещё и закреплён, его следует пидорнуть куда-нибудь в /media
>>1425605
Две строчки в консолечке так трудно, что только злобный анимешник-линуксоид осилит? Тебе не стыдно быть таким дауном?
Две строчки в консолечке так трудно, что только злобный анимешник-линуксоид осилит? Тебе не стыдно быть таким дауном?
>>1425695
Вики из шапки почитать, например, мудило.
Вики из шапки почитать, например, мудило.
158 Кб, 790x444
Пришла пора выяснить, какой же браузер лучше справляется с задачей проигрывания WebM?
Firefox
± Традиционно куча проблем с MSE на Linux, но в найтли вроде уже починили
− Не понимает теги цветового пространства VP9, всегда использует BT.601
+ Перешёл на ffvp9 (пока только в Nightly и на Linux)
± С ffvp9 воспроизводит все профили VP9, даже многобитные, но корректно выглядят только нулевой и в некоторых случаях первый
Chrome
+ С MSE всё в порядке
+ Начиная с версии 46 есть даже эвристика выбора цветовой матрицы по разрешению видео, теги правильно понимал ещё раньше
± libvpx для VP9 (теоретически, можно отключить при компиляции и тогда должен использоваться ffvp9, но не проверял)
− Только нулевой профиль, на остальных крашит таб с видео
Бонус: поддерживает альфа-канал в VP8.
Итог: я б сказал, что суммарно более-менее одинаково, но если в FF починят распрознавание тегов и дополнительные профили (в чём я сомневаюсь, впрочем), будет перевес на его стороне.
Firefox
± Традиционно куча проблем с MSE на Linux, но в найтли вроде уже починили
− Не понимает теги цветового пространства VP9, всегда использует BT.601
+ Перешёл на ffvp9 (пока только в Nightly и на Linux)
± С ffvp9 воспроизводит все профили VP9, даже многобитные, но корректно выглядят только нулевой и в некоторых случаях первый
Chrome
+ С MSE всё в порядке
+ Начиная с версии 46 есть даже эвристика выбора цветовой матрицы по разрешению видео, теги правильно понимал ещё раньше
± libvpx для VP9 (теоретически, можно отключить при компиляции и тогда должен использоваться ffvp9, но не проверял)
− Только нулевой профиль, на остальных крашит таб с видео
Бонус: поддерживает альфа-канал в VP8.
Итог: я б сказал, что суммарно более-менее одинаково, но если в FF починят распрознавание тегов и дополнительные профили (в чём я сомневаюсь, впрочем), будет перевес на его стороне.
>>1426151
У меня никаких проблем нет с MSE.
> ± Традиционно куча проблем с MSE на Linux, но в найтли вроде уже починили
У меня никаких проблем нет с MSE.
>>1426151
Пока здоровые люди смотрят в mpv, браузероговноеды все пытаются скрестить ежа с ужом, приделывая к просмотрщику гипертекста невероятные костыли для задачи, к которой он вообще не предназначен.
Пока здоровые люди смотрят в mpv, браузероговноеды все пытаются скрестить ежа с ужом, приделывая к просмотрщику гипертекста невероятные костыли для задачи, к которой он вообще не предназначен.
>>1426153
Не надо, здесь другие ребята. Пердолят исходники и все дела.
Я вот только не пойму, вы в какую-нибудь релиз-группу попасть не пробовали? Делали бы качественные рипы людям на пользу вместо смищных роликов.
Не надо, здесь другие ребята. Пердолят исходники и все дела.
Я вот только не пойму, вы в какую-нибудь релиз-группу попасть не пробовали? Делали бы качественные рипы людям на пользу вместо смищных роликов.
141 Кб, 1253x947
>>1426153
В багтрекер глянь. Например, на этот метабаг, ололо: https://bugzilla.mozilla.org/show_bug.cgi?id=MSE
>>1426158
Дай угадаю, очередной адепт NoScript, поддавшийся на идиотские форсы ничего не смыслящих в предмете фанатиков :3 Я-то через mpv смотрю, кстати, так удобнее и не хочу в контейнере звук включать.
>>1426161
Будто бы здесь кто-нибудь умеет что-то кроме вбивания стандартной команды ffmpeg. Впрочем, я понемногу VapourSynth ковыряю, выглядит прикольно и кроссплатформенный к тому же.
В багтрекер глянь. Например, на этот метабаг, ололо: https://bugzilla.mozilla.org/show_bug.cgi?id=MSE
>>1426158
Дай угадаю, очередной адепт NoScript, поддавшийся на идиотские форсы ничего не смыслящих в предмете фанатиков :3 Я-то через mpv смотрю, кстати, так удобнее и не хочу в контейнере звук включать.
>>1426161
>Делали бы качественные рипы
Будто бы здесь кто-нибудь умеет что-то кроме вбивания стандартной команды ffmpeg. Впрочем, я понемногу VapourSynth ковыряю, выглядит прикольно и кроссплатформенный к тому же.
>>1426171
Ну у меня то никаких проблем нет с ним.
> В багтрекер глянь. Например, на этот метабаг, ололо: https://bugzilla.mozilla.org/show_bug.cgi?id=MSE
Ну у меня то никаких проблем нет с ним.
>>1426161
Этих релиз-групп с "качественными рипами" так дохуя, что просто дохуя. Зачем?
>Я вот только не пойму, вы в какую-нибудь релиз-группу попасть не пробовали? Делали бы качественные рипы людям на пользу вместо смищных роликов.
Этих релиз-групп с "качественными рипами" так дохуя, что просто дохуя. Зачем?
http://www.compression.ru/video/codec_comparison/hevc_2015/MSU_HEVC_comparison_2015_free.pdf
Расширенная версия сравнения кодеков от MSU. Они оказывается libvpx 1.3.0 со speed=1 тестировали, я фигею (впрочем, в 1.3.0 ещё не было tile-columns, всё напутали небось). Но даже так результат очень хороший по сравнению с остальными.
Расширенная версия сравнения кодеков от MSU. Они оказывается libvpx 1.3.0 со speed=1 тестировали, я фигею (впрочем, в 1.3.0 ещё не было tile-columns, всё напутали небось). Но даже так результат очень хороший по сравнению с остальными.
>>1426248
Параметр-то был, только он не использовался в VP9, а игнорировался.
> впрочем, в 1.3.0 ещё не было tile-columns, всё напутали небось
Параметр-то был, только он не использовался в VP9, а игнорировался.
>>1395791 (OP)
test
test
Тут было про хардварный декод, вот madshi, создатель madvr, тоже пояснил
>Both CUVID and "copyback DXVA" are very similar. CUVID also always includes a copyback operation. The only advantage CUVID offers over copyback DXVA is that CUVID supports deinterlacing inside of LAV Video Decoder, which copyback DXVA currently does not support. But that's really not very important, when using madVR. So there's pretty much zero reason to use CUVID. It used to be a good solution, but copyback DXVA has improved so much that it's overall quite a bit better than CUVID now.
>Native DXVA saves the copyback, so it lowers CPU usage. However, DXVA decodes to a format that it hard to work with for madVR. This results in a certain loss in chroma quality. In most situations you probably won't see the difference, but it's there. So unless you have to use native DXVA for some reason, using copyback DXVA is the better choice. Personally, I even use straight software decoding because for me it's the fastest and most reliable decoder.
>Can't you just trust in what we said? Namely that native DXVA decoding comes with a small quality loss on some GPUs? That's a fact. Why that is the case is highly technical and shouldn't really be very important to you as a user, or am I wrong? It's just the way it is. Use native DXVA decoding if you want lowest power consumption. Use copyback DXVA or software decoding if you want highest quality. My best guess is that CUVID will sooner or later disappear from LAV Video Decoder.
>>1428247
На каком-нибудь кукарекоре ай7 что ли? Это сейчас никого не ебет. Иди владельцам смартфонов (особенно нетоповых) расскажи про чудеса софтварного декодирования, лол.
>I even use straight software decoding because for me it's the fastest and most reliable decoder
На каком-нибудь кукарекоре ай7 что ли? Это сейчас никого не ебет. Иди владельцам смартфонов (особенно нетоповых) расскажи про чудеса софтварного декодирования, лол.
>>1428275
Это подразумевает использование всяких анальных извращений (вроде ваших ИТТ) ради 1% экономии, после чего получившийся файл не переварит большая часть аппаратных декодеров.
>most reliable decoder
Это подразумевает использование всяких анальных извращений (вроде ваших ИТТ) ради 1% экономии, после чего получившийся файл не переварит большая часть аппаратных декодеров.
>>1428303
Много видюх знаешь с аппаратной поддержкой популярных анимешных H.264 10bit релизов? inb4 они тоже извращенцы
Много видюх знаешь с аппаратной поддержкой популярных анимешных H.264 10bit релизов? inb4 они тоже извращенцы
>>1428311
В хорошем вопросе есть 80% ответа. У тебя просто отличный вопрос.
>анимешных
>10bit
>они тоже извращенцы
В хорошем вопросе есть 80% ответа. У тебя просто отличный вопрос.
>>1428247
В mpv, кстати, LCMS и весь прочий color management на GPU производится и копирование результата декодинга только для VAAPI и DXVA2 реализовано. С hwdec=vdpau, видимо, всё ок.
Ещё есть поддержка аппаратного постпроцессинга вроде vdpaupp и vavpp. Качество, наверняка, плохое, зато может быть быстрее собственных шейдеров mpv на слабых видеокарточках.
В mpv, кстати, LCMS и весь прочий color management на GPU производится и копирование результата декодинга только для VAAPI и DXVA2 реализовано. С hwdec=vdpau, видимо, всё ок.
Ещё есть поддержка аппаратного постпроцессинга вроде vdpaupp и vavpp. Качество, наверняка, плохое, зато может быть быстрее собственных шейдеров mpv на слабых видеокарточках.
>>1428258
Неужели какой-нибудь дешевый пентиум на последнем ядре, если такие есть, я честно говоря не слежу, не потянет софтварно все современное? Без 4К.
>На каком-нибудь кукарекоре ай7
Неужели какой-нибудь дешевый пентиум на последнем ядре, если такие есть, я честно говоря не слежу, не потянет софтварно все современное? Без 4К.
В ffmpeg добавили фильтр zscale на основе z.lib из VapourSynth для конвертирования между разными цветовыми моделями, с дизерингом и всей фигнёй.
https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=416e35e5aafc2a2bf77372d5e8479c28796d1451;hp=e11e32686fdb21aded1ccf70202f1fffe87bb6a2
Олсо,
https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=416e35e5aafc2a2bf77372d5e8479c28796d1451;hp=e11e32686fdb21aded1ccf70202f1fffe87bb6a2
Олсо,
>add VAG support
Господа хорошие, может быть, очевидная вещь прозвучит, но всё же спрошу.
-vf subtitles нужен для нарезки хардсаба из контейнера, -vf ass - из внешних сабов форматов .ass и .ssa, так? А чем тогда нарезать внешние сабы из .srt?
-vf subtitles нужен для нарезки хардсаба из контейнера, -vf ass - из внешних сабов форматов .ass и .ssa, так? А чем тогда нарезать внешние сабы из .srt?
>>1428842
vf_subtitles конвертирует любой поддерживаемый формат субтитров в ASS, vf_ass поддерживает только ASS. Оба используют libass. vf_ass смысла использовать почти нет вообще.
vf_subtitles конвертирует любой поддерживаемый формат субтитров в ASS, vf_ass поддерживает только ASS. Оба используют libass. vf_ass смысла использовать почти нет вообще.
>>1428847
Тогда еще вдогонку спрошу - пробовал конвертить сабы из .srt в .ass одной строкой:
ffmpeg -i sub.srt -sub_charenc windows-1251 sub.ass
Всё правильно сделал?
Тогда еще вдогонку спрошу - пробовал конвертить сабы из .srt в .ass одной строкой:
ffmpeg -i sub.srt -sub_charenc windows-1251 sub.ass
Всё правильно сделал?
>>1428959
ffmpeg -i video -map 0:0 -map 0:1 -i subtitry -map 1:0 -c:s libass -f matroska filmec.mkv
Ты делаешь лишние телодвижения.
Никогда не делал этого, но должно быть так.
ffmpeg -i video -map 0:0 -map 0:1 -i subtitry -map 1:0 -c:s libass -f matroska filmec.mkv
Ты делаешь лишние телодвижения.
Никогда не делал этого, но должно быть так.
>>1428981
А зачем субтитры перекодировать? Матрёшка ж и SRT поддерживает, просто -c:s copy достаточно.
А зачем субтитры перекодировать? Матрёшка ж и SRT поддерживает, просто -c:s copy достаточно.
гайс, подскажите программу для установки и обновлений дров, а то после переустановки винды все дрова потерялись
>>1429209
ffmpeg
ffmpeg
>>1429209
У вас же пакетный менеджер есть. Шоколадка или как там его.
У вас же пакетный менеджер есть. Шоколадка или как там его.
>>1429209
Обрати внимание, о чём тхреад, дегенерат.
Обрати внимание, о чём тхреад, дегенерат.
2436 Кб, 1328x2500
Тем временем новости из багзиллы.
На виндоуз завезли кривой патчи для поддержки ffmpeg: https://bugzilla.mozilla.org/show_bug.cgi?id=1214462
Для Windows 10 хотят включить VP9 MSE по умолчанию: https://bugzilla.mozilla.org/show_bug.cgi?id=1216018
Любители H.265 до того упоролись, что засовывают AAC в WebM: https://bugzilla.mozilla.org/show_bug.cgi?id=1214441
Четырёхлетний баг проигрывания Theora без цветовой дискретизации исправлен: https://bugzilla.mozilla.org/show_bug.cgi?id=1195152
На виндоуз завезли кривой патчи для поддержки ffmpeg: https://bugzilla.mozilla.org/show_bug.cgi?id=1214462
Для Windows 10 хотят включить VP9 MSE по умолчанию: https://bugzilla.mozilla.org/show_bug.cgi?id=1216018
Любители H.265 до того упоролись, что засовывают AAC в WebM: https://bugzilla.mozilla.org/show_bug.cgi?id=1214441
Четырёхлетний баг проигрывания Theora без цветовой дискретизации исправлен: https://bugzilla.mozilla.org/show_bug.cgi?id=1195152
>>1395791 (OP)
Есть 20Gb записей захватом экрана с онлайн трансляций, но из-за кривой записи, видео воспроизводится в 2 раза медленней чем должно быть (15фпс вместо 30фпс), а звук заканчивается на середине всех записей. Можно ли как то это пофиксить через ffmpeg без переконвертации всех 20гб видео? Пока ебусь с двумя плеерами, на одном только звук, а на другом видео х2 ускорением, но это очень неудобно.
Есть 20Gb записей захватом экрана с онлайн трансляций, но из-за кривой записи, видео воспроизводится в 2 раза медленней чем должно быть (15фпс вместо 30фпс), а звук заканчивается на середине всех записей. Можно ли как то это пофиксить через ffmpeg без переконвертации всех 20гб видео? Пока ебусь с двумя плеерами, на одном только звук, а на другом видео х2 ускорением, но это очень неудобно.
3167 Кб, Webm
3446 Кб, Webm
2333 Кб, Webm
>>1430546
Шикарно, почти на уровне хрома. Нужно подождать стабильной версии и можно перекатываться.
>патчи для поддержки ffmpeg
Шикарно, почти на уровне хрома. Нужно подождать стабильной версии и можно перекатываться.
>>1430654
ffmpeg ещё не мержили на виндоуз, это скорее всего результат патчей из
https://bugzilla.mozilla.org/show_bug.cgi?id=1193614 и
https://bugzilla.mozilla.org/show_bug.cgi?id=1213131
Хотя странно, что у тебя лиса до сих пор фреймы дропает. Они там бедные уже все извелись в попытках сделать проигрывание без тормозов.
ffmpeg ещё не мержили на виндоуз, это скорее всего результат патчей из
https://bugzilla.mozilla.org/show_bug.cgi?id=1193614 и
https://bugzilla.mozilla.org/show_bug.cgi?id=1213131
Хотя странно, что у тебя лиса до сих пор фреймы дропает. Они там бедные уже все извелись в попытках сделать проигрывание без тормозов.
>>1430673
Если запущена только лиса без какой-либо фоновой нагрузки, то не кадры не пропускаются.
Если, например, запустить вебм одновременно в хроме и лисе, то в лисе есть подвисания, а в хроме нет.
Если запущена только лиса без какой-либо фоновой нагрузки, то не кадры не пропускаются.
Если, например, запустить вебм одновременно в хроме и лисе, то в лисе есть подвисания, а в хроме нет.
58 Кб, 952x638
>>1430649
Если без перекодировки, то можешь попробовать поиграться с выделенными настройками на пикрелейтед, как для видео, так и для звука.
Если без перекодировки, то можешь попробовать поиграться с выделенными настройками на пикрелейтед, как для видео, так и для звука.
Делаю вебм сохранив оригинальный фреймрейт 60 (без звука)
Делаю с точно такими же параметрами, добавив лишь -r 30
Объясните это дерьмо.
> 9,58 МБ.
Делаю с точно такими же параметрами, добавив лишь -r 30
> 10,7 МБ
Объясните это дерьмо.
>>1431132
Из-за изменений в последовательности кадров, кодек сделал другие, менее эффективные предсказания движения?
Сдампи все кадры в обоих случаях, сравнивай. Размеры пакетов тоже сравни покадрово.
Из-за изменений в последовательности кадров, кодек сделал другие, менее эффективные предсказания движения?
Сдампи все кадры в обоих случаях, сравнивай. Размеры пакетов тоже сравни покадрово.
87 Кб, Webm
тест
ffmpeg -i pr.webm -i pr1.webm -c copy -map 0:v -map 1:v -c:v:1 vp9 -b:v:1 0 d-on3p.web
ffmpeg -i pr.webm -i pr1.webm -c copy -map 0:v -map 1:v -c:v:1 vp9 -b:v:1 0 d-on3p.web
102 Кб, Webm
тест2
ffmpeg -hide_banner -i pr.webm -i pr1.webm -c copy -map 0:v -map 1:v -c:v:1 vp9 -b:v:1 0 -crf 8 -speed 1 d-on3p.webm
ffmpeg -hide_banner -i pr.webm -i pr1.webm -c copy -map 0:v -map 1:v -c:v:1 vp9 -b:v:1 0 -crf 8 -speed 1 d-on3p.webm
>>1431330
да, бля
да, бля
>>1431303
Разрешение должно быть больше. Это особенность ffmpeg просто. Макака может в любую минуту добавить -map 0:v:0 и работать перестанет.
Разрешение должно быть больше. Это особенность ffmpeg просто. Макака может в любую минуту добавить -map 0:v:0 и работать перестанет.
84 Кб, Webm
>>1431370
-pix_fmt yuv420p забыл
-pix_fmt yuv420p забыл
>>1431341
Главное чтобы на краутчане работало, только так там можно постить vp9 - с vp8 превью.
Главное чтобы на краутчане работало, только так там можно постить vp9 - с vp8 превью.
>>1431374
краучан для педофилов
краучан для педофилов
Дайте нюфагу советов мудрых по кодированию хорошего аудио.
Я пока просто пишу просто -b:a 320k, например.
Это по дефолту будет Vorbis. В ОП-посте написано:
"libvorbis при указании битрейта (-b:a) работает в режиме CBR (постоянный битрейт), и это портит качество звука; для режима VBR вместо битрейта надо указывать качество (-q:a);"
Значит я нерационально делаю? Как работать с ключом -q:a ?
Алсо, если указывать таки битрейт, число должно быть чему-то пропорционально, или можно любое ставить? Например 142к, 228к, 1488к и т.д.
Я пока просто пишу просто -b:a 320k, например.
Это по дефолту будет Vorbis. В ОП-посте написано:
"libvorbis при указании битрейта (-b:a) работает в режиме CBR (постоянный битрейт), и это портит качество звука; для режима VBR вместо битрейта надо указывать качество (-q:a);"
Значит я нерационально делаю? Как работать с ключом -q:a ?
Алсо, если указывать таки битрейт, число должно быть чему-то пропорционально, или можно любое ставить? Например 142к, 228к, 1488к и т.д.
>>1431460
Opus — лучший аудио-кодек для сжатия с потерями общего назначения, особенно хорош на низких битрейтах.
-c:a libopus -b:a 64k ← нормально для немузыкально-ориентированных видео (в основном речь)
-c:a libopus -b:a 96k или 128k и выше ← для музыки
-c:a libopus -b:a 48k ← если совсем в размер не влезаешь, будет нормально, в принципе (я и в 8k скринкасты энкодил, впрочем)
>по кодированию хорошего аудио
Opus — лучший аудио-кодек для сжатия с потерями общего назначения, особенно хорош на низких битрейтах.
-c:a libopus -b:a 64k ← нормально для немузыкально-ориентированных видео (в основном речь)
-c:a libopus -b:a 96k или 128k и выше ← для музыки
-c:a libopus -b:a 48k ← если совсем в размер не влезаешь, будет нормально, в принципе (я и в 8k скринкасты энкодил, впрочем)
>>1431484
Но ведь в вики написано, что для звука выше 128к лучше использовать Vorbis. Тогда разве не им следует кодировать видео с упором на музыку? В чем соль использовать opus ?
Но ведь в вики написано, что для звука выше 128к лучше использовать Vorbis. Тогда разве не им следует кодировать видео с упором на музыку? В чем соль использовать opus ?
>>1431526
иди ВУЗ поступай, там тебе обеснят о психовосприятии звука, Емеля ты деревенщина
иди ВУЗ поступай, там тебе обеснят о психовосприятии звука, Емеля ты деревенщина
>>1431526
Так не сказано, что надо использовать Vorbis, а что Vorbis на высоких битрейтах тоже достаточно хорош. И что у Opus баг с зацикливанием в Firefox, который уже починен.
Вот что говорят разработчики Xiph по этому поводу:
16:14 < q> Are there any disadvantages of using Opus for high bitrates compared to Vorbis, in terms of quality?
16:17 < ron_> aside from "maybe a few things that support vorbis still don't support opus yet", not really.
16:18 < ron_> once you're at a high enough bitrate for it to be transparent, it's transparent. and opus should generally get there at a lower bitrate than vorbis.
16:19 < ron_> there's might be some outliers to that, but they're probably good candidates for further tuning of opus :)
Если недостаточно, то вот: https://wiki.xiph.org/OpusFAQ#Will_Opus_replace_Vorbis_in_video_files.3F
Можешь ещё сравнения на Hydrogenaudio погуглить.
Так не сказано, что надо использовать Vorbis, а что Vorbis на высоких битрейтах тоже достаточно хорош. И что у Opus баг с зацикливанием в Firefox, который уже починен.
Вот что говорят разработчики Xiph по этому поводу:
16:14 < q> Are there any disadvantages of using Opus for high bitrates compared to Vorbis, in terms of quality?
16:17 < ron_> aside from "maybe a few things that support vorbis still don't support opus yet", not really.
16:18 < ron_> once you're at a high enough bitrate for it to be transparent, it's transparent. and opus should generally get there at a lower bitrate than vorbis.
16:19 < ron_> there's might be some outliers to that, but they're probably good candidates for further tuning of opus :)
Если недостаточно, то вот: https://wiki.xiph.org/OpusFAQ#Will_Opus_replace_Vorbis_in_video_files.3F
Можешь ещё сравнения на Hydrogenaudio погуглить.
>>1431540
Благодарю, так понятнее.
Благодарю, так понятнее.
krysa
31 Кб, 667x604
авпваппав
Аноны, объясните на пальцах идиоту про совместное использование -b:v и -crf.
В треде почти везде -b:v 0, а -crf имеет какое-то значение.
Понял только, что -b:v ограничивает битрейт видео, а -crf типа сжимает видео, что заметно на динамических сценах.
В треде почти везде -b:v 0, а -crf имеет какое-то значение.
Понял только, что -b:v ограничивает битрейт видео, а -crf типа сжимает видео, что заметно на динамических сценах.
>>1431615
-b:v означает что ты хочешь чтобы битрейт не был константой, т.е. где сцена динамическая - там побольше битрейт, где нихуя не происходит - поменьше.
После этого ты или указываешь crf, что есть степень сжатия (0 - лосслесс, каждые 6 в среднем режут объем в 2 раза), или -b:v 620K где 620к - это целевой средний битрейт (т.е. при 2pass кодинге у тебя по идее наберется примерно 620*секунд в видео килобит+звук). По сути в этом случае ffmpeg сам подберет нужный crf. Поскольку с выбранным вручную crf сложно что-то прогнозировать, не советую им пользоваться, он может быть полезен когда тебе нужно определенное качество, а на объем похуй (bdrip пережимаешь например).
-b:v означает что ты хочешь чтобы битрейт не был константой, т.е. где сцена динамическая - там побольше битрейт, где нихуя не происходит - поменьше.
После этого ты или указываешь crf, что есть степень сжатия (0 - лосслесс, каждые 6 в среднем режут объем в 2 раза), или -b:v 620K где 620к - это целевой средний битрейт (т.е. при 2pass кодинге у тебя по идее наберется примерно 620*секунд в видео килобит+звук). По сути в этом случае ffmpeg сам подберет нужный crf. Поскольку с выбранным вручную crf сложно что-то прогнозировать, не советую им пользоваться, он может быть полезен когда тебе нужно определенное качество, а на объем похуй (bdrip пережимаешь например).
>>1431644
Криво объяснено, кстати. И термины переведены неправильно.
VBR это по сути автоподбор QP. И при CQ QP тоже плавает в некоторых пределах. Кроме QP на низком уровне и нет ничего, что приводило бы к порче изображения (почти, ещё всякие луп-фильтры), он определяет сколько информации о цвете пикселей потеряется (точнее там уже коэффициенты DCT-матриц), выступая в роли знаменателя.
В режиме VBR на первом проходе выполняется обычный энкодинг с каким-то фиксированным QP, на втором он корректируется, исходя из заданного пользователем битрейта и реально полученного размера пакетов (т.е. интерполируется).
В режиме CQ заданный QP используется в качестве базового. (Про -b:v в режиме CQ, qmin и qmax по ссылке правильно написано.) Т.е. энкодер всегда оперирует с QP, явно или неявно.
Constant quality это частный случай CQ, когда ограничений на итоговый размер нет (т.е. -b:v 0 в ffmpeg).
CBR почти то же, что и VBR, но энкодер не позволяет себе гибко перераспределять QP кадров в пределах своего буфера, тем самым теряя в эффективности. По этой же причине однопроходное кодирование приводит к ухудшению качества. (У x264, как говорят, и один проход с -crf использует гигантские буфера, в отличии от libvpx, где второй проход с CQ помогает лучше распределять QP.)
Криво объяснено, кстати. И термины переведены неправильно.
VBR это по сути автоподбор QP. И при CQ QP тоже плавает в некоторых пределах. Кроме QP на низком уровне и нет ничего, что приводило бы к порче изображения (почти, ещё всякие луп-фильтры), он определяет сколько информации о цвете пикселей потеряется (точнее там уже коэффициенты DCT-матриц), выступая в роли знаменателя.
В режиме VBR на первом проходе выполняется обычный энкодинг с каким-то фиксированным QP, на втором он корректируется, исходя из заданного пользователем битрейта и реально полученного размера пакетов (т.е. интерполируется).
В режиме CQ заданный QP используется в качестве базового. (Про -b:v в режиме CQ, qmin и qmax по ссылке правильно написано.) Т.е. энкодер всегда оперирует с QP, явно или неявно.
Constant quality это частный случай CQ, когда ограничений на итоговый размер нет (т.е. -b:v 0 в ffmpeg).
CBR почти то же, что и VBR, но энкодер не позволяет себе гибко перераспределять QP кадров в пределах своего буфера, тем самым теряя в эффективности. По этой же причине однопроходное кодирование приводит к ухудшению качества. (У x264, как говорят, и один проход с -crf использует гигантские буфера, в отличии от libvpx, где второй проход с CQ помогает лучше распределять QP.)
Аноны, дайте какую-нибудь инфу о сея действах, как шаманить 60fps? Через pp и ae получается постоянно треш. Гайды в инетах дрвние, как динозавры. Поясните как делаете сами.
>>1395791 (OP)
При запуске конвертирования пишет следующее:
ffmpeg.exe exited with exit code 1.
Что блядь ему нужно? Уже и в простейшей программе с двумя кнопками нужно копаться?
>WebMConverter
При запуске конвертирования пишет следующее:
ffmpeg.exe exited with exit code 1.
Что блядь ему нужно? Уже и в простейшей программе с двумя кнопками нужно копаться?
>>1431677
Там же по ссылке внизу сказано, что нужно ещё кое-какой софт иметь установленным, это условие выполнено?
Там же по ссылке внизу сказано, что нужно ещё кое-какой софт иметь установленным, это условие выполнено?
>>1431682
Естественно.
Естественно.
>>1431688
Создавай тогда новый баг. Фигли ты здесь-то ноешь?
Создавай тогда новый баг. Фигли ты здесь-то ноешь?
Конвертирую папку из ts в mp4. Всего там три файла.
Юзаю команду ffmpeg -i in.ts out.mp4
Вот размеры файлов, ts->mp4:
111M->123M
86M->165M
129M->766M
У входных файлов разрешение одинаковое. Длительность 40-60 мин. Первые два файла заняли не больше 15 мин. Последний конвертировался всю ночь, при том еще и не завершился, остановил.
Почему так долго занял последний файл?
Может опцию еще какую указать?
Почему размеры выходных файлов не пропорциональны?
В каком формате сейчас модно хранить видео?
Юзаю команду ffmpeg -i in.ts out.mp4
Вот размеры файлов, ts->mp4:
111M->123M
86M->165M
129M->766M
У входных файлов разрешение одинаковое. Длительность 40-60 мин. Первые два файла заняли не больше 15 мин. Последний конвертировался всю ночь, при том еще и не завершился, остановил.
Почему так долго занял последний файл?
Может опцию еще какую указать?
Почему размеры выходных файлов не пропорциональны?
В каком формате сейчас модно хранить видео?
>>1431795
-c copy укажи.
-c copy укажи.
>>1431795
Ты думаешь дефалтные параметры в ффмпеге сделаны на все случаи жизни и для всех целей? Хуй там. Подбирай сам, читай вики, откуда ффмегу знать в каком говнокачестве у тебя исходники и какое говно из них ты хочешь сделать?
Ты думаешь дефалтные параметры в ффмпеге сделаны на все случаи жизни и для всех целей? Хуй там. Подбирай сам, читай вики, откуда ффмегу знать в каком говнокачестве у тебя исходники и какое говно из них ты хочешь сделать?
>>1431795
В оригинале? Любое перекодирование снижает качество.
Кстати, никто не пробовал фильтры вроде 2dcleaner накручивать, чтобы избавиться от отвратительного алиасинга на очень низких битрейтах (~200k)?
Вот как здесь, например: http://rutracker.org/forum/viewtopic.php?t=2253052 Да, вся душа в виде оригинального шума плёнки потеряна, знаю, зато сжалось-то как офигенно. Аналогичные рипы раза в 3 больше весят. Для борд самое то.
Пока только приходится уменьшать разрешение в самый край (288p) и уменьшать fps до 12, чтобы выглядело пристойно.
>В каком формате сейчас модно хранить видео?
В оригинале? Любое перекодирование снижает качество.
Кстати, никто не пробовал фильтры вроде 2dcleaner накручивать, чтобы избавиться от отвратительного алиасинга на очень низких битрейтах (~200k)?
Вот как здесь, например: http://rutracker.org/forum/viewtopic.php?t=2253052 Да, вся душа в виде оригинального шума плёнки потеряна, знаю, зато сжалось-то как офигенно. Аналогичные рипы раза в 3 больше весят. Для борд самое то.
Пока только приходится уменьшать разрешение в самый край (288p) и уменьшать fps до 12, чтобы выглядело пристойно.
Есть ли какой-нибудь скрипт по поиску и выпиливанию одинаковых webm?
6085 Кб, Webm
>>1432070
VP8 и VP9 позволяют их указывать, это не H.264.
Разве что у хромиума были проблемы с воспроизведением.
VP8 и VP9 позволяют их указывать, это не H.264.
Разве что у хромиума были проблемы с воспроизведением.
>>1432118
Лол, даже в 3gp на первых телефонах с видеокамерами вроде больше было.
Я вот тут подумал: в какой момент алиасинг/блочность начинают субъективно восприниматься лучше, чем минтиатюрное разрешение? Да, постоянно видимые искажения раздражают, зато в целом информации в картинке присутствует больше. По идее, для аниму намного выгоднее снижать фпс, 2/3 кадров на большей части повествования можно смело выкидывать, только в некоторых моментах (вроде движений камеры) 12/24 обратно включать.
>400x225
Лол, даже в 3gp на первых телефонах с видеокамерами вроде больше было.
Я вот тут подумал: в какой момент алиасинг/блочность начинают субъективно восприниматься лучше, чем минтиатюрное разрешение? Да, постоянно видимые искажения раздражают, зато в целом информации в картинке присутствует больше. По идее, для аниму намного выгоднее снижать фпс, 2/3 кадров на большей части повествования можно смело выкидывать, только в некоторых моментах (вроде движений камеры) 12/24 обратно включать.
90 Кб, 1020x680
>>1432129
Переставать жрать говно.
Переставать жрать говно.
>>1432118
Дело не в ffmpeg, а в мокропиське.
Дело не в ffmpeg, а в мокропиське.
375 Кб, 1728x1152
5983 Кб, Webm
5767 Кб, Webm
6040 Кб, Webm
>>1432159
Зависит от формата. С VP8 алиасинг/блочность воспринимаются хуже чем с VP9.
Если эта информация высосана декодером из пальца, то кому она нужна. Хотя…
Пик взят с https://people.xiph.org/~jm/daala/paint_demo/
Но с этим неплохо справляется и компенсация движения, не?
На практике применение фильтра mpdecimate с VP9 давало буст качества, но при этом ломало напрочь работу контроллера ширины потока — он переставал держать битрейт и начинал распидорашивать кадры смены сцен.
Вебмрелэйтед.
> Я вот тут подумал: в какой момент алиасинг/блочность начинают субъективно восприниматься лучше, чем минтиатюрное разрешение?
Зависит от формата. С VP8 алиасинг/блочность воспринимаются хуже чем с VP9.
> Да, постоянно видимые искажения раздражают, зато в целом информации в картинке присутствует больше.
Если эта информация высосана декодером из пальца, то кому она нужна. Хотя…
Пик взят с https://people.xiph.org/~jm/daala/paint_demo/
> По идее, для аниму намного выгоднее снижать фпс, 2/3 кадров на большей части повествования можно смело выкидывать, только в некоторых моментах (вроде движений камеры) 12/24 обратно включать.
Но с этим неплохо справляется и компенсация движения, не?
На практике применение фильтра mpdecimate с VP9 давало буст качества, но при этом ломало напрочь работу контроллера ширины потока — он переставал держать битрейт и начинал распидорашивать кадры смены сцен.
Вебмрелэйтед.
3463 Кб, Webm
>>1432212
Кусочек не поместился.
Кусочек не поместился.
352 Кб, 960x540
95 Кб, 400x225
>>1432212
Так нет же, пиксели настоящие. Просто у тебя, допустим, в одном случае разрешение 960x540 и блочности много, а в другом 400x225 и серьёзных искажений почти незаметно. Мне интересно, где находится та грань, когда лучше сделать покрупнее, но с артефактами. Пикрелейтед.
Это всё равно не бесплатно. Я несколько вещей энкодил с "-r 12" и улучшения были очевидны. Там просто реально 2/3 кадров это полные повторы в большинстве сцен, если ты посмотришь на раскадровку. Энкодить их — тратить битрейт попусту, пусть и не сильно много.
Я бегло пролистал и ничего особо криминального не заметил. Какие конкретно моменты?
Ты уверен, что это не особенность libvpx просто? Оно любит кадры в момент смены сцены энкодить с очень плохим качеством, типо как незаметные. Не знаю, кому как, но я теперь постоянно обращаю внимание, как начал энкодить, блин.
>Если эта информация высосана декодером из пальца
Так нет же, пиксели настоящие. Просто у тебя, допустим, в одном случае разрешение 960x540 и блочности много, а в другом 400x225 и серьёзных искажений почти незаметно. Мне интересно, где находится та грань, когда лучше сделать покрупнее, но с артефактами. Пикрелейтед.
>Но с этим неплохо справляется и компенсация движения, не?
Это всё равно не бесплатно. Я несколько вещей энкодил с "-r 12" и улучшения были очевидны. Там просто реально 2/3 кадров это полные повторы в большинстве сцен, если ты посмотришь на раскадровку. Энкодить их — тратить битрейт попусту, пусть и не сильно много.
>Вебмрелэйтед.
Я бегло пролистал и ничего особо криминального не заметил. Какие конкретно моменты?
>он переставал держать битрейт и начинал распидорашивать кадры смены сцен
Ты уверен, что это не особенность libvpx просто? Оно любит кадры в момент смены сцены энкодить с очень плохим качеством, типо как незаметные. Не знаю, кому как, но я теперь постоянно обращаю внимание, как начал энкодить, блин.
1516 Кб, 2560x1442
1486 Кб, 2560x1440
1462 Кб, 2560x1440
1433 Кб, 2560x1440
>>1432363
Апскейлы до 2560x1440 (эмуляция проигрывания в фуллскрине).
Выглядит так, как будто 640x360 — золотая середина.
Апскейлы до 2560x1440 (эмуляция проигрывания в фуллскрине).
Выглядит так, как будто 640x360 — золотая середина.
>>1432363
Олсо, лол, libvpx нещадно выдрал на нос на всём, кроме 400x255.
Олсо, лол, libvpx нещадно выдрал на нос на всём, кроме 400x255.
>>1432436
Если ты мне подаришь железо, которое сможет 24fps выдать с этим фильтром.
Если ты мне подаришь железо, которое сможет 24fps выдать с этим фильтром.
>>1432443
А не пиздишь? Вот здесь сообщают о 0.25fps для DVD-разрешения на GTX 770: http://forums.qhimm.com/index.php?topic=16359.0
NNEDI3 тогда уж. Или хотя бы ewa_lanczossharp. Вайфу для реалтайма никогда не предназначалась.
А не пиздишь? Вот здесь сообщают о 0.25fps для DVD-разрешения на GTX 770: http://forums.qhimm.com/index.php?topic=16359.0
NNEDI3 тогда уж. Или хотя бы ewa_lanczossharp. Вайфу для реалтайма никогда не предназначалась.
546 Кб, 1280x720
>>1432243
А ты апскейли 400x225 до 960x540 и сравни. (already done) Если видео с низким разрешением, но без видимых артефактов, то его и апскейлить можно не плюясь довольно сильно.
А ещё восприятие зависит от динамики.
Угу. Возможно, по большей части потому, что статичной картинке кодек стремится выделить больше битрейта.
Если кодировать чисто статичную картинку, то количество её повторов в пределах GoP'а на размер мало влияет: каждый новый кадр весит копейки.
64.356 первой вебмки, например. Кадр пожат так, как будто является частью непрерывной анимации, хотя на деле он висит 1.293 секунды.
>>1432266
Нихуя он не делает, просто пропускает кадры и всё. Видимо, потому и контроллер ширины потока libvpx фэйлится: у упомянутого выше кадра стоит pkt_duration_time=0.041.
https://github.com/FFmpeg/FFmpeg/blob/n2.7.2/libavfilter/vf_mpdecimate.c#L198
> Так нет же, пиксели настоящие. Просто у тебя, допустим, в одном случае разрешение 960x540 и блочности много, а в другом 400x225 и серьёзных искажений почти незаметно. Мне интересно, где находится та грань, когда лучше сделать покрупнее, но с артефактами. Пикрелейтед.
А ты апскейли 400x225 до 960x540 и сравни. (already done) Если видео с низким разрешением, но без видимых артефактов, то его и апскейлить можно не плюясь довольно сильно.
А ещё восприятие зависит от динамики.
> Это всё равно не бесплатно.
Угу. Возможно, по большей части потому, что статичной картинке кодек стремится выделить больше битрейта.
Если кодировать чисто статичную картинку, то количество её повторов в пределах GoP'а на размер мало влияет: каждый новый кадр весит копейки.
> Я бегло пролистал и ничего особо криминального не заметил. Какие конкретно моменты?
64.356 первой вебмки, например. Кадр пожат так, как будто является частью непрерывной анимации, хотя на деле он висит 1.293 секунды.
>>1432266
Нихуя он не делает, просто пропускает кадры и всё. Видимо, потому и контроллер ширины потока libvpx фэйлится: у упомянутого выше кадра стоит pkt_duration_time=0.041.
https://github.com/FFmpeg/FFmpeg/blob/n2.7.2/libavfilter/vf_mpdecimate.c#L198
Антоны, поясните нюфане. Обрезаю кусок вот такой строкой
ffmpeg -ss 00:15:43 -i "путь А" -to 00:01:24.120 -vf scale=-1:800 -b:v 0 -crf 30 -c:v vp9 "путь Б"
При перемотке видео не воспроизводится сразу, а еще подгружается какое-то время, как этого избежать или так и должно быть?
ffmpeg -ss 00:15:43 -i "путь А" -to 00:01:24.120 -vf scale=-1:800 -b:v 0 -crf 30 -c:v vp9 "путь Б"
При перемотке видео не воспроизводится сразу, а еще подгружается какое-то время, как этого избежать или так и должно быть?
>>1432590
-g поставь поменьше (по умолчанию 9999 для VP9) . См. https://github.com/pituz/webm-thread/wiki/glossary#gop-group-of-pictures .
-g поставь поменьше (по умолчанию 9999 для VP9) . См. https://github.com/pituz/webm-thread/wiki/glossary#gop-group-of-pictures .
>>1432580
Смотря насколько низкое. Если 400x225 апскейлить до 2560x1440, то выглядит неприятно мутно даже с хорошим ресемплером.
Да, похоже что libvpx плохо с VFR дружит. Но как костыль, например: определить (глазами или скриптом) области с 8, 12 и 24fps в используемом отрывке, энкодить их отдельно с соответствующим "-r" и затем склеивать на уровне демуксера.
>Если видео с низким разрешением, но без видимых артефактов, то его и апскейлить можно не плюясь довольно сильно
Смотря насколько низкое. Если 400x225 апскейлить до 2560x1440, то выглядит неприятно мутно даже с хорошим ресемплером.
>Кадр пожат так, как будто является частью непрерывной анимации
Да, похоже что libvpx плохо с VFR дружит. Но как костыль, например: определить (глазами или скриптом) области с 8, 12 и 24fps в используемом отрывке, энкодить их отдельно с соответствующим "-r" и затем склеивать на уровне демуксера.
ffmpeg -i in.mkv -ss 03:21 -to 08:08 -c:v vp9 -b:v 300 -vf scale=-1:480 -c:a libvorbis -q:a 7 out.webm
Звук получается идеально 224 Kbps, а вот видео не 300, а ~300-224, то есть около 80.
Какого хрена, ведь -b:v задает битрейт видео!?
Звук получается идеально 224 Kbps, а вот видео не 300, а ~300-224, то есть около 80.
Какого хрена, ведь -b:v задает битрейт видео!?
>>1432266
Имел ввиду pkt_duration_time.
Кстати, что интересно, libvpx в главной функции vpx_codec_encode таки принимает длительность кадра:
http://www.webmproject.org/docs/webm-sdk/group__encoder.html#gaf990542e2aeb389f05fae3e9c7803639
https://chromium.googlesource.com/webm/libvpx/+/v1.4.0/vpx/src/vpx_encoder.c#200
Но ffmpeg передаёт туда даже не pkt_duration_time, а fps, который указан в контейнере, как я понимаю:
https://github.com/FFmpeg/FFmpeg/blob/n2.8.1/libavcodec/libvpxenc.c#L909
Так что со всем сторон сломано.
>>1432797
300k.
Имел ввиду pkt_duration_time.
Кстати, что интересно, libvpx в главной функции vpx_codec_encode таки принимает длительность кадра:
http://www.webmproject.org/docs/webm-sdk/group__encoder.html#gaf990542e2aeb389f05fae3e9c7803639
https://chromium.googlesource.com/webm/libvpx/+/v1.4.0/vpx/src/vpx_encoder.c#200
Но ffmpeg передаёт туда даже не pkt_duration_time, а fps, который указан в контейнере, как я понимаю:
https://github.com/FFmpeg/FFmpeg/blob/n2.8.1/libavcodec/libvpxenc.c#L909
Так что со всем сторон сломано.
>>1432797
300k.
>>1432807
Кажись, у ffmpeg'а вообще нет поддержки кодирования кадров с переменным fps: поле frame->pkt_duration используется при декодировании.
https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/frame.h#L432
Кажись, у ffmpeg'а вообще нет поддержки кодирования кадров с переменным fps: поле frame->pkt_duration используется при декодировании.
https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/frame.h#L432
>>1432212
А как у тебя mpdecimate вообще кадры удалял? У меня на тестовом файле ничего не меняется — на выходе такое же количество кадров, как и на входе. Помогает только задание "-r" руками, но оно ж заранее неизвестно.
А как у тебя mpdecimate вообще кадры удалял? У меня на тестовом файле ничего не меняется — на выходе такое же количество кадров, как и на входе. Помогает только задание "-r" руками, но оно ж заранее неизвестно.
7 Кб, 717x87
>>1432972
Просто брал и удалял.
Мб у тебя там фильтр fps добавлял кадры обратно? Или выходной формат не поддерживал переменный фпс.
> А как у тебя mpdecimate вообще кадры удалял?
Просто брал и удалял.
> У меня на тестовом файле ничего не меняется
Мб у тебя там фильтр fps добавлял кадры обратно? Или выходной формат не поддерживал переменный фпс.
>>1432991
Точно, спасибо. Полчаса ебался. С .avi получилось сразу, а с .y4m ни в какую.
>Или выходной формат не поддерживал переменный фпс.
Точно, спасибо. Полчаса ебался. С .avi получилось сразу, а с .y4m ни в какую.
http://arhivach.org/thread/32446/
Случайно нагуглил. tfw всё уже было и всё сто раз как обсудили.
Случайно нагуглил. tfw всё уже было и всё сто раз как обсудили.
>>1433057
Кстати да, в ffmpeg же интерполяцию завезли недавно, можно возобновить эксперименты с дропаньем и восстановлением кадров.
Кстати да, в ffmpeg же интерполяцию завезли недавно, можно возобновить эксперименты с дропаньем и восстановлением кадров.
>>1433059
Я вот только не понял, нафиг эта еботня с mpdecimate, если ставишь смело "-r 8" и получаешь корректный результат на большей части сцен?
Я вот только не понял, нафиг эта еботня с mpdecimate, если ставишь смело "-r 8" и получаешь корректный результат на большей части сцен?
>>1433060
Далеко не во всех сценах 8фпс — бывают, например, сцены со скроллингом фона или плавной сменой освещения, где фпс полный. Превращать их в рывки не очень хочется.
Далеко не во всех сценах 8фпс — бывают, например, сцены со скроллингом фона или плавной сменой освещения, где фпс полный. Превращать их в рывки не очень хочется.
477 Кб, 1280x720
5016 Кб, Webm
>>1433140
Да хоть в 120. Толку-то, если при этом картинка размазывается?
Да хоть в 120. Толку-то, если при этом картинка размазывается?
5458 Кб, Webm
>>1433164
Ох, лел. Тогда толку нет. Это, как ресемплинг в SV или смеживание кадров в AE.
Ох, лел. Тогда толку нет. Это, как ресемплинг в SV или смеживание кадров в AE.
Вебм-господа, интересует какой-нибудь не монструозный видео редактор Нет, не для вебмок, но я не знаю куда еще обратиться способный в адекватную, относительно простую работу с видео будь-то вырезание лишних кусков, играть с видео с конца в начало и в подобном духе?
Sony Vegas есть, но уж больно он тяжелый и набит разным. Гайды смотрел, много телодвижений.
Если нет ничего адекватнее, буду ебать с Вегасом.
Sony Vegas есть, но уж больно он тяжелый и набит разным. Гайды смотрел, много телодвижений.
Если нет ничего адекватнее, буду ебать с Вегасом.
/
Да что такое, почему я тред не могу создать? Где мне эту капчу вводить?
Короче, дилема. Никогда не заморачивался по поводу превью %т.к. резал с середины%,
а тут начал делать превью по гайду, но постоянно получается webm,состорящая из превью
и аудио дорожки из видео. Куда при сжатии 2я проходами надо прописывать добавление превью?
Объясните на примере кода гайда:
%ffmpeg -i amv.mp4 -map 0:v -vf scale=-1:540 -c:v libvpx-vp9 -pass 1 -f null -y /dev/null
fmpeg -i amv.mp4 -map 0:v -vf scale=-1:540 -c:v libvpx-vp9 -pass 2 -b:v 277k -auto-alt-ref 1 -lag-in-frames 25 video.webm
ffmpeg -i amv.mp4 -i video.webm -map 0:a -c:a libopus -b:a 64k -map 1:v -c:v copy out.webm%
а тут начал делать превью по гайду, но постоянно получается webm,состорящая из превью
и аудио дорожки из видео. Куда при сжатии 2я проходами надо прописывать добавление превью?
Объясните на примере кода гайда:
%ffmpeg -i amv.mp4 -map 0:v -vf scale=-1:540 -c:v libvpx-vp9 -pass 1 -f null -y /dev/null
fmpeg -i amv.mp4 -map 0:v -vf scale=-1:540 -c:v libvpx-vp9 -pass 2 -b:v 277k -auto-alt-ref 1 -lag-in-frames 25 video.webm
ffmpeg -i amv.mp4 -i video.webm -map 0:a -c:a libopus -b:a 64k -map 1:v -c:v copy out.webm%
>>1433237
Добавляй второй дорожкой, чтобы видео не поганить левым кадром.
https://github.com/pituz/webm-thread/blob/master/tools/add-preview
Добавляй второй дорожкой, чтобы видео не поганить левым кадром.
https://github.com/pituz/webm-thread/blob/master/tools/add-preview
>>1433240
Но мне нужно кадр не из webm. Или я что-то не так понял?
сори я 5и вебемочный пидор мне тяжело в https://github.com/pituz/webm-thread/blob/master/tools/add-preview этом ковыряться
Но мне нужно кадр не из webm. Или я что-то не так понял?
сори я 5и вебемочный пидор мне тяжело в https://github.com/pituz/webm-thread/blob/master/tools/add-preview этом ковыряться
1639 Кб, Webm
>>1433246
Допустим у тебя есть сковернтированная вебмс (со звуком) и разрешением 960x540
То берешь картинку/кадр из вебм и делаешь:
ffmpeg -i pic.jpg -c:v vp8 -crf 4 -b:v 0k -vf scale=960:541 1frame.webm
Разрешение у превью должно быть больше
Затем:
ffmpeg -i video.webm -i 1frame.webm -c copy -map 0:v -map 1:v -map 0:a video_with_preview.webm
Допустим у тебя есть сковернтированная вебмс (со звуком) и разрешением 960x540
То берешь картинку/кадр из вебм и делаешь:
ffmpeg -i pic.jpg -c:v vp8 -crf 4 -b:v 0k -vf scale=960:541 1frame.webm
Разрешение у превью должно быть больше
Затем:
ffmpeg -i video.webm -i 1frame.webm -c copy -map 0:v -map 1:v -map 0:a video_with_preview.webm
>>1432903
Написал мега-кривой патч, который фиксит VFR в mpdecimate, libvpx и matroska.
Единственный косяк — последний кадр проёбывается, не придумал пока как лучше это пофиксить.
https://gist.github.com/anonymous/aa0333d87831f9e64364
Написал мега-кривой патч, который фиксит VFR в mpdecimate, libvpx и matroska.
Единственный косяк — последний кадр проёбывается, не придумал пока как лучше это пофиксить.
https://gist.github.com/anonymous/aa0333d87831f9e64364
>>1433285
Откуда оригинальное видео ? Хочу тоже его перекодировать
Откуда оригинальное видео ? Хочу тоже его перекодировать
>>1433285
Хватит уже в конец видео левые байты дописывать, чините свои куклы.
Хватит уже в конец видео левые байты дописывать, чините свои куклы.
23 Кб, 676x422
>>1433203
Кстати, в ffmpeg недавно завезли фильтр reverse, который пожрёт всю оперативку.
>>1433217
И где тут еботня — в ручном нарезании на куски или в примененнии фильтра mpdecimate (который можно попросить не выкидывать больше двух кадров подряд).
Работаю над этим. Что-то уже получается — libvpx'у передаётся разница в PTS между текущим и следующим кадрами. Но пока дропается последний кадр и вычисленный pkt_duration не сохраняется в контейнер.
> играть с видео с конца в начало
Кстати, в ffmpeg недавно завезли фильтр reverse, который пожрёт всю оперативку.
>>1433217
> Ну надо их отдельно энкодить и склеивать, как я выше писал.
И где тут еботня — в ручном нарезании на куски или в примененнии фильтра mpdecimate (который можно попросить не выкидывать больше двух кадров подряд).
> Или VFR чинить.
Работаю над этим. Что-то уже получается — libvpx'у передаётся разница в PTS между текущим и следующим кадрами. Но пока дропается последний кадр и вычисленный pkt_duration не сохраняется в контейнер.
173 Кб, Webm
>>1433320
Ага. Вот моё: http://pastebin.com/wBdP2LFQ
Кажется, в случае с фильтром проблему потери кадра легко решить.
Ага. Вот моё: http://pastebin.com/wBdP2LFQ
Кажется, в случае с фильтром проблему потери кадра легко решить.
>>1433318
А зачем это:
и пара аналогичных выключений условий?
А зачем это:
> - if ((side_data_size && additional_id == 1) || discard_padding) {
> + if (1 || (side_data_size && additional_id == 1) || discard_padding) {
и пара аналогичных выключений условий?
>>1433331
В SimpleBlock нельзя BlockDuration элемент положить. Это мега-костыль на самом деле, я за 2 минуты пролистнул доку по матроске и кое-как запатчил.
В SimpleBlock нельзя BlockDuration элемент положить. Это мега-костыль на самом деле, я за 2 минуты пролистнул доку по матроске и кое-как запатчил.
>>1433334
Т.е. там BlockGroup нужен. Ну ты понел. Лень спеку читать.
Т.е. там BlockGroup нужен. Ну ты понел. Лень спеку читать.
>>1433285
Спасибо, видимо в разрешении превью была проблема
Спасибо, видимо в разрешении превью была проблема
515 Кб, 1280x720
511 Кб, 1280x720
529 Кб, 1280x720
527 Кб, 1280x720
Сравнения fps vs mpdecimate. Пока по скриншотам. Команды:
webm -i '[DeadFish] Anitore! EX - 01v2 [720p][AAC].mp4' -vb 200 -t 10 24fps.webm
webm -i '[DeadFish] Anitore! EX - 01v2 [720p][AAC].mp4' -vb 200 -t 10 -fo='-r 12' 12fps.webm
webm -i '[DeadFish] Anitore! EX - 01v2 [720p][AAC].mp4' -vb 200 -t 10 -fo='-r 8' 8fps.webm
webm -i '[DeadFish] Anitore! EX - 01v2 [720p][AAC].mp4' -vb 578 -t 10 -vf mpdecimate mpdecimate.webm
WEBM_FFMPEG=patched-ffmpeg webm -i '[DeadFish] Anitore! EX - 01v2 [720p][AAC].mp4' -vb 23 -t 10 -vf mpdecimate mpdecimate-patch.webm
Все файлы получились примерно одинакового размера, около 325k. Патч также ломает рейт-контроль, но в обратную сторону, лол. Улучшений по сравнению с дефолтом нет, даже наоборот. Самый качественный результат дал 8fps.
webm -i '[DeadFish] Anitore! EX - 01v2 [720p][AAC].mp4' -vb 200 -t 10 24fps.webm
webm -i '[DeadFish] Anitore! EX - 01v2 [720p][AAC].mp4' -vb 200 -t 10 -fo='-r 12' 12fps.webm
webm -i '[DeadFish] Anitore! EX - 01v2 [720p][AAC].mp4' -vb 200 -t 10 -fo='-r 8' 8fps.webm
webm -i '[DeadFish] Anitore! EX - 01v2 [720p][AAC].mp4' -vb 578 -t 10 -vf mpdecimate mpdecimate.webm
WEBM_FFMPEG=patched-ffmpeg webm -i '[DeadFish] Anitore! EX - 01v2 [720p][AAC].mp4' -vb 23 -t 10 -vf mpdecimate mpdecimate-patch.webm
Все файлы получились примерно одинакового размера, около 325k. Патч также ломает рейт-контроль, но в обратную сторону, лол. Улучшений по сравнению с дефолтом нет, даже наоборот. Самый качественный результат дал 8fps.
>>1433405
Походу в libvpx просто rate control на такое не рассчитан.
Пока придумался только костыль с анализом видео через mpdecimate (последовательности drop_count:1, 2, -1 = 8fps, drop_count:1, -1 = 12fps и т.д.) и скриптом для разрезания, энкодинга и склеивания. На постоянном framerate libvpx проблем не испытывает.
Походу в libvpx просто rate control на такое не рассчитан.
Пока придумался только костыль с анализом видео через mpdecimate (последовательности drop_count:1, 2, -1 = 8fps, drop_count:1, -1 = 12fps и т.д.) и скриптом для разрезания, энкодинга и склеивания. На постоянном framerate libvpx проблем не испытывает.
Пытаюсь подключиться через вайфай адаптер к сети. Ввожу scаn - пишет устройство не поддерживает сканирование. Ввожу сразу key пароль - пишет
Читаю
http://www.imagemagick.org/Usage/resize/
http://www.imagemagick.org/Usage/filter/
http://www.imagemagick.org/Usage/filter/nicolas/
Пиздец как всё сложно. Я всю жизнь ресайзил картинки неправильно!
http://www.imagemagick.org/Usage/resize/
http://www.imagemagick.org/Usage/filter/
http://www.imagemagick.org/Usage/filter/nicolas/
Пиздец как всё сложно. Я всю жизнь ресайзил картинки неправильно!
После конверта вебм (-c:v vp9 -b:v 300K -vf scale=-1:480) длительностью 6:03 она не перематывается в плеере (MPC). Вернее перематывается, но только на отметку 05:34.
В чем косяк, как поправить?
В чем косяк, как поправить?
1372 Кб, Webm
> webm-тред прикреплён
> прыщетред прикреплен
> дрисняткотред прикреплён
> каноничный спермотред на дне
Моча обезумела.
>>1433904
Всю нулевую занять прикреплёнными, мне нравится ход твоих мыслей.
Всю нулевую занять прикреплёнными, мне нравится ход твоих мыслей.
>>1433875
Понял. Как альтернатива получается можно увеличить число ключевых кадров через -g.
Не понимаю только, почему в вебм покороче с чуть большим битрейтом такого нет. Там можно мотнуть куда угодно, правда с загрузкой.
Понял. Как альтернатива получается можно увеличить число ключевых кадров через -g.
Не понимаю только, почему в вебм покороче с чуть большим битрейтом такого нет. Там можно мотнуть куда угодно, правда с загрузкой.
876 Кб, 1589x1221
Дааловцы таки запилили сравнение по скриншотам, используя последние ревизии энкодеров из гита, что я предлагал в качестве идеи для стартапа в прошлом треде. В основном там даала, но есть несколько прогонов x265 в subset2:
https://arewecompressedyet.com/ (вкладка Images)
https://arewecompressedyet.com/ (вкладка Images)
Памятка по вытягиванию качества видео в совсем плохих случаях, отсортировано по убыванию важности (с моей точки зрения):
- Уменьшаем разрешение в самый край, 360p/288p/225p вполне смотрибельно
- Смело ставим битрейт аудио в 48k/36k, речь и фоновую музыку будет нормально слышно (для скринкастов и аудиокниг допустимо 8-10k)
- Если это аниму, то уменьшаем fps до 8 или 12, главное чтобы длительных движений камерой не было, их нужно с полным fps кодировать
- -qmin 15/20/30 может помочь энкодеру не тратить битрейт попусту
- -speed 0 -tile-columns 0; будет медленно, но чуть лучше
- Можно попробовать CQ/constant quality и поподбирать QP
Эх, проводили бы какие контексты по кодированию хоть, чтобы коллективными усилиями сбрутить идеальные настройки для заданного видео. А то вот я до сих пор не в курсе про отличия в качестве VBR vs CQ, влияет ли aq-mode и насколько хорошо помогает снижение undershoot-pct/overshoot-pct.
- Уменьшаем разрешение в самый край, 360p/288p/225p вполне смотрибельно
- Смело ставим битрейт аудио в 48k/36k, речь и фоновую музыку будет нормально слышно (для скринкастов и аудиокниг допустимо 8-10k)
- Если это аниму, то уменьшаем fps до 8 или 12, главное чтобы длительных движений камерой не было, их нужно с полным fps кодировать
- -qmin 15/20/30 может помочь энкодеру не тратить битрейт попусту
- -speed 0 -tile-columns 0; будет медленно, но чуть лучше
- Можно попробовать CQ/constant quality и поподбирать QP
Эх, проводили бы какие контексты по кодированию хоть, чтобы коллективными усилиями сбрутить идеальные настройки для заданного видео. А то вот я до сих пор не в курсе про отличия в качестве VBR vs CQ, влияет ли aq-mode и насколько хорошо помогает снижение undershoot-pct/overshoot-pct.
516 Кб, 1280x720
519 Кб, 1280x720
520 Кб, 1280x720
524 Кб, 1280x720
>>1434421
vbr-200k = vbr-200k-qmin30 < crf-57-200k < crf-60
Все файлы одинакого размера.
Таки VBR хуже. Я фигею с libvpx.
vbr-200k = vbr-200k-qmin30 < crf-57-200k < crf-60
Все файлы одинакого размера.
Таки VBR хуже. Я фигею с libvpx.
287 Кб, 1280x720
300 Кб, 1280x720
>>1434440
Хотя, некоторые кадры у VBR лучше. Херня такие сравнения, короче. Надо строить график SSIM по кадрам и оценивать в целом.
Хотя, некоторые кадры у VBR лучше. Херня такие сравнения, короче. Надо строить график SSIM по кадрам и оценивать в целом.
Test.
>>1435034
В целом CRF, но результатам с одного прогона мало смысла доверять, надо побольше потестировать.
Вот код для IPython, если что (надо бы в скрипт оформить): https://gist.github.com/anonymous/224c05f87f5bcddec634
В целом CRF, но результатам с одного прогона мало смысла доверять, надо побольше потестировать.
Вот код для IPython, если что (надо бы в скрипт оформить): https://gist.github.com/anonymous/224c05f87f5bcddec634
Поцаны есть 1.mkv http://pastebin.com/4yszYsg7
Я делаю ffmpeg -i 1.mkv -map_metadata -1 -c:v copy -c:a copy 2.mp4
Но главы всеравно остаются, гуглил ffmpeg chapters remove, нече другого не нашел.
Я делаю ffmpeg -i 1.mkv -map_metadata -1 -c:v copy -c:a copy 2.mp4
Но главы всеравно остаются, гуглил ffmpeg chapters remove, нече другого не нашел.
Пример того, как -g влияет на вес webm (по результатам одного эксперимента):
ffmpeg -i g.mkv -ss 45:12 -to 51:15 -c:v vp9 -b:v 300K -vf scale=-1:480 -c:a libvorbis -q:a 7 ichiban2.webm - 18.9 МБ
ffmpeg -i g.mkv -ss 45:12 -to 51:15 -c:v vp9 -b:v 300K -vf scale=-1:480 -g 1000 -c:a libvorbis -q:a 7 ichiban2.webm - 19 МБ
ffmpeg -i g.mkv -ss 45:12 -to 51:15 -c:v vp9 -b:v 300K -vf scale=-1:480 -g 500 -c:a libvorbis -q:a 7 ichiban3.webm - 19.1 МБ
ffmpeg -i g.mkv -ss 45:12 -to 51:15 -c:v vp9 -b:v 300K -vf scale=-1:480 -g 250 -c:a libvorbis -q:a 7 ichiban4.webm - 19.3 МБ
Думал больше места отжирается.
ffmpeg -i g.mkv -ss 45:12 -to 51:15 -c:v vp9 -b:v 300K -vf scale=-1:480 -c:a libvorbis -q:a 7 ichiban2.webm - 18.9 МБ
ffmpeg -i g.mkv -ss 45:12 -to 51:15 -c:v vp9 -b:v 300K -vf scale=-1:480 -g 1000 -c:a libvorbis -q:a 7 ichiban2.webm - 19 МБ
ffmpeg -i g.mkv -ss 45:12 -to 51:15 -c:v vp9 -b:v 300K -vf scale=-1:480 -g 500 -c:a libvorbis -q:a 7 ichiban3.webm - 19.1 МБ
ffmpeg -i g.mkv -ss 45:12 -to 51:15 -c:v vp9 -b:v 300K -vf scale=-1:480 -g 250 -c:a libvorbis -q:a 7 ichiban4.webm - 19.3 МБ
Думал больше места отжирается.
>>1435105
А сколько ключевых кадров в первом и последнем видео?
(ffprobe -loglevel quiet -show_frames -select_streams v in.webm | grep -c key_frame=1)
А сколько ключевых кадров в первом и последнем видео?
(ffprobe -loglevel quiet -show_frames -select_streams v in.webm | grep -c key_frame=1)
Можно как-то указывать выходной размер файла, а остальное мне само соберется? Типа указал 10 метров максимум и пусть перекодирует в лучшем качестве без перевеса 10 mb?
19 Кб, 669x70
>>1435303
можно пример? Я только для питона нашел:
# Fit video to 6 MiB
python webm.py -i in.mkv -l 6
но он пытается открыть "webm" файл, а не обработать мое видео с помощью webm библиотеки. Можешь ткнуть меня в правильный вариант?
можно пример? Я только для питона нашел:
# Fit video to 6 MiB
python webm.py -i in.mkv -l 6
но он пытается открыть "webm" файл, а не обработать мое видео с помощью webm библиотеки. Можешь ткнуть меня в правильный вариант?
>>1435327
Если через pip, то просто "webm".
Иначе нужно скачать webm.py с гитхаба и из директории с ним запускать как "python webm.py".
Если через pip, то просто "webm".
Иначе нужно скачать webm.py с гитхаба и из директории с ним запускать как "python webm.py".
>>1435330
иди на хуй
иди на хуй
>>1435132
Спермоконсоль не понимает команду:
"grep" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом.
А я не так прошарен, чтобы пофиксить.
Скажу так, в первом случае MPC с быстрой перемоткой видит две точки этой самой перемотки.
В последнем мотать можно на каждые 9 сек, то есть около 40 точек.
Спермоконсоль не понимает команду:
"grep" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом.
А я не так прошарен, чтобы пофиксить.
Скажу так, в первом случае MPC с быстрой перемоткой видит две точки этой самой перемотки.
В последнем мотать можно на каждые 9 сек, то есть около 40 точек.
>>1435374
PS:\>ffprobe -loglevel quiet -show_frames -select_streams v in.webm | Select-String -Pattern key_frame=1 | Measure-Object -Line
Ололо.
PS:\>ffprobe -loglevel quiet -show_frames -select_streams v in.webm | Select-String -Pattern key_frame=1 | Measure-Object -Line
Ололо.
2106 Кб, 2055x1321
Поясните по простецки в чем различие между avc1 и h264? Основные преимущества? Где используются?
>>1433237
а еще можно не заморачиватся и не писать каждый раз разрешение
@
превью из картинки
ffmpeg -i pix.png -pix_fmt yuv420p -vf scale=iw+1:ih+1 prev.webm
@
превью из видео
ffmpeg -ss 1:10 -i file.mkv -map 0:v -t 1 -r 1 -vf scale=iw+1:ih+1 prev.webm
вырезать 1 секунду начиная с минуты десяти секунд
@
собрать webm с превью
ffmpeg -i file.webm -i prev.webm -c copy -map 0:v -map 0:a -map 1:v out.webm
а еще можно не заморачиватся и не писать каждый раз разрешение
@
превью из картинки
ffmpeg -i pix.png -pix_fmt yuv420p -vf scale=iw+1:ih+1 prev.webm
@
превью из видео
ffmpeg -ss 1:10 -i file.mkv -map 0:v -t 1 -r 1 -vf scale=iw+1:ih+1 prev.webm
вырезать 1 секунду начиная с минуты десяти секунд
@
собрать webm с превью
ffmpeg -i file.webm -i prev.webm -c copy -map 0:v -map 0:a -map 1:v out.webm
>>1435481
Это одно и то же.
Это одно и то же.
>>1435330
Большое спасибо! Первый раз питон библиотеку запускаю не вызывая явно питон.
Большое спасибо! Первый раз питон библиотеку запускаю не вызывая явно питон.
120 Кб, 1920x1080
Есть видео 650М длительностью 20 мин. Как можно уменьшить его размер? Только обрезать битрейт какой командой? А может в другой формат перекодировать?
970 Кб, Webm
Поясните что такое key-frame и почему если не по нему обрезаешь видео, то появляются артефакты как на середине вебмки?
Как этого избежать?
Как этого избежать?
11 Кб, 375x250
Короче, есть во внешней сети мультикаст с видеостримом. Роутер на pfSense. Включен igmpproxy, который раздает этот стрим во внутреннюю сеть. Проблема в том, что igmpproxy перестает раздавать стрим, если на него никто не обращается из локалки (через 10 минут), из-за этого приходится перезапускать igmpproxy, что не удобно. Есть какое-то решение?
>>1435901
Бля, хотел тред создать. Потрите это.
Бля, хотел тред создать. Потрите это.
Вы все пидары азаза
>>1435941
Ты нам так дохуя информации дал, что помогать тебе это первое, что хочется делать. Сейчас только включу чтение мысль и побегу помогать. Мудак.
Ты нам так дохуя информации дал, что помогать тебе это первое, что хочется делать. Сейчас только включу чтение мысль и побегу помогать. Мудак.
209 Кб, 844x844
Чому VP9 так пиздецово долго конвертится? Оптимизацию формата ещё не завезли чтоль?
>>1436129
Ты если делаешь вебм для порнотреда можешь делать ее и в вп8, если делаешь хорошую вебм 4-5 фпс это вполне быстро.
Ты если делаешь вебм для порнотреда можешь делать ее и в вп8, если делаешь хорошую вебм 4-5 фпс это вполне быстро.
>>1436129
Насколько долго? С настройками помедленее у меня скорость 3-5 фпс. С дефолтными в конвертере 14-17, делается за пару минут.
Насколько долго? С настройками помедленее у меня скорость 3-5 фпс. С дефолтными в конвертере 14-17, делается за пару минут.
>>1436549
Либо libvpx 1.3.0.
Либо libvpx 1.3.0.
>>1436549
Да, убрал галку - стало около трёх фпс.
Да, убрал галку - стало около трёх фпс.
>>1435951
Какую еще информацию тебе давать, черт? Читай внимательнее мой вопрос, там все есть. формат забыл указать .mov.
Какую еще информацию тебе давать, черт? Читай внимательнее мой вопрос, там все есть. формат забыл указать .mov.
>>1436782
Для чего уменьшать? На каком устройстве смотреть будешь? Где вывод mediainfo? Скрин из видео где?
Для чего уменьшать? На каком устройстве смотреть будешь? Где вывод mediainfo? Скрин из видео где?
261 Кб, 1652x1053
>>1435045
Написал немного быдлокода: https://gist.github.com/anonymous/0a3ee3f68c2d1c6fba7c
Немного косячит на расстановке надписей, но в целом норм, можно более-менее объективно сравнивать энкоды.
Написал немного быдлокода: https://gist.github.com/anonymous/0a3ee3f68c2d1c6fba7c
Немного косячит на расстановке надписей, но в целом норм, можно более-менее объективно сравнивать энкоды.
224 Кб, 1632x1053
>>1401710
Сравнение для интереса.
best в самом деле чуть получше.
Команды, если что:
wget https://2ch.hk/s/src/1395791/14430405474460.webm -O good.webm
wget https://2ch.hk/s/src/1395791/14430405475091.webm -O best.webm
youtube-dl -f 136+bestaudio wVuA74sdMIw -o orig-full.mp4
# Проверяем число кадров
ffprobe -loglevel quiet -show_frames -select_streams v -of csv good.webm | wc -l
ffprobe -loglevel quiet -show_frames -select_streams v -of csv best.webm | wc -l
# Ищем тот же момент в исходнике и копируем
ffmpeg -ss 1:23 -i orig-full.mp4 -frames:v 576 ref.y4m
# График
cmpv -ref ref.y4m best.webm good.webm -k
# Контрольные проверки среднего на всяких случай
awk -F '[: ]' '{a += $10}END{print 10(log(NR)/log(10) - log(NR - a)/log(10))}' good.log
awk -F '[: ]' '{a += $10}END{print 10(log(NR)/log(10) - log(NR - a)/log(10))}' best.log
Сравнение для интереса.
best в самом деле чуть получше.
Команды, если что:
wget https://2ch.hk/s/src/1395791/14430405474460.webm -O good.webm
wget https://2ch.hk/s/src/1395791/14430405475091.webm -O best.webm
youtube-dl -f 136+bestaudio wVuA74sdMIw -o orig-full.mp4
# Проверяем число кадров
ffprobe -loglevel quiet -show_frames -select_streams v -of csv good.webm | wc -l
ffprobe -loglevel quiet -show_frames -select_streams v -of csv best.webm | wc -l
# Ищем тот же момент в исходнике и копируем
ffmpeg -ss 1:23 -i orig-full.mp4 -frames:v 576 ref.y4m
# График
cmpv -ref ref.y4m best.webm good.webm -k
# Контрольные проверки среднего на всяких случай
awk -F '[: ]' '{a += $10}END{print 10(log(NR)/log(10) - log(NR - a)/log(10))}' good.log
awk -F '[: ]' '{a += $10}END{print 10(log(NR)/log(10) - log(NR - a)/log(10))}' best.log
>>1436901
Забыл про звёздочку:
awk -F '[: ]' '{a += $10}END{print 10∗(log(NR)/log(10) - log(NR - a)/log(10))}' log
Кстати, у меня переодически код не макаба не принимает, ссылаясь на спамлист, это такая защита от кулхацкеров что ли?
Забыл про звёздочку:
awk -F '[: ]' '{a += $10}END{print 10∗(log(NR)/log(10) - log(NR - a)/log(10))}' log
Кстати, у меня переодически код не макаба не принимает, ссылаясь на спамлист, это такая защита от кулхацкеров что ли?
>>1436902
Не мучайся:
echo YXdrIC1GICdbOiBdJyAne2EgKz0gJDEwfUVORHtwcmludCAxMCoobG9nKE5SKS9sb2coMTApIC0gbG9nKE5SIC0gYSkvbG9nKDEwKSl9JyBsb2cK|base64 -d
Не мучайся:
echo YXdrIC1GICdbOiBdJyAne2EgKz0gJDEwfUVORHtwcmludCAxMCoobG9nKE5SKS9sb2coMTApIC0gbG9nKE5SIC0gYSkvbG9nKDEwKSl9JyBsb2cK|base64 -d
"-vf scale=640:-1", где "-1" это? В вики также пишут "-vf scale=-1:540", в чем разница?
>>1437119
vf scale=width:height
Если ставишь -1, то этот параметр будет подобран автоматически с сохранением пропорций
vf scale=width:height
Если ставишь -1, то этот параметр будет подобран автоматически с сохранением пропорций
241 Кб, 1730x837
Распределение fps в типичной аниму-серии. Чуть выше, чем я думал.
>>1438266
Да, обычный mpdecimate с дефолтными параметрами. Детектирование панарамирования я пока не осилил.
Да, обычный mpdecimate с дефолтными параметрами. Детектирование панарамирования я пока не осилил.
>>1438120
Фапаю на ipython. Удобно, быстро, воспроизводимо. Красота!
http://nbviewer.ipython.org/gist/anonymous/df3bc83fa6fb21d900c2
Фапаю на ipython. Удобно, быстро, воспроизводимо. Красота!
http://nbviewer.ipython.org/gist/anonymous/df3bc83fa6fb21d900c2
Набросал батник для енкода в стиле тащи @ бросай (вдруг кому-то пригодится).
https://gist.github.com/x5f3759df/842a8ab5734c4fdd937e
https://gist.github.com/x5f3759df/842a8ab5734c4fdd937e
Предварительное раписание выступлений со следующего IETF Meting в Японии:
https://datatracker.ietf.org/meeting/94/agenda/netvc/
Офигенно кодеки писать: раскатываешь по странам, фигачишь публикации, придумываешь мемчики:
http://ietfmemes.tumblr.com/
https://datatracker.ietf.org/meeting/94/agenda/netvc/
Офигенно кодеки писать: раскатываешь по странам, фигачишь публикации, придумываешь мемчики:
http://ietfmemes.tumblr.com/
36 Кб, 642x443
Нужно сконвертить avi файл в другой avi или ешё какой-нибудь фидео формат можно и webm так чтобы он был из ascii графики. Получилось только открыть его с помощью VLC и просмотреть как это будет выглядеть, но экспортировать полученный видео поток я не могу. Ещё у полученного видео слишком маленький размер, а настроек для этого нет. Как такое можно сделать максимально просто?
>>1438862
Через mpv должно работать, у него есть -vo caca и возможность энкодинга вывода.
Через mpv должно работать, у него есть -vo caca и возможность энкодинга вывода.
>>1438868
Нужен не цветной и не вижу настройки чтобы размер шрифта уменьшить. Размер выходного файла отдельно от этого параметра прописывать?
>Color ASCII art video output driver that works on a text console
Нужен не цветной и не вижу настройки чтобы размер шрифта уменьшить. Размер выходного файла отдельно от этого параметра прописывать?
35 Кб, 428x240
51 Кб, 777x204
>>1438910
Находил, но не смог установить. Пишет нужно выполнить это.
./configure
make
make install
На втором или третям шаге ошибки.
Находил, но не смог установить. Пишет нужно выполнить это.
./configure
make
make install
На втором или третям шаге ошибки.
>>1438950
Вот как въебать бы тебе молотком по голове!
Вот как въебать бы тебе молотком по голове!
>>1439706
Лол, не в тот тред.
Лол, не в тот тред.
>>1439840
Мод, проси Абу для тех кто поле почта заполняет включать капчу, иначе боты рендомные заебут
Мод, проси Абу для тех кто поле почта заполняет включать капчу, иначе боты рендомные заебут
Й
>>1440033
Напиши скрипт - попросит.
Напиши скрипт - попросит.
А нет ли где исследований на тему энкода вебмок с большим значением crf против указания битрейта вручную? Например, crf требуется 50, чтобы уложить в 1400к. Да и вообще он 1400к при этом значении выдает почти постоянно, плавает 1390-1410, ощущение, будто в cbr нахожусь. Оно вообще при таких значениях должно нормально энкодить?
Напомните команду для создания превью без добавления кадра в начале через канкоат и прочую хрень
>>1397036
некрофила ответ, но всеже.
нахуй все автоматизировать, может и еблю - кнопку нажал - выебал?
некрофила ответ, но всеже.
нахуй все автоматизировать, может и еблю - кнопку нажал - выебал?
3528 Кб, Webm
Спасибо, Анон!
Двач научил полезному!
Двач научил полезному!
>>1440525
От самого видео это разве не зависит? Если сцены разные постоянно, то и прыгать должен, у меня скачет только так. Вроде ещё -qcomp задаёт ширину "скачков" от 0 cbr до 1 vbr.
От самого видео это разве не зависит? Если сцены разные постоянно, то и прыгать должен, у меня скачет только так. Вроде ещё -qcomp задаёт ширину "скачков" от 0 cbr до 1 vbr.
test
>>1441024
Получилось!
Получилось!
>>1440992
Ещё как зависит!
Ещё как зависит!
Итак есть вопрос.
Есть внешние субтитры на видосике с трубы для тупых, они не являются частью видеоряда, как можно запилить ШЕБМ с этими субтитрами?
Есть внешние субтитры на видосике с трубы для тупых, они не являются частью видеоряда, как можно запилить ШЕБМ с этими субтитрами?
6142 Кб, Webm
>>1438862
https://gist.github.com/anonymous/3a51256a326cc50b13f7
Держи. 9000 часов в виме.
Пока только PCF, без поддержки атрибутов символов и ресайз нормальный я не осилил. Могу скинуть бинарь, если надо. Использовать так:
ffmpeg -i in.mkv -f rawvideo -pix_fmt gray - |\
y2aa -w 1280 -h 720 - |\
ffmpeg -f rawvideo -pixel_format gray -video_size 1280x720 -i - out.mkv
(Такие вебмки, кстати, сносят крышу напрочь рейт-контролю libvpx, еле закодировал в лимит.)
https://gist.github.com/anonymous/3a51256a326cc50b13f7
Держи. 9000 часов в виме.
Пока только PCF, без поддержки атрибутов символов и ресайз нормальный я не осилил. Могу скинуть бинарь, если надо. Использовать так:
ffmpeg -i in.mkv -f rawvideo -pix_fmt gray - |\
y2aa -w 1280 -h 720 - |\
ffmpeg -f rawvideo -pixel_format gray -video_size 1280x720 -i - out.mkv
(Такие вебмки, кстати, сносят крышу напрочь рейт-контролю libvpx, еле закодировал в лимит.)
http://comments.gmane.org/gmane.comp.multimedia.webm.devel/2488
>Javan Whistling Duck Release Candidate
>The release will be ABI incompatible with 1.4.0. It removes the long deprecated controls VP8E_UPD_ENTROPY, VP8E_UPD_REFERENCE and VP8E_USE_REFERENCE. VP8 gains a new screen content mode. VP9 gains VP9E_GET_ACTIVE_MAP, VP9E_SET_RENDER_SIZE, VP9E_SET_COLOR_RANGE, VP9E_SET_[MIN|MAX]_GF_INTERVAL, and VP9_SET_SKIP_LOOP_FILTER.
>What's new?
> - The above codec controls
> - Substantially improved VP9 encoding speed and quality
> - Improvements to VP9 decode speed including algorithmic changes to the multi threaded decoder.
>>1442447
Угу, я уже соснул со сборкой ffmpeg'а 2.8.1. Пришлось откатываться на релизный libvpx.
Угу, я уже соснул со сборкой ffmpeg'а 2.8.1. Пришлось откатываться на релизный libvpx.
Поясните нубу, компрессия видео как-то зависит от фпс? Предположим у меня есть набор картинок, я их кодирую VP9 или еще чем в разном фпс. Потом беру кадр из готового видео, где будет качество хуже или оно будет одинаковое?
5986 Кб, Webm
>>1442439
Что с этим делать? Нужно как-то скомпилировать в файл с названием y2aa ?
мимо-тоже-захотел-вебм-в-ascii
Что с этим делать? Нужно как-то скомпилировать в файл с названием y2aa ?
мимо-тоже-захотел-вебм-в-ascii
>>1442499
Бери ffmpeg из гита, там починили.
>>1442502
→ >>1433405 и выше.
Если ты имеешь ввиду один и тот же набор картинок (количество кадров одинаковое), просто с разной скоростью проигрываются, то разницы не должно быть.
>>1442563
Ставишь rustc и cargo. Пишешь cargo new --bin y2aa, заходишь в директорию и заменяешь Cargo.toml и main.rs на файлы из гиста. Затем cargo build --release и получаешь бинарь в target/release/y2aa. В системе должны стоять freetype и aalib (только shared либы, dev-версии пакетов не нужны).
Бери ffmpeg из гита, там починили.
>>1442502
→ >>1433405 и выше.
Если ты имеешь ввиду один и тот же набор картинок (количество кадров одинаковое), просто с разной скоростью проигрываются, то разницы не должно быть.
>>1442563
Ставишь rustc и cargo. Пишешь cargo new --bin y2aa, заходишь в директорию и заменяешь Cargo.toml и main.rs на файлы из гиста. Затем cargo build --release и получаешь бинарь в target/release/y2aa. В системе должны стоять freetype и aalib (только shared либы, dev-версии пакетов не нужны).
>>1442648
Недавно просто тренд был на форчане, как можно разнообразный контент на ютуб заливать. Короче делается архив с intel и amd, разбивается на равные куски по 2,95кб, это кодируется с помощью qr кода 40L. Около 20-30 штук таких кодов помещается на 4K картинку, а после такие картинки склеиваются в видео и отправляются на ютуб в 60 фпс.
Проблема лишь в том, не испортит ли ютуб картинку, нет ли алгоритмов, делающих картинку в высоком фпс похуже.
Недавно просто тренд был на форчане, как можно разнообразный контент на ютуб заливать. Короче делается архив с intel и amd, разбивается на равные куски по 2,95кб, это кодируется с помощью qr кода 40L. Около 20-30 штук таких кодов помещается на 4K картинку, а после такие картинки склеиваются в видео и отправляются на ютуб в 60 фпс.
Проблема лишь в том, не испортит ли ютуб картинку, нет ли алгоритмов, делающих картинку в высоком фпс похуже.
>>1442701
Конечно испортит, у него ж не лосслесс кодирование, а lossy и с очень плохим качеством к тому же. Компенсируется размером и частотой появления QR. Даст ли 60fps вместо 30 возможность поместить в два раза больше информации или только 1.5 — надо экспериментировать. Зависит от того, насколько больше они битрейта выделяют под 60fps. Они и на 1080p24 жмотятся так, что вся картинка в мелком шуме.
Практичность уровня «облачное хранилище из писем gmail».
>>1442499
Ещё можно временно использовать libvpx до коммита https://chromium.googlesource.com/webm/libvpx/+/849e54cedd5efbd0841b32a757cecca9b921e153%5E1..849e54cedd5efbd0841b32a757cecca9b921e153/ Всего 9 дней назад было.
>Проблема лишь в том, не испортит ли ютуб картинку
Конечно испортит, у него ж не лосслесс кодирование, а lossy и с очень плохим качеством к тому же. Компенсируется размером и частотой появления QR. Даст ли 60fps вместо 30 возможность поместить в два раза больше информации или только 1.5 — надо экспериментировать. Зависит от того, насколько больше они битрейта выделяют под 60fps. Они и на 1080p24 жмотятся так, что вся картинка в мелком шуме.
>как можно разнообразный контент на ютуб заливать
Практичность уровня «облачное хранилище из писем gmail».
>>1442499
Ещё можно временно использовать libvpx до коммита https://chromium.googlesource.com/webm/libvpx/+/849e54cedd5efbd0841b32a757cecca9b921e153%5E1..849e54cedd5efbd0841b32a757cecca9b921e153/ Всего 9 дней назад было.
>>1442723
Неограниченное хранилище же! Забесплатно!
Ну qr же задумывался как помехоустойчивый, на это расчет.
>Практичность
Неограниченное хранилище же! Забесплатно!
>Конечно испортит
Ну qr же задумывался как помехоустойчивый, на это расчет.
>>1442648
А если с ним половина софта не соберётся? Там тоже API меняют только так.
На десктопе с кучей софта проще иметь в системе релизные версии.
>>1442723
Можно, да. Но мне было лень искать коммит и делать костыль с его указанием в /etc/paludis/bashrc.
> Бери ffmpeg из гита, там починили.
А если с ним половина софта не соберётся? Там тоже API меняют только так.
На десктопе с кучей софта проще иметь в системе релизные версии.
>>1442723
> Ещё можно временно использовать libvpx до коммита
Можно, да. Но мне было лень искать коммит и делать костыль с его указанием в /etc/paludis/bashrc.
>>1442851
Использую полгода ffmpeg из гита на десктопе, никаких проблем. Софта, который использует ffmpeg, впрочем, немного и mpv тоже из гита. Но сидеть на старье в любом софте, от которого ждёшь хороших результатов, бессмысленно. В гите все последние фичи и фиксы.
Можно просто скопировать ебилд в локальный оверлей и прописать EGIT_COMMIT.
>На десктопе с кучей софта проще иметь в системе релизные версии.
Использую полгода ffmpeg из гита на десктопе, никаких проблем. Софта, который использует ffmpeg, впрочем, немного и mpv тоже из гита. Но сидеть на старье в любом софте, от которого ждёшь хороших результатов, бессмысленно. В гите все последние фичи и фиксы.
>и делать костыль с его указанием в /etc/paludis/bashrc
Можно просто скопировать ебилд в локальный оверлей и прописать EGIT_COMMIT.
>>1442865
Если у тебя один mpv, то, конечно, никаких проблем. У меня просто софта чуть больше:
( cave print-dependent-ids 'virtual/ffmpeg'; cave print-dependent-ids media-video/ffmpeg;) | sort
kde-apps/ffmpegthumbs-5.9999:5::installed
kde-apps/kdenlive-15.08.2:5::installed
kde-frameworks/kfilemetadata-5.15.0:5::installed
media-gfx/blender-2.72b-r3:0::installed
media-gfx/synfig-9999:0::installed
media-libs/chromaprint-1.2:0::installed
media-libs/ffmpegsource-2.20:0::installed
media-libs/gegl-0.2.0-r2:0::installed
media-libs/mlt-9999:0::installed
media-libs/opencv-3.0.0:0::installed
media-libs/vapoursynth-28-r2:0::installed
media-plugins/alsa-plugins-1.0.29-r1:0::installed
media-plugins/gst-plugins-ffmpeg-0.10.13_p201211-r4:0.10::installed
media-plugins/gst-plugins-libav-1.4.5-r2:1.0::installed
media-sound/deadbeef-0.6.1:0::installed
media-sound/moc-2.6_alpha1:0::installed
media-video/lives-1.4.6:0::installed
media-video/mplayer-1.2-r1:0::installed
media-video/mpv-0.11.0-r1:0::installed
media-video/vlc-2.2.1:0::installed
media-video/x264-encoder-0.0.20151011:0::installed
net-im/qtox-9999:0::installed
net-misc/freerdp-1.2.1_pre20150326-r1:0::installed
> Софта, который использует ffmpeg, впрочем, немного
Если у тебя один mpv, то, конечно, никаких проблем. У меня просто софта чуть больше:
( cave print-dependent-ids 'virtual/ffmpeg'; cave print-dependent-ids media-video/ffmpeg;) | sort
kde-apps/ffmpegthumbs-5.9999:5::installed
kde-apps/kdenlive-15.08.2:5::installed
kde-frameworks/kfilemetadata-5.15.0:5::installed
media-gfx/blender-2.72b-r3:0::installed
media-gfx/synfig-9999:0::installed
media-libs/chromaprint-1.2:0::installed
media-libs/ffmpegsource-2.20:0::installed
media-libs/gegl-0.2.0-r2:0::installed
media-libs/mlt-9999:0::installed
media-libs/opencv-3.0.0:0::installed
media-libs/vapoursynth-28-r2:0::installed
media-plugins/alsa-plugins-1.0.29-r1:0::installed
media-plugins/gst-plugins-ffmpeg-0.10.13_p201211-r4:0.10::installed
media-plugins/gst-plugins-libav-1.4.5-r2:1.0::installed
media-sound/deadbeef-0.6.1:0::installed
media-sound/moc-2.6_alpha1:0::installed
media-video/lives-1.4.6:0::installed
media-video/mplayer-1.2-r1:0::installed
media-video/mpv-0.11.0-r1:0::installed
media-video/vlc-2.2.1:0::installed
media-video/x264-encoder-0.0.20151011:0::installed
net-im/qtox-9999:0::installed
net-misc/freerdp-1.2.1_pre20150326-r1:0::installed
>>1442865
Если у тебя один mpv, то, конечно, никаких проблем. У меня просто софта чуть больше:
( cave print-dependent-ids 'virtual/ffmpeg'; cave print-dependent-ids media-video/ffmpeg;) | sort
kde-apps/ffmpegthumbs-5.9999:5::installed
kde-apps/kdenlive-15.08.2:5::installed
kde-frameworks/kfilemetadata-5.15.0:5::installed
media-gfx/blender-2.72b-r3:0::installed
media-gfx/synfig-9999:0::installed
media-libs/chromaprint-1.2:0::installed
media-libs/ffmpegsource-2.20:0::installed
media-libs/gegl-0.2.0-r2:0::installed
media-libs/mlt-9999:0::installed
media-libs/opencv-3.0.0:0::installed
media-libs/vapoursynth-28-r2:0::installed
media-plugins/alsa-plugins-1.0.29-r1:0::installed
media-plugins/gst-plugins-ffmpeg-0.10.13_p201211-r4:0.10::installed
media-plugins/gst-plugins-libav-1.4.5-r2:1.0::installed
media-sound/deadbeef-0.6.1:0::installed
media-sound/moc-2.6_alpha1:0::installed
media-video/lives-1.4.6:0::installed
media-video/mplayer-1.2-r1:0::installed
media-video/mpv-0.11.0-r1:0::installed
media-video/vlc-2.2.1:0::installed
media-video/x264-encoder-0.0.20151011:0::installed
net-im/qtox-9999:0::installed
net-misc/freerdp-1.2.1_pre20150326-r1:0::installed
> Софта, который использует ffmpeg, впрочем, немного
Если у тебя один mpv, то, конечно, никаких проблем. У меня просто софта чуть больше:
( cave print-dependent-ids 'virtual/ffmpeg'; cave print-dependent-ids media-video/ffmpeg;) | sort
kde-apps/ffmpegthumbs-5.9999:5::installed
kde-apps/kdenlive-15.08.2:5::installed
kde-frameworks/kfilemetadata-5.15.0:5::installed
media-gfx/blender-2.72b-r3:0::installed
media-gfx/synfig-9999:0::installed
media-libs/chromaprint-1.2:0::installed
media-libs/ffmpegsource-2.20:0::installed
media-libs/gegl-0.2.0-r2:0::installed
media-libs/mlt-9999:0::installed
media-libs/opencv-3.0.0:0::installed
media-libs/vapoursynth-28-r2:0::installed
media-plugins/alsa-plugins-1.0.29-r1:0::installed
media-plugins/gst-plugins-ffmpeg-0.10.13_p201211-r4:0.10::installed
media-plugins/gst-plugins-libav-1.4.5-r2:1.0::installed
media-sound/deadbeef-0.6.1:0::installed
media-sound/moc-2.6_alpha1:0::installed
media-video/lives-1.4.6:0::installed
media-video/mplayer-1.2-r1:0::installed
media-video/mpv-0.11.0-r1:0::installed
media-video/vlc-2.2.1:0::installed
media-video/x264-encoder-0.0.20151011:0::installed
net-im/qtox-9999:0::installed
net-misc/freerdp-1.2.1_pre20150326-r1:0::installed
На рутрекере голосуют за закрытие из-за абуз мигалковых. Наконец-то станут нормальным пиратотрекером как остальные. И зачем они изначально начали подсасывать копирастоблядям давая им возможность закрывать раздачи, на что они надеялись?
>>1443225
Ты FAQ-то читал? Специально добавили для таких умных:
Легко говорить за себя, а когда приходится работать с многомилионной аудиторией, решение должно быть хорошо взвешенным.
Ты FAQ-то читал? Специально добавили для таких умных:
>В случае блокировки аудитория Рутрекера уменьшится примерно в 2-3 раза и многие раздачи также "погибнут".
Легко говорить за себя, а когда приходится работать с многомилионной аудиторией, решение должно быть хорошо взвешенным.
Суп, проясните мне пару вещей плиз.
Считаю на 2-pass
(maxsize_k - audiosize_k) 8 / time_s = bvk
В моём случае
10240 - 293 8 / 40 = 1989.4
Дальше делаю
ffmpeg -i mp4.mp4 -c:v libvpx-vp9 -b:v 1989k -c:a libopus -b:a 64k -ac 2 -sn -pass 1 webm.webm
ffmpeg -i mp4.mp4 -c:v libvpx-vp9 -b:v 1989k -c:a libopus -b:a 64k -ac 2 -sn -pass 2 -y webm.webm
Гуд, 9.98м.
И тут вопросы:
1. -pass 2. 0.4 fps. Это норма 40 сек, бля, больше часа кодить? Как быстрее сделать?
2. Хули перематываеться такими большими кусками? Мне надо больше ключевых кадров или чего, и как?
3. (maxsize_k - audiosize_k) * 8 / time_s = bvk Что это за магическая константа 8?
Считаю на 2-pass
(maxsize_k - audiosize_k) 8 / time_s = bvk
В моём случае
10240 - 293 8 / 40 = 1989.4
Дальше делаю
ffmpeg -i mp4.mp4 -c:v libvpx-vp9 -b:v 1989k -c:a libopus -b:a 64k -ac 2 -sn -pass 1 webm.webm
ffmpeg -i mp4.mp4 -c:v libvpx-vp9 -b:v 1989k -c:a libopus -b:a 64k -ac 2 -sn -pass 2 -y webm.webm
Гуд, 9.98м.
И тут вопросы:
1. -pass 2. 0.4 fps. Это норма 40 сек, бля, больше часа кодить? Как быстрее сделать?
2. Хули перематываеться такими большими кусками? Мне надо больше ключевых кадров или чего, и как?
3. (maxsize_k - audiosize_k) * 8 / time_s = bvk Что это за магическая константа 8?
>>1443301
1. Норм, если проц слабоват, а видиво фулл ашди.
2. Добавь параметр -g 30 и будет ключевой кадр не более чем через каждые 30 кадров.
3. Количество бит в байте.
1. Норм, если проц слабоват, а видиво фулл ашди.
2. Добавь параметр -g 30 и будет ключевой кадр не более чем через каждые 30 кадров.
3. Количество бит в байте.
>>1443371
Хуита, те же 0.4.
>>1443422
Та ну нах епта. С libx264 30-40fps. На том же видиво.
Буду в vp8 значит делать, там хоть 4-7fps.
спс
Я вот ещё в доке нагуглил -force_key_frames expr:gte(t,n_forced*5) каждые 5 сек. Чем оно от -g отличается?
Хуита, те же 0.4.
>>1443422
>1. Норм, если проц слабоват, а видиво фулл ашди.
Та ну нах епта. С libx264 30-40fps. На том же видиво.
Буду в vp8 значит делать, там хоть 4-7fps.
>3. Количество бит в байте.
спс
>2. Добавь параметр -g 30 и будет ключевой кадр не более чем через каждые 30 кадров.
Я вот ещё в доке нагуглил -force_key_frames expr:gte(t,n_forced*5) каждые 5 сек. Чем оно от -g отличается?
>>1443439
Вопрос снят, сам понял.
>Я вот ещё в доке нагуглил -force_key_frames expr:gte(t,n_forced*5) каждые 5 сек. Чем оно от -g отличается?
Вопрос снят, сам понял.
6024 Кб, Webm
test
>>1443380
В настройках самой борды можно включить панель размеки в форме постинга. Ну и помнить про то, что макака сломал звёздочки и для знака умножения лучше использовать Икс.
В настройках самой борды можно включить панель размеки в форме постинга. Ну и помнить про то, что макака сломал звёздочки и для знака умножения лучше использовать Икс.
Есть одно видео 1280х720
-vf scale=720:-1
Как от результата 720х405 отрезать 1 пиксель с низу?
-vf scale=720:-1 -vf crop=wut?
-vf scale=720:-1
Как от результата 720х405 отрезать 1 пиксель с низу?
-vf scale=720:-1 -vf crop=wut?
Още медленно перекодирует, в чём проблема?
>>1443229
Первая новость на главной
>>1443241
Это сильно преувеличено, сейчас уже каждый хомячок знает про прокси-шмокси, разве что процентов 10-20 мммаксимум васянов не додумаются сами, и то, через пару месяцев всё равно подключатся. Вообще мне кажется, что там есть какой-то подводный камень, из-за которого рутрекер начал содействовать копирайтерам, вангую они проплачивали администрации за это, а теперь денежки кончились и торенты решили пидорнуть, или ещё что-то, у такого большого ресурса 100% должна быть какая-нибудь закулисная игра.
Первая новость на главной
>>1443241
Это сильно преувеличено, сейчас уже каждый хомячок знает про прокси-шмокси, разве что процентов 10-20 мммаксимум васянов не додумаются сами, и то, через пару месяцев всё равно подключатся. Вообще мне кажется, что там есть какой-то подводный камень, из-за которого рутрекер начал содействовать копирайтерам, вангую они проплачивали администрации за это, а теперь денежки кончились и торенты решили пидорнуть, или ещё что-то, у такого большого ресурса 100% должна быть какая-нибудь закулисная игра.
>>1443839
Попробуй -vf "scale=-720:-1, crop=720:404:0:1"
Попробуй -vf "scale=-720:-1, crop=720:404:0:1"
>>1443225
C нулем сидов на всем, кроме репачков и порнушки. Как на руторе, фриторрентсе и пиратской бухте. Единственное, что они смогли хорошо сделать - удержать людей на сидировании, там даже рейтинг убрали, а раздача все равно идет почти везде.
>Наконец-то станут нормальным пиратотрекером как остальные.
C нулем сидов на всем, кроме репачков и порнушки. Как на руторе, фриторрентсе и пиратской бухте. Единственное, что они смогли хорошо сделать - удержать людей на сидировании, там даже рейтинг убрали, а раздача все равно идет почти везде.
>>1443927
Для сидирования тебе прокси не понадобится.
Для сидирования тебе прокси не понадобится.
>>1433679
Так повсюду такая хуйня: чуть копнёшь поглубже — сразу находишь изъяны распространённых решений. Перфекционизм — опасная штука, да ещё и заразная, к тому же.
>>1433405
Т.е. без работы над libvpx вообще нет смысла это запиливать. Понятно.
>>1443839
Слитно.
-vf scale=720:-1,crop=iw:trunc(ih/2)/0.5
Можно и не отрезать, а масштабировать до чётной величины:
-vf scale=720:trunc(720/dar/2)/0.5
Что из этого лучше — ещё вопрос.
>>1443927
Что-то мне подсказывает, что будет наоборот: отвалятся в основном порнобляди.
Так повсюду такая хуйня: чуть копнёшь поглубже — сразу находишь изъяны распространённых решений. Перфекционизм — опасная штука, да ещё и заразная, к тому же.
>>1433405
> Патч также ломает рейт-контроль, но в обратную сторону, лол. Улучшений по сравнению с дефолтом нет, даже наоборот.
Т.е. без работы над libvpx вообще нет смысла это запиливать. Понятно.
>>1443839
> с низу
Слитно.
> Как от результата 720х405 отрезать 1 пиксель снизу?
-vf scale=720:-1,crop=iw:trunc(ih/2)/0.5
Можно и не отрезать, а масштабировать до чётной величины:
-vf scale=720:trunc(720/dar/2)/0.5
Что из этого лучше — ещё вопрос.
>>1443927
Что-то мне подсказывает, что будет наоборот: отвалятся в основном порнобляди.
Пиздец, вы тут все ебанулись. Скажите лучше прогу по конверту мп4 в шебм с 2 кнопками "Старт" и "Куда сохранить готовый файл, милорд?".
>>1444305
https://www.youtube.com/watch?v=Kb1HuZczYtY
>с 2 кнопками "Старт" и "Куда сохранить готовый файл, милорд?"
https://www.youtube.com/watch?v=Kb1HuZczYtY
>>1443966
Мне, кстати, пояснили, что лучше бы с денойз фильтров вообще начинать. Есть шанс, что кодек неэффективно убирает дубли из-за шума (обрати внимание, кстати, на меняющиеся символы в ASCII-версии даже на статичных областях >>1442439 ; подозреваю, что это оно и есть).
По-хорошему надо сделать разные версии энкодов:
1) Оригинал
2) Денойз
3) Дедуп
и сравнить размеры пакетов в каждом случае. А то как-то маловато результатов экспериментов, в основном домыслы.
Особенно фигово когда ты ненастоящий энкодер и ffmpeg на стройке нашёл. Столько лет наработок в этом направлении, разных техник, фильтров вроде тех же denoise, dedup, 2d cleaner, которые могли бы помочь значительно выправлять качество в плохих случаях, а ты ничего про это не знаешь, блин.
>Т.е. без работы над libvpx вообще нет смысла это запиливать
Мне, кстати, пояснили, что лучше бы с денойз фильтров вообще начинать. Есть шанс, что кодек неэффективно убирает дубли из-за шума (обрати внимание, кстати, на меняющиеся символы в ASCII-версии даже на статичных областях >>1442439 ; подозреваю, что это оно и есть).
По-хорошему надо сделать разные версии энкодов:
1) Оригинал
2) Денойз
3) Дедуп
и сравнить размеры пакетов в каждом случае. А то как-то маловато результатов экспериментов, в основном домыслы.
>чуть копнёшь поглубже — сразу находишь изъяны распространённых решений
Особенно фигово когда ты ненастоящий энкодер и ffmpeg на стройке нашёл. Столько лет наработок в этом направлении, разных техник, фильтров вроде тех же denoise, dedup, 2d cleaner, которые могли бы помочь значительно выправлять качество в плохих случаях, а ты ничего про это не знаешь, блин.
>>1444385
Test
Test
Нет ли возможности с помощью ффмпега пофиксить плавающий рассинхрон звука и видео? Есть файл на час, по началу там 0мс, к концу 500мс. Или это надо ебаться непосредственно с аудио-дорожкой через йоба-редакторы?
>>1444542
Скорее всего второе. В нем хотя бы понятно будет, плавающий рассинхрон или нет. Хотя в ffmpeg наверняка есть какой-нибудь таймстретч, но придется наугад хреначить.
Скорее всего второе. В нем хотя бы понятно будет, плавающий рассинхрон или нет. Хотя в ffmpeg наверняка есть какой-нибудь таймстретч, но придется наугад хреначить.
>>1444587
Ты смотри, и правда есть atempo. Только непонятно, меняет ли он тон https://ffmpeg.org/ffmpeg-filters.html#atempo
Ты смотри, и правда есть atempo. Только непонятно, меняет ли он тон https://ffmpeg.org/ffmpeg-filters.html#atempo
>>1444305
В анимублядском последняя строчка шапки, кнопок много (более 2), но жмет не хуже ффмпега (она им и жмет, внезапно).
В анимублядском последняя строчка шапки, кнопок много (более 2), но жмет не хуже ффмпега (она им и жмет, внезапно).
цуиь с чередующимися статичными изображениями или гифками, как? луп гиф как таковой не поддерживает как понимаю.
Можно ли ффмпегом сжимать AVI по битрейту и разрешению но не перекодируя в вэбм ?
>>1444385
Смешная хуйня получается: выходит, кодек сначала распидорашивает картинку, и только потом начинает искать дубли?
1) Оригинал
2) Денойз
3) Дедуп
и сравнить размеры пакетов в каждом случае.
Погоди. У тебя что, на вход энкодера подаётся распидорашенная картинка?
Хреново, конечно, но что поделать. Владельцы знаний всегда будут в таких вещах в преимуществе.
Другое дело, что неидеальной картинки может быть достаточно для выполнения поставленной задачи. Вон, взять тех же порноблядей — квадраты им дрочить не мешают.
> Есть шанс, что кодек неэффективно убирает дубли из-за шума (обрати внимание, кстати, на меняющиеся символы в ASCII-версии даже на статичных областях >>1442439 ; подозреваю, что это оно и есть
Смешная хуйня получается: выходит, кодек сначала распидорашивает картинку, и только потом начинает искать дубли?
> По-хорошему надо сделать разные версии энкодов:
1) Оригинал
2) Денойз
3) Дедуп
и сравнить размеры пакетов в каждом случае.
Погоди. У тебя что, на вход энкодера подаётся распидорашенная картинка?
> Особенно фигово когда ты ненастоящий энкодер и ffmpeg на стройке нашёл. Столько лет наработок в этом направлении, разных техник, фильтров вроде тех же denoise, dedup, 2d cleaner, которые могли бы помочь значительно выправлять качество в плохих случаях, а ты ничего про это не знаешь, блин.
Хреново, конечно, но что поделать. Владельцы знаний всегда будут в таких вещах в преимуществе.
Другое дело, что неидеальной картинки может быть достаточно для выполнения поставленной задачи. Вон, взять тех же порноблядей — квадраты им дрочить не мешают.
>>1445224
Можно, если перекодировать в любой другой поддерживаемый формат.
Можно, если перекодировать в любой другой поддерживаемый формат.
>>1444542
Есть: фильтры asetrate и aresample. Делишь частоту звука на коэффициент сползания (он от этого ускоряется) и ресэмплишь обратно до стандартного значения 44100 или 48000Hz.
Хотя мб будет достаточно и одного фильтра atempo.
Ещё можно изменить тайминги кадров фильтром setpts, но перекодировать видео дольше.
Фильтр asetpts использовать даже не пытайся, т.к. с ним нарушится непрерывность потока сэмплов.
> Нет ли возможности с помощью ффмпега пофиксить плавающий рассинхрон звука и видео?
Есть: фильтры asetrate и aresample. Делишь частоту звука на коэффициент сползания (он от этого ускоряется) и ресэмплишь обратно до стандартного значения 44100 или 48000Hz.
Хотя мб будет достаточно и одного фильтра atempo.
Ещё можно изменить тайминги кадров фильтром setpts, но перекодировать видео дольше.
Фильтр asetpts использовать даже не пытайся, т.к. с ним нарушится непрерывность потока сэмплов.
4224 Кб, 1280x720
4225 Кб, 1280x720
36 Кб, 1280x720
>>1445224
Вебм это вообще контейнер. А так ffmpeg это самый мощный комбайн из всех существующих на рынке транскодеров, если что. Ещё и свободный к тому же.
>>1445230
Может в оригинале было? Хотя вот здесь есть кое-какие пояснения по поводу луп-фильтра, но я до сих пор плохо представляю, как оно всё вместе работает:
http://permalink.gmane.org/gmane.comp.multimedia.webm.user/7097
Нет, обычный аниме-исходник. Просто вот тебе 2 последовательных, не отличимых на глаз кадра ([Commie] Plastic Memories - 01 [D921F939].mkv, 12:35.046, 12:35.088) и дифф между ними. Неплохо так, да?
Вебм это вообще контейнер. А так ffmpeg это самый мощный комбайн из всех существующих на рынке транскодеров, если что. Ещё и свободный к тому же.
>>1445230
>кодек сначала распидорашивает картинку
Может в оригинале было? Хотя вот здесь есть кое-какие пояснения по поводу луп-фильтра, но я до сих пор плохо представляю, как оно всё вместе работает:
http://permalink.gmane.org/gmane.comp.multimedia.webm.user/7097
>У тебя что, на вход энкодера подаётся распидорашенная картинка?
Нет, обычный аниме-исходник. Просто вот тебе 2 последовательных, не отличимых на глаз кадра ([Commie] Plastic Memories - 01 [D921F939].mkv, 12:35.046, 12:35.088) и дифф между ними. Неплохо так, да?
test
>>1445273
Можно и на GPU, но результаты не блещут. Если надо хреново, но быстро, разве что. Крупнейшие видео-хостинги (Youtube, Netflix) используют обычные софтварные реализации.
Можно и на GPU, но результаты не блещут. Если надо хреново, но быстро, разве что. Крупнейшие видео-хостинги (Youtube, Netflix) используют обычные софтварные реализации.
>>1445286
Двойная точность не к черту, на игровых видюхах режется ради продажи проф решений по цене в 10 раз дороже.
Двойная точность не к черту, на игровых видюхах режется ради продажи проф решений по цене в 10 раз дороже.
>>1445288
Что за точность, как это будет на видео выглядеть? Просто у меня одноядерный атлон и на нём всё уж слишком медленно кодируется, подумываю кодировать на видеокарте (HD4650)
Что за точность, как это будет на видео выглядеть? Просто у меня одноядерный атлон и на нём всё уж слишком медленно кодируется, подумываю кодировать на видеокарте (HD4650)
>>1445286
Сложнее реализация? Хотя, интелловский вроде ничего:
https://software.intel.com/en-us/blogs/2015/10/23/intel-media-server-studio-hevc-codec-wins-transcoding-title
http://compression.ru/video/codec_comparison/hevc_2015/
Но он стоит $4к и только на последних зеонах работает, ололо:
https://software.intel.com/en-us/intel-media-server-studio/details
>>1445292
Ты вначале найди под неё нормальный энкодер, а потом подумывай. Если он вообще есть.
Да и всё это маркетинговый буллшит. Инженеры не стоят на месте, пилятся VP10, NetVC. Через пару лет будут более эффективные форматы и софтварные реализации под них, а стоимость аппаратных решений так и не окупится. По крайней мере в любительском применении.
Сложнее реализация? Хотя, интелловский вроде ничего:
https://software.intel.com/en-us/blogs/2015/10/23/intel-media-server-studio-hevc-codec-wins-transcoding-title
http://compression.ru/video/codec_comparison/hevc_2015/
Но он стоит $4к и только на последних зеонах работает, ололо:
https://software.intel.com/en-us/intel-media-server-studio/details
>>1445292
>подумываю кодировать на видеокарте (HD4650)
Ты вначале найди под неё нормальный энкодер, а потом подумывай. Если он вообще есть.
Да и всё это маркетинговый буллшит. Инженеры не стоят на месте, пилятся VP10, NetVC. Через пару лет будут более эффективные форматы и софтварные реализации под них, а стоимость аппаратных решений так и не окупится. По крайней мере в любительском применении.
>>1445305
То есть чтобы кодировать через видеокарту нужно покупать какие-то мокрописьки?
То есть чтобы кодировать через видеокарту нужно покупать какие-то мокрописьки?
>>1445318
Для начала, о кодере для вебм (vp8-9) на видеокартах ничего неизвестно, если видел такие, то давай ссылку. Т.е. покупать нечего. Для h.264 они есть.
Для начала, о кодере для вебм (vp8-9) на видеокартах ничего неизвестно, если видел такие, то давай ссылку. Т.е. покупать нечего. Для h.264 они есть.
>>1445318
Ну можешь купить какую-нибудь топовую nvidia, вроде GTX 970 и использовать nvenc, см. http://habrahabr.ru/post/262507/
nvenc в ffmpeg поддерживается, SDK бесплатное, хоть и проприетарное. Только вот качество будет хуже чем x264/x265 в medium. Т.е. отсос. (И да, это для HEVC, если что.)
Ну можешь купить какую-нибудь топовую nvidia, вроде GTX 970 и использовать nvenc, см. http://habrahabr.ru/post/262507/
nvenc в ffmpeg поддерживается, SDK бесплатное, хоть и проприетарное. Только вот качество будет хуже чем x264/x265 в medium. Т.е. отсос. (И да, это для HEVC, если что.)
>>1445348
На самом быстром, который можешь себе позволить? Бери Skylake E3, ололо.
На самом быстром, который можешь себе позволить? Бери Skylake E3, ололо.
6134 Кб, Webm
TEST
>>1395791 (OP)
Можно ли кодирование в ffmpeg поставить на паузу или остановить или что то в этом роде? Если там срочно уйти надо, например.
Можно ли кодирование в ffmpeg поставить на паузу или остановить или что то в этом роде? Если там срочно уйти надо, например.
>>1445361
Хотя я вспомнил. На винде ProcessExplorer умеет приостанавливать процесс.
Хотя я вспомнил. На винде ProcessExplorer умеет приостанавливать процесс.
>>1444385
>>1445253
Кстати, сейчас осознал, что vo=aalib/vo=caca реально хороший индиактор зашумлённости видео. Раньше тоже как-то запускал вывод в ASCII и не мог понять, отчего всё дрожит. Надо с денойзом перед y2aa поэкспериментировать и попробоваться добиться идеально статичных поверхностей. Быть может и dedup/mpdecimate тогда не понадобится — ведь с в точности одинаковыми картинками кодек и сам хорошо справляется. (По крайней мере в паттерне X, X, X, ...; насчёт X X Y Y Z Z не уверен.)
Я ебал капчу, кстати.
>>1445253
Кстати, сейчас осознал, что vo=aalib/vo=caca реально хороший индиактор зашумлённости видео. Раньше тоже как-то запускал вывод в ASCII и не мог понять, отчего всё дрожит. Надо с денойзом перед y2aa поэкспериментировать и попробоваться добиться идеально статичных поверхностей. Быть может и dedup/mpdecimate тогда не понадобится — ведь с в точности одинаковыми картинками кодек и сам хорошо справляется. (По крайней мере в паттерне X, X, X, ...; насчёт X X Y Y Z Z не уверен.)
Я ебал капчу, кстати.
>>1445358
А уйти и оставить его кодировать — не? Можно ещё нарисовать однострочник, который выключит или засуспендит компьютер после завершения процесса ffmpeg.
А уйти и оставить его кодировать — не? Можно ещё нарисовать однострочник, который выключит или засуспендит компьютер после завершения процесса ffmpeg.
63 Кб, 677x594
В чем ошибка? По этому же коду сделал 4 вебмки, все работает, а тут не хочет ни при 16, ни при 8. Как фиксить?
>>1445544
Ах, блядь, точно ведь, я слепой мудак. Спасибо.
Ах, блядь, точно ведь, я слепой мудак. Спасибо.
когаме в рот ебут сапогаме
>>1395795
Бл от
Бл от
Можно как-то снимать видео с десктопа и на ходу кодировать в vp9?
56 Кб, 1280x720
>>1445253
А вот во что превращается разница между двумя одинаковыми кадрами после энкода. Не всё так плохо, кажется. Размеры пакетов: 8986 и 193. Чётко видно, что практически вся разница идёт по границам суперблоков. Т.е. всего-навсего разный deblock. Но надо нормально посравнивать покадрово в любом случае.
А вот во что превращается разница между двумя одинаковыми кадрами после энкода. Не всё так плохо, кажется. Размеры пакетов: 8986 и 193. Чётко видно, что практически вся разница идёт по границам суперблоков. Т.е. всего-навсего разный deblock. Но надо нормально посравнивать покадрово в любом случае.
>>1445496
Ставь 25 и забудь про него.
> The --lag-in-frames parameter defines an upper limit on the number of frames into the future that the encoder can look.
Ставь 25 и забудь про него.
>>1445496
Бамп вопросу.
Бамп вопросу.
>>1446312
Это что-то вроде подзагрузки видео во время онлайн просмотра?
Это что-то вроде подзагрузки видео во время онлайн просмотра?
>>1446315
А я вот это, кстати, не нашел. Просто много где оно фигурирует в строках для энкодинга, зачем?
А я вот это, кстати, не нашел. Просто много где оно фигурирует в строках для энкодинга, зачем?
>>1446387
На случай если поменяют умолчания. Или просто по привычке. В общем-то без разницы, главное знать, какие настройки будут использоваться на самом деле. Проверить можно с помощью -loglevel debug.
На случай если поменяют умолчания. Или просто по привычке. В общем-то без разницы, главное знать, какие настройки будут использоваться на самом деле. Проверить можно с помощью -loglevel debug.
>>1446503
Что тебе в данной цитате непонятно?
>When --auto-alt-ref is enabled the default mode of operation is to either populate the buffer with a copy of the previous golden frame when this frame is updated, or with a copy of a frame derived from some point of time in the future (the choice is made automatically by the encoder). The --lag-in-frames parameter defines an upper limit on the number of frames into the future that the encoder can look.
Что тебе в данной цитате непонятно?
>>1446530
Можно ссылку где это написано? Что такое auto-alt-ref? И я не совсем понял что такое золотой кадр. Как я понял, лаг-ин-фрамес это количество кадров, которые загружаются в кодек чтобы их просчитать по степени быстроты изменения сцены видео и выдать им варьируемый битрейт. Но я не понял как это будет происходить. Если указать максимальное число 25 то что будет: вычисления будут точнее но медленее? А если указать меньшее число то наоборот?
Можно ссылку где это написано? Что такое auto-alt-ref? И я не совсем понял что такое золотой кадр. Как я понял, лаг-ин-фрамес это количество кадров, которые загружаются в кодек чтобы их просчитать по степени быстроты изменения сцены видео и выдать им варьируемый битрейт. Но я не понял как это будет происходить. Если указать максимальное число 25 то что будет: вычисления будут точнее но медленее? А если указать меньшее число то наоборот?
Вот нашёл. "Также присутствует опция -auto-alt-ref 1, включающая режим создания альтернативных ключевых кадров." Но тогда что такое эти альтернативные кадры?
>>1446640
Аналог B-frame, но при проигрывании не отображаеся. Почитай ссылки отсюда для начала:
https://github.com/Kagami/webm.py/wiki/Lowlevel-VPx-details
Кстати, внезапно:
Может -sws_flags lanczos сжимаемость ухудшает. Надо бы с bilinear попробовать.
Аналог B-frame, но при проигрывании не отображаеся. Почитай ссылки отсюда для начала:
https://github.com/Kagami/webm.py/wiki/Lowlevel-VPx-details
Кстати, внезапно:
>As you might know, the more detail a frame has, the more difficult it is to compress it. This means that Lanczos is NOT suited for low bitrate video, the various Bicubic flavours are much better for this. If however you have enough bitrate then using Lanczos will give you a better picture, but in general I do not recommend using it for 1 CD rips because the bitrate is usually too low (there are exceptions of course).
Может -sws_flags lanczos сжимаемость ухудшает. Надо бы с bilinear попробовать.
>>1446785
Это наверно тот кун с одноядерным атлоном, твой телефон возможно мощнее.
Это наверно тот кун с одноядерным атлоном, твой телефон возможно мощнее.
>>1446783
Подтверждаю, было такое, пришлось от него отказаться.
>Может -sws_flags lanczos сжимаемость ухудшает
Подтверждаю, было такое, пришлось от него отказаться.
200 Кб, 635x478
Не получается склеить видео с аудиодорожкой в контейнер AVI, пишет
И ещё после перекодирование мп4 в vp9 распидорашивает первые несколько секунд видео. Почему?
>Could not write header for output file #0 (incorrect codec parameters ?): Error number -1 occurred как сделать чтобы работало?
И ещё после перекодирование мп4 в vp9 распидорашивает первые несколько секунд видео. Почему?
>>1447344
Тоже блюрит, но качество получше, чем bilinear. В mpv с vo=opengl-hq, spline36 дефолтный ресемплер.
Вот, например: http://compare.bakashots.me/compare.php?setId=1410&comparisonId=8735&imageNum=2
Везде мыло, кроме bicubic (catrom).
Тоже блюрит, но качество получше, чем bilinear. В mpv с vo=opengl-hq, spline36 дефолтный ресемплер.
Вот, например: http://compare.bakashots.me/compare.php?setId=1410&comparisonId=8735&imageNum=2
Везде мыло, кроме bicubic (catrom).
>>1447315
Дорожки каких форматов ты пытаешься туда запихнуть? Контейнер AVI поддерживает их далеко не все: например, он не может в H.264 с B-фреймами и в mp3 с переменным битрейтом.
Если уровень квантизации выше чем у остального видео, то ты кодируешь одним проходом;
если как на пике, то проблема на стороне декодирования.
> Не получается склеить видео с аудиодорожкой в контейнер AVI
Дорожки каких форматов ты пытаешься туда запихнуть? Контейнер AVI поддерживает их далеко не все: например, он не может в H.264 с B-фреймами и в mp3 с переменным битрейтом.
> И ещё после перекодирование мп4 в vp9 распидорашивает первые несколько секунд видео. Почему?
Если уровень квантизации выше чем у остального видео, то ты кодируешь одним проходом;
если как на пике, то проблема на стороне декодирования.
Я с утра пораньше задумался над вопросом, который решить сам не в состоянии:
Вот в процессоре, скажем, заявлено какое-то хардварное кодирование видео. Что это вообще означает и как поиметь с этого профиты? Нужно какие-то специальные библиотеки использовать, или оно автоматом включается?
Вот в процессоре, скажем, заявлено какое-то хардварное кодирование видео. Что это вообще означает и как поиметь с этого профиты? Нужно какие-то специальные библиотеки использовать, или оно автоматом включается?
Аноны, мне нид ужать видео после фрапса, все программы чет ужимают в несколько десятков\сотен раз за счет качества, как не потерять качество?
>>1447551
Может. Сам стандарт контейнера их не запрещает и тысячи таких энкодов прекрастно делаются.
Может. «There is a value in the stream headers, called dwSampleSize, which is 0 in order to trigger VBR stream seeking. This is officially documented in the MSDN and not a hack, bug or whatever. The way MP3-VBR and AAC are stored in AVI are specified and completely compliant with the AVI file specification.» Не все демуксеры поддерживают, но это их проблемы.
Квантования.
Или пытается обрезать с -c copy не по ключевым кадрам или ещё какая херня.
>>1447600
Просто отдельный блок вычислений на чипе? См, например, https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video
Реальных профитов практически нет, а просто чтобы поиграться, достаточно иметь поддержку в драйвере и транскодере. Тот же QSV в ffmpeg'е поддерживается, нужно поставить драйвер/Intel Media SDK и скомпилировать.
>не может в H.264 с B-фреймами
Может. Сам стандарт контейнера их не запрещает и тысячи таких энкодов прекрастно делаются.
>mp3 с переменным битрейтом
Может. «There is a value in the stream headers, called dwSampleSize, which is 0 in order to trigger VBR stream seeking. This is officially documented in the MSDN and not a hack, bug or whatever. The way MP3-VBR and AAC are stored in AVI are specified and completely compliant with the AVI file specification.» Не все демуксеры поддерживают, но это их проблемы.
>квантизации
Квантования.
>то проблема на стороне декодирования
Или пытается обрезать с -c copy не по ключевым кадрам или ещё какая херня.
>>1447600
>Что это вообще означает
Просто отдельный блок вычислений на чипе? См, например, https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video
>и как поиметь с этого профиты
Реальных профитов практически нет, а просто чтобы поиграться, достаточно иметь поддержку в драйвере и транскодере. Тот же QSV в ffmpeg'е поддерживается, нужно поставить драйвер/Intel Media SDK и скомпилировать.
>>1447796
В шакалах.
В шакалах.
g
Мой ффмпег некоторое время простаивает перед кодированием на нулевом кадре, при этом нагружая процессор, это нормально? Что он там делает?
>>1448240
strace -p <pid>
strace -p <pid>
Котаны, чем я могу быстро переконвентировать .mp4 файл в .webm длинной в 1 час 30 минут? Качество не сильно важно. Под "быстро" подразумевается ~2 часа. Не спрашивайте, зачем.
>>1448546
Пасиба.
Пасиба.
>>1395791 (OP)
Но у меня не отправляется файл размером 5132кб, ЧЯДНТ?
> максимальный размер файла: 20480КБ в /b/ и /media/, 6144КБ в тематике
Но у меня не отправляется файл размером 5132кб, ЧЯДНТ?
Нужна помощь от гуру ffmpeg.
Дано:
background.mp3
1.mp3 2.mp3
1.png 2.png 3.png
hint.png
Нужно из этого получить видеофайл, где:
background.mp3 играет от начала до конца
1.mp3 и 2.mp3 играют на определенных участках
1, 2 и 3.png сменяют друг друга с заданной скоростью
hint.png в определенный момент появляется, накладываясь на картинку, длится некоторое время и исчезает.
Нужна команда ffmpeg, чтобы это сделать. Благодарю, как минимум, за внимание. Сам со временем в любом случае разберусь как это сделать, но если поможете, буду благодарен за ускорение.
Дано:
background.mp3
1.mp3 2.mp3
1.png 2.png 3.png
hint.png
Нужно из этого получить видеофайл, где:
background.mp3 играет от начала до конца
1.mp3 и 2.mp3 играют на определенных участках
1, 2 и 3.png сменяют друг друга с заданной скоростью
hint.png в определенный момент появляется, накладываясь на картинку, длится некоторое время и исчезает.
Нужна команда ffmpeg, чтобы это сделать. Благодарю, как минимум, за внимание. Сам со временем в любом случае разберусь как это сделать, но если поможете, буду благодарен за ускорение.
Очередной NetVC meeting сегодня в 9:20 по Москве (через 8 часов):
https://datatracker.ietf.org/meeting/94/agenda/netvc/
Как минимум несколько докладов выглядят интересно.
Ещё в thor слили все наработки одним громадным коммитом:
https://github.com/cisco/thor/pull/28
Все эти их заявления об открытости и порицания политики гугля в отношении участия коммьюнити, ясное дело, только на словах:
http://blogs.cisco.com/collaboration/world-meet-thor-a-project-to-hammer-out-a-royalty-free-video-codec
https://datatracker.ietf.org/meeting/94/agenda/netvc/
Как минимум несколько докладов выглядят интересно.
Ещё в thor слили все наработки одним громадным коммитом:
https://github.com/cisco/thor/pull/28
Все эти их заявления об открытости и порицания политики гугля в отношении участия коммьюнити, ясное дело, только на словах:
http://blogs.cisco.com/collaboration/world-meet-thor-a-project-to-hammer-out-a-royalty-free-video-codec
>>1448774
ffmpeg \
-loop 0 -r <скорость в fps> -i %1d.png \
-i background.mp3 \
-i 1.mp3 \
-i 2.mp3 \
-lavfi 'anullsrc,atrim=end=<начало 1.mp3>[a0-0];
[a0-0][2:a]concat=v=0:a=1,apad=whole_len=<начало 2.mp3>[a0];
[1:a][a0]amix[a]' \
-map 0:v -map '[a]' -shortest out.mkv
Если нужно меньше 1 fps, то видеодорожку надо хуячить фильтром setpts.
ffmpeg \
-loop 0 -r <скорость в fps> -i %1d.png \
-i background.mp3 \
-i 1.mp3 \
-i 2.mp3 \
-lavfi 'anullsrc,atrim=end=<начало 1.mp3>[a0-0];
[a0-0][2:a]concat=v=0:a=1,apad=whole_len=<начало 2.mp3>[a0];
[1:a][a0]amix[a]' \
-map 0:v -map '[a]' -shortest out.mkv
Если нужно меньше 1 fps, то видеодорожку надо хуячить фильтром setpts.
>>1448876
Забыл прилепить 2.mp3. По аналогии с 1.mp3:
'[a0-1][3:a]concat=v=0:a=1[a0]', где [a0-1] — вывод фильтра apad.
Забыл прилепить 2.mp3. По аналогии с 1.mp3:
'[a0-1][3:a]concat=v=0:a=1[a0]', где [a0-1] — вывод фильтра apad.
>>1448445
Да. Если указывать -ss на выходе, то он декодирует все кадры от начала. Надо на входе.
>>1447871
Бля. Надо покупать новый мозг: в старом это слишком прочно засело.
Погуглил, действительно так: не могут только реализации от спермософта.
Ты ведь об этом тоже уже здесь писал, да?
Но он же пишет что кодирует из какого-то mp4-совместимого формата в vp9.
Да. Если указывать -ss на выходе, то он декодирует все кадры от начала. Надо на входе.
>>1447871
> Квантования.
Бля. Надо покупать новый мозг: в старом это слишком прочно засело.
> Может.
Погуглил, действительно так: не могут только реализации от спермософта.
Ты ведь об этом тоже уже здесь писал, да?
> Или пытается обрезать с -c copy не по ключевым кадрам
Но он же пишет что кодирует из какого-то mp4-совместимого формата в vp9.
131 Кб, 1422x966
>>1447871
Это у процессороблядей нету, а вот у нвидиябогов h265 в 100 FPS кококодируется!
>Реальных профитов практически нет
Это у процессороблядей нету, а вот у нвидиябогов h265 в 100 FPS кококодируется!
>>1447871
Вейт, quicksync использует же встроенное видео для обработки, я зачастую пишется о раздельном кодировании по типу "Используется gpu" и "Hardware"
Может там какие-то алгоритмы в процессор зашиты? Впрочем, ладно. Вот конкретно в скайлейках есть "Частичная поддержка кодирования/декодирования vp9"
Что с этим делать теперь? Это тоже на quicksync завязано?
Вейт, quicksync использует же встроенное видео для обработки, я зачастую пишется о раздельном кодировании по типу "Используется gpu" и "Hardware"
Может там какие-то алгоритмы в процессор зашиты? Впрочем, ладно. Вот конкретно в скайлейках есть "Частичная поддержка кодирования/декодирования vp9"
Что с этим делать теперь? Это тоже на quicksync завязано?
>>1435410
Так однострочник для спермы есть или нет? И так никто и не ответил на вопрос, лучше юзать
Или -g 150. Если похуй, то вставьте любой из этих вариантов в вики, т.к. меня доебало уже в анимублядском ждать пока промотается вебмка. А особенно объяснять это кому-то.
Так однострочник для спермы есть или нет? И так никто и не ответил на вопрос, лучше юзать
>-force_key_frames expr:gte(t,n_forced*5)
Или -g 150. Если похуй, то вставьте любой из этих вариантов в вики, т.к. меня доебало уже в анимублядском ждать пока промотается вебмка. А особенно объяснять это кому-то.
282 Кб, 1048x731
>>1448903
С качеством хуже, чем x264 -preset medium? Ну и кому оно такое надо?
>>1448975
Да, на встроенном GPU, который также на чипе. (Хотя, декодирование, как пишут, может быть и отдельным блоком: http://www.anandtech.com/show/4083/the-sandy-bridge-review-intel-core-i7-2600k-i5-2500k-core-i3-2100-tested/8 )
Формат (или его основные ресурсоёмкие примитивы) поддерживается аппаратно, так что, грубо говоря, да. У тебя, допустим, библиотека аппаратного энкодера предоставляет функцию encode_h264_frame, из которой motion esimation/entropy coding прям зашиты в железку.
Да, как я понял. И для VP9 только декодирование.
>>1448981
Это он и есть. Для повершелла.
С качеством хуже, чем x264 -preset medium? Ну и кому оно такое надо?
>>1448975
>Вейт, quicksync использует же встроенное видео для обработки
Да, на встроенном GPU, который также на чипе. (Хотя, декодирование, как пишут, может быть и отдельным блоком: http://www.anandtech.com/show/4083/the-sandy-bridge-review-intel-core-i7-2600k-i5-2500k-core-i3-2100-tested/8 )
>Может там какие-то алгоритмы в процессор зашиты?
Формат (или его основные ресурсоёмкие примитивы) поддерживается аппаратно, так что, грубо говоря, да. У тебя, допустим, библиотека аппаратного энкодера предоставляет функцию encode_h264_frame, из которой motion esimation/entropy coding прям зашиты в железку.
>Это тоже на quicksync завязано?
Да, как я понял. И для VP9 только декодирование.
>>1448981
>Так однострочник для спермы есть или нет?
Это он и есть. Для повершелла.
Вопрос ньюфага. Можете скинуть гайд по грабу потокового видео через ffmpeg?
На Твиче пару месяцев назад сменили систему водов, старые способы по скачке видео не работают. Ранее с ffmpeg не работал, но слышал, что он хорошо умеет в такие вещи.
На Твиче пару месяцев назад сменили систему водов, старые способы по скачке видео не работают. Ранее с ffmpeg не работал, но слышал, что он хорошо умеет в такие вещи.
537 Кб, 1266x613
>>1449060
Только что проверил, всё через youtube-dl скачивается. И без лишних пережатий, стрим напрямую копирует.
Я ебал этот идиотский спам-лист, кстати. Реальный спам никто не чистит >>1438476 >>1439840 , а какую-то хуйню, из-за которой половина сообщений с копипастой из консоли не постится, используют. Охуеть свободное общение.
Только что проверил, всё через youtube-dl скачивается. И без лишних пережатий, стрим напрямую копирует.
Я ебал этот идиотский спам-лист, кстати. Реальный спам никто не чистит >>1438476 >>1439840 , а какую-то хуйню, из-за которой половина сообщений с копипастой из консоли не постится, используют. Охуеть свободное общение.
>>1449051
Спасибо. Жаль только он не пишет отрезки времени для ключевых кадров. Просто число не слишком полезно.
>Это он и есть. Для повершелла.
Спасибо. Жаль только он не пишет отрезки времени для ключевых кадров. Просто число не слишком полезно.
>>1449074
Блин, не отрезки времени, а просто время, спать уже пора.
Блин, не отрезки времени, а просто время, спать уже пора.
>>1449074
ffprobe -loglevel quiet -show_frames -select_streams v -of compact file.webm | Select-String -Pattern key_frame=1
В поле pkt_pts_time — время в секундах. Или в файл весь вывод сохранить и по Ctrl+F смотреть. Или через webm_info. Или mkvinfo -v -v -v. Вариантов куча.
ffprobe -loglevel quiet -show_frames -select_streams v -of compact file.webm | Select-String -Pattern key_frame=1
В поле pkt_pts_time — время в секундах. Или в файл весь вывод сохранить и по Ctrl+F смотреть. Или через webm_info. Или mkvinfo -v -v -v. Вариантов куча.
А как сейчас vp9 относится к черным полоскам? Есть смысл кропать для экономии размера?
>>1449093
Полосы динамически-плавающие, если кропать по самой широкой видео чутка потеряется, по самой узкой они появляться будут. Думаешь так менее уродливо?
Полосы динамически-плавающие, если кропать по самой широкой видео чутка потеряется, по самой узкой они появляться будут. Думаешь так менее уродливо?
>>1449070
А вот у меня нет. Делаю как этот http://www.youtube.com/watch?v=8iMxJ52o-bI
Возврат от сервера. HTTP error 400 Bad Request
Исходный вод: http://www.twitch.tv/headstrong1290/v/21249108.
А вот у меня нет. Делаю как этот http://www.youtube.com/watch?v=8iMxJ52o-bI
Возврат от сервера. HTTP error 400 Bad Request
Исходный вод: http://www.twitch.tv/headstrong1290/v/21249108.
>>1449097
Хуярь pan & scan, ололо:
https://www.youtube.com/watch?v=gwsvewJ4HTo
Ну а так-то похуй, конечно.
>>1449103
У меня и этот скачивает. Проверяй версию youtube-dl (youtube-dl --version). Должна быть 2015.11.01.
Хуярь pan & scan, ололо:
https://www.youtube.com/watch?v=gwsvewJ4HTo
Ну а так-то похуй, конечно.
>>1449103
У меня и этот скачивает. Проверяй версию youtube-dl (youtube-dl --version). Должна быть 2015.11.01.
>>1449088
И ещё раз спасибо.
И ещё раз спасибо.
>>1449106
Нашёл косяк, пошла загрузка, спасибо. Не могу только настроить старт с начала видео. Приходится выставлять -ss 00:00:01. Как нужно прописывать?
Нашёл косяк, пошла загрузка, спасибо. Не могу только настроить старт с начала видео. Приходится выставлять -ss 00:00:01. Как нужно прописывать?
Помогите урезать видео. Сейчас framerate 60, а хотелось бы 25 или 30. Качество ведь не должно пострадать, т. к. человек не способен различать больше 24 кадров, верно? Какой командой можно это все сделать?
>>1449226
Вторая часть неверная, с первой частью никак не связана.
>Качество ведь не должно пострадать, т. к. человек не способен различать больше 24 кадров, верно?
Вторая часть неверная, с первой частью никак не связана.
>>1448876
я неправильно изъяснился. Картинки должны не каруселью сменяться в страшном цикле смерти, а как 1,2,3.mp3 - начинаться и заканчиваться на определенных местах видео. Например, первая картинка от начала и до 22%, вторая от 22% до 85%, и третья оттуда до конца. Попробую сделать это по аналогии с указанным тобой способом со звуками позже днем.
Спасибо!
я неправильно изъяснился. Картинки должны не каруселью сменяться в страшном цикле смерти, а как 1,2,3.mp3 - начинаться и заканчиваться на определенных местах видео. Например, первая картинка от начала и до 22%, вторая от 22% до 85%, и третья оттуда до конца. Попробую сделать это по аналогии с указанным тобой способом со звуками позже днем.
Спасибо!
>>1449272
Ты же хочешь фпс понизить, причем тут битрейт? Про битрейт можешь почитать пачкой постов выше, как человеку помогали, походу твой случай.
Ты же хочешь фпс понизить, причем тут битрейт? Про битрейт можешь почитать пачкой постов выше, как человеку помогали, походу твой случай.
5878 Кб, Webm
>>1449226
Качество видео в целом может пострадать. Если видео было 60 фпс, а ты урезал до 25 или было в 25 фпс, а ты интерполировал до 60, то может пропасть синергия звука с видеорядом, например, когда видеоряд подстраивается под ритм музыки.
>Качество ведь не должно пострадать
Качество видео в целом может пострадать. Если видео было 60 фпс, а ты урезал до 25 или было в 25 фпс, а ты интерполировал до 60, то может пропасть синергия звука с видеорядом, например, когда видеоряд подстраивается под ритм музыки.
42 Кб, 776x517
>>1395791 (OP)
Аноны, что за хуйня?
Скачал ffpmeg с официального сайта, а в архиве нет ни папки bin ни хоть одного exe-шника.
Аноны, что за хуйня?
Скачал ffpmeg с официального сайта, а в архиве нет ни папки bin ни хоть одного exe-шника.
51 Кб, 1238x731
>>1449433
Что тут можно неправильно скачать? Написано download FFMPEG. Даже на форчане ссылка именно на эту страницу.
Что тут можно неправильно скачать? Написано download FFMPEG. Даже на форчане ссылка именно на эту страницу.
>>1449449
Спасибо!
Странно, что нигде не даётся ссылка именно на зераное. Вводят людей в заблуждение.
http://ffmpeg.zeranoe.com/builds/
Спасибо!
Странно, что нигде не даётся ссылка именно на зераное. Вводят людей в заблуждение.
http://ffmpeg.zeranoe.com/builds/
>>1449444
https://codeload.github.com/rdp/ffmpeg-windows-build-helpers/zip/master
Отсюда качай @ распаковывай в C:\ @ батник запускай native_build/build_locally_XXX.bat
и у тебя будет свой пропердоленный ffmpeg с поддержкой аппаратного кодирования
https://github.com/rdp/ffmpeg-windows-build-helpers
https://codeload.github.com/rdp/ffmpeg-windows-build-helpers/zip/master
Отсюда качай @ распаковывай в C:\ @ батник запускай native_build/build_locally_XXX.bat
и у тебя будет свой пропердоленный ffmpeg с поддержкой аппаратного кодирования
https://github.com/rdp/ffmpeg-windows-build-helpers
>>1395791 (OP)
Есть ли что-нибудь быстрее libvpx-vp9 ffmpeg'а для vp9? Находил новости какой-то кодек ffvp9 от их команды, но на деле его нигде нет. Или может есть что-то быстрее самого ffmpeg'а?
Есть ли что-нибудь быстрее libvpx-vp9 ffmpeg'а для vp9? Находил новости какой-то кодек ffvp9 от их команды, но на деле его нигде нет. Или может есть что-то быстрее самого ffmpeg'а?
>>1449457
А с какого фига неофициальные билды от левого чувака должны быть на первом месте? Основное, что даёт их проект — исходники. Как это превратить в бинарь уже дело десятое. При том, что нет единственно правильного способа сделать бинарь, т.к. фич очень много и сборщики их все не включают.
>>1449483
ffvp9 это декодер. Из альтернативных энкодеров только это http://www.webmproject.org/hardware/vp9/bige/ вроде бы есть. А так, от ffmpeg, libav или ещё какой прослойки, кодирование не зависит абсолютно. Всё, что они делают, — декодируют исходное видео и покадрово скармливают libvpx.
А с какого фига неофициальные билды от левого чувака должны быть на первом месте? Основное, что даёт их проект — исходники. Как это превратить в бинарь уже дело десятое. При том, что нет единственно правильного способа сделать бинарь, т.к. фич очень много и сборщики их все не включают.
>>1449483
ffvp9 это декодер. Из альтернативных энкодеров только это http://www.webmproject.org/hardware/vp9/bige/ вроде бы есть. А так, от ffmpeg, libav или ещё какой прослойки, кодирование не зависит абсолютно. Всё, что они делают, — декодируют исходное видео и покадрово скармливают libvpx.
>>1449501
Т.е. можно не надеяться, что в ближайшее время появится энкодер быстрее нынешнего?
Т.е. можно не надеяться, что в ближайшее время появится энкодер быстрее нынешнего?
>>1449226
Откуда вы вообще берёте этот бред?
24 кадра в секунду — примерный порог, на котором мозг начинает делать интерполяцию движения между кадрами, в результате чего они воспринимаются как непрерывное движение. И это значение зависит от многих факторов — психического состояния зрителя, характера анимации, размера и расстояния до экрана.
Чем больше в видеоряде частота кадров, тем легче он воспринимается и тем плавнее кажется картинка. Например, с использованием чересстрочности в аналоговом эфирном телевидении показывают 50 кадров в секунду.
Для смены частоты кадров на указанную постоянную без воздействия на скорость воспроизведения видео ffmpeg имеет два фильтра: fps и framerate. Первый выкидывает или дублирует кадры, второй вместо дублирования делает интерполяцию.
>>1449457
А может, лучше на пакет для debian sid дать ссылку? Или на ебилд для gentoo.
Хочешь использовать продвинутые инструменты —
не будь умственно отсталым. В противном случае пользуйся адекватным твоим способностям софтом.
>>1449483
ffvp9 входит в состав ffmpeg, см. ffmpeg -codecs.
Но это только декодер.
> человек не способен различать больше 24 кадров
Откуда вы вообще берёте этот бред?
24 кадра в секунду — примерный порог, на котором мозг начинает делать интерполяцию движения между кадрами, в результате чего они воспринимаются как непрерывное движение. И это значение зависит от многих факторов — психического состояния зрителя, характера анимации, размера и расстояния до экрана.
Чем больше в видеоряде частота кадров, тем легче он воспринимается и тем плавнее кажется картинка. Например, с использованием чересстрочности в аналоговом эфирном телевидении показывают 50 кадров в секунду.
Для смены частоты кадров на указанную постоянную без воздействия на скорость воспроизведения видео ffmpeg имеет два фильтра: fps и framerate. Первый выкидывает или дублирует кадры, второй вместо дублирования делает интерполяцию.
>>1449457
> Странно, что нигде не даётся ссылка именно на зераное.
А может, лучше на пакет для debian sid дать ссылку? Или на ебилд для gentoo.
Хочешь использовать продвинутые инструменты —
не будь умственно отсталым. В противном случае пользуйся адекватным твоим способностям софтом.
>>1449483
ffvp9 входит в состав ffmpeg, см. ffmpeg -codecs.
Но это только декодер.
>>1449511
Смотрел уже, нету его там. Да и если декодер, то он мне не нужон.
>ffvp9 входит в состав ffmpeg, см. ffmpeg -codecs.
>Но это только декодер.
Смотрел уже, нету его там. Да и если декодер, то он мне не нужон.
>>1449512
Ну вп9 нужен гуглу, они и запилили этот слоупочный энкодер. Кроме них никто быстрый не сделает (т.к. похуй), т.ч. остается ждать когда повысят производительность в libvpx.
Ну вп9 нужен гуглу, они и запилили этот слоупочный энкодер. Кроме них никто быстрый не сделает (т.к. похуй), т.ч. остается ждать когда повысят производительность в libvpx.
>>1449523
decoders: vp9 ← вот это оно и есть.
libvpx-vp9 тоже для декодирования можно использовать. Особенно раньше, когда ffvp9 не умел дополнительные профили.
>нету его там
decoders: vp9 ← вот это оно и есть.
libvpx-vp9 тоже для декодирования можно использовать. Особенно раньше, когда ffvp9 не умел дополнительные профили.
1.png, 2.png
ffmpeg -f image2 -i %d.png video.mpg
ffmpeg -i video.mpg -filter:v "setpts=100*PTS" video2.mpg
и второе, удлиненное видео, получается четырехсекундным показом первой пикчи. Где вторая?
ffmpeg -f image2 -i %d.png video.mpg
ffmpeg -i video.mpg -filter:v "setpts=100*PTS" video2.mpg
и второе, удлиненное видео, получается четырехсекундным показом первой пикчи. Где вторая?
>>1449544
Нахуя ты вообще делаешь промежуточный файл?
Появляется на 1/25 секунды, наверно. Timebase и pkt_duration-то ты не менял.
Нахуя ты вообще делаешь промежуточный файл?
> Где вторая?
Появляется на 1/25 секунды, наверно. Timebase и pkt_duration-то ты не менял.
Лучше юзать -force_key_frames expr:gte(t,n_forced*5) или -g 100-150? Вставьте в вики более правильный вариант.
>>1449549
только учусь, хочу чтобы на каждом шаге было что-то готовое и работающее
что это такое и как поменять?
только учусь, хочу чтобы на каждом шаге было что-то готовое и работающее
>Timebase и pkt_duration-то ты не менял.
что это такое и как поменять?
Как повернуть видео без потери качества?
пробовал -vf "transpose=x", видео на выходе в 3 раза меньше весит
пробовал -vf "transpose=x", видео на выходе в 3 раза меньше весит
>>1449555
Тогда не сохраняй промежуточные результаты в lossy-форматы хотя бы. Используй кодеки ffvhuff и flac, например.
Timebase — длительность единицы PTS, pkt_duration — время отображения кадра.
Укажи -r на входе с картинками. Если нужно меньше 1fps, то можешь продублировать второй кадр, это на правах костыля.
> только учусь, хочу чтобы на каждом шаге было что-то готовое и работающее
Тогда не сохраняй промежуточные результаты в lossy-форматы хотя бы. Используй кодеки ffvhuff и flac, например.
> что это такое
Timebase — длительность единицы PTS, pkt_duration — время отображения кадра.
> и как поменять?
Укажи -r на входе с картинками. Если нужно меньше 1fps, то можешь продублировать второй кадр, это на правах костыля.
>>1449571
Никак. Видео — это не жпег, и ориентации камеры в его заголовках нет. Фильтр transpose требует перекодирования.
Никак. Видео — это не жпег, и ориентации камеры в его заголовках нет. Фильтр transpose требует перекодирования.
>>1449573
что значит "продублировать второй кадр"?
и если кадров больше двух, и мне нужна скорость меньше 1fps, то будет ли это все еще работать?
что значит "продублировать второй кадр"?
и если кадров больше двух, и мне нужна скорость меньше 1fps, то будет ли это все еще работать?
>>1449579
Вот это пробовал
http://superuser.com/questions/578321/how-to-flip-a-video-180-vertical-upside-down-with-ffmpeg/
ffmpeg скочал 12 октября
в metadata написано rotate: 90
прописал такую команду:
ffmpeg -i in.mp4 -c:a copy out.mp4
видео опять в 3 раза меньше.
>Фильтр transpose требует перекодирова
Вот это пробовал
http://superuser.com/questions/578321/how-to-flip-a-video-180-vertical-upside-down-with-ffmpeg/
>You need a build that includes commit 1630224, from 2 May 2015, to be able to use the autorotation feature.
ffmpeg скочал 12 октября
в metadata написано rotate: 90
прописал такую команду:
ffmpeg -i in.mp4 -c:a copy out.mp4
видео опять в 3 раза меньше.
>>1449597
Смотри: проблема в том, что длительность показа кадра фильтром setpts не меняется. Результат его применения — «прерывистый» видеоряд, который всеми плеерами (вроде) воспроизводится тем не менее непрерывно — отсутствие кадра для воспроизведения не приводит к очистке картинки, но к последнему кадру это не относится.
Предложенный костыль — добавить ещё кадр в конец.
Ещё вариант — попробовать поколдовать с timebase (фильтр settb). Так, оставив PTS и pkt_duration (который тоже исчисляется в PTS) без изменений, тоже можно изменить скорость воспроизведения.
Смотри: проблема в том, что длительность показа кадра фильтром setpts не меняется. Результат его применения — «прерывистый» видеоряд, который всеми плеерами (вроде) воспроизводится тем не менее непрерывно — отсутствие кадра для воспроизведения не приводит к очистке картинки, но к последнему кадру это не относится.
Предложенный костыль — добавить ещё кадр в конец.
Ещё вариант — попробовать поколдовать с timebase (фильтр settb). Так, оставив PTS и pkt_duration (который тоже исчисляется в PTS) без изменений, тоже можно изменить скорость воспроизведения.
>>1449635
Есть, есть. И mpv, судя по ману, даже поддерживает. Но то ли я тег другой, то ли сломано, у меня не получается почему-то.
https://stackoverflow.com/questions/15335073/can-i-set-rotation-field-for-a-video-stream-with-ffmpeg
Есть, есть. И mpv, судя по ману, даже поддерживает. Но то ли я тег другой, то ли сломано, у меня не получается почему-то.
https://stackoverflow.com/questions/15335073/can-i-set-rotation-field-for-a-video-stream-with-ffmpeg
>>1449635
Даа. Значит, нужно найти способы его изменения и софт, который это поддерживает.
Даа. Значит, нужно найти способы его изменения и софт, который это поддерживает.
>>1449638
видео в таком случае остается повернутым.
видео в таком случае остается повернутым.
>>1449580
Нужно форсить ффмпег делать кейфреймы. Иногда он их не делает. Я знаю эти два способа. Какой лучше?
Нужно форсить ффмпег делать кейфреймы. Иногда он их не делает. Я знаю эти два способа. Какой лучше?
>>1449640
Please note that this does not actually rotate the video. It just sets the rotation flag, which causes some players to show it in a rotated way
>у меня не получается почему-то
Please note that this does not actually rotate the video. It just sets the rotation flag, which causes some players to show it in a rotated way
>>1449652
Ну так у mpv заявлено, что поддерживается.
Ну так у mpv заявлено, что поддерживается.
>>1449594
Ну вот ты и поправь. Я не ебу как там в гитхабе всё делается, ещё наверно и регаться надо, палить свой ник.
Ну вот ты и поправь. Я не ебу как там в гитхабе всё делается, ещё наверно и регаться надо, палить свой ник.
>>1449651
Зачем?
И не ffmpeg, а libvpx.
Потому что находит общую информацию между сценами, наверно.
Зависит от материала и задачи. На этот вопрос не может быть однозначного ответа.
> Нужно форсить ффмпег делать кейфреймы.
Зачем?
И не ffmpeg, а libvpx.
> Иногда он их не делает.
Потому что находит общую информацию между сценами, наверно.
> Я знаю эти два способа. Какой лучше?
Зависит от материала и задачи. На этот вопрос не может быть однозначного ответа.
>>1449544
делаю вот так
ffmpeg -framerate 1/5 -i %d.png -c:v libx264 -vf "scale=trunc(iw/2)2:trunc(ih/2)2" -r 1 out.mp4
на второй пикче видео просто дропается
и вторая пикча это та же самая первая, только в гимпе на ней красной кистью "2" написано(думал, может из-за разных размеров и так далее, но нет)
делаю вот так
ffmpeg -framerate 1/5 -i %d.png -c:v libx264 -vf "scale=trunc(iw/2)2:trunc(ih/2)2" -r 1 out.mp4
на второй пикче видео просто дропается
и вторая пикча это та же самая первая, только в гимпе на ней красной кистью "2" написано(думал, может из-за разных размеров и так далее, но нет)
>>1449668
git clone https://github.com/pituz/webm-thread.wiki.git
cd webm-thread.wiki
vim
git commit -a
git format-patch --to=pituz@mt2014.com --stdout origin | git imap-send
>>1449640
С mp4 получилось, а в mkv сказали что не поддерживается.
git clone https://github.com/pituz/webm-thread.wiki.git
cd webm-thread.wiki
vim
git commit -a
git format-patch --to=pituz@mt2014.com --stdout origin | git imap-send
>>1449640
С mp4 получилось, а в mkv сказали что не поддерживается.
>>1449687
а если -r 1 аутпута поменять на -r 2, то вторая пикча в конце мигает только
и еще непонятно, почему при -r 1 аутпута длина видео в vlc показывается 00:06(а дропается на 00:03), а при -r2 становится уже не шесть, а пять секунд, не дропается, и вторая пикча в конце мигает
вообще охуеть какой-то
а если -r 1 аутпута поменять на -r 2, то вторая пикча в конце мигает только
и еще непонятно, почему при -r 1 аутпута длина видео в vlc показывается 00:06(а дропается на 00:03), а при -r2 становится уже не шесть, а пять секунд, не дропается, и вторая пикча в конце мигает
вообще охуеть какой-то
>>1449544
делаю это
ffmpeg -r 1/5 -i d%.png -c:v libx264 -vf "fps=25,format=yuv420p" out.mp4
по вот этим гайдам
https://trac.ffmpeg.org/wiki/Create%20a%20video%20slideshow%20from%20images
http://stackoverflow.com/questions/24961127/ffmpeg-create-video-from-images
в итоге или десять секунд черноты, если не меняю фпс аутпута, или миг второй пикчи в самом конце, если меняю
=(
делаю это
ffmpeg -r 1/5 -i d%.png -c:v libx264 -vf "fps=25,format=yuv420p" out.mp4
по вот этим гайдам
https://trac.ffmpeg.org/wiki/Create%20a%20video%20slideshow%20from%20images
http://stackoverflow.com/questions/24961127/ffmpeg-create-video-from-images
в итоге или десять секунд черноты, если не меняю фпс аутпута, или миг второй пикчи в самом конце, если меняю
=(
>>1449708
Фильтр fps не может в pkt_duration и прекращает дублировать кадры при исчерпании входа.
> ffmpeg -r 1/5 -i d%.png -c:v libx264 -vf "fps=25,format=yuv420p" out.mp4
Фильтр fps не может в pkt_duration и прекращает дублировать кадры при исчерпании входа.
>>1449685
Бля, ффмпег высирает мне вебмки с 1 кейфремом, нихуя он не находит общей информации, какой-то баг видимо. И он у всех это делает, весь анимублядский в этих говновебмках. И да, предлагаю этот параметр использовать по умолчанию, я думаю всем как и мне просто лень будет кодировать, проверять баг, и перекодировывать в случае если он есть. К тому же я даже не знаю минусов этих команд, если они вообще есть, не заметил их. Если не может быть однозначного ответа, значит оба или любой вариант суйте в вики.
Бля, ффмпег высирает мне вебмки с 1 кейфремом, нихуя он не находит общей информации, какой-то баг видимо. И он у всех это делает, весь анимублядский в этих говновебмках. И да, предлагаю этот параметр использовать по умолчанию, я думаю всем как и мне просто лень будет кодировать, проверять баг, и перекодировывать в случае если он есть. К тому же я даже не знаю минусов этих команд, если они вообще есть, не заметил их. Если не может быть однозначного ответа, значит оба или любой вариант суйте в вики.
>>1449736
С чего ты взял? Зафорси кейфрейм там, где ты считаешь что он должен быть, и сравни размер и PSNR результатов.
> нихуя он не находит общей информации
С чего ты взял? Зафорси кейфрейм там, где ты считаешь что он должен быть, и сравни размер и PSNR результатов.
157 Кб, 1366x768
>>1449732
вот так он себя ведет начиная с конца первых пяти секунд
вот так он себя ведет начиная с конца первых пяти секунд
>>1449736
Если размер становится больше, то это минус. В общем-то я согласен, при выигрыше в 0.2 мегабайта, смысла в одном кейфреме на 3 минуты мало. Но 3 минуты сдекодить тоже фигня. Вон в лисе уже ffvp9, который 260 fps на четырёх ядрах на FullHD даёт.
>>1449741
Да было уже сравнение → >>1435105
Ну ты понел.
>К тому же я даже не знаю минусов этих команд
Если размер становится больше, то это минус. В общем-то я согласен, при выигрыше в 0.2 мегабайта, смысла в одном кейфреме на 3 минуты мало. Но 3 минуты сдекодить тоже фигня. Вон в лисе уже ffvp9, который 260 fps на четырёх ядрах на FullHD даёт.
>>1449741
Да было уже сравнение → >>1435105
>PSNR
Ну ты понел.
Вот вебм с 4 кейфремами на 90 секунд https://2ch.hk/b/src/105569197/14464779230730.webm . Кейфремы расположены так : 1 - 0.007000, 2 - 5.846000, 3 - 89.597000, 4 - 89.638000
>>1449756
И теперь эмулируем прыжок в самое неудобную позицию с помощью нормального декодера:
$ time ffmpeg -loglevel quiet -ss 89 -i 14464779230730.webm -frames:v 1 -f null -
ffmpeg -loglevel quiet -ss 89 -i 14464779230730.webm -frames:v 1 -f null - 11.12s user 0.15s system 291% cpu 3.873 total
Всего-то. Для сравнения более вероятный случай:
$ time ffmpeg -loglevel quiet -ss 30 -i 14464779230730.webm -frames:v 1 -f null -
ffmpeg -loglevel quiet -ss 30 -i 14464779230730.webm -frames:v 1 -f null - 2.96s user 0.04s system 270% cpu 1.109 total
Одна секунда. Офигеть как долго.
И теперь эмулируем прыжок в самое неудобную позицию с помощью нормального декодера:
$ time ffmpeg -loglevel quiet -ss 89 -i 14464779230730.webm -frames:v 1 -f null -
ffmpeg -loglevel quiet -ss 89 -i 14464779230730.webm -frames:v 1 -f null - 11.12s user 0.15s system 291% cpu 3.873 total
Всего-то. Для сравнения более вероятный случай:
$ time ffmpeg -loglevel quiet -ss 30 -i 14464779230730.webm -frames:v 1 -f null -
ffmpeg -loglevel quiet -ss 30 -i 14464779230730.webm -frames:v 1 -f null - 2.96s user 0.04s system 270% cpu 1.109 total
Одна секунда. Офигеть как долго.
>>1449768
Говоришь что по утрам в пятницу хуи в жопе не так уж и больно ощущаются? А занять место можно и пораньше.
Говоришь что по утрам в пятницу хуи в жопе не так уж и больно ощущаются? А занять место можно и пораньше.
>>1449773
Ты говоришь так, как будто есть возможность этого избежать. Ты либо теряешь на скорости перемотки, либо в качестве. Что тебе не ясно в понятии «компромисс»?
Ты говоришь так, как будто есть возможность этого избежать. Ты либо теряешь на скорости перемотки, либо в качестве. Что тебе не ясно в понятии «компромисс»?
>>1449780
Я не теряю в качестве из-за 0.3 мб, это очень маленькое число. Кроме того, если бы ффмпег работал нормально, вес был бы больше, а значит я наоборот заставляю его работать правильно, по идее. Предложения компромисса не увидел, 4 кейфрейма это где-то рядом с минимумом, явный перевес в сторону качества которого нет. И почему-то сам ффмпег делает перевес в сторону скорости промотки.
Я не теряю в качестве из-за 0.3 мб, это очень маленькое число. Кроме того, если бы ффмпег работал нормально, вес был бы больше, а значит я наоборот заставляю его работать правильно, по идее. Предложения компромисса не увидел, 4 кейфрейма это где-то рядом с минимумом, явный перевес в сторону качества которого нет. И почему-то сам ффмпег делает перевес в сторону скорости промотки.
>>1449790
Как уже было сказано выше, сравнение некорректно. У файлов размер разный не из-за ключевых кадров, а из-за неточности в работе рейт-контроля. Мне почему-то казалось, что у тебя там CRF. При VBR ты сам указываешь итоговый размер, энкодер не может ослушаться только потому, что у тебя ключевых кадров больше стало.
Где делает? Как?
Это вообще не распарсил.
>Я не теряю в качестве из-за 0.3 мб
Как уже было сказано выше, сравнение некорректно. У файлов размер разный не из-за ключевых кадров, а из-за неточности в работе рейт-контроля. Мне почему-то казалось, что у тебя там CRF. При VBR ты сам указываешь итоговый размер, энкодер не может ослушаться только потому, что у тебя ключевых кадров больше стало.
>И почему-то сам ффмпег делает перевес в сторону скорости промотки
Где делает? Как?
>Кроме того, если бы ффмпег работал нормально, вес был бы больше, а значит я наоборот заставляю его работать правильно, по идее
Это вообще не распарсил.
И я вообще не понимаю сути этих разговоров что туда-то проматывается 1 секунда и типа норм, это баг ффмпега, ну или ещё что-то, какого хуя вы считаете это нормой? Пиздец, расставление кейфреймов - 2 в самом начале, 2 в самом конце, это просто охуенно. Ни разу не похоже на баг.
>>1449799
Я не тот анон что тесты проводил. Меня просто заебало проматывать по 2, а иногда и каких-нибудь 10 секунд. Если это нормально, значит у меня проблемы с пониманием что нормально или нет. Я уебал спать.
Я не тот анон что тесты проводил. Меня просто заебало проматывать по 2, а иногда и каких-нибудь 10 секунд. Если это нормально, значит у меня проблемы с пониманием что нормально или нет. Я уебал спать.
3993 Кб, Webm
>>1449799
Поподробнее. Как так сделать? Качество не хуже будет? Если такое есть, то почему это скрывают и простые анончики вынуждены кодировать через crf?
>При VBR ты сам указываешь итоговый размер
Поподробнее. Как так сделать? Качество не хуже будет? Если такое есть, то почему это скрывают и простые анончики вынуждены кодировать через crf?
>>1449806
Ну, для начала, 0.02bpp это изначально дикий изврат (2 минуты HD для 8МБ лимита: 8×1024×1024×8/(1280×720×24×120)).
В том же аниму, если ты посмотришь, в 3.5 раза больше — около 0.09 (24 минуты HD в 339 мегабайт: 339×1024×1024×8/(1280×720×24×(23×60+42))). При том, что в больших файлах намного больше возможностей скостить битрейт.
>Если это нормально, значит у меня проблемы с пониманием что нормально или нет
Ну, для начала, 0.02bpp это изначально дикий изврат (2 минуты HD для 8МБ лимита: 8×1024×1024×8/(1280×720×24×120)).
В том же аниму, если ты посмотришь, в 3.5 раза больше — около 0.09 (24 минуты HD в 339 мегабайт: 339×1024×1024×8/(1280×720×24×(23×60+42))). При том, что в больших файлах намного больше возможностей скостить битрейт.
>>1449832
Если ты пишешь -b:v и число ты можешь рассчитать битрейт и итоговый размер файла. Но качество будет, вроде как, хуже, чем если ты подберешь нужный -crf при -b:v 0
Если ты пишешь -b:v и число ты можешь рассчитать битрейт и итоговый размер файла. Но качество будет, вроде как, хуже, чем если ты подберешь нужный -crf при -b:v 0
>>1449836
А я когда пишу -b:v и число, то битрейт получается на +10-15% больше чем указанный, и видео не влазит в размер, при этом суть vbr'a это уменьшать размер конечного видео путём уменьшения битрейта на малодинамичных сценах видео, чего на деле почти никогда не происходит. В общем vbr - кривое говно без задач. Поэтому я пишу -b:v xxxK -vbr off
А я когда пишу -b:v и число, то битрейт получается на +10-15% больше чем указанный, и видео не влазит в размер, при этом суть vbr'a это уменьшать размер конечного видео путём уменьшения битрейта на малодинамичных сценах видео, чего на деле почти никогда не происходит. В общем vbr - кривое говно без задач. Поэтому я пишу -b:v xxxK -vbr off
>>1450066
И выключаешь таким образом VBR у libopus? Ну ты крут.
Вообще, есть специальные настройки -undershoot-pct и -overshoot-pct, которые контролируют пределы перерасхода/недорасхода битрейта. Ну и -qmin/-qmax помогают. Так-то да, VBR в libvpx хреновый.
И выключаешь таким образом VBR у libopus? Ну ты крут.
Вообще, есть специальные настройки -undershoot-pct и -overshoot-pct, которые контролируют пределы перерасхода/недорасхода битрейта. Ну и -qmin/-qmax помогают. Так-то да, VBR в libvpx хреновый.
>>1450071
Да и в аудио вбр тоже выключаю. Как я понял реальное преимущество опуса это то, что у него почти отсутствуют задержки и можно сразу накатывать видеоряд без временной корректировки, поэтому использовать нужно только libopus и считать битрейт самому вручную. Аудио сжимаю в 96 кбит из оригинальных каких-нибудь 128или выше кбит, разницы в звучании почти нет. Если включать вбр в аудио то может происходить заметное ухудшение качества если скажем в кодируемом фильме будет какой-нибудь тихий диалог актёров а остальные сцены будут громкими. И ещё раз, сам вбр работает как-то криво и делает битрейт большим чем нужно, пробовал указывать -maxrate xxxK — не помогает. И ещё я не совсем понял какие настоящие улучшения у vp9 перед vp8, пишут что вп9 лучше кодирует большое >2K разрешение, и что он вроде как лучше заточен под vbr (который работает криво). А ещё я не совсем понял зачем нужно двухпроходное кодирование, по идее оно нужно чтобы более точно вычислять динамичность сцены и делать записи в логфайл для последующего кодирования с vbr, соответственно если вбр отключать то такая необходимость пропадает, ещё пишут что если не делать двух проходов то иногда изображение может дёргать и происходить ухудшении качества — ни того ни другого лично мною замечено не было, выходить что два прохода тоже не нужны.
Да и в аудио вбр тоже выключаю. Как я понял реальное преимущество опуса это то, что у него почти отсутствуют задержки и можно сразу накатывать видеоряд без временной корректировки, поэтому использовать нужно только libopus и считать битрейт самому вручную. Аудио сжимаю в 96 кбит из оригинальных каких-нибудь 128или выше кбит, разницы в звучании почти нет. Если включать вбр в аудио то может происходить заметное ухудшение качества если скажем в кодируемом фильме будет какой-нибудь тихий диалог актёров а остальные сцены будут громкими. И ещё раз, сам вбр работает как-то криво и делает битрейт большим чем нужно, пробовал указывать -maxrate xxxK — не помогает. И ещё я не совсем понял какие настоящие улучшения у vp9 перед vp8, пишут что вп9 лучше кодирует большое >2K разрешение, и что он вроде как лучше заточен под vbr (который работает криво). А ещё я не совсем понял зачем нужно двухпроходное кодирование, по идее оно нужно чтобы более точно вычислять динамичность сцены и делать записи в логфайл для последующего кодирования с vbr, соответственно если вбр отключать то такая необходимость пропадает, ещё пишут что если не делать двух проходов то иногда изображение может дёргать и происходить ухудшении качества — ни того ни другого лично мною замечено не было, выходить что два прохода тоже не нужны.
Добавлю, пока что на сегодняшний момент, использовать VBR нужно: где, скажем сначала играет музыка и идёт видео, потом музыка выключается и начинается к примеру презентация сменяющихся картинок. То есть вбр нужен для какого-нибудь монтажа, а для клипов/фильмов вбр не нужен так как там в 95% случаев никогда не будет статичных сцен чтобы получить выигрыш в их сжатии.
>>1395791 (OP)
Ваш ffmpeg такой замечательный, может, он и flac сможет по cue нарезать?
Ваш ffmpeg такой замечательный, может, он и flac сможет по cue нарезать?
>>1450626
прост пиши правильный ввод
прост пиши правильный ввод
>>1450621
Срыв покровов, ffmpeg - новый emacs
Срыв покровов, ffmpeg - новый emacs
5458 Кб, Webm
>>1450601
А как проходил сравнение качества? Ты сравнивал файлы одинакового размера?
> ни того ни другого лично мною замечено не было
А как проходил сравнение качества? Ты сравнивал файлы одинакового размера?
>>1450621
Было б что писать: https://gist.github.com/bancek/b37b780292540ed2d17d
Только зачем, если уже есть shnsplit? Да и зачем вообще image+cue нарезать? Навеевает 2008-ым, когда не было нормальных плееров под линь и пердолики тратили кучу времени на перевод раздачи из одного формата в другой, т.к. все нарезалки неидеальны и что-нибудь, да не так сделают.
Было б что писать: https://gist.github.com/bancek/b37b780292540ed2d17d
Только зачем, если уже есть shnsplit? Да и зачем вообще image+cue нарезать? Навеевает 2008-ым, когда не было нормальных плееров под линь и пердолики тратили кучу времени на перевод раздачи из одного формата в другой, т.к. все нарезалки неидеальны и что-нибудь, да не так сделают.
>>1450601
Уже из-за этого можно было дальше не читать.
Это имеет значение исключительно для передачи звука в реальном времени.
Нет у libopus'а таких крутилок. Все передаваемые ffmpeg'ом параметры можно посмотреть в исходниках: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libopusenc.c#L105
Список параметров самой библиотеки можно посмотреть здесь: https://www.opus-codec.org/docs/html_api-1.1.0/group__opus__encoderctls.html
Допустим, хотя я не замечал. Реквестирую сравнение — исходник и два варианта сжатия, с VBR и без, будем слушать. Хотя из дальнейшего содержимого поста мне кажется, что ничего толкового мы не услышим.
Ну это вообще пушка. Хотя, если сравнение производилось с идиотскими параметрами, могло и не такое получиться.
Все эффективные видеокодеки работают в режиме VBR. С CBR получается либо говно с артефактами на каждом шагу, либо лютый перерасход битрейта.3
> Microsoft Windows XP
Уже из-за этого можно было дальше не читать.
> Как я понял реальное преимущество опуса это то, что у него почти отсутствуют задержки и можно сразу накатывать видеоряд без временной корректировки
Это имеет значение исключительно для передачи звука в реальном времени.
> пробовал указывать -maxrate xxxK — не помогает
Нет у libopus'а таких крутилок. Все передаваемые ffmpeg'ом параметры можно посмотреть в исходниках: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libopusenc.c#L105
Список параметров самой библиотеки можно посмотреть здесь: https://www.opus-codec.org/docs/html_api-1.1.0/group__opus__encoderctls.html
> вбр в аудио то может происходить заметное ухудшение качества если скажем в кодируемом фильме будет какой-нибудь тихий диалог актёров а остальные сцены будут громкими
Допустим, хотя я не замечал. Реквестирую сравнение — исходник и два варианта сжатия, с VBR и без, будем слушать. Хотя из дальнейшего содержимого поста мне кажется, что ничего толкового мы не услышим.
> И ещё я не совсем понял какие настоящие улучшения у vp9 перед vp8
Ну это вообще пушка. Хотя, если сравнение производилось с идиотскими параметрами, могло и не такое получиться.
> и что он вроде как лучше заточен под vbr (который работает криво)
Все эффективные видеокодеки работают в режиме VBR. С CBR получается либо говно с артефактами на каждом шагу, либо лютый перерасход битрейта.3
Поясните нубу, как по-быстрому сконвертить из mkv 720p в webm без потери качества?
Пишу -quality best, всё равно жуткие артефакты.
Пишу -quality best, всё равно жуткие артефакты.
>>1451060
Ничего не изменилось. Может я как-то не так пишу аргументы?
ffmpeg -i in.mkv -ss starttime -to finishtime out.webm -lossless 1
Ничего не изменилось. Может я как-то не так пишу аргументы?
ffmpeg -i in.mkv -ss starttime -to finishtime out.webm -lossless 1
>>1450651
Ну они не были не совсем одинаковых размеров, просто перекодированы из одного источника, ничего такого дефектного не было.
>>1450721
Пердтушка спросить забыли.
А почему у меня тогда звук от видеоряда запаздывает, а если выбирать опус то всё норм?
Ну значит я что-то напутал, какой там тогда параметр ограничивающий битрейт у опуса?
Ну хуй знает, вот ты и сделай сравнение.
Да вроде всё норм получается. Кстати артефакты у меня и правду появились >>1447315 и пару раз не только первые секунды а вообще всё распидорашивало, но там был как раз vb9 с включённым vbr, только я пытался это запихнуть в avi.
Ну они не были не совсем одинаковых размеров, просто перекодированы из одного источника, ничего такого дефектного не было.
>>1450721
>Уже из-за этого можно было дальше не читать.
Пердтушка спросить забыли.
>Это имеет значение исключительно для передачи звука в реальном времени.
А почему у меня тогда звук от видеоряда запаздывает, а если выбирать опус то всё норм?
>Нет у libopus'а таких крутилок. Все передаваемые ffmpeg'ом параметры можно посмотреть в исходниках:
Ну значит я что-то напутал, какой там тогда параметр ограничивающий битрейт у опуса?
>Допустим, хотя я не замечал.
Ну хуй знает, вот ты и сделай сравнение.
>С CBR получается либо говно с артефактами на каждом шагу, либо лютый перерасход битрейта
Да вроде всё норм получается. Кстати артефакты у меня и правду появились >>1447315 и пару раз не только первые секунды а вообще всё распидорашивало, но там был как раз vb9 с включённым vbr, только я пытался это запихнуть в avi.
72 Кб, Webm
>>1451147
Тебе не было чем заняться и ты решил втереть нам какую-то дичь?
Тебе не было чем заняться и ты решил втереть нам какую-то дичь?
983 Кб, Webm
>>1451688
в чем проблема со второй webm? почему нет превью? Первую я просто обрезал из видео сразу. Вторую разобрал по кадрам, склеил в webm, приклеил звук. Пришлось это сделать так-как звук в оригинале не воспроизводился,звуковую дорожку я в стороннем редакторе вырезал. Где я накосячил?
в чем проблема со второй webm? почему нет превью? Первую я просто обрезал из видео сразу. Вторую разобрал по кадрам, склеил в webm, приклеил звук. Пришлось это сделать так-как звук в оригинале не воспроизводился,звуковую дорожку я в стороннем редакторе вырезал. Где я накосячил?
где почитать про эту штуку "%d" в ffmpeg, как она называется, что ею можно перебирать, что нельзя и так далее
>>1451770
не, ну а как именно она называется, блять, что именно на официальном сайте искать
не, ну а как именно она называется, блять, что именно на официальном сайте искать
>>1451770
ну вот, например, могу ли я брать каждый второй файл? или, могу ли я использовать его в квадратных скобочках стрим специфаера - [0:v].
[%d:v] - вот так можно? а как можно? где почитать?
ну вот, например, могу ли я брать каждый второй файл? или, могу ли я использовать его в квадратных скобочках стрим специфаера - [0:v].
[%d:v] - вот так можно? а как можно? где почитать?
ffmpeg умеет выполнять команду из файла?
>>1451807
man 3 printf
Это знать надо! А вообще: https://ffmpeg.org/ffmpeg-formats.html#image2-1
>где почитать?
man 3 printf
Это знать надо! А вообще: https://ffmpeg.org/ffmpeg-formats.html#image2-1
>>1451827
хорошо, спрошу по-другому. внутри команды ffmpeg можно задавать циклы?
хорошо, спрошу по-другому. внутри команды ffmpeg можно задавать циклы?
725 Кб, Webm
test
723 Кб, Webm
again
Уважаемые, подскажите, оно умеет не в один поток кодировать? Нахуя мне гейсемь-то, если 2.5 минуты видео кодируются целую вечность…
>>1451998
Ну не стукай, расскажи лучше, как заставить кодировать двумя ядрами хотя бы? Или это ебать сложный не параллелящися процесс?
Ну не стукай, расскажи лучше, как заставить кодировать двумя ядрами хотя бы? Или это ебать сложный не параллелящися процесс?
>>1452015
-threads 4
В шапке крупными буквами где-то написано, есть еще 2 параметра, но они по умолчанию стоят на 4 точно потока, так что ставь -threads 4 и моли Аллаха что бы libvpx-vp9 хоть что-то распаралелел. На 8 потоков прочти шапку.
-threads 4
В шапке крупными буквами где-то написано, есть еще 2 параметра, но они по умолчанию стоят на 4 точно потока, так что ставь -threads 4 и моли Аллаха что бы libvpx-vp9 хоть что-то распаралелел. На 8 потоков прочти шапку.
>>1452015
А там последний ффмпег по-умолчанию уже разве не параллелит? Тогда -frame-parallel 0 -threads 4 -tile-columns 2, например.
А там последний ффмпег по-умолчанию уже разве не параллелит? Тогда -frame-parallel 0 -threads 4 -tile-columns 2, например.
>>1452095
Да. Я не представляю, откуда ты взял там "2". Единичку еще можно написать.
Да. Я не представляю, откуда ты взял там "2". Единичку еще можно написать.
>>1452055
Ну че ты сразу-то так не мог, спасибо!
Ну че ты сразу-то так не мог, спасибо!
>>1452209
Cпасибо, мил человек, теперь всё заебца.
Cпасибо, мил человек, теперь всё заебца.
>>1452341
Сабы не прилепились, однако!
Сабы не прилепились, однако!
>>1451830
Веб М.
Веб М.
>>1449833
Извини, я не знаю что такое bpp, и не горю желанием узнавать. Ответь на несколько вопросов. Ты считаешь это багом? Если да, может куда-то сообщить об этом чтобы разработчики ффмпега узнали? Второй - ты считаешь стоит прописывать -g каждый раз тем кто кодит вебмки и вбрасывает в анимублядский? Моя позиция - я считаю это багом, несмотря на то что нихрена не знаю про ффмпег. И я считаю что -g стоит прописывать, я уже некоторое время это делаю и не заметил потери в качестве, возможно стоит сделать тесты, но мне как-то лень. Думаю, потерь в качестве в анимублядском никто вообще не заметит никогда, а вот медленную перемотку - ещё как.
Извини, я не знаю что такое bpp, и не горю желанием узнавать. Ответь на несколько вопросов. Ты считаешь это багом? Если да, может куда-то сообщить об этом чтобы разработчики ффмпега узнали? Второй - ты считаешь стоит прописывать -g каждый раз тем кто кодит вебмки и вбрасывает в анимублядский? Моя позиция - я считаю это багом, несмотря на то что нихрена не знаю про ффмпег. И я считаю что -g стоит прописывать, я уже некоторое время это делаю и не заметил потери в качестве, возможно стоит сделать тесты, но мне как-то лень. Думаю, потерь в качестве в анимублядском никто вообще не заметит никогда, а вот медленную перемотку - ещё как.
есть видеофайл, в котором есть как аудио, так и видеодорожка. хочу набросить ему аудиофрагмент на определенное время. как это сделать?
то есть, сохраняются существующуе аудио и видеотреки, но аудиотрек модифицируется путем добавление и смешивания поверх его небольшой части другого трека
то есть, сохраняются существующуе аудио и видеотреки, но аудиотрек модифицируется путем добавление и смешивания поверх его небольшой части другого трека
>>1452676
Это не баг ffmpeg, это особенность libvpx. Пока никто не приводил нормальные тесты, насколько эта особенность дурная.
Я просто не понимаю твой проблемы. Тебе ж уже написали как добавить информацию в вики без регистрации и смс, а ты всё равно чем-то не доволен.
Это не баг ffmpeg, это особенность libvpx. Пока никто не приводил нормальные тесты, насколько эта особенность дурная.
Я просто не понимаю твой проблемы. Тебе ж уже написали как добавить информацию в вики без регистрации и смс, а ты всё равно чем-то не доволен.
>>1452769
Я просто уточню - мы говорим про расставление ключевых кадров 2 в начале и 2 в конце?
>Это не баг ffmpeg, это особенность libvpx
Я просто уточню - мы говорим про расставление ключевых кадров 2 в начале и 2 в конце?
>>1452772
Тебе объяснить как из исходного файла получается вебм, как связаны ffmpeg и libvpx, что такое контейнер, формат, кодек, библиотека?
Тебе объяснить как из исходного файла получается вебм, как связаны ffmpeg и libvpx, что такое контейнер, формат, кодек, библиотека?
>>1452821
Нет, просто ответить да/нет.
Нет, просто ответить да/нет.
сделать из одного аудиофайла два на лету. Например, есть one_two_three.mp3, где человек говорит: "раз, два, три"
я хочу командой с использованием ffmpeg получить на выходе аудиофайл, звучащий "раз, два, три [пауза в x секунд] раз, два, три"
то есть, дупликация файла в заданных параметрах. можно так?
я хочу командой с использованием ffmpeg получить на выходе аудиофайл, звучащий "раз, два, три [пауза в x секунд] раз, два, три"
то есть, дупликация файла в заданных параметрах. можно так?
>>1451079
This. Параметр -lossless (или -qmax 0, что приведёт к тому же результату) должен быть указан на выходе, а он у тебя вообще хуй знает где.
Смотри в местной вики статью по ffmpeg, там в самом начале описывается порядок параметров.
>>1453040
ffmpeg -i in.mp3 -i in.mp3 -lavfi "[0:a]apad=pad_len=$x[a0]; [a0][1:a]concat=v=0:a=1' out.mp3
> Может я как-то не так пишу аргументы?
This. Параметр -lossless (или -qmax 0, что приведёт к тому же результату) должен быть указан на выходе, а он у тебя вообще хуй знает где.
Смотри в местной вики статью по ffmpeg, там в самом начале описывается порядок параметров.
>>1453040
ffmpeg -i in.mp3 -i in.mp3 -lavfi "[0:a]apad=pad_len=$x[a0]; [a0][1:a]concat=v=0:a=1' out.mp3
>>1452769
Я бы даже больше написал для прояснения: эта особенность была сделана осознанно ради повышения эффективности сжатия.
И в указанной вебм (https://2ch.hk/b/src/105569197/14464779230730.webm ) целесообразность её применения чётко просматривается: там есть статичные объекты, висящие на протяжении большей части клипа.
Кстати, там ещё файл кривой:
Firefox из-за этого останавливает декодирование видео на 80 секунде. Возможно, из-за этого же и проблемы с перемоткой: при перемотке назад недогруженных файлов он зачем-то начинает качать их снова (ff41 и древнее).
>>1453083
s/\$x/${x}
s/'/"
> Это не баг ffmpeg, это особенность libvpx.
Я бы даже больше написал для прояснения: эта особенность была сделана осознанно ради повышения эффективности сжатия.
И в указанной вебм (https://2ch.hk/b/src/105569197/14464779230730.webm ) целесообразность её применения чётко просматривается: там есть статичные объекты, висящие на протяжении большей части клипа.
Кстати, там ещё файл кривой:
> [mkv] Corrupt file detected. Trying to resync starting from position 20961910...
Firefox из-за этого останавливает декодирование видео на 80 секунде. Возможно, из-за этого же и проблемы с перемоткой: при перемотке назад недогруженных файлов он зачем-то начинает качать их снова (ff41 и древнее).
>>1453083
s/\$x/${x}
s/'/"
>>1453703
Так это они юзерскриптами в конец левые данные дописывают, чтобы можно было файл несколько раз запостить. С картинками это в принципе всегда прокатывало, но видео всё-таки посложнее декодить. Открой в редакторе, там последние 6 байт — аски-символы 130169.
В vpxenc, кстати, они ставят kf_max_dist в 5*fps. Но если мы откроем какую-нибудь http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide , то там рекомендуется как раз побольше для лучшего качества.
>Кстати, там ещё файл кривой
Так это они юзерскриптами в конец левые данные дописывают, чтобы можно было файл несколько раз запостить. С картинками это в принципе всегда прокатывало, но видео всё-таки посложнее декодить. Открой в редакторе, там последние 6 байт — аски-символы 130169.
В vpxenc, кстати, они ставят kf_max_dist в 5*fps. Но если мы откроем какую-нибудь http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide , то там рекомендуется как раз побольше для лучшего качества.
>>1453711
Так в конец же, а не посреди дорожки. Говно в конце, хоть и формально лишает файл соответствия спекам, вряд ли может помешать парсерам.
Хотя ошибка mpv указывает как раз на последние байты. Странно.
> Так это они юзерскриптами в конец левые данные дописывают, чтобы можно было файл несколько раз запостить.
Так в конец же, а не посреди дорожки. Говно в конце, хоть и формально лишает файл соответствия спекам, вряд ли может помешать парсерам.
Хотя ошибка mpv указывает как раз на последние байты. Странно.
1224 Кб, 2560x1712
Скажем есть in.mp4 c аудиодорожкой. Хочу добавить в это видео музыку из .flv файла (но чтобы оригинальную дорожку тоже было слышно не удалять ее, mix 2 tracks, короче), подскажи команду как это быстрее и удобнее всего осуществить, софтач.
>>1453772
ffmpeg -i in.mp4 -i in.flv -lavfi '[0:a][1:a]amix[a]' -map 0:v -map '[a]' $output
ffmpeg -i in.mp4 -i in.flv -lavfi '[0:a][1:a]amix[a]' -map 0:v -map '[a]' $output
32 Кб, 437x361
>>1453772
Короче, я не знаю это баг или фича, но я попробовал с помощью этой команды добавить музыку:
ffmpeg -i out.mp3 -i out.mp4 video_finale.mp4
И в video_finale.mp4 была только музыка (та которая out.mp3), а в исходном out.mp4 (который по идее меняться был не должен раз он исходный) был микс из музыки и исходной аудиодорожки.
Но если у исходного аудиофайла и видеофайла разные имена, исходный видеофайл остается неизмененным, команда работает таким образом только если имена (до расширения) идентичны.
Короче я добавил музыку и сохранил под ней исходный звук, но такое ощущение, что через баг.
Короче, я не знаю это баг или фича, но я попробовал с помощью этой команды добавить музыку:
ffmpeg -i out.mp3 -i out.mp4 video_finale.mp4
И в video_finale.mp4 была только музыка (та которая out.mp3), а в исходном out.mp4 (который по идее меняться был не должен раз он исходный) был микс из музыки и исходной аудиодорожки.
Но если у исходного аудиофайла и видеофайла разные имена, исходный видеофайл остается неизмененным, команда работает таким образом только если имена (до расширения) идентичны.
Короче я добавил музыку и сохранил под ней исходный звук, но такое ощущение, что через баг.
1230 Кб, 3072x2304
>>1453931
А если, скажем, музыка длится меньше чем видео, и я хочу вставить еще одну композицию после первой, можно это в одну/в твою команду запихнуть или отдельно клеить две аудио дорожки? И чтобы автоматом обрезало видео, там где кончается видео, а не показывало черный экран если аудио длиннее видео.
А если, скажем, музыка длится меньше чем видео, и я хочу вставить еще одну композицию после первой, можно это в одну/в твою команду запихнуть или отдельно клеить две аудио дорожки? И чтобы автоматом обрезало видео, там где кончается видео, а не показывало черный экран если аудио длиннее видео.
когда перекодирую из одного файла в него же(фреймрейт меняю), то ругается что-то типа input buffer exhausted и так далее, и не докодирует до конца, а когда в разные, то все норм. но бля, мне нужно именно этот взять и перезаписать, нахуя мне в разные пердолиться, считать их, учитывать
поясните
поясните
>>1455024
Для этого нужно результат весь в памяти держать, только потом открывать выходной файл на запись. ffmpeg так не делает, т.к. поточный. Как вариант можешь записывать на tmpfs, оттуда перемещать на место исходного. Или вот такой костыль: https://serverfault.com/a/135537
ffmpeg -i in.mkv -f matroska - | sponge in.mkv
Для этого нужно результат весь в памяти держать, только потом открывать выходной файл на запись. ffmpeg так не делает, т.к. поточный. Как вариант можешь записывать на tmpfs, оттуда перемещать на место исходного. Или вот такой костыль: https://serverfault.com/a/135537
ffmpeg -i in.mkv -f matroska - | sponge in.mkv
>>1455048
Какие кэши? Ты в курсе, что файлы могут транскодиться многогигабайтные? И даже если он будет записывать во временный файл в какой-нибудь TMP_DIR, не факт, что там места хватит. Как раз твоё предложение это и есть дикое пердольство. Вызванное незнанием основ операционных систем.
Какие кэши? Ты в курсе, что файлы могут транскодиться многогигабайтные? И даже если он будет записывать во временный файл в какой-нибудь TMP_DIR, не факт, что там места хватит. Как раз твоё предложение это и есть дикое пердольство. Вызванное незнанием основ операционных систем.
>>1455052
ffmpeg -i in -filter_complex yoba in
...
внимание, вы пытаетесь писать в тот же файл, из которого читаете. так как ффмпег - потоковая программа, то сходу это невозможно.
нажмите да, чтобы разрешить создать временный буферный файл. нажмите нет, чтобы сбросить
какое-такое знание основ операционных систем запрещает выдать такой промтик, а не подбрасывать мне порванные буферы на лицо?
ffmpeg -i in -filter_complex yoba in
...
внимание, вы пытаетесь писать в тот же файл, из которого читаете. так как ффмпег - потоковая программа, то сходу это невозможно.
нажмите да, чтобы разрешить создать временный буферный файл. нажмите нет, чтобы сбросить
какое-такое знание основ операционных систем запрещает выдать такой промтик, а не подбрасывать мне порванные буферы на лицо?
>>1455081
ffmpeg -i in in.tmp && mv in.tmp in
Problem solved. Или sponge.
Ну или если ты хочешь поныть, то багтрекер там → https://trac.ffmpeg.org/
Здесь разработчиков ffmpeg нет.
ffmpeg -i in in.tmp && mv in.tmp in
Problem solved. Или sponge.
Ну или если ты хочешь поныть, то багтрекер там → https://trac.ffmpeg.org/
Здесь разработчиков ffmpeg нет.
>>1455081
У ffmpeg нет задачи создавать буферы и т.п., это задача костылей, тебе уже даже нашли их, а ты все комбайн хочешь. Книжки бы умные почитал про всю хуйню, Таненбаума там, вот это все.
У ffmpeg нет задачи создавать буферы и т.п., это задача костылей, тебе уже даже нашли их, а ты все комбайн хочешь. Книжки бы умные почитал про всю хуйню, Таненбаума там, вот это все.
>>1455107
-f $format
хотя я предпочитаю и во временных файлах использовать расширения:
>>1455081
ffmpeg — неинтерактивная программа (хотя и с элементами интерактивности вроде подтвержжения перезаписи файла).
Подобные костыли — это палки в колёса любому автоматизированному использованию. Если такое и реализовывать, то только в виде вывода warning'а и продолжения работы.
Но я почти уверен, что это реализовано не будет. Файл — это лишь частный случай источника и вывода информации (ffmpeg также поддерживает разнообразное вещание, захват, генерацию и утилизацию потоков, см. https://ffmpeg.org/ffmpeg-devices.html , https://ffmpeg.org/ffmpeg-protocols.html и фильтры категорий sinks и sources), и рисовать в файловом протоколе какие-то костыли, в обход выданного ему контекста проверяющие, не долбоёб ли пользователь, я бы не стал.
Многочисленные проверки на долбоебизм (в т.ч. реализованные поверх общей архитектуры программы) уместны в софте для соответствующих пользователей, но в решениях вроде ffmpeg им места нет. Пользователь ffmpeg должен сам понимать, куда и как он что направляет и как оно должно буферизироваться. У меня почему-то и мысли ни разу не возникло перезаписывать ffmpeg'ом читаемый файл, хотя случаев, когда это было бы удобно, было достаточно.
-f $format
хотя я предпочитаю и во временных файлах использовать расширения:
>>1455081
ffmpeg — неинтерактивная программа (хотя и с элементами интерактивности вроде подтвержжения перезаписи файла).
Подобные костыли — это палки в колёса любому автоматизированному использованию. Если такое и реализовывать, то только в виде вывода warning'а и продолжения работы.
Но я почти уверен, что это реализовано не будет. Файл — это лишь частный случай источника и вывода информации (ffmpeg также поддерживает разнообразное вещание, захват, генерацию и утилизацию потоков, см. https://ffmpeg.org/ffmpeg-devices.html , https://ffmpeg.org/ffmpeg-protocols.html и фильтры категорий sinks и sources), и рисовать в файловом протоколе какие-то костыли, в обход выданного ему контекста проверяющие, не долбоёб ли пользователь, я бы не стал.
Многочисленные проверки на долбоебизм (в т.ч. реализованные поверх общей архитектуры программы) уместны в софте для соответствующих пользователей, но в решениях вроде ffmpeg им места нет. Пользователь ffmpeg должен сам понимать, куда и как он что направляет и как оно должно буферизироваться. У меня почему-то и мысли ни разу не возникло перезаписывать ffmpeg'ом читаемый файл, хотя случаев, когда это было бы удобно, было достаточно.
Господа, гялньте на строчку и скажите какого хрена игноится параметр "-threads 4"?
ffmpeg.exe -i temp.mp4 -ss 00:06.140 -to 12:37.237 -c:v libvpx-vp9 -crf 32 -b:v 200K -vf scale=320:180 -threads 4 -fs 20M -metadata title="Kings of Power 4 Billion%" -quality best out_new.webm
Фигачит в один поток и все тут, с vp8 такой укни не наблюдалось.
ffmpeg.exe -i temp.mp4 -ss 00:06.140 -to 12:37.237 -c:v libvpx-vp9 -crf 32 -b:v 200K -vf scale=320:180 -threads 4 -fs 20M -metadata title="Kings of Power 4 Billion%" -quality best out_new.webm
Фигачит в один поток и все тут, с vp8 такой укни не наблюдалось.
9 Кб, 748x148
9 Кб, 756x136
>>1455607
УМВР. Первый скрин ffmpeg -i 1.mkv -threads 4 out.webm
Даже без указания не в один поток, второй скрин ffmpeg -i 1.mkv out.webm
Алсо, quality best нафига? У тебя там пару суток есть кодировать?
УМВР. Первый скрин ffmpeg -i 1.mkv -threads 4 out.webm
Даже без указания не в один поток, второй скрин ffmpeg -i 1.mkv out.webm
Алсо, quality best нафига? У тебя там пару суток есть кодировать?
>>1455657
Анон, я сам дурак, оказалось у меня просто какой-то протухший билд ffmpeg был, на свежем все ок.
А -quality best просто тестил.
Анон, я сам дурак, оказалось у меня просто какой-то протухший билд ffmpeg был, на свежем все ок.
А -quality best просто тестил.
3591 Кб, 4000x3000
>>1453931
Получилось вот так: ffmpeg -i in.mp4 -i music.mp3 -lavfi [0][1:0]amix[1] -map 0:v -map [1] out.mp4
Но качество плоховатое на выходе, даже если по весу посмотреть на выходе файл в 7 раз меньше чем исходный, как форсировать исходное качество?
Получилось вот так: ffmpeg -i in.mp4 -i music.mp3 -lavfi [0][1:0]amix[1] -map 0:v -map [1] out.mp4
Но качество плоховатое на выходе, даже если по весу посмотреть на выходе файл в 7 раз меньше чем исходный, как форсировать исходное качество?
2132 Кб, 2592x1944
>>1455892
Im pretty much некомпетентен in this. Куда именно в этой строке: ffmpeg -i in.mp4 -i music.mp3 -lavfi [0][1:0]amix[1] -map 0:v -map [1] out.mp4
вставить -c:v copy ?
Im pretty much некомпетентен in this. Куда именно в этой строке: ffmpeg -i in.mp4 -i music.mp3 -lavfi [0][1:0]amix[1] -map 0:v -map [1] out.mp4
вставить -c:v copy ?
>>1455996
Смотри. У тебя есть
ffmpeg - название собственно, оно неизменно.
Дальше ты можешь написать -ss, чтобы отрезать кусок. Время указываешь начало файла. Больше сюда обычно ничего не пишут, по крайней мере для вебм. Не уверен можно ли вообще что-то писать.
Дальше ты пишешь путь и имя входного файла или файлов. Это считай начальной точкой, дальше все, что касается этих файлов будет за ними, и в конце ты завершишь выходным файлом. Все настройки пишутся между входными и выходным файлом. Поэтому -c:v copy вставляй в любое место между in.mp4 и out.mp4
Смотри. У тебя есть
ffmpeg - название собственно, оно неизменно.
Дальше ты можешь написать -ss, чтобы отрезать кусок. Время указываешь начало файла. Больше сюда обычно ничего не пишут, по крайней мере для вебм. Не уверен можно ли вообще что-то писать.
Дальше ты пишешь путь и имя входного файла или файлов. Это считай начальной точкой, дальше все, что касается этих файлов будет за ними, и в конце ты завершишь выходным файлом. Все настройки пишутся между входными и выходным файлом. Поэтому -c:v copy вставляй в любое место между in.mp4 и out.mp4
>>1456037
Я бы подкорректировал.
ffmpeg — команда, остальное — параметры.
Во-первых, ему даже -ss не надо. Во-вторых, у него два входа, и -ss при применении на входе пришлось бы писать для каждого из них отдельно.
Есть довольно много параметров, которые можно использовать на входе — как универсальных, так и специфичных для входных форматов и протоколов.
Только настройки конкретно этого выхода. Параметры входа были рассмотрены выше, а ещё существуют глобальные параметры вроде -y и -hide_banner, которые можно пихать куда угодно.
Я бы подкорректировал.
> ffmpeg - название собственно, оно неизменно.
ffmpeg — команда, остальное — параметры.
> Дальше ты можешь написать -ss, чтобы отрезать кусок. Время указываешь начало файла. Больше сюда обычно ничего не пишут, по крайней мере для вебм.
Во-первых, ему даже -ss не надо. Во-вторых, у него два входа, и -ss при применении на входе пришлось бы писать для каждого из них отдельно.
> Не уверен можно ли вообще что-то писать.
Есть довольно много параметров, которые можно использовать на входе — как универсальных, так и специфичных для входных форматов и протоколов.
> Все настройки пишутся между входными и выходным файлом.
Только настройки конкретно этого выхода. Параметры входа были рассмотрены выше, а ещё существуют глобальные параметры вроде -y и -hide_banner, которые можно пихать куда угодно.
>>1456037
>>1456200
Я вот только не пойму, чего вы в ман-то сразу не отправляете?
https://www.ffmpeg.org/ffmpeg.html#Description
Офигенно ж объяснено, даже с картинками.
>>1456200
Я вот только не пойму, чего вы в ман-то сразу не отправляете?
https://www.ffmpeg.org/ffmpeg.html#Description
Офигенно ж объяснено, даже с картинками.
>>1456206
Но там нет картинки по принадлежности опций, синопсис не имеющий прыщенавыков человек сходу может и не понять, а абзац, где об этом написано, может быть труден для понимания человеку с низким скиллом английского.
Я бы послал в местную вики, но её лучше бы сначала обновить, т.к. инфа по дефолтам устарела.
> Я вот только не пойму, чего вы в ман-то сразу не отправляете?
Но там нет картинки по принадлежности опций, синопсис не имеющий прыщенавыков человек сходу может и не понять, а абзац, где об этом написано, может быть труден для понимания человеку с низким скиллом английского.
Я бы послал в местную вики, но её лучше бы сначала обновить, т.к. инфа по дефолтам устарела.
>>1456224
Обычно это одно и тоже. Разница есть только в новых версиях ffmpeg при картинках и камерах через v4l2 на входe, какая именно — из документации не вполне понятно. Указывается использовать -framerate.
Видимо, разделение сделано чтобы не путали с выходным параметром -r, действие которого аналогично фильтру fps.
Обычно это одно и тоже. Разница есть только в новых версиях ffmpeg при картинках и камерах через v4l2 на входe, какая именно — из документации не вполне понятно. Указывается использовать -framerate.
Видимо, разделение сделано чтобы не путали с выходным параметром -r, действие которого аналогично фильтру fps.
>>1456755
Конфиг в каком файле? Я скачал билд для шиндоус, при запуске он воспроизводит, но в папку \webm ничего не сохраняет.
Конфиг в каком файле? Я скачал билд для шиндоус, при запуске он воспроизводит, но в папку \webm ничего не сохраняет.
>>1456755
https://github.com/ValdikSS/endless-sosuch/blob/master/config.py.
Он вкомпилен внутрь, ололо. Качай нормально.
> Конфиг в каком файле?
https://github.com/ValdikSS/endless-sosuch/blob/master/config.py.
> Я скачал билд для шиндоус
Он вкомпилен внутрь, ололо. Качай нормально.
>>1422849
Нахуя? Чтобы смотреть одни и те же вебмки, которые к тому же я уже 100 раз видел?
Нахуя? Чтобы смотреть одни и те же вебмки, которые к тому же я уже 100 раз видел?
-vf "scale=x:y" пидорасит картинку, растягивая ее как животную кожу
как сделать, чтобы растягивало ПРОПОРЦИОНАЛЬНО до первой попавшейся границы по вертикали или горизонтали, останавливалось на этом, и остальное заливало каким-нибудь цветом?
как сделать, чтобы растягивало ПРОПОРЦИОНАЛЬНО до первой попавшейся границы по вертикали или горизонтали, останавливалось на этом, и остальное заливало каким-нибудь цветом?
>>1457015
Но я не могу в питон, у меня нет компилятора, как я это запущу то потом.
Но я не могу в питон, у меня нет компилятора, как я это запущу то потом.
Пацаны, в вп9 на 4(8) ведрах кодируется со скоростью 4 кадра в секунду видеопоток с 1000кбитным битрейтом и 1280х720 фреймом. Хуле тут так мало?
>>1395791 (OP)
WEBMо няши реквестирую создать вебмку
С этим видео → https://coub.com/view/8zv5i
И музыкой отсюда → http://meatspin.fr/
WEBMо няши реквестирую создать вебмку
С этим видео → https://coub.com/view/8zv5i
И музыкой отсюда → http://meatspin.fr/
>>1457550
Ничо толком не поменялось в плане скорости. На качество гляну, но вроде не особо ссано вышло с -cpu-used 4 и дефолтным -quality.
Ничо толком не поменялось в плане скорости. На качество гляну, но вроде не особо ссано вышло с -cpu-used 4 и дефолтным -quality.
>>1457194
scale=x:-1
scale=x:y:force_original_aspect_ratio=decrease
pad=x:y:color=red
> как сделать, чтобы растягивало ПРОПОРЦИОНАЛЬНО
scale=x:-1
> до первой попавшейся границы по вертикали или горизонтали, останавливалось на этом
scale=x:y:force_original_aspect_ratio=decrease
> остальное заливало каким-нибудь цветом
pad=x:y:color=red
1067 Кб, Webm
>>1457563
Всё, как просил. Поток с coub напрямую скачан youtube-dl, музыка выдрана из ms.swf с помощью swfextract.
>inb4 обвинения в качестве
Всё, как просил. Поток с coub напрямую скачан youtube-dl, музыка выдрана из ms.swf с помощью swfextract.
>>1457617
Оригинал музыки вот: http://rutracker.org/forum/viewtopic.php?t=4516578
Если есть лучше видео, то давай. Можно ещё закольцевать на какое-то время. (Я, кстати, нашёл способ как это нормально сделать без перевода в RGB пнгшки с потерями.)
Оригинал музыки вот: http://rutracker.org/forum/viewtopic.php?t=4516578
Если есть лучше видео, то давай. Можно ещё закольцевать на какое-то время. (Я, кстати, нашёл способ как это нормально сделать без перевода в RGB пнгшки с потерями.)
>>1457626
Вот кое что нашел:
http://imgur.com/gallery/r3Zx7Km
И да закольцевать хорошая идея, ориджинал видео можно подрезать чтоб небыло видно как она останавливается
Вот кое что нашел:
http://imgur.com/gallery/r3Zx7Km
И да закольцевать хорошая идея, ориджинал видео можно подрезать чтоб небыло видно как она останавливается
2359 Кб, Webm
>>1457637
Вот. Видео с imgur оригинальное без пережатия, аудио — 128k опус, скодированный из флака, считай что transparent.
Циклить особо не куда, всего 6 мегабайт лимит. Разве что синхру можно получше затюнить, но мне лениво.
Вот. Видео с imgur оригинальное без пережатия, аудио — 128k опус, скодированный из флака, считай что transparent.
Циклить особо не куда, всего 6 мегабайт лимит. Разве что синхру можно получше затюнить, но мне лениво.
тест
>>1457682
Ух ты, Серёженька. Пойду передёрну на него.
Ух ты, Серёженька. Пойду передёрну на него.
7 Кб, 243x208
>>1395791 (OP)
Вроде скачал 35мб.
Но что нажимать так и не нашел.
Можно более ПОДРОБНУЮ инструкцию?
>Если для кого-то это слишком сложно, то можно взять гуй с минимумом кнопок для умственно отсталых (сперма-only): https://gitgud.io/nixx/WebMConverter
Вроде скачал 35мб.
Но что нажимать так и не нашел.
Можно более ПОДРОБНУЮ инструкцию?
74 Кб, 462x500
>>1457754
> гуй с минимумом кнопок для умственно отсталых
> Но что нажимать так и не нашел
> Можно более ПОДРОБНУЮ инструкцию?
> Windows 10
>>1457938
Хотя с графоном обосрамс полнейший.
Хотя с графоном обосрамс полнейший.
>>1457911
Не переживай ему на windows 11 завезут с Адварьным Абу и Пропиетарным двачем.
Не переживай ему на windows 11 завезут с Адварьным Абу и Пропиетарным двачем.
>>1457906
Так 4 фпс с таким процем это её хорошо получается. Чего ты ждал от ноутбука? Производителньость эквивалентную ПК?
Так 4 фпс с таким процем это её хорошо получается. Чего ты ждал от ноутбука? Производителньость эквивалентную ПК?
>>1457972
Ну так по всяким бенчмаркам этот камень жжот как i5-2500. Или кодировать в вп9 можно только на 2011 сокете?
Ну так по всяким бенчмаркам этот камень жжот как i5-2500. Или кодировать в вп9 можно только на 2011 сокете?
63 Кб, 671x853
Можете ли мне объяснить — что это значит?
Я предполагаю, что это из за исходной видеодорожки, а не из за моей рукожопости, ибо всё время нормально
Поясните за это плиз
Я предполагаю, что это из за исходной видеодорожки, а не из за моей рукожопости, ибо всё время нормально
Поясните за это плиз
1 Кб, 141x48
>>1457998
А потом дописывает пик
А потом дописывает пик
>>1457983
А ты сам позапускай линпаки и сисбенчи и посмотри, насколько они соответствуют действительности.
>Ну так по всяким бенчмаркам
А ты сам позапускай линпаки и сисбенчи и посмотри, насколько они соответствуют действительности.
>>1458051
Ну тогда сравнивай на реальных энкодах. Это ж ещё от видео и настроек качества зависит.
Например: https://media.xiph.org/video/derf/y4m/park_joy_420_720p50.y4m
$ time ffmpeg -hide_banner -i park_joy_420_720p50.y4m -c:v libvpx-vp9 -speed 1 -threads 4 -b:v 0 -crf 30 -f null -
frame= 500 fps=2.6 q=0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A
634.26s user 0.65s system 331% cpu 3:11.44 total
(500 кадров 720p, средний fps 2.6, 3 минуты 11 секунд, средняя загрузка CPU около 331 процента. i7 3820)
Ну тогда сравнивай на реальных энкодах. Это ж ещё от видео и настроек качества зависит.
Например: https://media.xiph.org/video/derf/y4m/park_joy_420_720p50.y4m
$ time ffmpeg -hide_banner -i park_joy_420_720p50.y4m -c:v libvpx-vp9 -speed 1 -threads 4 -b:v 0 -crf 30 -f null -
frame= 500 fps=2.6 q=0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A
634.26s user 0.65s system 331% cpu 3:11.44 total
(500 кадров 720p, средний fps 2.6, 3 минуты 11 секунд, средняя загрузка CPU около 331 процента. i7 3820)
>>1458072
На разогнанном i7 2600k здесь лучше результаты показывали. Сокет ещё не показатель, проц-то десктопный и AVX2 нет.
На разогнанном i7 2600k здесь лучше результаты показывали. Сокет ещё не показатель, проц-то десктопный и AVX2 нет.
>>1458068
Ах да, сравнивать в энкодах как-то не особо хочется, придется пгыщи накатывать какие-нибудь, ибо консольную клоунаду в сперме не люблю… Пгыщи тоже не особо люблю на десктопе, х сервер настраивать, вот это все, не под себя запилили.
Эх, вот дилемма, сперма для игор хороша, гейось для всего остального но не для игор нихуя, ускорение у мышки ебанутое, а пгыщи хороши для энкодинга вебмок всего остального.
Ах да, сравнивать в энкодах как-то не особо хочется, придется пгыщи накатывать какие-нибудь, ибо консольную клоунаду в сперме не люблю… Пгыщи тоже не особо люблю на десктопе, х сервер настраивать, вот это все, не под себя запилили.
Эх, вот дилемма, сперма для игор хороша, гейось для всего остального но не для игор нихуя, ускорение у мышки ебанутое, а пгыщи хороши для энкодинга вебмок всего остального.
>>1458083
Ой да ладно, материнки отличные все под этот сокет – рассыпуха качественная и биос объемный, сами камни тоже хорошие – жиды так и не решились заливать их спермой.
>Сокет ещё не показатель
Ой да ладно, материнки отличные все под этот сокет – рассыпуха качественная и биос объемный, сами камни тоже хорошие – жиды так и не решились заливать их спермой.
>>1458087
PowerShell чуть получше. И вот как у этого >>1448903 эмулятор терминала можешь поставить (в прошлых тредах было, забыл как называется).
Именно на запуске команд ffmpeg особой разницы нет. Вот что-нибудь компилировать — да, на линуксах удобнее, особенно на генту. И пакетные менеджеры побогаче, не то что шоколадки всякие.
>придется пгыщи накатывать какие-нибудь, ибо консольную клоунаду в сперме не люблю
PowerShell чуть получше. И вот как у этого >>1448903 эмулятор терминала можешь поставить (в прошлых тредах было, забыл как называется).
Именно на запуске команд ffmpeg особой разницы нет. Вот что-нибудь компилировать — да, на линуксах удобнее, особенно на генту. И пакетные менеджеры побогаче, не то что шоколадки всякие.
>>1458093
Да то cygwin, я его ставил года два назад, не под себя было, мб поменялось чего.
Да то cygwin, я его ставил года два назад, не под себя было, мб поменялось чего.
>>1457998
Вот, давно хотел с этим разобраться, но что-то руки не доходили.
Судя по коду, это получается когда разница в PTS в процессе конвертации меняется более чем на 0.6 сек в сторону ускорения вывода:
https://github.com/FFmpeg/FFmpeg/blob/master/ffmpeg.c#L1009
Дай соус видео, хочу поковырять это.
Надеюсь, ты там с FPS, PTS и timebase никаких штук не делал?
Вот, давно хотел с этим разобраться, но что-то руки не доходили.
Судя по коду, это получается когда разница в PTS в процессе конвертации меняется более чем на 0.6 сек в сторону ускорения вывода:
https://github.com/FFmpeg/FFmpeg/blob/master/ffmpeg.c#L1009
Дай соус видео, хочу поковырять это.
Надеюсь, ты там с FPS, PTS и timebase никаких штук не делал?
32 Кб, 645x439
Подскажите пикрелейтед, почему профиль baseline хоть я и пишу high?
>>1457608
Ан нет туплю, ниже же вторая версия.
Ан нет туплю, ниже же вторая версия.
>>1458672
Это что, ЗУБАСТИК же на пикче? Или нет?
Это что, ЗУБАСТИК же на пикче? Или нет?
Скажите мне, где можно нормально каждый день почитать новости из мира софта?Заебали всякие сраные журнальчики. Ну кроме /s конечно же.
>>1458827
HN, slashdot, reddit. Ну и тематические — мэйллисты, блоги, чатики, конференции, слайды. Зависит от направления.
HN, slashdot, reddit. Ну и тематические — мэйллисты, блоги, чатики, конференции, слайды. Зависит от направления.
ffmpeg -ss 1:30 -i sex.mp4 -to 3:30 sex.webm
Encoder (codec vp8) not found for output stream #0:0
ffmpeg -ss 1:30 -i sex.mp4 -to 3:30 -c:v vp8 sex.webm
Unknown encoder 'vp8'
ЧЯДНТ?
Encoder (codec vp8) not found for output stream #0:0
ffmpeg -ss 1:30 -i sex.mp4 -to 3:30 -c:v vp8 sex.webm
Unknown encoder 'vp8'
ЧЯДНТ?
Итак, затестил дома под сперменью оказывается, под себя запилили все, даже кнопочки те же, реально удобно, 2500к@4.5 ГГц, перекодирует на дефолтных настройках в 4 потока со скоростью 20 фпс... Хуле мобильный штеудомусор третьего поколения в 5 раз медленней? На бумажке-то он ух, чуть ли не на клыка всем дает!
>>1459123
Пруфани бумажку, а то могильное говно всегда хуй сосало у десктопных процессоров.
>На бумажке-то он ух
Пруфани бумажку, а то могильное говно всегда хуй сосало у десктопных процессоров.
>>1459003
ffmpeg собрал как?
Сноси его и ставь заново с флагами
--with-fdk-aac --with-ffplay --with-freetype --with-frei0r --with-libass --with-libvo-aacenc --with-libvorbis --with-libvpx --with-opencore-amr --with-openjpeg --with-opus --with-rtmpdump --with-schroedinger --with-speex --with-theora --with-tools
Эти я ща в бложике каком-то по первой ссылке взял, там их больше, советую собрать со всеми, один хуй не теряешь ничего кроме времени на сборку.
ffmpeg собрал как?
Сноси его и ставь заново с флагами
--with-fdk-aac --with-ffplay --with-freetype --with-frei0r --with-libass --with-libvo-aacenc --with-libvorbis --with-libvpx --with-opencore-amr --with-openjpeg --with-opus --with-rtmpdump --with-schroedinger --with-speex --with-theora --with-tools
Эти я ща в бложике каком-то по первой ссылке взял, там их больше, советую собрать со всеми, один хуй не теряешь ничего кроме времени на сборку.
>>1459128
Ну типа вот всеми любимый штеудом купленный сайтик с бенчмарками, например.
http://www.cpubenchmark.net/compare.php?cmp[]=1784&cmp[]=804
Ну типа вот всеми любимый штеудом купленный сайтик с бенчмарками, например.
http://www.cpubenchmark.net/compare.php?cmp[]=1784&cmp[]=804
>>1459123
Какой файл-то? В отрыве от исходника эти данные не имеют смысла.
>перекодирует на дефолтных настройках в 4 потока со скоростью 20 фпс
Какой файл-то? В отрыве от исходника эти данные не имеют смысла.
6 Кб, 296x212
>>1459142
Вот такой. Ща попробую его же с теми же флагами (только под 8 потоков, айсемь жи) пустить на лаптопе.
Вот такой. Ща попробую его же с теми же флагами (только под 8 потоков, айсемь жи) пустить на лаптопе.
>>1459151
Ты, кажется, не понял. Влияет не только разрешение и частота кадров, но и сам исходник.
Кроме того, если настройки были совсем дефолтными, то это VBR 200k, т.е. не имеющие смысла.
Почитай вот это для начала: https://web.archive.org/web/20141103202912/http://x264dev.multimedia.cx/archives/472
Ты, кажется, не понял. Влияет не только разрешение и частота кадров, но и сам исходник.
Кроме того, если настройки были совсем дефолтными, то это VBR 200k, т.е. не имеющие смысла.
Почитай вот это для начала: https://web.archive.org/web/20141103202912/http://x264dev.multimedia.cx/archives/472
>>1459156
Там многа буков, мне лень ща.
Настройки были следующие:
ffmpeg -i input.mp4 -ss 0:00 -t 384 -b:v 0 -tile-columns 6 -threads 48 -crf 30 output.webm
Лаптоп делает в 4 раза медленней сейчас.
Там многа буков, мне лень ща.
Настройки были следующие:
ffmpeg -i input.mp4 -ss 0:00 -t 384 -b:v 0 -tile-columns 6 -threads 48 -crf 30 output.webm
Лаптоп делает в 4 раза медленней сейчас.
>>1459171
При активности одного до 3.4. Свежий цпу-з с прикрученным бенчмарком вроде даже одно ведро этой мобильной кукурузы считает более мощным, чем одно ведро 2500к.
При активности одного до 3.4. Свежий цпу-з с прикрученным бенчмарком вроде даже одно ведро этой мобильной кукурузы считает более мощным, чем одно ведро 2500к.
11 Кб, 405x402
>>1459174
А нет, напиздел.
У могильного 1417 и 5882 соответственно. Ща попробую там под спермой запустить тот же самый файл.
А нет, напиздел.
У могильного 1417 и 5882 соответственно. Ща попробую там под спермой запустить тот же самый файл.
>>1459184
Превратили тред в мокрописьки какие-то. Эти циферки в проприетарной поделке показывают чуть менее, чем ничего.
Превратили тред в мокрописьки какие-то. Эти циферки в проприетарной поделке показывают чуть менее, чем ничего.
>>1459203
Хех, зато под спермой оно троттлит, а под гейосью нет. Мертвый господин 1:0 Потный господин.
Хех, зато под спермой оно троттлит, а под гейосью нет. Мертвый господин 1:0 Потный господин.
>>1459217
Да нет хуле, он 3.2 таки выдавал, троттлил не полностью, только одним ядром. 3.4, как я сказал, может только одним ядром.
А какие альтернативы-то? Я даже не знаю, что там у свежего ULV-кала, наверное вообще адок.
Да нет хуле, он 3.2 таки выдавал, троттлил не полностью, только одним ядром. 3.4, как я сказал, может только одним ядром.
А какие альтернативы-то? Я даже не знаю, что там у свежего ULV-кала, наверное вообще адок.
>>1459003 - кун вернулся,
помогло установка libvpx и libvobris. Оказывается они необходимы для кодирования webm.
Но у меня теперь другая проблема, очень медленно получается. Юзаю такую команду:
ffmpeg -ss 1:30 -i sex.mp4 -to 3:30 -c:a libvorbis -c:v libvpx-vp9 sex.webm
5 секунд кодировалось около минуты. Меня такая скорость не устраивает. Что посоветуете дописать?
помогло установка libvpx и libvobris. Оказывается они необходимы для кодирования webm.
Но у меня теперь другая проблема, очень медленно получается. Юзаю такую команду:
ffmpeg -ss 1:30 -i sex.mp4 -to 3:30 -c:a libvorbis -c:v libvpx-vp9 sex.webm
5 секунд кодировалось около минуты. Меня такая скорость не устраивает. Что посоветуете дописать?
>>1459250
Это дефолты в ffmpeg.
Это дефолты в ffmpeg.
>>1459248
Этот господин прав.
libvpx-vp9 -> libvpx
после этого поползло, аж по несколько фреймов в секунду
еще поставил -threads 4, тоже очень хорошо помогает
Но все равно довольно медленно (около 4-5 fps)
Пробовал добавить -cpu-used 5. Пошло быстро, прямо как мне и надо, только вот картинка хреновая вышла. Можно еще что-нибудь сделать?
Этот господин прав.
libvpx-vp9 -> libvpx
после этого поползло, аж по несколько фреймов в секунду
еще поставил -threads 4, тоже очень хорошо помогает
Но все равно довольно медленно (около 4-5 fps)
Пробовал добавить -cpu-used 5. Пошло быстро, прямо как мне и надо, только вот картинка хреновая вышла. Можно еще что-нибудь сделать?
>>1459208
Поменял термопасту, под спермой теперь тоже не троттлит. Интересно, хули он только 60% ресурса цпу в среднем юзает? 2500к сотку жрет...
Поменял термопасту, под спермой теперь тоже не троттлит. Интересно, хули он только 60% ресурса цпу в среднем юзает? 2500к сотку жрет...
>>1459298
Разрезать файл пополам/на три части и запустить параллельно. Будет полное задействование ядер.
>Можно еще что-нибудь сделать?
Разрезать файл пополам/на три части и запустить параллельно. Будет полное задействование ядер.
>>1459298
Ну так это vp8. Он быстрее но хуевей.
Бутнуть спермуху - там в два раза быстрее. Хуй знает, почему так, мб в хоумбрю протухший vp9.
>libvpx-vp9 -> libvpx
Ну так это vp8. Он быстрее но хуевей.
>Можно еще что-нибудь сделать?
Бутнуть спермуху - там в два раза быстрее. Хуй знает, почему так, мб в хоумбрю протухший vp9.
>>1459304
Так хули нечем - я тут ему сую за щеку ffmpeg.
Кстати в гейоси та же хуйня походу - он грузит камень не полностью несмотря на 8 потоков в опциях..
Так хули нечем - я тут ему сую за щеку ffmpeg.
Кстати в гейоси та же хуйня походу - он грузит камень не полностью несмотря на 8 потоков в опциях..
>>1459314
libvpx-vp9 похуй сколько потоков там в опциях, сколько он захочет, столько и будет грузить.
libvpx-vp9 похуй сколько потоков там в опциях, сколько он захочет, столько и будет грузить.
>>1459319
Ну естественно что один он загрузит, а вот дальше со скрипом пойдет, уменьшай количество потоков по одному с 8 и смотри когда начала скорость падать, вот столько потоков значит нагрузил.
Ну естественно что один он загрузит, а вот дальше со скрипом пойдет, уменьшай количество потоков по одному с 8 и смотри когда начала скорость падать, вот столько потоков значит нагрузил.
5510 Кб, Webm
>>1459298 - кун тут
таки дождался (около 15 мин)
frame= 2955 fps=2.6 q=0.0 Lsize=6177kB time=00:01:58.23 bitrate= 428.0kbits/s
video:4637kB audio:1474kB subtitle:0kB other streams:0kB global headers:4kB muxing overhead: 1.082532%
На этот раз юзал такую команду:
ffmpeg -ss 1:36 -i sex.mp4 -to 3:30 -c:a libvorbis -c:v libvpx -vf scale=-1:720 -threads 4 sex.webm
Хотя -cpu-used 5 задействовано не было, картинка, как можно видеть, все равно херовая. Почему так? Я ведь долго кодировал.
пришлось обрезать 15 сек чтобы влезло
таки дождался (около 15 мин)
frame= 2955 fps=2.6 q=0.0 Lsize=6177kB time=00:01:58.23 bitrate= 428.0kbits/s
video:4637kB audio:1474kB subtitle:0kB other streams:0kB global headers:4kB muxing overhead: 1.082532%
На этот раз юзал такую команду:
ffmpeg -ss 1:36 -i sex.mp4 -to 3:30 -c:a libvorbis -c:v libvpx -vf scale=-1:720 -threads 4 sex.webm
Хотя -cpu-used 5 задействовано не было, картинка, как можно видеть, все равно херовая. Почему так? Я ведь долго кодировал.
пришлось обрезать 15 сек чтобы влезло
>>1459332
Ты неправильно сделал расчёты. У тебя битрейт маленький для такого разрешения.
У тебя получилось:
1280720px 25fps при всего 313Kb/s, выходит соотношение битрейт / (кол-во пикселей число кадров) = 0,014. А чтобы было более-менее смотрибельное качество нужен коэффициент >= 0,1.
Выходит тебе нужно либо повысить битрейт видеоряда аж до 2300 Кбит/с, но тогда у тебя он в тематические 6Мбайт не влезет. Либо понижать разрешение.
Ты неправильно сделал расчёты. У тебя битрейт маленький для такого разрешения.
У тебя получилось:
1280720px 25fps при всего 313Kb/s, выходит соотношение битрейт / (кол-во пикселей число кадров) = 0,014. А чтобы было более-менее смотрибельное качество нужен коэффициент >= 0,1.
Выходит тебе нужно либо повысить битрейт видеоряда аж до 2300 Кбит/с, но тогда у тебя он в тематические 6Мбайт не влезет. Либо понижать разрешение.
>битрейт / (кол-во пикселей Х число кадров)
>>1459332
И ты бы мог соус куда-нибудь залить?
И ты бы мог соус куда-нибудь залить?
>>1459332
Используй vp9, там картинка лучше и сжатие тоже.
Используй vp9, там картинка лучше и сжатие тоже.
Помогите плиз. Записываю поток из интернета в файл. Ничего необычного и сложного. Но вот интересует вопрос. Я по неосторожности закрыл консольку и теперь файл не открывается. Я не очень знаю структуру контейнеров и не знаю как это пофиксить.
код был такой:
ffmpeg -re -i "ссылка на поток" -c copy video.mp4
код был такой:
ffmpeg -re -i "ссылка на поток" -c copy video.mp4
>>1459413
Это проблема. Зря ты в mp4 сохранял. Если прямо нужно восстановить, то вот, держи http://vcg.isti.cnr.it/~ponchio/untrunc.php
Это проблема. Зря ты в mp4 сохранял. Если прямо нужно восстановить, то вот, держи http://vcg.isti.cnr.it/~ponchio/untrunc.php
Я тут вещание Бесконечного Сосача сделал, суйте в любимые видеоплееры и деградируйте.
rtmp://serv.valdikss.org.ru/sosuch
rtmp://serv.valdikss.org.ru/sosuch
>>1459416
Из анимублядского ничего не транслирует? И сделай таймаут для видео, а то сейчас мужик минут 15 пиздел так нудно, что я решил этот пост написать.
Из анимублядского ничего не транслирует? И сделай таймаут для видео, а то сейчас мужик минут 15 пиздел так нудно, что я решил этот пост написать.
>>1459418
спасибо. Буду пробовать восстанавливать.
Я изначально и хотел в мкв, но ффмпег ошибку выдал связанную с аудиопотоком. Работало только если звук перекодировать или сменить на mp4. Подумал что мне не особо важно в каком контейнере будет видео, а так проц напрягать не придётся.
Вообщем еще раз спасибо, буду думать
спасибо. Буду пробовать восстанавливать.
Я изначально и хотел в мкв, но ффмпег ошибку выдал связанную с аудиопотоком. Работало только если звук перекодировать или сменить на mp4. Подумал что мне не особо важно в каком контейнере будет видео, а так проц напрягать не придётся.
Вообщем еще раз спасибо, буду думать
>>1459422
Оно из всех вещает, просто тот тред добавился первее. Может, бота какого-нибудь для скипа прикручу. Я, на самом деле, хочу всякие сервисы, погоду, мониторинг серверов прикрутить, дома вещать это на отдельном мониторе круглосуточно.
Оно из всех вещает, просто тот тред добавился первее. Может, бота какого-нибудь для скипа прикручу. Я, на самом деле, хочу всякие сервисы, погоду, мониторинг серверов прикрутить, дома вещать это на отдельном мониторе круглосуточно.
>>1459424
Т.е. он по очереди целый тред крутит, а потом следующий? А рандомизация тогда где?
Т.е. он по очереди целый тред крутит, а потом следующий? А рандомизация тогда где?
>>1459425
Рандомизации и нет. Как только очередь заканчивается, подсасываются новые видео из старых тредов и ищатся новые треды.
Рандомизации и нет. Как только очередь заканчивается, подсасываются новые видео из старых тредов и ищатся новые треды.
>>1459443
mp4, пожалуй, единственный контейнер, который пишет все метаданные о потоках внутри себя в конец файла, поэтому и нельзя просто так останавливать процесс кодирования/муксирования. Любой другой контейнер пишет эти метаданные либо в начале, либо в произвольном месте файла, и таких проблем нет. А в mkv можно засунуть потоки буквально любого формата, за это его и любят.
mp4, пожалуй, единственный контейнер, который пишет все метаданные о потоках внутри себя в конец файла, поэтому и нельзя просто так останавливать процесс кодирования/муксирования. Любой другой контейнер пишет эти метаданные либо в начале, либо в произвольном месте файла, и таких проблем нет. А в mkv можно засунуть потоки буквально любого формата, за это его и любят.
>>1459833
И какой смысл вещать в h264/aac, если всё равно перекодируешь? Ещё и через гстример, лол.
И какой смысл вещать в h264/aac, если всё равно перекодируешь? Ещё и через гстример, лол.
>>1459833
wut? А по какому протоколу вещать? Я мультики вещаю по HTTP обычному, т.к. там файлы и буфер в 30 секунд, а тут-то лайв.
>>1459873
Что плохого в gstreamer? Смысл я выше написал. Можно и без перекодировки вещать, но не знаю, какой протокол матрешку поддерживает. Когда два года назад пробовал матрешку вещать, у меня ничего не получилось, хотя сейчас есть уже стримеры, надо бы еще раз потестировать.
wut? А по какому протоколу вещать? Я мультики вещаю по HTTP обычному, т.к. там файлы и буфер в 30 секунд, а тут-то лайв.
>>1459873
Что плохого в gstreamer? Смысл я выше написал. Можно и без перекодировки вещать, но не знаю, какой протокол матрешку поддерживает. Когда два года назад пробовал матрешку вещать, у меня ничего не получилось, хотя сейчас есть уже стримеры, надо бы еще раз потестировать.
>>1459884
Да DASH хотя бы. Форматы — VP9 и Opus. При таком bpp H.264/AAC неэффективны.
Ты писал, что единственный смысл в отсутствии перекодирования. А оно есть.
Да DASH хотя бы. Форматы — VP9 и Opus. При таком bpp H.264/AAC неэффективны.
>Смысл я выше написал
Ты писал, что единственный смысл в отсутствии перекодирования. А оно есть.
>>1459904
О, спасибо за хинт с DASH.
На мониторе-то у меня без перекодирования показывается, только в вещалке перекодируется.
О, спасибо за хинт с DASH.
На мониторе-то у меня без перекодирования показывается, только в вещалке перекодируется.
>>1395791 (OP)
Как перекодировать в 60FPS? Так и не нашел инструкции.
Как перекодировать в 60FPS? Так и не нашел инструкции.
>>1460187
Если не работает, то никуда не надо, очевидно же.
Если не работает, то никуда не надо, очевидно же.
ffmpeg -framerate 1/10 pic.png -c:v libx264 -pix_fmt yuv420p -r 2 vid.mp4
Пикча сама по себе нормальная, но в видео картинка дерьмо с лесенками. Пробовал крутить -b:v и -q:v, не помогает.
Как сделать заебись?
Пикча сама по себе нормальная, но в видео картинка дерьмо с лесенками. Пробовал крутить -b:v и -q:v, не помогает.
Как сделать заебись?
>>1460716
Значит проблема в другом. Тестируй для начала так:
ffmpeg -r 1 -loop 1 -i in.png -c:v libx264 -qp 0 -vf format=rgb48,format=yuv444p10 -t 10 out.mkv
Это должно дать почти минимальное количество потерь (для картинки разрешения меньше 1280x720). Потом начинай CRF/дискретизацию убавлять.
Значит проблема в другом. Тестируй для начала так:
ffmpeg -r 1 -loop 1 -i in.png -c:v libx264 -qp 0 -vf format=rgb48,format=yuv444p10 -t 10 out.mkv
Это должно дать почти минимальное количество потерь (для картинки разрешения меньше 1280x720). Потом начинай CRF/дискретизацию убавлять.
>>1460910
ffmpeg -r 1 -loop 1 -i in.png -t 10 -c:v libvpx -b:v 0 -crf 4 -pix_fmt yuva420p -y out.webm
Вообще, думаю можно и в yuv420p нормально сделать. Надо фильтры позадрачивать, по умолчанию ffmpeg просто выкидывает альфа-канал, а в данной картинке плавные переходы как раз все в альфе.
ffmpeg -r 1 -loop 1 -i in.png -t 10 -c:v libvpx -b:v 0 -crf 4 -pix_fmt yuva420p -y out.webm
Вообще, думаю можно и в yuv420p нормально сделать. Надо фильтры позадрачивать, по умолчанию ffmpeg просто выкидывает альфа-канал, а в данной картинке плавные переходы как раз все в альфе.
25 Кб, Webm
>>1460919
Или просто через IM: convert in.png -background black -alpha remove in2.png
Или просто через IM: convert in.png -background black -alpha remove in2.png
>>1460899
Что должно произойти?
Что должно произойти?
Несколько раз вроде за тред проскакивала ссылка, в которой написаны дефолты в ффмпеге. Но я смог найти лол. Можно еще раз?
>>1461106
Да, спасибо.
Да, спасибо.
>>1460919
Вот так нормально блендит: -lavfi 'color=s=1280x720;[0:v]overlay,format=yuv420p'
Вот так нормально блендит: -lavfi 'color=s=1280x720;[0:v]overlay,format=yuv420p'
>>1461212
Лол, макаба решила, что это бб-код.
-lavfi 'color=s=1280x720[bg];[bg][0:v]overlay,format=yuv420p'
Лол, макаба решила, что это бб-код.
-lavfi 'color=s=1280x720[bg];[bg][0:v]overlay,format=yuv420p'
Клею видосы вот так
ffmpeg -f concat -i vids.txt -c copy vid.mp4
У некоторых видосов в списке аудио нет, у некоторых - есть. У результирующего видео нет вообще.
Как починить?
ffmpeg -f concat -i vids.txt -c copy vid.mp4
У некоторых видосов в списке аудио нет, у некоторых - есть. У результирующего видео нет вообще.
Как починить?
>>1461238
У результирующего видео звука нет вообще, имеется ввиду.
У результирующего видео звука нет вообще, имеется ввиду.
9
Как обнулить звуковую дорожку? То есть, оставить тип такой же, но чтобы была пустота.
>>1459298
Вернуть -cpu-used 1 и не использовать значения выше единицы, кроме как для первого прохода. 4-5 фпс у vp9 это нормально.
> Пошло быстро, прямо как мне и надо, только вот картинка хреновая вышла. Можно еще что-нибудь сделать?
Вернуть -cpu-used 1 и не использовать значения выше единицы, кроме как для первого прохода. 4-5 фпс у vp9 это нормально.
Почему при -vf scale=1280:-1 видео кодируется быстрее, чем -vf scale=960:-1 ? Я вообще не понимаю, как это работает. Я думал, наоборот должно быстрее быть. Разрешение меньше и всё такое же.
>>1461899
tile columns multi-threading?
При ширине 960 пикселей можно только 2 треда максимум, а при 1024+ уже 4.
tile columns multi-threading?
При ширине 960 пикселей можно только 2 треда максимум, а при 1024+ уже 4.
>>1461911
Обходится очень легко, надо купить процессор с самой большой производительностью на ядро.
Обходится очень легко, надо купить процессор с самой большой производительностью на ядро.
>>1461916
Но оно же не станет на четырех от этого кодировать. Не обход.
Но оно же не станет на четырех от этого кодировать. Не обход.
>>1461908
Нет, количество тредов по степеням двойки только. (Значение опции tile-columns это логарифм по основнию два.)
>>1461911
Дели файл на части с помощью -ss/-t и запускай в отдельных процессах. У меня так даже в браузере прекрасно на веб-воркерах параллелилось, т.к. нормальных тредов там ещё нет.
Нет, количество тредов по степеням двойки только. (Значение опции tile-columns это логарифм по основнию два.)
>>1461911
Дели файл на части с помощью -ss/-t и запускай в отдельных процессах. У меня так даже в браузере прекрасно на веб-воркерах параллелилось, т.к. нормальных тредов там ещё нет.
>>1461921
Интересное решение, спасибо.
Интересное решение, спасибо.
>>1461921
Действительно, при 960 только 2 ядра нагружены, но если сделать 964 то уже около 3 ядер грузит. Это как объясняется?
>Нет, количество тредов по степеням двойки только. (Значение опции tile-columns это логарифм по основнию два.)
Действительно, при 960 только 2 ядра нагружены, но если сделать 964 то уже около 3 ядер грузит. Это как объясняется?
>>1461951
Кстати, интересно, в самом деле. Но не 3, а 4, и на границе 960 пикселей. Вероятно минимальный размер tile не 256 пикселей или он использует обрывок для последней колонки начиная с 961.
На линуксах удобно ps смотреть: ps -LC ffmpeg -o %cpu= | sort -n
На венде лучше ProcessExplorer какой-нибудь, дефолтный диспетчер почти ничего не показывает.
Результирующее разрешение 960 пикселей:
…много строчек с нулями (незагруженные треды)
0.8
0.8
0.8
0.8
76.0
96.4
Результирующая ширина 961 пиксель:
…много строчек с нулями (незагруженные треды)
0.9
0.9
52.3
54.7
77.0
86.3
Результирующая ширина 1280 пикселей:
…много строчек с нулями (незагруженные треды)
0.7
0.8
50.7
55.2
81.1
83.5
Т.е. между 961 и 1280 никакой разницы нет.
>>1461953
Ширина колонки видео, которая кодируется независимо от остальных, т.е. может параллелиться.
>но если сделать 964 то уже около 3 ядер грузит
Кстати, интересно, в самом деле. Но не 3, а 4, и на границе 960 пикселей. Вероятно минимальный размер tile не 256 пикселей или он использует обрывок для последней колонки начиная с 961.
На линуксах удобно ps смотреть: ps -LC ffmpeg -o %cpu= | sort -n
На венде лучше ProcessExplorer какой-нибудь, дефолтный диспетчер почти ничего не показывает.
Результирующее разрешение 960 пикселей:
…много строчек с нулями (незагруженные треды)
0.8
0.8
0.8
0.8
76.0
96.4
Результирующая ширина 961 пиксель:
…много строчек с нулями (незагруженные треды)
0.9
0.9
52.3
54.7
77.0
86.3
Результирующая ширина 1280 пикселей:
…много строчек с нулями (незагруженные треды)
0.7
0.8
50.7
55.2
81.1
83.5
Т.е. между 961 и 1280 никакой разницы нет.
>>1461953
Ширина колонки видео, которая кодируется независимо от остальных, т.е. может параллелиться.
>>1461951
Кстати, интересно, в самом деле. Но не 3, а 4, и на границе 960 пикселей. Вероятно минимальный размер tile не 256 пикселей или он использует обрывок для последней колонки начиная с 961.
На линуксах удобно ps смотреть: ps -LC ffmpeg -o %cpu= | sort -n
На венде лучше ProcessExplorer какой-нибудь, дефолтный диспетчер почти ничего не показывает.
Результирующее разрешение 960 пикселей:
…много строчек с нулями (незагруженные треды)
0.8
0.8
0.8
0.8
76.0
96.4
Результирующая ширина 961 пиксель:
…много строчек с нулями (незагруженные треды)
0.9
0.9
52.3
54.7
77.0
86.3
Результирующая ширина 1280 пикселей:
…много строчек с нулями (незагруженные треды)
0.7
0.8
50.7
55.2
81.1
83.5
Т.е. между 961 и 1280 никакой разницы нет.
>>1461953
Ширина колонки видео, которая кодируется независимо от остальных, т.е. может параллелиться.
>но если сделать 964 то уже около 3 ядер грузит
Кстати, интересно, в самом деле. Но не 3, а 4, и на границе 960 пикселей. Вероятно минимальный размер tile не 256 пикселей или он использует обрывок для последней колонки начиная с 961.
На линуксах удобно ps смотреть: ps -LC ffmpeg -o %cpu= | sort -n
На венде лучше ProcessExplorer какой-нибудь, дефолтный диспетчер почти ничего не показывает.
Результирующее разрешение 960 пикселей:
…много строчек с нулями (незагруженные треды)
0.8
0.8
0.8
0.8
76.0
96.4
Результирующая ширина 961 пиксель:
…много строчек с нулями (незагруженные треды)
0.9
0.9
52.3
54.7
77.0
86.3
Результирующая ширина 1280 пикселей:
…много строчек с нулями (незагруженные треды)
0.7
0.8
50.7
55.2
81.1
83.5
Т.е. между 961 и 1280 никакой разницы нет.
>>1461953
Ширина колонки видео, которая кодируется независимо от остальных, т.е. может параллелиться.
>>1461963
Ну то что 4 потока создаются я видел, только у меня нагрузка на них неравномерная, 2 ядра почти полностью, остальные частично. По времени кодирования проверил, у 960 за 4:11 а на 964 за 2:35 (минуты:секунды).
Ну то что 4 потока создаются я видел, только у меня нагрузка на них неравномерная, 2 ядра почти полностью, остальные частично. По времени кодирования проверил, у 960 за 4:11 а на 964 за 2:35 (минуты:секунды).
>>1461971
С 1280 также, подозреваю что-то плохо параллелится (какой-нибудь entropy coding или что-то вроде этого в слайдах было) и отсос.
Для восьми тредов граница — 1984 пикселей, кстати. Как-то не сходится (960/4=240, 1984/8=248), может где захардкожено, надо код посмотреть.
Значит вместо 960x540 намного выходнее делать 961x541 (или 964x542 для чётности) с точки зрения скорости кодирования. 1920x1080 до 1985x1117 апскейлить как-то не то.
С 1280 также, подозреваю что-то плохо параллелится (какой-нибудь entropy coding или что-то вроде этого в слайдах было) и отсос.
Для восьми тредов граница — 1984 пикселей, кстати. Как-то не сходится (960/4=240, 1984/8=248), может где захардкожено, надо код посмотреть.
Значит вместо 960x540 намного выходнее делать 961x541 (или 964x542 для чётности) с точки зрения скорости кодирования. 1920x1080 до 1985x1117 апскейлить как-то не то.
>>1461977
64.0
64.0
Вот так сходится. Наверно, последняя колонка может быть на один суперблок (64 пикселей) уже или что-то вроде этого.
>>> (256-960/4)4
64.0
>>> (256-1984/8)8
64.0
Вот так сходится. Наверно, последняя колонка может быть на один суперблок (64 пикселей) уже или что-то вроде этого.
>>1461985
64.0
64.0
Сука, меня дико заебали как капча, так и разметка.
>>> (256-960/4)×4
64.0
>>> (256-1984/8)×8
64.0
Сука, меня дико заебали как капча, так и разметка.
>>1461989
Капчу отменили же. Кстати а -frame-parallel 1 вроде не ухудшает скорость?
Капчу отменили же. Кстати а -frame-parallel 1 вроде не ухудшает скорость?
>>1461994
В смысле улучшает.
В смысле улучшает.
>>1461994
Для нерусских айпишников включили неразгадываемую, наверно. Там в больше чем в половине случаев цифры друг от друга неотличимы.
frame-parallel уже вообще не нужен, он только качество ухудшает.
Для нерусских айпишников включили неразгадываемую, наверно. Там в больше чем в половине случаев цифры друг от друга неотличимы.
frame-parallel уже вообще не нужен, он только качество ухудшает.
>>1461997
Просто он по умолчанию на 1 стоит, а нигде особо не писали что можно его на 0 ставить и безболезненно улучшить качество (правда всего около 100 Кб на 10 Мб экономится, но все же).
>frame-parallel уже вообще не нужен, он только качество ухудшает.
Просто он по умолчанию на 1 стоит, а нигде особо не писали что можно его на 0 ставить и безболезненно улучшить качество (правда всего около 100 Кб на 10 Мб экономится, но все же).
>>1461999
Я про это полгода пишут. Но никто ж не читает ни вики, ни прошлые треды. Всё это уже по сто раз обсуждалось, лол.
>а нигде особо не писали
Я про это полгода пишут. Но никто ж не читает ни вики, ни прошлые треды. Всё это уже по сто раз обсуждалось, лол.
>>1462001
Я видел это только в связке с однопоточным кодированием, по этому и не трогал его. А он оказывается ненужен совсем.
Я видел это только в связке с однопоточным кодированием, по этому и не трогал его. А он оказывается ненужен совсем.
45 Кб, 947x221
>>1462089
Ну мне лень разбираться с этими кодерами, хватит с меня EAC и foobara.
Годная вебм получится же.
Ну мне лень разбираться с этими кодерами, хватит с меня EAC и foobara.
Годная вебм получится же.
>>1462093
в он-лайне ебани в VP8
в он-лайне ебани в VP8
Кстати, когда режу mkv -ss -to(с микро-секундами и без), выходной файл стартует не с нуля, а с пятой-седьмой секунды. Как победить?
Перекаты-перекатики.
Тред утонул или удален.
Это копия, сохраненная 8 ноября 2015 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 8 ноября 2015 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.