WebM

Тред про кодирование вебмок.

Основным обсуждаемым здесь инструментом является 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
Проиграл с этих пердолегайдов. Это блять не рокет саенс, это ебаные вебмки! Скачать любой конвертер там за пару сек можно всё обрезать, изменить разрешение. Всё с человеческим гуи. Нахуя это?

>>1395798
Это для того, чтобы делать красиво.
Через гуй всегда получается большой размер при низком качестве, нормальных гуев пока не завезли.

>>1395798
> Пердолики с мокрописечными гуями вроде xmedia recode и прочие клепальщики распидорашенного кривопиксельного говна из порнотреда со своими воплями о ненужности консоли не нужны сами — пусть сначала научатся делать качественные вебмки, а потом уже лезут сюда с советами.

>>1395883

Прошлый тред: http://arhivach.org/thread/100617/

>>1395930
Но консоль это совсем не страшно, особенно если это помершеллчик.

Иногда в вебм треде проскакивает программа от Васяна. Просто указал путь до файла, путь сохранения, да лимит размера. Без пердольства. Где найти?

>>1396200
Последние строки оп-поста.

>>1395994
О, спасибо, а я в поиске не смог найти.

Кстати, насчёт оп-пасты: VP9 и 12 бит поддерживает, -pix_fmt +yuvXXXp12le. Немного помогает от бандинга на градиентах, но не так хорошо как отдельный дизеринг-фильтр. Первая картинка — 8 бит, вторая — 12, третья — дизеринг 8 бит.

>>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

Разумеется, ты сейчас про себя подумал «Нафиг это надо? Мне только смешной момент вырезать из кинчика и с пацанами под пивко поугарать». Ну так тред и не для тебя, проходи мимо. Возможно, вембрелейтед натолкнёт тебя на какие-нибудь размышления.

>>1396973
>Специалисты будут использовать те инструменты, которые обеспечивают максимально низкоуровневый доступ к процессу.
Ебать дебил.

>>1396996
Я ж написал, в случае надобности. Да, будешь и исходники читать, и в хекс-редакторе сидеть, и не только.

>>1397009
Я ваш гайд немного посмотрел. Там рекомендуется вручную битрейт рассчитывать (!). Вы же понимаете, что вы полностью поехавшие наркоманы-пердолики с карго-культом низкоуровневости? Все, что может быть автоматизировано - должно быть автоматизировано.

>>1397036
Про такие мелочи никто и не говорит. В оп-посте есть ссылки на обёртки, которые всё это делают (и от которых иногда приходится отказываться). Гайды обучают ffmpeg'у, базовому инструменту, в этом их ценность.

>>1397042
>и от которых иногда приходится отказываться
Так надо дорабатывать обертки до юзабельного в 99.9% случаев состояния, а не сидеть и пердолиться, кичась тем, что зазубрил зачем-то все ключи ffmpeg.

>>1397036
Попробуй серию SP в гуевине или на скриптиках с авторасчетом битрейта в 10МБ ужать без тотальных квадратов.
Для подобных фокусов и нужно небольшое понимание ффмпега.
А сложного там ничего нет, в чем надо было бы долго разбираться, если владеть английским хотя бы на уровне 5 класса общеобразовательной школы.
http://rghost.ru/8dzDksvLG

>>1397050
>Так надо дорабатывать обертки до юзабельного в 99.9% случаев состояния
Ну, значит ты ничего не понял из того, что я написал. Я даже вебм специально прикрепил.

>>1397054
То есть ты сидишь и подбираешь все руками, пока не ужмешь именно в 10 МБ? И сколько времени у тебя это занимает для одной вебмки? Интересна целесообразность подобного.

>>1397062
Да, я подбираю все руками.
Один раз посчитать в калькуляторе сколько будет занимать видео и оставить необходимое место под звук до лимита, потом просто добавлять звук с максимальным качеством таким, чтобы он влез в лимит.
Сама подгонка звука занимает совсем немного, он кодируется очень быстро, занимает много времени кодирование видео с хорошим соотношением размер/качество, но это уже от процессора непосредственно зависит.

>>1396973
> при конвертировании из 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

Тест.

>>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 и прочих известных релизеров почему-то.

>>1397217
Забыл добавить. В JPEG Y'CbCr формат с нестандартным цветовым пространством (не 601/709), да ещё и full range, так что здесь может быть куча дополнительных камней. Меня от одного PNG с его sRGB, гаммами, хер знает как работающими просмотрщиками и перекодировщиками уже тошнить тянет. А ещё говорят без потерь. Как в compare orig.png result.png -compose src diff.png посмотришь, так плакать хочется.

Гуй ещё не завезли?

>>1397533
https://github.com/BAXTER001/VideoNurd

>>1397217
> А какая задача-то?
В случае с пикрелэйтедами выше — как можно меньше потерять при конвертации из H.264 в VP9, а потом результат сконвертировать в RGB подобно тому, как это делают видеокарты, и сохранить в PNG. Нужно это было для оценки полезности применения VP9 c глубиной цвета 10 бит.

За инфу спасибо, открыл для себя много нового.

>>1397591
>как можно меньше потерять при конвертации из 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
>--screenshot-high-bit-depth=yes
О, ничего себе, это дефолт оказывается. Я таки 16-битные скриншоты значит использовал/сравнивал. Одна из возможных причин погрешностей, кстати — сравниваемые файлы должны быть максимально схожих форматов.

>>1397616
> 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

Вопрос к специалистам: как можно просто без регистрации и смс обрезать все чёрные кадры в начале, чтобы на превьюшку попадал первый не пустой?

>>1397675
Полсекунды от начала обрежь, если с ютуба скачал, и не еби мозги.
Можно отдельный кадр с превью добавить, если чернота слишком долгая в начале, чтобы часть звука не терять при ее обрезании.

>>1397675
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 пользователями, что могло бы привести к выработке более эффективных гайдов.

>>1397858
> Почему бы просто макабу не поправить, чтобы превью генерировалось из кадра посередине видео
Предсказуемость сломается. Нахуй нужно.

> Заодно и H.265 разрешить, давно уж пора.
Какие браузеры его поддерживают?

>>1397858
>Заодно и H.265 разрешить, давно уж пора
Бравзеры уже играют 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 тоже поставить?

>>1397981
Теперь для всего ставить васяноплагины? Нахуй не надо. Тем более как их загружать? Абу пришлось бы разрешить загрузку не только вебмок, а и других контейнеров под 265, короче ебли дохуя, толку нихуя.

>>1397981
> Что это значит?
Значит, что ты не сможешь сделать вебмку с определённым превью. А если и сможешь, то только путём впихивания кадра в середину видеоряда, что может нарушить целостность его восприятия.

> Нужно чтобы превью соответствовало содержимому
Сейчас это лежит целиком на плечах создателя вебмки — он может выбрать для превью тот кадр, который по его мнению лучше всего укажет на содержимое.

> Вы же для 10bit ставите плагины, в чём проблема для H.265 тоже поставить?
Их ставят единицы. А макаке, я полагаю, нужно чтобы работало у большинства.
А ещё патентные отчисления за форматы. Неизвестно, где находится хостинг, и нужно ли там их платить.

А зачем эту хуйню прикрепляют вообще?

>>1397989
>Теперь для всего ставить васяноплагины?
Скоро и нативно будет, тем более на 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
>типа того же VLC
Лол. Я его ставил, так он здесь не заработал из-за https. Да и vp9 он играл плохо.

>>1398025
> И кому это надо?
Клепальщикам вебмок для сосача, кому ещё.

> Ты понимаешь, что вставляя левый кадр в первую секунды видео, ты таким образом нарушаешь его визуальное восприятие?
Если кадр вставляется в середину видеоряда, его восприятие нарушается значительно сильнее.
Кроме того, кадр для превью можно вставлять отдельной дорожкой, тогда его при воспроизведении вообще не будет видно.

> И что обычное среднее видео, сделанное без применения костылей, будет часто иметь кривое превью?
Обычное среднее видео не влезет в лимит 6мб.

> Ещё раз говорю — так больше никто не делает, насколько я заню.
Потому что у порноблядей нет культуры лепки вебм, вестимо.

> поддержки никакой в инструментах нет
https://github.com/pituz/webm-thread/blob/master/tools/add-preview

> Если действительно надо и делать по-нормальному, то нужно брать первый кадр из второго видео-потока.
Скрипт по ссылке выше так и делает. Используется особенность ffmpeg: он считает дефолтной видеодорожку с большим разрешением.

> 2к-постовые треды очень тяжело ворочаются, особенно с включёнными скриптами
Ну да, надо бы перекатывать на тысячном посте где-то.

>>1398026
> Я его ставил, так он здесь не заработал из-за https.
Это зависит от фазы луны отношения к твоему айпишнику клаудфлары: если она пускает без куков и javascript-защиты, то всё работает.
А вообще да: то, что vlc не может использовать браузер для получения контента и вместо этого сам ебётся со ссылкой, портит всю малину.

>>1398047
>Если кадр вставляется в середину видеоряда, его восприятие нарушается значительно сильнее.
Не, я не предлагал так делать. Просто кадр из середине намного чаще передаёт суть видео, чем первый.

>Обычное среднее видео не влезет в лимит 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 никаких недовольств не выказывают от подобных файлов.

Хотя это, конечно, курам на смех, а не документация.

>>1398331
Я это встречал то ли в педивикии, то ли по первой ссылке из твоего списка, но теперь там этого нет. Нагуглилось только https://groups.google.com/a/webmproject.org/forum/#!topic/webm-discuss/J8xN-Fc2rAQ .
> Зато есть ряд вещей, подразумевающих, что так делать можно — структура Track, описания полей и т.д
Наследие матрёшки же. Но похоже, действительно, от идеи ограничить кол-во дорожек разработчики ушли.

Пацаны, а есть способ качать видео с ютуба в рам и смотреть через мплеер? прям как браузер делает.

>>1398471
mpv https://www.youtube.com/watch?v=dQw4w9WgXcQ
Давно уже умеет.

>>1398471
> в рам
Ну так- то в кэш..

test

ГОВНОЕДЫ СОСНУЛИ ХУЙЦА

>>1398988
Что ты с моей вебмкой сделал, ирод? Даже я так над ней не издевался!

>>1395791 (OP)
https://2ch.hk/b/res/102325329.html#102325329

>>1399011
> 404 Not found
Молодец, чё.

>>1399031

test

>>1399041
Скорее всего ненулевой профиль у 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]

>>1399058
весь не помещается.

Test.

>>1395791 (OP)
а ну ка ся

>>1395791 (OP)
а ну ка ся

>>1399060
у тебя не пересылает на гугл . как тот.
читайте коменты на скрине

Пасаны - http://2ch.hk/b/res/102347348.html здесь вента-опущенка говорит что пинукс спизжен у гавно-мака. обоснуйте ему плес.

>>1399209
>мам, ну скажи ему
Вся суть колясочников.

Кто пробовал, что из нелинейных видео-редакторов под *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 лет так ничего и не сделали.

>>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
Но без сорцов и упрощённая версия.

>>1400243
Ещё в ней нельзя экспортировать лосслесс, только пожатый встроенным кодеком H.264 с ограничением по разрешению. Фигня, короче.

>>1396070
Подожди, помершелл ведь не умеет exe открывать из-за каких-то политик безопасности. Как ты это сделал?

>>1400520
У меня из коробки норм работает

Мимо другой анон

>>1400185
Что конкретно нужно? Всякие эффекты?
Бери редакторы на фреймворке MLT (kdenlive, shotcut). Если их возможностей мало — пробуй blender.

>>1400670
Хоспади одни негры и белые бабы с неграми. Как же американцы заебали с насаждением белых баб на черные хуи.

>>1400737
Ну да. Эффекты, маски, слои и т.д. Большинство программ из того списка, судя по скриншотам, что-то на уровне Movie Maker.
Вот, кстати, ещё интересно: https://en.wikipedia.org/wiki/AviSynth#AviSynth_for_non-Windows_operating_systems AviSynth с открытыми исходниками, так что зашквара нет.

Печально, что практически все гайды пишутся под платную проприетарщину типо After Effects и скрипты на AviSynth.

>>1400761
> Большинство программ из того списка, судя по скриншотам, что-то на уровне Movie Maker.
Ты не скриншоты смотри, а списки фич.
> Вот, кстати, ещё интересно: https://en.wikipedia.org/wiki/AviSynth#AviSynth_for_non-Windows_operating_systems
Практически все плагины из AviSynth уже портированы на AvxSynth.

>>1400771
>Ты не скриншоты смотри, а списки фич
Так я и спросил, кто что использовал. Список фич не показатель.
>уже портированы на AvxSynth
Чего-то он дохлый какой-то, судя по активности. Да и поведение слегка отличается от вендового + оптимизаций мало:
https://github.com/avxsynth/avxsynth/wiki/Built-in-Functions

>>1400790
> Так я и спросил, кто что использовал.
Тыкал я всё из твоего списка, использовал же только kdenlive и немного blender.
Другое дело, что я мувимэйкер и вегас, на которые ты ссылаешься, ни разу не видел.
> Список фич не показатель.
С хуя ли?

Посоны, поясните за -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 сам разные видео, сделай сравнение по скриншотам и метрикам, всем будет интересно (серьёзно).

>>1401289
>Сэнкоди с --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

>>1401308
Сырно пизды получила, я почему-то этому рад.

>>1401340
Ты мерзавец.

>>1401308
Меня возбуждает побитая и плачущая Сырно. Пора на ичан?

>>1401313
Вот я, кстати, в данный момент нулевым дедлайном, но в 4 потока с -тайл-колумнс 6, кодирую под лимит в 6 МБ.
Завтра посмотрим, что из этого получится.

>>1401368

>>1401313
0:46
1:12
В каких-то случаях у --good деталей детали чуть лучше сохранились, так что тут хз даже как сравнивать. А видео-дорожка --best всего лишь 193 на килобайта меньше весит:
8046253 best.webm
8239733 good.webm

>>1401371
Кстати, тут недавно обнаружил, что некоторый софт очень не любит нечётные разрешения, а некоторые кодеки даже не поддерживают (H.264). 860x484 вроде чаще используется если нужно 480p. Или принудительно скейлить в 854x480 как на ютубе, например.

>>1401391
Ну это не для софта же кодируется, в софте нужно с оригиналом работать.
Кстати, на мой взгляд, делати лучше сохранились в best, так как в good над шляпой у нее размытие больше.
Да и вообще при гуд мыла побольше, как обычно при нехватке битрейта.
Вообще дедлайн 0 все же позволяет уменьшить количество квадратов при сильной нехватке битрейта, только я старые версии файлов с -cpu-used 0 не сохранил, чтобы показать в сравнении, оставил только с -deadline 0.

>>1401420
>Вообще дедлайн 0 все же позволяет уменьшить количество квадратов при сильной нехватке битрейта
А засекал сколько по времени оба варианта кодируются? Я пару раз попробовал и решил что это совсем не практично. Даже tile-columns=0 на 720p всё слишком печальным делает.

>>1401452
-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 и т.д.

>>1401659
ВиртуалДаб, но я не уверен что он все еще поддерживается

>>1401313
Первое видео без дедлайн 0. Размер видео дорожки - 3982kB.
У второго - 3898. Итого 84kB выигрыша(2.1%) за более чем 5 часов кодирования.

tst

>>1401710
Лучше в тот же размер кодируй и так, чтобы хоть в одном видео были чёткие сцены. А то и там, и там мыло, как такое сравнивать?
Впрочем, я б вообще не стал говорить, что 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

>>1401752
Оригинал тоже говнина полная хоть и няшечки. Но однозначно у good на волосах деталей больше осталось.
Тестируй отсюда: https://media.xiph.org/video/derf/ Или хотя бы качественные H.264 рипы бери.

Вечером сравним, короче.

user agent test

user agent test 2

>>1401800
Без звука.
Первое -deadline 0, второе -cpu-used 0.

>>1401850
Со звуком.

test user agent

Есть способ посмотреть дефолтные значения параметров для установленной сборки ffmpeg?

>>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 и пересобери.

Я тут подумал, что следовало бы сравнивать -deadline 0 и -speed 0 при -b:v 0 -crf 10, например, ну и длительности пару-тройку минут.
Тогда можно было бы посмотреть сколько реально экономит дедлайн 0 при одинаковом качестве.

>>1402267
Я это ещё в >>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 это сделать, причём вырезать из исходного ролика два фрагмента и слепить в один файл?

>>1402442
Он где-то писал, что консолечка не нужна или поучал кого-то как кодить вебм?

>>1402662
Ну так тред не для него. Пусть обращается к разрабам своей мокрописьки.

Немного не в тему, а тут на дваче есть раздел или тред посвященный проге Source Filmmaker?

>>1402690
двач умер (нету такого треда)

>>1402712
а как теперь 2ch.hk сайт называют?
>нету такого треда
Ого не ожидал, столько говна есть, а полезных тредов почти нет.
Спасибо вам хоть про ВебМки тред запилили.

>>1402717
Сосач, харкач, абучан, неназываемый (в местах не столь отдалённых).

>>1402722
Сосач будет всё же неверным, на мой взгляд, потому что возникнет путаница с обозначением сайта в период араспоожения на 2ch.so

>>1402729
Как раз тогда и возник этот термин и до сих пор живёт. Сосач это прикольно. Сосать хуй это прикольно. Народу нравится.

>>1402737
Мне всё же больше нравится харкач, в таком пренебрежительном сравнении с харчком на пол. И как бы олицетворение аудитории - быдлота, постоянно плюющая на пол, себе под ноги (лично меня это очень раздражает, например)

>>1402742
Голосую за хоркач, сосут тут мало, в основном на хуй посылают и срут везде.

Набыдлокодил скрипт для mpv по типу OSD в ffdshow. Удобно для сравнения по скриншотам.
К сожалению, номер кадра и его тип так не показать, и OSC тоже не работает из-за кривости API. Накорябал небольшой враппер и для ffplay, так всё получше с доступной информацией, но сам ffplay жутко кривующий, да и скриншотить надо отдельно.

http://pastebin.com/jZKEnkkq

Зашел к вам в /s, почитал треды, пиздец у вас тут. Заместо политики придумали себе развлечение - сраться по поводу осей, причем в каждом ебаном треде. Я просто охуеваю с вас, люди.

>>1403042
Новый ньюфаг детектед в этом ИТТ треде.

>>1403152
>Новый ньюфаг
>Масло масляное
>Пердолик линукс
Ну ты понел.

>>1403279
Лолировал заливаясь хохотом от смеха с этого нового ньюфага в этом ИТТ треде.

Ты поди ещё и на сосаче не сидел, ньфажина нубская? А про тот двач вообще не слыхал? Может ты и про коробочку фотонов не в курсе, пёс шелудивый?

>>1403283
Не на того вскукарекнул, дауненок.

>>1395791 (OP)
Антон, какого хуя на моем хакинтоше вместо вебма показывает вот такую поебень? Расскажи скорей, как пофиксить.

>>1403328
Никак, пока здешние webm-бляди кодируют видео в швабодных кодеках.

+

Забавно, не думал что VP10 хотят настолько серьёзно улучшить. Если получится, то H.265 точно хана, с его-то ценами.

>>1397652
>Кстати, говорят что в VP10 будет 12бит по умолчанию и что это таки сказывается на качестве
Вот слайд.

>>1403332
А можно как-то накатить швабодный кодек в макось?

>>1403362
Обратитесь в сертифицированный (R) сервис (c) центр (тм)

Объясните дауну почему не видит файлы и куда их надо кидать.

>>1404002

Даун репортинг ин. С большинством проблем разобрался, за исключением того, что получается музыка без картинки. Поаутирую у вас еще немного.

>>1404055
Либо убери -map 1:a, либо добавь перед ним -map 0:v

>>1404080

Помогло, благодарю.

Можно ли в ffmpeg показывать только прогресс без всей этой шапки с опциями и инфой о файле?

Дрочит консоль вместо удобного интерфейса, да вы тут все ебанутые.

Xvid4psp-кун

>>1404387
>эта избыточность

>>1404387
ты бы еще мокропську притащил, клован обоссанный

>>1404387
В консольке удобнее, быстрее и качественнее, а главное все под контролем.

>>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
Тоже ведь, скорее всего, в таком ключе рассуждали — зачем мне разбираться, автор гуёвины уж точно мастер своего дела и за меня всё продумал. Нажал кнопку и готово.

>>1404438
> яндекс браузер
> называет кого-то клованом

Насколько оправдано использование quality=best у vp9? Кодировать 30 секунд пару часов это же ебануться можно, какая будет разница с дефолтным good?

>>1404605
Ты тред вообще читаешь?
Вообще лучше всего использовать -quality good -cpu-used 0 (или -speed 0, что одно и то же).
Так и качество/размер хорошее, и кодируется не слишком долго.
Но с введением лимита в 20МБ можно, конечно, и просто -good, только битрейта побольше надо выставить, или просто -b:v 0 -crf 15 где-нибудь.
-best стоит использовать когда что-то совсем годное решил закодировать по лимиту в максимальном качестве и можешь подождать день-два-три, но такие ситуации редко возникают.

>>1404605
Не стоит. Разница не существенна и не стоит того, чтобы кодировать вебмс часами.

>>1404621
>Но с введением лимита в 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.

>>1404621
>или просто -b:v 0 -crf 15 где-нибудь.
Нафига столько, кстати? Я 23-25 для коротких клипов ставлю, там с лупой надо смотреть, чтобы отличить. 15 это дикий перерасход битрейта обычно.
В позапрошлом треде ещё проскакивала идея ставить -qmin 15, чтобы зря не расходовать битрейт. Особо не тестил, но выглядит интересно.

>>1404657
> Нафига столько, кстати?
2 0 М Е Г О В
0
М
Е
Г
О
В

>>1404672
Но ведь не запостишь потом никуда, кроме hk/b/ нигде таких лимитов больше нет.
Я тут VapourSynth осилил. Думал какая-то неизвестная прыщавая поделка, а он чуть ли не популярнее AviSynth уже и фильтров куча крутых портировано. Было бы интересно взять какой-нибудь фиговый сорец, через flash3kyuu_deband пропустить и в 12бит VP9 закодировать.

>>1404707
>2015
>сидеть где-то кроме сосача

>>1404818
> сосача
> 2015
> сосач умер два года назад

>>1404657
Проверил, действительно, даже при -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

>>1405084
Впрочем, я бы не сказал, что -vf format=rgb48,scale=out_color_matrix=bt709,format=yuv444p даёт результат хуже. Похоже, у ffmpeg всё же есть dithering при конвертировании с понижением битности; дефолтная конвертация 8bit RGB → 8bit YUV просто ужасна.
Зато VapourSynth погибче будет и фильтры к нему можно дописывать.

Способ добавления превью через вторую дорожку не работает в бете лисы. Неславное грядёт время.

>>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. Что ещё посоветовать?

>>1405290
>В исходнике стерео, аудио дорожка, AAC 48000Hz, я хочу сконвертить в 41000, как?

-ar 44100

>На будущее, а если дорожка пятиканальная, как её конвертнуть в двухканальную?

я лично делаю это в саундфорже, но в ффмпеге тоже есть такая возможность.
https://trac.ffmpeg.org/wiki/AudioChannelManipulation

>Для x.265 какой лучше контейнер?

не вижу причин использовать не mkv

>А аудио, может нахуй AAC?

может быть

>>1404264
-hide_banner -loglevel error -stats

>>1405269
Есть подозрение что из-за этого: 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-ой строчке не проверяется, что трек уже мог быть добавлен и поэтому луп крутится до последнего видео-трека.
Можно зарепортить но мне лень.

>>1405354
спс

>>1395791 (OP)
w

>>1405269
>>1405434
https://bug1208799.bmoattachments.org/attachment.cgi?id=8666430 накати@проверяй

>>1405647
>накати@проверяй
Нужно просто ждать обновления?

>>1405713
Ещё не заревьюили, но вроде разработчик нового демуксера согласен, что баг.

Что не так сделал?

>>1405907
Убери лишние \

>>1405907
Отступы и scale поправил, теперь так.

>>1405914
В твоем случае нужно вообще убрать \ - они нужны были, чтобы скрипты писать не в одну строку, а ты просто все вводишь в консолечку - в одну строку

>>1405921
Океей.

>>1405928
Ты перед pic.jpg забыл -i
Все, я лимит ответов на совсем глупые вопросы исчерпан

>>1405933
Спасибо.

>>1404818
> 2015
> Сидеть в /b/

>>1405968
> Илитка подала голос.

>>1405940
У меня встал, что со мной не так?

>>1406436
Ты анимедебил.

>>1406439
Да вроде аниме не смотрю, а это лечится? Как с этим жить теперь?

>>1406441
Не заходить на сосач.

>>1406447
А может просто пофапать на эту милашку? Звучит заманчиво, а жене сказать что сегодня болит голова.

>>1406458
Пацаны уважать не будут.

>>1406458
Ещё можно найти пикчу на iqdb.org и смотреть другой арт этого художника. Теги авторства обозначаются на gelbooru красным цветом, а Роскомнадзор, возможно, кого-то от этого недуга спас.

Ну и не стоит забывать о том, что это тред о кодировании вебмок, а не о тохоарте, и не разводить тут не относящихся к нему дискуссий. Для touhou где-то тут была отдельная доска..

>>1406458

У меня тут назрел вопрос, почему на этой доске пишут: оперативную систему и браузер или например : firefox based, это ведь некорректно правильней было бы написать Gecko.

> это ведь некорректно правильней было бы написать Gecko.
Потому что gecko -- это не браузер, вот почему.

>>1406748
Блять, я понимаю, но "Firefox based" тоже не браузер, а что-то основанное на лисе, а значит логичнее было бы писать название движка , а не самого браузера.

Вышла статья со сравнением эффективности 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 (который используется в т.ч. в браузерах) соснул полностью.

>>1407076
Ох, лол. А почему не используют ffvp9?

>>1407082
Потому что для этого надо тащить целый libavcodec, авторы которого клали на патенты сшп.

>>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, ему похуй. А для лисы сраные прослойки в виде гстримера с его вечно глючными декодерами.

>>1407151
>и только 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

>>1407173
Да, Broadwell и Skylake, причём на первый в прошлом треде жаловались как недостаточно производительный: http://arhivach.org/thread/100617/#1377625

>>1405269
>>1405647
Я тут рылся в коде и случайно нашёл wokaround: надо поставить media.format-reader.webm в false, тогда будет использоваться старый демуксер.
Можно пользоваться этим хаком, пока не пофиксили.

Тест колорспейса превью на сосаче. Слева протеганный BT.709, справа протеганный BT.601.
Firefox, как оказалось, всегда показыват BT.601, несмотря ни на какие теги и вне зависимости от разрешения. В хроме не проверял. mpv корректно работает с тегами цветового пространства. Видимо, пока в браузерах поддержка видео в таком зачаточном состоянии, нужно всегда использовать BT.601 для совместимости с помощью принудительного -vf colormatrix=bt709:bt601 для всего HD.

>>1407252
Ну да, генератор превью думает, что видео всегда в BT.601. Я ебал весь этот хаос, происходящий в видео-энкодинге.

>>1407256
> генератор превью
Так это ж ffmpeg!

>>1407281
Ну так ясно дело. Но ведь можно вручную поставить цветовое пространство YUV на входе с помощью -vf scale=in_color_matrix=X при генерации JPEG из WebM. Эвристики можно использовать как у mpv, так вроде все делают. От ffmpeg ждать исправления, думают, не стоит, поломает кучу всего, что сейчас завязано на такое поведение.
Хотя, я пожалуй слишком много хочу от кодеров сосача, которые даже превью брать из кадра посередине видео или yuv444p не осилили.

>>1407298
> превью брать из кадра посередине видео
Не нужно, блять, этого делать! Превью из первого кадра — стандарт имиджборд. Так делается везде — на форчане, краутчане, гелбуре, различных мелкобордах. Авторы вебм под это давно подстроились, и ставить им палки в колёса я не вижу никакого смысла.

> или yuv444p
Тут дело скорее всего в версии ffmpeg. Вангую, что на сервере стоит какой-нибудь стабильный debian или centos и ffmpeg из репозитория.

>>1407328
>на форчане, краутчане, гелбуре, различных мелкобордах
Хм, не знал. Но на 8chan (и всех бордах на tinyboard и infinity next соответственно) из середины.
>Авторы вебм под это давно подстроились
Да ладно. Что-то не видел в форчановских вембах такого изврата с вставкой левого кадра в начало видео.
>и ставить им палки в колёса
Это прежде всего ставит палки в колёсо обычным пользователям, которые привыкли к нормальной генерации превью во всём десктопном софте и вдруг встречают такой идиотизм. Притом что кто мешает использовать отдельный трек для кастомного превью, если так уж надо?

>какой-нибудь стабильный debian или centos и ffmpeg из репозитория
Да понятно. Особенно будет смешно макаке, когда кто-нибудь откопает RCE под древний ffmpeg. В libvpx-то вон сколько находят в каждом выпуске FF и помечают как критические, а в дефолтном ffmpeg куча форматов.

>>1395791 (OP)
Посоны, как wget'ом слить все webm'ки из треда?

>>1407346
> Что-то не видел в форчановских вембах такого изврата с вставкой левого кадра в начало видео.
Не умеют, наверно. В местном анимублядском это на каждом шагу.

> Это прежде всего ставит палки в колёсо обычным пользователям
Это которые с 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 не даёт оверхэда и что это не вызовет другие проблемы.

>>1408600
>Десктопный софт часто сосёт на генерации превью из видеодорожек с единственным кадром
Можно секунд 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 могут себе позволить.

Кек новый мем.
Кек.
https://2ch.pm/media/src/9670/14433925259590.webm
https://2ch.pm/media/src/9670/14434896181150.webm

>>1407151
> ffvp9 почему-то по умолчанию ещё не используется
А может и используется. В хроме не тормозят вебм, а в лисе тормозят.

Накопилась целая папка с годными фапабельными вебмками.
Как можно сделать webm - шоу? ( по аналогии со слайд-шоу)
Хотелось бы настроить количество повторов webm, после чего должен происходить переход к другой вебмке.

>>1408711
В 41 лисе вообще не тормозят, даже не древних ПК.

>>1408720
Дело не в железе и не в ОС, а в самой лисе.
Посмотри как себя ведет процесс plugin container.

>>1408739
Что-то странная у тебя лиса.
Попробуй все же на 41 релизной.

>>1397688
>Можно отдельный кадр с превью добавить

Будьте любезны, напомните как это делается.

>>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'

Почему-то кодировка в файле проебалась, ну да ладно.

>>1408741
Пробовал уже.

>>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

>>1408718
for f in *.webm; do mpv -fs -loop 5 $f; done

>>1408830
> Если используется неускоренный видео-вывод, например.
А что, лис умеет иначе? Я думал, что в десктопной версии он всегда рендерит в пиксмап в оперативке, который потом натягивает на веб-страницу, и о прикручивании всяких xv, vdpau, va api и прочих ускоренных интерфейсов там вообще речи не идёт.

>>1408844
Через OpenGL можно, например, в том же хроме интерфейс весь через OpenGL рендерится (Aura их).

>>1408847
Всмысле, что я не знаю, как лиса на самом деле рендерит видео, поэтому предложил в фуллскрине попробовать. Может хотя бы фуллскрин они оптимизировали.

>>1408830
>Попробуй в фуллскрине может.
Всё также - тормозят.
>Какое у видео разрешение-то?
Проверял на 720p и выше

>>1408857
gfx.content.azure.backends в skia поставь ололо
Я хз, надо дебажить и исключать одну проблему за другой по очереди. Зайди в about:support, посмотри что там с GPU/WebGL. Попробуй какой-нибудь лёгкое VP8 или Theora видео того же разрешения, чтобы исключить проблему на стороне декодинга. Попробуй в найтли/бете и т.д.

>>1408866
>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 на секунду-две, а вхроме просто просадки фпс.

Надеюсь когда-нибудь они это исправят, а пока есть хром.

>>1408893
Так ты не сказал что у тебя в chrome://media-internals

>>1408898
libvpx, и оказалось что тестовое видео в vp9. Придется самому конвертировать, куда-то пропали все vp8 example

>>1408830
В найтли уже работает.
yuv444p и 10/12bit им зарепортить что ли.
Вебмки с webvtt треком тоже работают в 41 и 44. Странно, когда они опять успели исправить, недавно только проверял.

test

Дайте нормальную прогу, что бы без пердолизма и матана - выбрал файл и получил WebM.
тренд не читал

>>1409186
ffmpeg.

>>1408988
На win тоже пришло. Теперь за будущее можно не бояться в этот раз

>>1409186
WinFF

>>1409186
https://kagami.github.io/webm.js/
Даже устанавливать ничего не надо!

http://permalink.gmane.org/gmane.comp.multimedia.webm.devel/2479
>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

Как добавить субтитры без ожидания, которое при указании -ss перед -i? Это было весело, пока не потребовалось вырезать отрывок в конце 2-х часового фильма.

Не про вебм, но про ффмпег. Поясните идиоту, вот ффмпег и https://github.com/Nevcairiel/LAVFilters/releases одно и тоже? Или второе форк? Или что-то отдельное? Я пытался читать, но я видимо слишком глупый для всех этих перефоркиваний всего подряд. Или ффмпег это по сути комбайн, в который входит куча библиотек, которые разрабатывают разные люди?

>>1410082
> -ss после -i
фикс

>>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 в вики кто-нибудь.

Я тут ещё немного потестил и охуел. Короче, переделывайте все свои HD вебмки, они неправильные. Если исходник был HD, то надо делать обязательно конвертацию в BT.601, иначе цвета в браузере поедут. Верхний по вертикали — BT.709 прочитанный как BT.601, средний — BT.709 преобразованный в BT.601 и прочитанный как BT.601, нижний — оригинальный BT.709 прочитанный как BT.709.

>>1410213
Какие браузеры на каких системах и на каких видеокартах потестил? А то, знаешь ли, результаты ведь могут различаться.

>>1410253
От видеокарты и системы это не зависит. Разве что в хромиуме вроде правильно, но он у меня падает на таких здоровых, надо будет поменьше сделать. Да и даже если в одном из браузеров правильно, то ничего не меняет, надо под оба делать одинаково.
Открой сам оба видео из >>1407252 и сделать скриншоты. Оба видео должны быть одинаковыми и как на пикрелейтеде.

>>1410264
>От видеокарты и системы это не зависит
Ты охуенно осведомленный, если знаешь, как устроен видеовывод в разных браузерах (в т.ч. проприетарных) на разных системах. На другой системе может оказаться другая реализация, может быть прямое скармливание потока видеосистеме, а там 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 сделать так, чтобы и в браузерах всё выглядело правильно.

>а кодировать HD в 601 ради того
А в чём проблема? У фреймов VP9 можно проставить тег цветового пространства. Все вменяемые проигрыватели (браузеры в их число не входят) их понимают. И не забывай, что то же превью как минимум на двух разных бордах (а наверняка и всех) при использовании BT.709 будет неправильными.

>у одного анона его любимый браузер коряво воспроизводит видео
Давай может ты сделать скриншоты, а мы посмотрим, как разные системы влияют? Толку от твоих теоретизирований?

>>1410371
Ну и ладно бы там HD→HD. Так ведь скейлинг HD→SD, как это часто бывает, даёт неправильный результат вообще везде.

>>1410371
>Ясно дело, что я имею ввиду софтовую реализацию декодера, от видеокарты она зависеть ну никак не может. libvpx
Да почему ты так уверен-то? Могут взять, да направить поток на системный медиафреймворк, это было бы самым рациональным решением. Тут https://en.wikipedia.org/wiki/HTML5_video#Browser_support этот вариант вообще как будто дефолтный преподносят, хотя это может быть устаревшая информация. Собственно, декодинг видео нам не важно где произведен, аппаратно или программно, даже программно декодированные YUV кадры рациональнее всего посылать на VMR/EVR/рандомнойсистемыотрисовщик/, а тот, соответственно, может делегировать конверсию в RGB драйверу видеокарты, а там уж как бог на душу пошлет, так и отконвертирует, и уж точно беспардонно насрет на все теги (их вообще кроме madVR на винде кто-нибудь почитает?). Вот такого подхода и стоит ожидать, по крайней мере, от браузеров Майкрософта и Эппл.

>Я в треде уже кучу раз писал про эвристики, которые используют многие плееры
Эвристика сводится к упованию, что отрисовщик и драйвер не обосрутся, а я лично видел, как релизы 848х480 рисовались то в 601, то в 709 в зависимости от версии драйвера Nvidia, и ведь тут даже предъяв не может быть: стандарта нет, на тэги отрисовка у большинства юзеров обычно срет, да даже кодеры в релизах, сейчас проверил, даже утянутый с баки "лучший" релиз одного бдрипа от сраных coalgirls - тэга не имеет, только половина из оказавшихся на винте нескольких бдрипов имеют тэг, а с твшками все наверняка будет еще печальнее.

>Давай может ты сделать скриншоты, а мы посмотрим, как разные системы влияют
Пока под рукой только хром и лиса на XP, результаты как и у тебя - лиса обосралась, хром молодец, а значит ничего городить с подгонкой стандартов не нужно. Хотя и тут фиг знает, вдруг хром все гонит в 709, нужно же проверять и SD.

>>1410392
Переделать в 601, удалить тэги - и будет отображаться правильно везде.

>Да почему ты так уверен-то? Могут взять, да направить поток на системный медиафреймворк
Ну потому что я смотрю в 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
>Хотя и тут фиг знает, вдруг хром все гонит в 709
Если оба видео одинаково выглядят, то нет, т.к. правое BT.601.

>>1410540
>Ну дела, ничего не работает, нахуй эти webm!
Надо просто долбить лисоделов этой проблемой, в хроме же вроде норм. Твой вариант сделает нормальные цвета на лисе, но может их поломать на других не-хром браузерах или на мобильных устройствах, и это надо пробовать, а не безосновательно полагать, что их кодят так же как лису.

>>1410569
>Надо просто долбить лисоделов этой проблемой
В случае игнорирования тегов согласен. В случае эвристики по разрешению могут и послать, так что как минимум тег BT.709 на HD надо ставить. Всегда правильно в апстрим долбить, конечно, тут ты прав. У меня штук 5 багов к ним уже накопилось. Просто здоровый апстрим это такая непоротливая махина, что всегда проще вокрэраундом заделать. Да и возни сколько, и когда это задеплоят только. В случае с многодорожечными webm просто повезло выйти сразу на разработчика, поэтому быстро исправили. А обычный баг они фиг знает сколько мариновать будут, у них там десятилетние открытые ишью в багзилле не редкость. Может как-нибудь и зашлю, если не лень будет.

>но может их поломать на других не-хром браузерах или на мобильных устройствах
Есть эвристика по разрешению, но не воспринимает теги? Как-то сомнительно.

Кстати, я тут глянул на свежем релизе Shimoneta от SallySubs и таки тег стоит. И цветовая матрица, и tv levels.

>>1410569
Да, лол, долбить тогда заодно и админов имиджборд, т.к. для превью всегда BT.601 используется. В общем, ты охуеешь делать всё по-нормальному.

>>1410578
>2015г
>борды

А ты не заметил, что концепция борд протухла и все это устарело? Поэтому этим говном серьезно никто не знаимается, на самом деле все протухло и требует принципиальной смены идей.

>>1410569
Проверил — хром без тега HD показывает как BT.601. Теги правильно интерпретирует.
Вот для теста: HD BT.601 с тегом | HD BT.709 с тегом | SD BT.601 без тега | HD BT.709 без тега
Все должны выглядеть одинаково. VP8 всегда BT.601, кстати, тоже надо делать конвертацию, если на входе был BT.709.

>>1410971
Ты йоба-дизайнер с откалиброванным йоба-монитором?
Я еле разницу >>1410213 здесь нашёл.

>>1411030
В таком расположении плохо заметно просто. По пробелу в просмотрщике изображений сразу в глаза бросается. А на огромных 4K с градиентами вообще косяк очевиден → >>1407252
Средненький Dell на AH-IPS, ещё недостаточно упоролся, чтобы EIZO брать. Есть поддержка аппаратной калибровки через i1Display Pro, но пока заводской профиль sRGB использую, который должен быть более-менее точен. Сраные вебмки, из-за них пришлось новый монитор покупать и упарываться по color management…

>>1410371
Олсо, в структуре YCbCrBuffer у FF, которая содержит данные декодированного кадра, даже поля с цветовым пространством не предусмотрено. Мне интересно посмотреть, как они это фиксить будут.

Как сделать вебмку с гиф анимации и музыки??

>>1411132

>>1411152
Ну и говно.
Как сделать вебм с лупом из гифки и мп3?

>>1411154
Самое простое — экспортировать в коллекцию png и импортировать обратно с флагом -loop 1.

>>1411154
Узнаешь фреймрейт и длительность гифки, разбираешь гифку на отдельные картинки, собираешь в вебэмку подстроив фреймрейт под длительность музыки или обрезав мукыку в нужном месте.
http://pastebin.com/VmJ0tFeG

>>1411185
>http://pastebin.com/VmJ0tFeG
И получишь yuv444p в новой версии ffmpeg, лол.

>>1411189
>новой версии ffmpeg
Да? Надо уже обновляться?

>>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.

Дайте быстрый гайд как сделать с пика и мп3 вебку?

>>1411225
1. Научиться читать.
2. Прочитать оппасту.

>>1411263
У меня медиа плеер классик крашится при просмотре моих вебмок.

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. Дикий костыль, но идею ты понел. Главное — работает.

>>1411374
А почему snews://, а не, например, video://?

>>1411289
Так из хрома вроде выпилили поддержку netscape-плагинов.

>>1411777
Кастомный протокол отдельно регестрировать надо, в FF по крайней мере. Лень было заморачиваться и вфигачил первый попавшийся устаревший.

>>1408421
Посмотри на путь до вебм, а дальше сам догадаешься.

>>1411374
>>1411777
Т.е по сути нихуя не сделать.

Со скриптов выше, Я ебать не хочу.

test

https://bugzilla.mozilla.org/show_bug.cgi?id=1210219
>(ffvp9) [meta] Ship ffpv9 on all desktop platforms

Ну вот, всё понемногу исправляется. Цветовые пространства бы ещё пофиксили.

>>1410971
>Проверил — хром без тега HD показывает как BT.601. Теги правильно интерпретирует.
Таки да: https://chromium.googlesource.com/chromium/src.git/+/31bc5867e1112af8b82d780b47fcb3a6f337a8a0/media/filters/vpx_video_decoder.cc#548
FF, как обычно, соснул.

>>1412887
Но хром тоже на BT.2020 соснёт.
Кстати, интересно что на ютубе у видео нет тегов цветового пространства → вероятно все кроме десктопных плееров отображают их неправильно.

>>1410971
>>1412937
Ха, фф теперь точно соснул: https://chromium.googlesource.com/chromium/src.git/+/7cb4525761b68e41671af9006920d568be3c5405
Я на стабильной версии тестировал, а на 46+ уже починил. Есть и эвристика по разрешению, и BT.709 предпочитается.

Ну что, ффлюбы, как вам с неправильными цветами в видосах на ютубе живётся? :3

>>1413055
У 90% людей мониторы в принципе показывают левые цвета, а ты с браузерами хуйню развел. Будто ты эти вебмки смотришь в браузерах круглые сутки.

>>1413082
Причём здесь вебмки. Половина VP9 (дефолтный формат на ютубе) и софтвартно декодируемых H.264 видео в фаерфоксе отображается неправильно вообще на любом сайте. Хоть вебмка, хоть ютуб, хоть вконтакт. Аргумент дурацкий, неправильные цвета с фиговым монитором в правильные не превратятся. Это косяк и его надо исправлять.

>>1412832
>Assigned To: Nobody;
>Importance: -- normal
А количество голосов vote на что-нибудь влияет?

>>1395791 (OP)
котики христом аллахом прошу!!! срочно! где скачать autocad без смс и прочей хуйни. я в отчаянии анончик.

>>1413354
Голосуй, хуже не будет.

>>1395791 (OP)
Я не очень понимаю, ffmpeg не доволен размером видео или что?

>>1413403
Нет. Он недоволен тем, что ты ему в 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(аудио), то он спокойно начал обрабатывать все, а как пофиксил начал выдавать этот эррор

>>1413411
> случайно написал 0:1(аудио)
Потому что проигнорировал -vf, ибо не было видеопотока

У тебя несколько сабов в файле?
Если нет, то напиши:
subtitles='c\:\\space\\1.mkv'
и добавь
-sn
чтобы софтсаба в вебм не было.

>>1413417
> У тебя несколько сабов в файле?
Да, 1. Русские, 2. Английские

>>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

Теперь вот это выпадает:

>>1413420
С таким мне не приходилось иметь дело.
Попробуй сделать
ffmpeg -i c:/space/1.mkv -map 0:7 c:/space/1.ass
Если получится то измени оригинал
на
vf ass='c\:\\space\\1.ass'
>>1413427
Потому что : и \ нужно экранировать с помощью \ смотри внимательней >>1413417
И почему у тебя вообще прямые слеши вместо обратных, ты же на линукс?

>>1413429
ПитухОС XP же, сейчас попробую твой способ, спасибо

>>1413430
Субтитры норм получились, проверил, работают, изменил, но выдает все ту же ошибку, не хочет кушать, ладно, обойдусь без них, спасибо что пытался

>>1413435
Последний совет
в vf ass и vf subititles
нужно указывать не двойные кавычки "", а одинарные ''

>>1413439
неа

гугл капча подскунула фотографию с говном, ммм

>>1413476
КАК

>>1413444
Fontconfig настраивал?
https://github.com/pituz/webm-thread/wiki/fontconfig-on-windows

>>1413476
А что с этой вебм не так?

>>1413476
Не хватает только кости вверх подброшенной.

>>1413491
ага

>>1413493
долбоеб вкрутил две видеодорожки туда

>>1413476
Хеееей! Она же для порно-треда в /b/ предназначена. Зачем нужно было её сюда кидать?
>>1413493
С неё всё так.

Короче потестил -qmin -qmax немного.
Указывание -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

>>1413930
Если у тебя -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 (впрочем, я особо не копался, он просто убог).

Я может немножко не по теме, но вроде как и по теме. В общем решил запилить вебмку небольшую, в смысле маленькую. Записал видос бандикамом, порезал его в Sony Vegas Pro 13.0, отрендил, получил файл 33 секунды продолжительностью и размером в 518 ЕБАНЫХ МЕГАБАЙТ. Как так-то? Я даже разрешение поставил меньше. Почему такой объем? Откуда бледь?

>>1413946
Выводи в uncompressed AVI и сжимай затем нормально ffmpeg'ом. Редакторы традиционно не умеют нормально транскодить, да и не их работа как бы.

>>1413948
Оу. То есть это нормальная ситуация? Я думал я просто очень неочень.

Аноны, у меня наитупейший вопрос, в какую директорию нужно положить видео, чтобы ffmpeg его нашел?

>>1413974
Либо указывай директорию полностью, либо сначала переходи в директорию из консоли и указывай имена файлов внутри.

>>1413986
Спасибо

Есть какие-нибудь, хм, гайды по подбору -crf? Или рекомендуемые значения. Например, для h264 указывается промежуток 18-28, для vp9 есть такое?
Вот это 32, 31 уже не влезает. Для vp9 такое значение нормально?

>>1414126
30-35 это весьма хорошее качество.
В вики вроде рекомендовали 20, но это излишний расход битрейта, разницу с 30 очень трудно заметить.

>>1414126
Сам смотри же, насколько видео распидорашивает.
Значение 30 я бы назвал умеренным распидорашиванием: если ставить на паузу, то небольшие артефакты можно разглядеть без сравнения с соусом почти всегда.

>>1414155
Я бы сказал, если ставить на паузу и охуенно приближать.
При просмотре на харкаче разницы между 10 и 30 никто не увидит.

>>1414165
От исходника зависит. С большим числом деталей или быстрым движением сразу в квадраты распидорасит. Даже 25 по сравению с 23 уже плохо. Попробуй какой-нибудь parkjoy в -crf 30 и охуеешь. Или, я не знаю, сцену в GIRL когда всё взрывается.

>>1414176
Если -b:v 0 -crf 30, то никаких квадратов не будет.
При большом количестве движения просто битрейта больше сожрет.

>>1414181
Больше похоже на то, что >>1414176 прав. Анимешные опенинги длиной в полторы минуты кодируются примерно с одинаковым crf (около 30).
>никаких квадратов не будет
Релейтед кодировался с -qmin 27 -crf 30. Обрати внимание на воду и увидишь, что квадраты завезли.
особой разницы по качеству с qmin или без я не замечал.

>>1414239
Дай ссылку на исхдник и время.
Более чем уверен, что если правильно кодировать (а не с указанием каких-то левых -qmin 27 и других левых настроек), то такой размытой картинки не будет при -b:v 0 -crf 30 в этом же примере.

>>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. В ином случае мне будет неинтересно, что там у тебя получится.
На остальные настройки ограничений нет.

>>1414181
>а не с указанием каких-то левых -qmin 27
Так без жёсткого лимита он может меньше взять, всё правильно.

Вот сложная сцена из GIRL (6:44), с crf30 все детали и контуры размыты нафиг. Скриншоты crf10 и crf30 для сравнения. Хотя квадратов почти нет, мылит в основном. Надо на других типах сцен попробовать, что-нибудь вроде быстрых движений градиентов.

>>1414276
Закодирую, посмотрим.
Ну я всегда со -speed 0 кодирую, но посмотрим и со -speed 1.
Звук роли никакой не играет.

>>1414279
Я серьезно мало представляю, как можно при просмотре этой вебмки различить первый и второй скрины.
А квадратов нет, мыла совсем немного, но на такой скорости оно незаметно в любом случае.
Ну и понятно, что -crf 30 это не лосслес, поэтому разница с оригиналом, конечно, будет.
Но чтобы заметить ее надо специально вглядываться в различия.
Квадраты заметить легко, а то, что тут что-то сгладилось слишком сильно, заметить при просмотре нельзя.

>>1414286
> Звук роли никакой не играет.
Если учесть, что он отнимает от лимита в 20M ~900кб, то можно и без звука вообще.

>>1414295
При просмотри сцены целиком в глаза сразу всё мыло бросается. Кодеки на подобных сценах в режиме VBR уйму битрейта тратят.

Ну вот у меня при -crf 30 вполне приемлемо получилось даже со -speed 1.
Квадраты на воде значительно менее заметны и цветочки без говна.
И битрейт почему-то больше, чем у тебя, так что неправильный у тебя какой-то -crf 30 в той вебм.
Посмотрим еще, что со -speed 0 будет, когда докодируется.
https://2ch.hk/media/src/9670/14439718875060.webm

>>1414343
Эээй. Так не интересно. Нужно учитывать, что делалось оно под лимит.

>>1414348
Нет, обсуждали мы -b:v 0 -crf 30 -speed 1, как я и закодировал, сам все видишь.
Под лимит кодируется с указыванием битрейта, а там уже далеко не -b:v 0 -crf 30.

>>1414355
Ну ладно.
> Под лимит кодируется с указыванием битрейта
Я уже пару месяцев не кодирую через битрейт, только -crf, иногда с добавлением -qmin -qmax.

>>1414362
Ты неправильно кодируешь, все, что я могу сказать.
Вот тут приблизительно как надо кодировать под лимит (последний скрин) -> >>1413922

>>1414365
>Ты неправильно кодируешь
Может быть, а может и нет.

>последний скрин
Почему ты прописываешь такие дефолты, как auto-alt-ref, lag-in-frames и c:v vp9? Обнови ffmpeg чтоли.

>>1414369
> Почему ты прописываешь такие дефолты
Чтобы при
>Обнови ffmpeg
Ничего не менять и все работало как до обновления.
Хуже от прописывания дефолтов не становится.

>>1414369
>Ты неправильно кодируешь, все, что я могу сказать.
>Может быть, а может и нет.
Этот вопрос может только мамкин модератор решить, видать в универе на факультете пердоления ffmpeg учится, так что выложи исходники видоса, параметры кодирования и жди его решения о том правильно или нет ты всё делаешь

>>1395791 (OP)
> — ролики с opus'ом в firefox зацикливаются не с начала, а с последнего ключевого кадра.
С недавних пор зацикливается нормально. Конкретно на текущей 41.0.1 точно как надо.

>>1414343
-speed 0 сэкономил 461 килобайт, то есть примерно 7% битрейта при том же качестве картинки.
https://2ch.hk/media/src/9670/14439743185370.webm

>>1414372
Тогда -c:v libvpx-vp9 вместо vp9 пиши. Вдруг кто напишет альтернативный энкодер VP9, но хуже качества!

>>1414395
Я тебе уже несколько раз сказал, что не бывает «того же качества картинки» в разных энкодах. Сделай им одинаковый размер, а потом сравнивай по скриншотам.

>>1400809
>использовал же <…> и немного 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)?

>>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 же.

>>1414691
>По умолчанию в библиотеке он выключен
Ну и отлично. Спасибо.

>>1395791 (OP)
Антонус, у меня пара вопросов, вебм рилейтед:

Есть один premiere pro и свои смехохуечки отснятые с андроида.
Но вот беда примьера не дружит с вебм и, с алсо, половиной порно.flv'шек с интернета. Что плохо т.к. хочеться пиздить от туда контент.
Вопрос во что мне такое ффмпегом конвертнуть так что бы максимум быстро и без потерь, что потом мог бы импортнуть в premiere pro? На размер похуй.

Второе, алсо, есть один диск блу рей, чем его рипнуть со снятием зашит и всего такого. Помню давно делал это в AnyDVD HD. Но может за время появилось что швабодное или не настолько мокрописечное?

>>1414697
>Вопрос во что мне такое ффмпегом конвертнуть так что бы максимум быстро и без потерь, что потом мог бы импортнуть в premiere pro? На размер похуй.
Uncompressed AVI RGB. Вот статья как раз целиком про это: http://amvnews.ru/index.php?go=Pages&in=view&id=33

Отсос только если надо >8бит. Самое простое, по идее, через пнгшки в таком случае.

>>1414701
Кстати, это справедливо вообще для любого видео-редактора, даже если формат исходного видео поддерживается. См., например, >>1414649 Косяки с неправильными цветовыми пространствами YUV, тормоза, странные артефакты. Да и редакторы, как я понимаю, только в RGB оперируют со всеми эффектами и цветом.

Если целевые клипы короткие, то вообще никаких проблем с занимаемым пространством нет. Купить 2 2TB винта, в RAID0 их и всю нарезку туда. Если винт отвалится, то пофиг вообще, ничего кроме временных непожатых фрагментов там не хранить.

>>1414739
А смысл?
1. Не умеет >8бит (ффмпеговский вариант ffvhuv плохо поддерживается).
2. Тормознее несжатого, а места не так уж и много экономит.
3. Твоя команда даст на выходе YUV, который не желателен.
4. Самое главное: не поддерживает сабсэмплинг выше 4:2:2 при использовании YUV, значит как раз-таки есть шанс похерить цвета.

>>1414740
>цвета херит
Ты думаешь редактор в YUV работает при накладывании эффектов? Преобразование цветового пространства в любом случае будет и поэтому надо сделать это правильно заранее. Вначале сабсэмплинг осиль.

>>1414742
>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 бит умеет. Я уже не говорю о том, что работать с пожатым видео в редакторе — это идиотизм.

>>1414760
>Работает он в 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
>Надо просто долбить лисоделов этой проблемой

>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 для уменьшения ошибок округления/артефактов.
>чтоб сделать пикрилейтед из 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, как я понял.

Сап, софтач! Пишу с первого смартфона в моей жизни - Nokia X2. Спрашивайте свои ответы.

Аноны, я новичок в создании webm, почему при первом проходе ffmpeg нихрена не кодирует? Делаю все по первой фотке треда. Я идиот?

>>1415293

>>1415293
В первом проходе время не пишется. На frame смотри. Примерное общее количество кадров можешь узнать через fpsduration (оба значения отображаются в первых строчках вывода). Процент выполнения: frame/total_frames100. Общий прогресс ≈ pass1percent/2.5, т.к. первый проход чуть быстрее.

>>1415312
Я ебал разметку.
>Примерное общее количество кадров можешь узнать через fps×duration (оба значения отображаются в первых строчках вывода). Процент выполнения: frame/total_frames×100.

Сколько по времени у вас кодируется webm на втором проходе?

>>1415461
- treads 8 -speed 1 -frame-parallel 1 будет 7-10fps хуяриться даже на деревянном двухядернике, -speed 0 раза в 2 медленней

>>1415480
> treads
ты обосрался маня

>>1415496
Да пох как оно пишется, все поняли о чем идет речь.

>>1415556
>правда один хуй на видяхе x265 400 FPS кодирует
Реализация x265 не поддерживает вычисления на GPU и медленнее, чем libvpx-vp9 → >>1407076

>>1415448
Зависит от длины видео же. Сейчас засёк, 1:36 на 29 секунд видео.

http://forum.doom9.org/showthread.php?p=1740028#post1740028
Тем временем предварительные результаты с MSU. Лучшая реализация хвалёного HEVC всего лишь на 3% лучше открыто-швободного VP9.

>>1415615
Лол, настолько охуенный энкодер, что даже в табличку не влезло. Я с таким же успехом могу в rawvideo с 9000fps энкодить. Ну да ладно, мы подождём пару дней до релиза полного обзора, чтобы не было обидно за пердолей.

>>1415624
Как нет? А интелловский? А иттиам? В описании указано, что они в основном 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. Всегда одна и та же ошибка. Что я делаю не так?

>>1416050
Длительность 37 секунд (мало ли в ней дело)

>>1416050
В тематике лимит в 6M либо 5М

>>1416056
Спасибо, анон, сделал < 6м, всё запостилось!

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?

>>1416056
6 мб как правило. В /vg/ подняли до 10, слышал что в /po/ тоже поднимали.

>>1416780
Вероятно, ты выбрал не самый лучший энкодер. Попробуй libfdk_aac.

>>1416783
в /mov 15мб
https://2ch.hk/mov/src/646672/14441628421780.webm

Тест

Чем вообще могут быть полезны эти ваши вебемки кроме как выкладывания в тредах на харкаче?

>>1417423
Крупшейние видеохостинги вроде ютуба используют 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фпс.

>>1417495
А ты как хотел?
Вот здесь есть некоторые советы по уменьшению размера/увеличению качества: http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html
Ну и уменьшай разрешение и fps. В аниме, например, реальный fps=8, часто можно до 5 уменьшить безболезненно.

>>1417503
Какими аппаратными, если таких в природе не существует? Netflix говорят тоже на обычных CPU энкодит, например.

>>1417503
Поэтому в метаданных его вебмок указано:
> Writing application : Lavf55.48.100
> Writing library : Lavf55.48.100

>>1417527
Но это же для потокового кодирования в реальном времени. То, что libvpx при таком использовании сосёт из-за скорости, ни для кого не секрет.
Покажи лучше железяку, которая обойдёт по качеству libvpx в двухпроходном режиме (а не по соотношению скорость/качество, которое вряд ли для ютуба сильно роляет).

>>1417527
А ты с хакерньюз/реддита? Нашёл чем гордиться. Люди, интересующиеся темой, берут новости из мэйллистов и чатов с разработчиками.

>http://www.webmproject.org/hardware/vp9/bige/
Интересно, не знал. Только вот он как бы совсем не для VOD, это для real-time. Попробуй читать ссылки перед тем, как их постить.

>>1417530
Это что за такой вид троллинга винить пердоликов (кто это вообще в твоей классификации?) за низкое качество аппаратных энкодеров?

>>1417543
>ты не понимаешь суть железяк и их предназначение
Нет ты. Вопрос был в том, что использует ютуб для энкодинга. Ответ: libvpx. Это, как бы, очевидно.

>>1417529
В новых VP9, кстати:
>| + Muxing application: google
>| + Writing application: google
Касательно настроек, там по всей логике CQ должен быть. Может в этом треде более точная информация есть:
http://forum.doom9.org/showthread.php?t=170682

>>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)?

>>1417889
Это пятая дорожка, лел.
Пиши -map 0:4
И пиши map с видеодорожкой перед map с аудио, чтобы лишних проблем не было:
-map 1:v -map 0:4

>>1417889
-vbr on еще добавь, чтобы opus был с переменным битрейтом - так звук лучше будет.

>>1417940
Да, я уже разобрался. Но теперь другая проблема: вытаскиваются все 25 минут звука, не догоняю как вырезать нужный участок и запихать их в webm. Создавать отдельный аудиофайл, а потом склеивать?

>>1417945
Я бы делал отдельный файл.

>>1417943
Что это за плацебо-советы? vbr по умолчанию включен в ffmpeg у libopus.

>>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?

>>1417948
Можно пруф этого?

>>1417958
https://ffmpeg.org/ffmpeg-codecs.html#Option-Mapping
https://github.com/FFmpeg/FFmpeg/blob/n2.8/libavcodec/libopusenc.c#L408
А самому никак, лол?

>>1417960
Благодарю.

Научите делать хардсаб.
Что именно нужно дописать чтоб добавить выделенные сабы в вырезанный отрывок (они идут 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 ещё добавить.

>>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

>>1418006
Так встроенные шрифты не будут использоваться.

>>1418002
Получилось, спасибо.
А где именно в этом отрезке происходит выбор дорожки субтитров -vf "subtitles=C\\:/kokoko.mkv:si=1"?

>>1418025
si же, читай ман. Кстати, ссу на ValdikSS, который додумался сделать индекс субтитров относительным, а не абсолютным номером стрима.

>>1418028
Благодарю.

А если субтитры лежат отдельным ass-файлом, то как их тогда вшивать в уже готовую webm?

Почему так?

-vf "ass=s\\:/1313.ass", тремя постами выше пример же, ёпт.

>>1418289
Потому что бэкслэши и дваеточия надо экранировать.

>>1418137
Никак, её надо перекодировать. Софтсаб сосач не держит.

>>1395791 (OP)
Я хуею просто и у меня неимоверно печет.
Чтобы сделать сраное видео нужно блядь заниматься таким пердолингом, но я не собираюсь становится ПОГРОМИСТОМ и вообще даже вникать в эту муть. Уже перекачал с десяток программ, все какие-то ЗАУМНЫЕ пиздец, питоны, скрипты, хуитоны.. вы охуели блядь?? Это блядь ВИДЕО!!! Я вам не пентагон тут взламавать собираюсь!!! СУУУКИ!!!
И главное, все сраные видеоредакторы тоже отказываются конвентировать, ну что за скотство?
Есть же наверняка какой-то вариант без пердолинга? или хотите сказать школьники из бэ вот это вот все дрочат, клепая свои высеры?

>>1418908
Неужели тебе трудно скопировать один файл в какую-нибудь папку и создать батник с двумя строчками в этой же папке?

>>1418909
У меня аллергия на консоли.
Да и как я в ней укажу точный тайминг обрезки, чтобы прям кадр в кадр?
Я скачал какой-то webm conveter, вот там все годно, по кадрам можно быстро отметить начало и конец, но он почему-то нихрена не сохраняет, а пишет следующее: ffmpeg.exe exited with exit code 1.

>>1418908
Ввести команду в консоль это даже не уровень программиста-8миклассника, ведь программа уже написана за тебя.

>>1418908
>Это блядь ВИДЕО!!!
Вот именно. Люди выдрачивают фильтры AviSynth, а то и свои пишут, оптимизируя под конкретную архитектуру до последнего такта. И о x264 ключах в многосотстраничных темах срутся. А тут какой-то быдлан решил, что это всё можно свести до нажатия одной кнопки в гуёвине.

>>1418908
>хотите сказать школьники из бэ вот это вот все дрочат, клепая свои высеры
Именно. Изучай ffmpeg - это стильно, модно, молодежно. Он тебе всегда пригодится.

>>1419228
Разве что в твоих влажных фантазия.
Если бы абдуль был бы не корявой обезьяной и впилил бы поддержку h264 который сраным вебм ссал на рот, двачаю двач бы стал самым популярным видеохостингом рунета ибо нормальные кодеры уже давно обходятся двумя кнопками битрейт видио\качество аудио. А так нормальный человек с этим вашим вебм и фмпегом возиться не будет. Что мы и видим, в бэ треды с одни и теми же вебм месяцами.
Но пердодибилы, как и бюрократы, любят превращать в работу то что ей не являеться и создавать себе проблемы на ровном месте.

>Он тебе всегда пригодится.
Гдеж он мне блять пригодиться то а? О нем блять и не услышал если бы не двачепомойка.

>>1419228
Пруф или проект без лидера и с неясным будущем, попирающий diversity и не проводящий программ по привлечению женщин и трансов к разработке. Настоящие SJW выбирают libav! Встречайте во всех дистрибутивах Linux ToleranUX.

>>1419383
Вембрелейтед. Подобное беспощное кукареканье уже столько раз разбиралось, в том числе в этом треде, что даже нечего добавить. Но ты, конечно, можешь воображать, как нам всем тут суть вещей показал.

>>1418908
У меня для тебя плохие новости. Так с любой хуйней, в которой ты хочешь преуспеть. NO PAIN, NO GAIN

>>1419383
>О нем блять и не услышал если бы не двачепомойка.
Зато уже четвёртый год смотришь его на Ютубе, лол.

>>1418908
>>1418910
>>1419383
Чтобы просто сделать вебм достаточно любой умеющий это программы с гуем. Подключив пару извилин можно даже кокретное время указать и размер поменять. То, что обсуждают тут немного выходит за рамки "просто".

>>1419383
>двачаю двач бы стал самым популярным видеохостингом рунета
>видеохостинг

ты совсем чтоли ебнутый, тупая мартышка? Кто ж ему даст столько ресурсов, гения ты инторнета? Абу всего лишь мелкая шавкапросто микроб среди господ видео-порнодельцов.

Как в ffmpeg сделать кроп с разными значениями? С одной стороны надо обрезать чуть больше, чем с другой. Я сколько не гуглю, то везде нахожу только варианты с указанием одного значения для обрезки с двух сторон.

>>1419517
Можно же подобрать координаты и размер так, чтобы было как ты хочешь.

>>1419520
Ну вот есть видео формата 1280х720, надо обрезать 150 слева и 154 справа (точные цифры знаю из ковыряния через гуёвину). Как?

>>1419522
-vf crop=1026:720:150:0

>>1419525
>-vf crop=976:720:150:0
fix

>>1419527
Я что-то затупил и ковырял не в том направлении, а оказалось всё проще. Спасибо.

>>1395791 (OP)
MPC-HC крашится при попытке воспроизвести webm, что делать?

>>1419581
попробуй переустановить питухос шиндос 10 на более олд фажную питухос шиндовс 7

Скукотище. Одни спермачи на первой, до чего дошел цвайч.

Уебываю

>>1395791 (OP)
Делюсь ссылкой на скрипт для скачивания всех webm треда пока только для /b/ раздела:
http://ad-file.com/7ttjC8zMr
Можете добавить в шапку треда.

>>1419592
Вот и уебывай.
Еще раз хоть че скажеш- без зубов останешся.

>>1419707
Сделай скрипт для скачивания всего треда с полноразмерными картинками и вебэмками. Чтоб было удобно сохранять интересные треды.

>>1419707
Лол, да ты охуел брать деньги за кривую версию 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 не катит. И звёздочки заменить на нормальные.

Поясните ньюфагу за скрипт по добавлению превью отдельной дорожкой по этой ссылке.
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

>>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
>gstreamer
Ну ты понел. Почему не скрипт на Lua к mpv с нормальным управлением и декодерами? Или даже впилить поддержку в youtube-dl, mpv подхватит автоматом.
Олсо, почему не залил на PYPI с проставленными зависимостями, чтобы устанавливать одной командой нормальный симлинк в PATH, как все нормальные пацаны делают? И сборочку через py2exe для вендузятников.

>>1419831
>Почему не скрипт на 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 не грузятся?

>>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

https://github.com/mpv-player/mpv/commit/78caf6ae8634b9fe9589187d8febb927dce2ddeb
Вот это круто. Наконец-то ffmpeg починили.

>>1420090
А что последняя строчка делает?

>>1420219
Исправляет ссылки на полные версии изображений, которые были скачаны первым вгетом.

>>1419751
> Платина наверное, но у меня в вебмках нет звука. Вообще ни в каких. Что надо сделать?
Бамп вопросу.

>>1420270
Пердоля, а ты молодец. Не упускаешь момента пореверсить.

>>1420313
Пердоля, зачем сам с собой разговариваешь?

>>1420313