>>1013257
FFMPEG
А теперь можешь удалять тред.
Хотя постой.
Юзай 10битный x264.
-vcodec libx264 -preset veryslow -tune animation -crf 15
Для хорошего качества.
-crf 20 для маленького размера.
Если аудио уже сжатое - не пережимай, копируй просто дорожку.
Ну или можешь попытать счастья с aac
-acodec libfdk_aac -cutoff 20000 -vbr 4 -afterburner 1
-vbr 1-4
4 - максимальное качество. - смотри чтобы размер пережатой аудиодорожки не получился больше оригинальной.
Вот и весь гайд.
> x264
не слушай этих ретроградов, юзай x265
>>1013290
Иди нахуй жирдяй.
x265 сырое дерьмо. Года через 2-3, может 5, может быть.
А пока он дает худшее качество и большее время сжатия.
>>1013287
Вот пример моего .bat файла для одного блюрея
@echo off
set ffmpegexe="D:\home\Programs\Video Coding\ffmpeg\ffmpeg_10bit.exe"
rem *******************************ffmpeg options****************************
set video_filter=-filter:v "format=yuv420p10le" -pix_fmt yuv420p10le
set video_encoder=-vcodec libx264 -preset veryslow -tune animation -crf 15
set audio_encoder=-acodec flac -compression_level 12
set threads=-threads 4
set infile="d:\home\Downloads\Torrent\Elfen Lied [BDRemux 1080p]\Elfen Lied 14 [BDRemux 1080p].mkv"
set voutfile="d:\encoded\Elfen Lied 14 V.mkv"
set aoutfile1="d:\encoded\Elfen Lied 14 A 1 stereo flac.mkv"
set metadataclear=-map_chapters -1 -map_metadata -1
set outfile="d:\encoded\Elfen Lied 14 - In the Passing Rain - Regenschauer.mkv"
set metadata=-metadata title="Elfen Lied 14 - In the Passing Rain - Regenschauer" -metadata:s:a:0 language=jpn -metadata:s:v:0 language=jpn
rem *************************************************************************
echo %ffmpegexe% -i %infile% -map 0:0 %metadataclear% %video_filter% %video_encoder% %threads% -f matroska %voutfile%
%ffmpegexe% -i %infile% -map 0:0 %metadataclear% %video_filter% %video_encoder% %threads% -f matroska %voutfile%
echo %ffmpegexe% -i %infile% -map 0:2 %metadataclear% %audio_encoder% %threads% -f matroska %aoutfile1%
%ffmpegexe% -i %infile% -map 0:2 %metadataclear% %audio_encoder% %threads% -f matroska %aoutfile1%
echo %ffmpegexe% -i %voutfile% -i %aoutfile1% %metadata% -map 0:0 -vcodec copy -map 1:0 -acodec copy %threads% -f matroska %outfile%
%ffmpegexe% -i %voutfile% -i %aoutfile1% %metadata% -map 0:0 -vcodec copy -map 1:0 -acodec copy %threads% -f matroska %outfile%
pause
>>1013279
А как же 2 прохода? Я не особо в теме особенностей x264, но в случае с libvpx это даёт значительный прирост соотношения битрейт/качество.
> libfdk_aac
А как же всякие vorbis'ы и opus'ы? Если нужно уменьшить размер файла, то opus, насколько я знаю, вне конкуренции.
См. https://trac.ffmpeg.org/wiki/GuidelinesHighQualityAudio
>>1013291
> set infile="d:\home\Downloads\Torrent\Elfen Lied [BDRemux 1080p]\Elfen Lied 14 [BDRemux 1080p].mkv"
> set outfile="d:\encoded\Elfen Lied 14 - In the Passing Rain - Regenschauer.mkv"
> set metadata=-metadata title="Elfen Lied 14 - In the Passing Rain - Regenschauer" -metadata:s:a:0 language=jpn -metadata:s:v:0 language=jpn
> -map 0:0
> -map 0:2
> …
Проиграл. Это ты вместо того, чтобы просто запускать скрипт с указанием имени файла и прочего в параметрах, каждый раз его правишь в 10 местах? Нахуй так жить?
>>1013302
>А как же 2 прохода?
Ты бы прочитал какую-то документацию вначале. Хули тупые вопросы задаешь?
Есть несколько методов выбора качества кодирования.
Постоянный битрейт.
Средний битрейт.
Постоянное качество.
2 прохода предназначены для среднего битрейта.
Когда тебя интересует определенный конечный размер файла.
1 проход оценивает количество информации в каждом кадре, после чего делит на это все заданное значение среднего битрейта и получает сколько килобит в секунду выделить на конкретный кадр.
Затем следует стандартное кодирование во втором проходе.
НИКАКОГО ПРИРОСТА КАЧЕСТВА ВИДЕО ИЛИ УРОВНЯ СЖАТИЯ ЭТО НЕ ДАЕТ.
При использовании постоянного битрейта, или постоянного качества (CRF) хоть 2 хоть 3 прохода - результат будет одним и тем же.
Если тебе интересен конкретный конечный размер файла - используй 2 прохода(например если тебе нужно записать фильм на болванку)
Иначе используй CRF.
>Это ты вместо того, чтобы просто запускать скрипт с указанием имени файла и прочего в параметрах, каждый раз его правишь в 10 местах?
5ти местах.
>Нахуй так жить?
Какая мне разница, вбивать эти 10 параметров в командной строке, или сохранить их в файле? Кроме того конечно, что скрипт будет сложнее во втором случае, а шансы допустить ошибку будут больше.
В файле все структурировано и наглядно. Никакой мотни с 10 переносами строк.
Что тебя смущает то?
>Проиграл
Научись выигрывать. Петушок.
>opus
>Opus продемонстрировал высокое качество[7] на битрейте 64 кбит/с по сравнению с Apple HE-AAC, Nero HE-AAC, Vorbis и AAC LC
>на битрейте 64 кбит/с
Это говно оптимизировано для низких битрейтов быстрого кодирования и потоковой передачи.
Эсли говнобитрейт и МАЛЕНЬКИЙ размер файла то что ты ищешь - на здоровье.
К тому-же
>* Muxing Opus in Matroska is experimental, but may be safe.
Не говоря уже о других форматах.
Проблемы с совместимостью во все поля.
Хочешь КАЧЕСТВА и имеешь PCM сорс - пользуй флак.
Хочешь просто приличного качества и имеешь PCM сорс libfdk_aac
Это мой опыт.
Имеешь уже сжатое с потерями аудио - не трогай его нахуй вообще. Копируй поток.
А это здравый смысл.
>>1013413
> Ты бы прочитал какую-то документацию вначале.
Основное предназначение двухпроходного кодирования мне известно.
> НИКАКОГО ПРИРОСТА КАЧЕСТВА ВИДЕО ИЛИ УРОВНЯ СЖАТИЯ ЭТО НЕ ДАЕТ.
А как же улучшение компенсации движения? Или x264 так не умеет?
В случае с libvpx прирост в некоторых случаях охуенен, для примера можешь попробовать пожать пару минут статичной картинки.
> Какая мне разница, вбивать эти 10 параметров в командной строке, или сохранить их в файле?
Большая. В командной строке есть автодополнение, возможность использовать умолчания, автоматическое сохранение истории введённых команд.
> Кроме того конечно, что скрипт будет сложнее во втором случае, а шансы допустить ошибку будут больше.
Нехуй писать на говне с палками. Возьми zsh, например.
> В файле все структурировано и наглядно.
Охуенно структурировано — параметры нужно менять по всей простыне.
> Научись выигрывать. Петушок.
Сказал аноним и запостил вебмку с кукареканьем.
> Это говно оптимизировано для низких битрейтов быстрого кодирования и потоковой передачи.
Это vorbis-то? Совсем пизданулся?
Олсо, кто сказал, что opus не годится для битрейтов выше? 128кбпс в нём звучат очень неплохо. Ещё выше не пробовал.
> >* Muxing Opus in Matroska is experimental, but may be safe.
И что? Плееры на основе библиотек из mplayer/ffmpeg играют его без проблем.
> Не говоря уже о других форматах.
О каких других форматах? О Vorbis'е? Он вообще влезает в матрёшку как влитой.
> Проблемы с совместимостью во все поля.
А с H.264 Hi10P никаких проблем нету, да.
> Имеешь уже сжатое с потерями аудио - не трогай его нахуй вообще.
Это да.
>>1013279
>FFMPEG
Попизди тут. Я в треде про FFMPEG спрашивал, почему у меня при выставлении всех параметров, описанных в руководстве по ffmpeg, аналогично параметрам в format factory, видео после ffmpeg даже на глаз получается заметно хуже, чем в format factory при том же кодеке и битрейте. И мне такие же гении перекодирования тут же заявили, что это очевидно же потому, что format factory знает намного больше параметров кодека, которые можно регулировать и выставлять оптимальным образом. Так что ебал я в рот ваш школопег.
>>1013441
Ты в курсе, что твоя мокрописечка сделана на коде пизженом из ffmpeg?
>>1013419
Я что-то понять не могу.
Ты за советом пришел, или поспорить со мной хочешь?
А может лучше нахуй?
>Основное предназначение двухпроходного кодирования мне известно.
Тогда не задавай тупые вопросы.
>А как же улучшение компенсации движения? Или x264 так не умеет?
Что? Ты о чем вообще? Совсем поехал уже.
libvpx это говно для стриминга с хуевым качеством и низкими битрейтами, как это вообще можно с x264 сравнивать?
>В случае с libvpx прирост в некоторых случаях охуенен, для примера можешь попробовать пожать пару минут статичной картинки.
Так.
Вот ты сам то понимаешь что ты несешь?
Прирост по СРАВНЕНИЮ С ЧЕМ?
Средний битрейт делается через 2 прохода, как-то по другому ты его не сделаешь, с чем сравнивать тогда?
С констант битрейтом?
Да, средний битрейт и 2 прохода дают лучшее качество чем постоянный битрейт.
>Большая. В командной строке есть автодополнение, возможность использовать умолчания, автоматическое сохранение истории введённых команд.
>Нехуй писать на говне с палками. Возьми zsh, например.
Может мне ПЕРДООС сразу поставить?
Слушай, вот какое тебе нахуй дело, до того, как я передаю параметры в кодировщик?
Ты такой пришел с просьбой о помощи, я тебе такой пример на блюдечке, а ты такой недоволен, неправильно я поступаю, консольку видители не пользую.
Ты ебанутый?
Ты что там делаешь?
>Это vorbis-то? Совсем пизданулся?
>Олсо, кто сказал, что opus не годится для битрейтов выше? 128кбпс в нём звучат очень неплохо. Ещё выше не пробовал.
Используй что хочешь. Раз ты такой умный. Хули тебе от меня надо?
>А с H.264 Hi10P никаких проблем нету, да.
А это ты сейчас к чему?
Тащемто нету.
Если ты конечно не собрался на железных плеерах смотреть.
Но железные плееры это совсем другая тема ваще.
>Это да.
Мне так не хватало твоего согласия.
>Сказал аноним и запостил вебмку с кукареканьем.
Проблемы?
>>1013441
Поехавший.
Хочется полного контроля над енкодером - так юзай его в чистом виде, а не в качестве компонента мега комбайна.
>>1013458
И что? Андроид тоже на коде глинукса. Но андроид - это 90% реально работающих смартфонов, а глинукс так и остается консольным обладателем победителем 1% пердоликов.
ОП, в /s/ есть только один человек, хорошо разбирающийся в области обработки видео. И он пока в твоем треде не отписался.
На рутрекере есть очень хороший раздел:
http://rutracker.org/forum/viewforum.php?f=23
Тут тебе и гайды и осуждение и все прочее.
Почитай там вот эти темы:
http://rutracker.org/forum/viewtopic.php?t=2660571
http://rutracker.org/forum/viewtopic.php?t=1037661
http://rutracker.org/forum/viewtopic.php?t=858138
От себя:
0) Используй CRF, если важно качество. Два прохода, если важен объем.
1) Не используй значения CRF ниже 16 - пустая трата битрейта.
2) Не используй 10-битный x264. Много места он тебе не сэкономит, зато потеряешь совместимость с туевой хучей устройств и аппаратным декодированием.
3) Не пережимай аудио дорожки, если они уже сжаты lossy-энкодером.
4) Не пережимай в AAC средствами ffmpeg. Лучше используй энкодер от Неро либо QAAC(лучше всего).
5) Не раздувай разрешение. Многие риперы делают из двд рипы чуть ли не в 1080p. Лучше всего будет вообще не трограть разрешение, а указывать SAR.
6) Самый главный твой враг при работе с двд это интерлейс. А про него никто пока ничего не сказал. И я не скажу, ибо могу только в yadif. Тут придется много читать.
Проверенная и надежная схема такая:
Берешь двд. Разрезаешь его на эпизоды через, например, SmartRipper. Эпизоды индексируешь через DGIndex. Полученный индексный файл подгружаешь в Avisynth. В Avisynth обрезаешь черные полосы, делаешь деинтерлейс, при необходимости корректируешь цвета. Скармливаешь полученный скрипт x264. Сжатое видео муксишь с аудио при помощи Mkvtoolnix. Все.
>>1013462
> Ты такой пришел с просьбой о помощи
Ты его с ОПом перепутал.
мимо
>>1013462
> Ты за советом пришел, или поспорить со мной хочешь?
Очевидно же что второе. Заодно хочу разобраться.
> Тогда не задавай тупые вопросы.
В каком месте я задавал тупые вопросы?
> libvpx это говно для стриминга с хуевым качеством и низкими битрейтами, как это вообще можно с x264 сравнивать?
Это "говно для стриминга" и на высоких битрейтах если и проигрывает x264, то незначительно, и в основном из-за сырости реализации энкодера, а не из-за недостатков формата.
> Прирост по СРАВНЕНИЮ С ЧЕМ?
Ты идиот? Очевидно же что по сравнению с одним проходом. Обе итерации — c crf, с указанием большого потолка битрейта.
В случае с двумя проходами размер файла значительно падает.
> Может мне ПЕРДООС сразу поставить?
Но у тебя и так ПЕРДООС, в которой ты ПЕРДОЛИШЬСЯ с батниками, не?
> Ты такой пришел с просьбой о помощи,
Я хуею с твоего детектора. Очевидно же что если бы я и приходил за помощью, то не в таком формате.
> а ты такой недоволен, неправильно я поступаю, консольку видители не пользую.
Нет, я просто в недоумении.
> Хули тебе от меня надо?
Чтобы ты не рекомендовал посредственные и устаревшие решения с безапелляционным видом и потом не защищал их кукареканьем, а научился дискуссии, например.
> > А с H.264 Hi10P никаких проблем нету, да.
> А это ты сейчас к чему?
К твоему кукареканью о проблемах совместимости opus'а и vorbis'а.
> Тащемто нету.
Ну тогда с opus'ом проблем ещё меньше — в отличие от 10-битного H.264 он не повышает требования к CPU.
>>1013469
> Не используй 10-битный x264. Много места он тебе не сэкономит, зато потеряешь совместимость с туевой хучей устройств и аппаратным декодированием.
В случае с анимой — утверждение очень спорное. С HiP для борьбы с бандингом на градиентах и распидорашиванием тёмных сцен приходится сильно поднимать битрейт, в то время как с Hi10P этого не нужно. Выигрыш — обычно где-то 30% размера, что довольно много.
> Самый главный твой враг при работе с двд это интерлейс.
Вот это сосачую.
> И я не скажу, ибо могу только в yadif.
В случае с анимой получается говно с разъёбанными линиями. Надо подбирать фильтры под конкретный вид интерлейса, мне часто помогали фильтры mplayer'а ivtc и detc.
Если же говорить об универсальных вариантах — то стоит обратить внимание на жутко медленный mcdeint и мокрописечный деинтерлейсер nvidia (его можно заюзать через vdpau в avidemux).
Ещё бывает что несколько методов интерлейса наложены друг на друга. Получается лютый пиздец, плохо поддающийся восстановлению.
В /b/ проходила специальная олимпиада по деинтерлейсингу и запиливанию WebM из http://rutracker.org/forum/viewtopic.php?t=4290607, но хорошего результата ни у кого не вышло — у всех остались наложенные друг на друга кадры — например, двоящийся рыбий глаз. Мб тут у кого получится?
Не мог пройти мимо.
>>1013479
> на высоких битрейтах если и проигрывает x264, то незначительно
Как насчёт почти вдвое по размеру потока? Это считается незначительным? Да, VP8 имеет преимущество в 10-20% ширины потока при одинаковом значении SSIM в диапазоне воспринимаемого качества от «заметны дефекты» до «безобразно». В диапазоне от «не заметно разницы», до «почти незаметно разницы» преимущество H.264 уже не те 10-20%, а больше. См. пикрел. Следует учесть, что на пикрел из VP8 выжато всё, что можно, а x264 работает в режиме строгой совместимости с bluray (параметры взяты рекомендованные разработчиком; подбора не проводилось).
> из-за сырости реализации энкодера
Много ли пунктов спецификации на VP8 не реализовано?
> не из-за недостатков формата.
Каковы возможные длины ДКП в VP8? Сколько возможных размеров макроблоков допустимо при смешанной компенсации движения в VP8?
> Ты идиот?
По аргументам, употреблённым в дискуссии, могу сделать вывод о том, что весьма вероятно, вы оба некомпетентны в области управления модулями контроля ширины потока. В VP8 год назад модуль контроля ширины потока не был достаточно гибким, кстати.
> в отличие от 10-битного H.264 он не повышает требования к CPU.
Это незначительно по сравнению с полной потерей совместимости с распространённым стандартными декодерами (например, в бытовой технике).
>>1013479
>В каком месте я задавал тупые вопросы?
Шизик ебаный.
>Ты идиот? Очевидно же что по сравнению с одним проходом. Обе итерации — c crf, с указанием большого потолка битрейта.
>сравнению с одним проходом
>Обе итерации — c crf
>с указанием большого потолка битрейта
>CRF 2 прохода указание макс битрейта
Может быть такая хуйня где-то и прокатывает.
В x264
Указание максимального битрейта+CRF бессмысленно.
2 прохода с CRF - бессмысленно. Потому, как использование CRF подразумевает лоокахедл поток, который как бы и выполняет роль первого прохода, только в виду того, что средний битрейт считать ненужно, делать этот проход отдельно - нет смысла.
Вердикт - ты делаешь какую-то бессмысленную хуйню, непонятно что с чем сравниваешь, по размеру файла, совсем ебанулся.
Не понимаешь же нихуя, базовых вещей, а несешь какой-то вздор, с умным видом.
>Ты идиот?
>Это "говно для стриминга" и на высоких битрейтах если и проигрывает x264, то незначительно, и в основном из-за сырости реализации энкодера, а не из-за недостатков формата.
Одна история охуительнее другой. Где ты этого говна набрался?
x264 - это математика, понимаешь, лучшее что есть на сегодняшний момент, никаких новых супер принципов сжатия видево человечество не придумало.
"говно для стриминга" - оптимизировано ДЛЯ БЫСТРОГО СЖАТИЯ! И БЫСТРОГО ПОИСКА.
Качество кодирования обратно пропорционально скорости кодирования.
Чудес в природе не бывает, дурачек.
>Чтобы ты не рекомендовал посредственные и устаревшие решения с безапелляционным видом и потом не защищал их кукареканьем, а научился дискуссии, например.
Шизик.
>безапелляционным видом
>видом
Шизик. Тебе всякие галлюцинации мерещатся уже. Терминальная стадия шизофрении.
Не говоря уже о попытке вынудить собеседника к "дискуссии" которая таковой не является. Потому, что ты не обладаешь достаточным знанием о предмете.
Ты просто ничего не хочешь знать, но хочешь, чтобы Я, тебя, УБЕЖДАЛ. Ты конечно же будешь сопротивляться, поливать меня дерьмом, но я ДОЛЖЕН ТЕБЯ УБЕЖДАТЬ.
Да иди ты нахуй, поехавший.
Ты себе что-то нафантазировал совсем безумное.
>Ну тогда с opus'ом проблем ещё меньше
Форматы во все поля.
>в отличие от 10-битного H.264 он не повышает требования к CPU.
Мой телефон 10 бит без проблем декодирует.
Вообще это бессмысленные репки с твоей стороны.
Я тебе говорю - "я считаю опус проблемным и подходящим только под узкий круг задач".
Ты мне отвечаешь - "КОКОКО ТЫ КУКАРЕКАШЬ ТУТ, А СОВЕТУЕШЬ МНЕ 10 БИТ А ОН ТОЖЕ НЕ ВСЮДУ ПОДХОДИТ".
Че?
Сам же советовать просил. К чему это вообще? Какую-то клоунаду устроил.
Не нравятся мои советы - не прислушивайся к ним.
Что еще за претензии такие?
>>1013487
>Это не ОП
Хули он мне тогда пишет? Чего хочет?
Поехавший какой-то прицепился. Мне-то покуда знать что это не ОП.
Я бы ему тогда совсем не отвечал бы.
>>1013491
Твой пост тоже нуждается в правке.
> Указание максимального битрейта+CRF бессмысленно.
Нет. Вы совершенно забываете про уровни, профили и размер видеобуферов.
> как использование CRF подразумевает лоокахедл поток
Любое кодирование с компенсацией движения использует опережающий анализ (и, соответственно, имеет минимальную задержку в число зависимых кадров). Не смотря на то, что опция называется «rc-lookahaed», она регулирует параметр, оказывающий сквозное влияние на процесс кодирования, при опережающем анализе используется и компенсация движения и, и регулирование ширины потока, и даже обе вместе c RDO, если попросишь. Это коренным образом отличается от многопроходных режимов, где между проходами сохраняются лишь некоторые статистические характеристики, а само же распределение макроблоков вычисляется каждый раз заново.
> как бы и выполняет роль первого прохода
Если только очень «как бы». Здесь больше искажений, нежели в сравнении CRF с CQP.
> средний битрейт считать ненужно
Тебе следует читнуть документации в области «QP curve» и больше не говорить таких глупостей. Например, у той же lavc пользователю предлагается указать уравнение («vrc_eq») самостоятельно. В двух проходах схема определения оптимальных квантователей далека «от средний битрейт считать».
> Не понимаешь же нихуя, базовых вещей, а несешь какой-то вздор, с умным видом.
Нутыпонел, да?
> никаких новых супер принципов сжатия видево человечество не придумало.
Вообще-то, реализованные в VP8 или H.264 способы представления информации являются развитием ещё старичка H.261 из конца восьмидесятых годов прошлого века. Принципиально новые представления изложены в MPEG-4 (не ASP|AVC),7,21, но на данный момент практикой не подтверждены. А ещё есть фракталы. А ещё есть много другой математики. Но пока эффективные решения есть для Фурье-подобных или Вейвлет-преобразований, векторной компенсации простого смещения (даже не полного аффинного преобразования), энергетической фильтрации и энтропийного кодирования.
>>1013506
>Нет. Вы совершенно забываете про уровни, профили и размер видеобуферов.
Имелось ввиду концептуально.
Ограничение по битрейту несовместимо с постоянным качеством, это уже получается не постоянное качество, как бы.
В таком случае качество сжатия стоит контролировать макс мин битрейтом и средним.
Ящитаю.
>Если только очень «как бы»
Ну да.
>Нутыпонел, да?
Ты конечно круто во всех этих потрахах разбираешься.
А я нет.
Но я и не о тонкостях реализации говорю, а с точки зрения пользователя готовых программных решений.
Со своей быдло точки зрения среднего пользователя. Основанной на личном опыте и вот такой развернутой информации которой обладаешь ты например.
>Вообще-то, реализованные в VP8 или H.264 способы представления информации являются развитием ещё старичка H.261 из конца восьмидесятых годов прошлого века. Принципиально новые представления изложены в MPEG-4 (не ASP|AVC),7,21, но на данный момент практикой не подтверждены. А ещё есть фракталы. А ещё есть много другой математики. Но пока эффективные решения есть для Фурье-подобных или Вейвлет-преобразований, векторной компенсации простого смещения (даже не полного аффинного преобразования), энергетической фильтрации и энтропийного кодирования.
Ну вот и я о том же.
Как и ожидалось, сколько людей столько и мнений. Добавил тред на всякий случай в архивач. Буду сидеть и разбирать что вы мне тут понаписали.
ОП
я уж обрадовался, а это не шизик с нульчана
(
>>1013534
Не факт вообще.
Он частично под описание подходит.
Детектор показывает средние значения.
>>1013490
> Как насчёт почти вдвое по размеру потока?
Выглядит как бред. Реквестирую скрипты, которыми рисовался график, и опции кодирования.
> Много ли пунктов спецификации на VP8 не реализовано?
Спеки VP8 писались от реализации, так что вопрос не совсем корректен. Я имел в виду другое: много ли ранее не реализованных фич спецификации MPEG1 Layer III было реализовано в Lame? Насколько я понял, на его примере можно наблюдать улучшенную реализацию ранее реализованных фич.
> Каковы возможные длины ДКП в VP8? Сколько возможных размеров макроблоков допустимо при смешанной компенсации движения в VP8?
Не в теме. Вот обзор формата VP8 от разработчика x264: http://x264dev.multimedia.cx/archives/377.
К своему стыду, я его вкурил только хорошо если на треть и забросил в открытой вкладке.
> вы оба некомпетентны в области управления модулями контроля ширины потока.
Львиная доля непонимания вызвана тем, что у libvpx и x264 они очень сильно различаются: libvpx требует указания и максимального битрейта, и crf одновременно, а конкретный режим выбирает в зависимости от сложности потока.
Хотя возможность впихивания указанного качества, полностью наплевав на битрейт, у него тоже есть: параметр -qmax.
> Это незначительно по сравнению с полной потерей совместимости с распространённым стандартными декодерами (например, в бытовой технике).
Много ли бытовой техники жуёт Hi10P?
>>1013491
> 2 прохода с CRF - бессмысленно. Потому, как использование CRF подразумевает лоокахедл поток, который как бы и выполняет роль первого прохода, только в виду того, что средний битрейт считать ненужно, делать этот проход отдельно - нет смысла.
В этом и был вопрос. Спасибо.
В случае с libvpx два прохода позволяют использовать altref-фреймы (отсутствующие в исходном видео кадры, которые используются исключительно для ссылок на них), что компенсирует низкое максимальное значение re-frames (3).
> Мой телефон 10 бит без проблем декодирует.
Аппаратным декодером?
>>1013506
> между проходами сохраняются лишь некоторые статистические характеристики, а само же распределение макроблоков вычисляется каждый раз заново.
Понятно, спасибо.
>>1013518
> Имелось ввиду концептуально.
Как раз концептуально есть гипотетический декодер с видеобуфером конечной длины, в котором должны поместиться зависимый кадр и все ссылочные. У ограничения на максимальную ширину потока из этого ограничения растут ноги. Одно дело, когда ты имеешь дело с каким-нибудь уникальным несовместимым йоба-кодеком, но когда речь идёт о стандартных совместимых решениях, следует всегда помнить о подобных ограничениях.
> с постоянным качеством
На самом деле с минимизацией отклонений от среднего уровня оценки искажений по наперёд заданному критерию. У всех стандартных кодеров с компенсацией движения, если они пытаются слушаться стандарта, в модуле контроля ширины потока всегда ограничение на максимальную ширину является приоритетным. О том, что «ограничение по битрейту несовместимо с постоянным качеством» говорить не приходится — в пределах стандарта даже проблема так не ставится.
> В таком случае качество сжатия стоит контролировать макс мин битрейтом и средним.
Всё дело в том, что есть предусмотренные и с разной степенью полноты документированные решения разработчиков видеокодеков, за пределами рекомендаций которых обывателям ловить нечего. Например, у CCE такой документ есть. К сожалению нет руководства, у x264 есть множество справочных документов, созданных сообществом. Это ситуацию усложняет.
>>1013543
> Выглядит как бред.
Нет. Это медицинский факт суровой реальности.
> опции кодирования.
http://pastebin.com/Y6cnJ3hi
> много ли ранее не реализованных фич спецификации
Тогда следует говорить об особенностях программы, а не формата, я считаю. Формат должен иметь какую-то устойчивую форму спецификации. Иначе будет как с самонесовместимыми офисными форматами Майкрософт, которые постоянно меняются.
Кстати, о спецификации VP8
> VP8, as a spec... [is] not even close to competitive with H.264 Main or High Profile. If Google is willing to revise the spec, this can probably be improved.
Здесь говориться о средствах анализа и уменьшения избыточности, заложенных в спецификацию. В статье разработчик указывает на довольно бедный их состав у VP8.
> Львиная доля непонимания вызвана тем, что у libvpx и x264 они очень сильно различаются
Не удивительно. С lavc тоже различий достаточно. Разные модули контроля ширины потока.
> Много ли бытовой техники жуёт Hi10P?
Телевизоры и декодеры в слотовых затычках предпочитали года три назад [email protected], как на bluray, и никаких вам 10 бит. Что-то изменилось?
>>1013571
> http://pastebin.com/Y6cnJ3hi
> lag 0
> ar-mf 0
То есть ты altref вообще не включал. Есс-но, без этого libvpx со своими 3 re-frames рядом не стоит с x264. См. http://blog.webmproject.org/2010/05/inside-webm-technology-vp8-alternate.html.
> Тогда следует говорить об особенностях программы, а не формата, я считаю.
"Особенности формата" — сферический конь в вакууме. При практическом сравнении всегда сравниваются реализации.
> Формат должен иметь какую-то устойчивую форму спецификации.
Согласен, взятие за основу реализации формата при отсутствии адекватной ей спецификации — лютый пиздец. Надеюсь, завтра будет лучше.
> Телевизоры и декодеры в слотовых затычках предпочитали года три назад [email protected], как на bluray, и никаких вам 10 бит. Что-то изменилось?
Не знаю. Полагаю, что нет.
Речь шла о том, что тот кукарекающий хуй рекомендовал использовать Hi10P, но при этом ругался на плохую совместимость opus'а и vorbis'а.
>>1013605
>ругался на плохую совместимость opus'а и vorbis'а
У тебя галлюцинации.
>рекомендовал использовать Hi10P
Опу аниме же сжимать надо.
>>1013637
>Иди лечись.
Нет ты.
Я ничего НЕ РУГАЛ.
Просто констатировал факты.
Вангую в тебе религиозного психа, последователя штолмана.
Уж больно ты трясешься за эти говновелосипеды.
Вангую потому что они ОТКРЫТЫЕ.
Поэтому не можешь спокойно читать про объекты своей анальной любви. Они у тебя священны, как каран у копроджихадистов.
>>1013605
> хуй рекомендовал использовать Hi10P, но при этом ругался на плохую совместимость opus'а и vorbis'а.
Одно из основных правил ЦОС гласит, что не существует волшебных опций или фильтров, а существует грамотная преобоработка и оптимальная фильтрация. С совместимостью действительно у того полемиста не сходится. Ты здесь прав. Я даже больше скажу, по вопросу совместимости моя позиция жёсткая: если претендуешь на распространённость и, тем паче, массовость, то строгая стандартизация и широкая совместимость абсолютно необходимы. Вот почему я не уважаю сомнительные достижения Майкрософт, например. Одно дело, когда разработчики копошатся в своём базаре, и совсем другое дело — средства массовой автоматизации, ибо другая мера ответственности должна быть, но некоторым за EULA как за каменной стеной.
> Согласен, взятие за основу реализации формата при отсутствии адекватной ей спецификации — лютый пиздец.
Это реверсная разработка, поскольку Гугл купил готовое. А вот ON2 — быдлокодеры, пренебрегающие хорошо известными и проверенными десятилетиями стадиями разработки.
> Надеюсь, завтра будет лучше.
Сомневаюсь, что завтра. У Theora ушло шесть лет, годнота вышла, но конкурентная борьба безоговорочно проиграна.
> сферический конь в вакууме.
Никаких коней. Я тебе указал вполне конкретные инструменты адаптации эффективного сжатия к материалу. Если инструменты есть, то есть гипотетическая возможность повысить эффективность. При отсутствии инструментов даже такой возможности нет. Не забудь, что эффективность от H.261 возрастала последние двадцать лет преимущественно за счёт адаптивных средств кодирования!
> При практическом сравнении всегда сравниваются реализации.
Да. По этой причине важно понимать разницу между форматом и кодером-декодером.
> http://blog.webmproject.org/2010/05/inside-webm-technology-vp8-alternate.html.
Эту статью я читал прежде, чем начать эксперименты. В них материал статьи учтён.
> Есс-но, без этого libvpx со своими 3 re-frames рядом не стоит с x264.
Он и с ними обходит x264 только при посредственном качестве картинки, и то не очень сильно. При такой совместимости с аппаратными декодерами (которые без настоящей спецификации если и будут изготавливать, то неохотно) остаётся только надеяться, что Гугль не замучают судебными исками за сходные с H.264. Если VP8 выдержит возможные патентные претензии, то можно будет говорить о формальной патентной чистоте.
> То есть ты altref вообще не включал.
Давай ты исправишь это заявление на истину, а я не буду тебя пристыжать! Скажем так: ты невнимательно отнёсся к столь обширной экспериментальной базе.
>>1013669
Ты слишком строг к нему.
> Вангую в тебе религиозного психа, последователя штолмана.
Ты слишком критичен. Столлман — это годнота, если бы разработчики хорошо разбирались в вопросе лицензирования собственного кода, то даже не наступали бы себе на яйца с казуистическими лицензиями GPL. В этом плане юрист Лессиг правильно придумал каждую лицензию растолковывать.
Религию делать из свободных лицензий, разумеется, ошибочно. Но из либеральных или потребительских ценностей сделали то же самое — возможно, людям сложно разобраться в казуистике и они всё сводят на доверительные примитивизированные догмы.
> Уж больно ты трясешься за эти говновелосипеды.
Вообще говоря, там трястись не за что. От патентных претензий по словам разработчика x264 и VP8 не застрахован. Принципиально лучшей позиции с это точки зрения не вижу.
> Вангую потому что они ОТКРЫТЫЕ.H.264 тоже открыт, просто защищён патентами, которые суть — злоупотребление властью и должны, по моему скромному убеждению, кануть в лету с прочими средневековыми пережитками.x264 выпущен под GPL. Тоже открыт и свободен.
> Поэтому не можешь спокойно читать про объекты своей анальной любви.
Зачем сразу низводить чувство надежды до такого?
> Они у тебя священны, как каран у копроджихадистов.
Ну, человеку же нужно на что-то ориентироваться. Людям приятно стоять на твёрдой почве.
>>1013688
>Вообще говоря, там трястись не за что.
Я это все к тому, что поделка гула раскрученна в соотвецтвующей среде как очень свободная и открытая, от чего ее соотвецтвующиие фанаты и форсят как очень правильную и во всем много лучшую.
Забывая вообще что она для стриминга делалась.
Ко всему нужно со здравым смыслом подходить.
Свободное По - однозначно добро. Да.
>>1013686
>если претендуешь на распространённость и, тем паче, массовость
Если речь об аниме, то 10 бит среди соотвецтвующей аудитории уже давно стандарт.
Очень любители воровать китайские порномультики это дело оценили.
>>1013748
> она для стриминга делалась.
Не делалсть, а позиционировалась Гуглем для стриминга. Мы же выяснили, что разрабатывать кодеки ON2 не умеет и не может, соответственно, «сделать кодек для стриминга» — это не про ON2. Я удивляюсь, как они смогли продать VP7 Скайпу.
>>1013750
> 10 бит среди соотвецтвующей аудитории уже давно стандарт.
Среди этой аудитории не так давно стала нормой двойка по русскому языку. Норма — это статистическая характеристика, само по себе попадание в норму не является чем-то хорошим или правильным.
> Очень любители воровать китайские порномультики это дело оценили.
Невежды и дилетанты взяли числом.
>>1013775
Не пугайся! Вот тебе сжатый.
Кстати, вот порадовало:
> this means that I’m not going to go easy on On2; they’ve had (at least) 6 years to work on VP8, and a much larger dev team than x264′s to boot.
> В связи с этим я не собираюсь проявлять снисхождение к On2 — у них было, по крайней мере, шесть лет на разработку и существенно большее число разработчиков, нежели у x264.
> While the C code isn’t half bad, the assembly is clearly written by retarded monkeys. But I’m being unfair: this is way better than with VP3.
> Хотя код на Си не так плох, ассемблерные вставки определённо написаны тупыми мартышками. Если быть честным, то это всё равно намного лучше, чем было с VP3.
> the slow mode tries all 2^16 possible DCT coefficient rounding permutations. Whoever wrote this needs to learn what trellis quantization (the dynamic programming solution to the problem) is and stop using exponential-time algorithms in encoders.
> в медленном режиме пробуются все перестановки ДКП-коэффициентов из возможных 2^16. Любому, кто пишет такое, следует знать, что существует сетчатая квантизация (решение проблемы на основе динамического программирования), и прекратить использовать к кодировщиках алгоритмы с экспоненциально возрастающим временем выполнения.
> Relies on “boosting” the quality of golden frames and “alt-ref” frames — a concept I find extraordinarily dubious because it means that the video will periodically “jump” to a higher quality level, which looks utterly terrible in practice.
> [Управление шириной потока], основанное на завышении качества «золотых» и «alt-ref» (альтернативных ссылочных?) кадров, я нахожу весьма сомнительной концепцией, поскольку подобная [стратегия] приводит к скачкообразному изменению качества [воспроизводимого видеоряда], что на практике выглядит ужасно. (Кстати, заметил такую особенность; сначала предположил баг, но из комментариев разработчика можно сделать вывод, что сие задокументировано как фича, Dark_Shikari подтвердил мои опасения — прим.)
> purely reactive ratecontrol algorithm, which probably will not do very well in difficult situations such as hard-CBR and tight buffer constraints
Чисто реактивный алгоритм управления шириной потока, который, весьма вероятно, не будет эффективным в сложных случаях, например, при строго постоянной ширине потока или жёстком ограничении [размера] буфера.
> Furthermore, it does no adaptation of the quantizer within the frame
> Кроме того, [модуль контроля ширины потока] адаптация лишён адаптации квантователя на уровне кадров.
> The encoder attempts to optimize the loop filter parameters for maximum PSNR. I’m not quite sure how good an idea this is; every example I’ve seen of this with H.264 ends up creating very bad (often blurry) visual results.
Кодировщик пытается оптимизировать параметры петлевого фильтра для достижения максимального соотношения сигнал-шум. Не уверен, что идея хорошая, поскольку подобные попытки с H.264 приводят к значительному ухудшению (преимущественно размыванию) картинки.
> Even on the absolute fastest settings with multithreading, their encoder is slow. ...not even enough to reliably do real-time compression. ...I don’t expect On2′s encoder to be anywhere near as fast as x264, but being unable to stream HD video on a modern quad-core system is simply not reasonable in 2010.
> С настройками, соответствующими высочайшей скорости работы, даже в многопоточном режиме их кодировщик [слишком] медленный. ...чего явно недостаточно для обеспечения кодирования в реальном масштабе времени. ...Я не жду, что скорость кодировщика от On2 будет хотя бы приблизительно той же, что у x264, неспособность кодировать потоковое видео на современной четырёхядерной системе в 2010 году просто недопустима.
Dark_Shikari их хорошо приложил. Вот, кстати, о реализованном потенциале:
> As said before, compression-wise the encoder does a pretty good job with the spec that it’s given. The slower algorithms in the encoder are clearly horrifically unoptimized ..., but they still work.
> Как я упомянул ранее, в смысле эффективности сжатия кодер обеспечивает относительно своей спецификации очень хороший результат. Медленные алгоритмы катастрофически нуждаются в оптимизации и, тем не менее, они работают.
А вот моё внимание приковано к следующему:
> The encoder and decoder share a staggering amount of code. This means that any bug in the common code will affect both, and thus won’t be spotted because it will affect them both in a matching fashion.
> Общая кодовая база для кодера и декодера поразительно обширна. Это означает, что ошибка в общем коде отразится и на том и на другом, но явной не будет, т. к. внесёт соответствующие искажения в обе программы. (Всё будет как с самонесовместимыми форматами MSO, где спецификация рождена от реализации — прим.)
(на пикрел VP8)
Интерпретация практического тестирования:
> Note that these numbers are a “best-case” situation: we’re testing all three optimized for PSNR, which is what the current VP8 encoder specializes in as well. This is not too different from my expectations above as estimated from the spec itself; it’s relatively close to x264′s Baseline Profile.
> Заметьте, что эти числа (данные отношения сигнал-шум для медленного профиля VP8, и медленных режимов x264 профилей high и baseline) отражают наилучший случай: мы тестирует все три [кодера] с оптимизацией по отношению сигнал-шум, для которой текущая версия VP8 и приспособлена. Это не сильно отличается от моих ожиданий на основе анализа спецификации, VP8 наиболее близок к H.264 с профилем baseline.
(на пикрел x264, та же ширина потока)
Я так понимаю, что на VP8 следует поставить крест и положить плиту как можно более тяжёлую сразу, как только в Гугль придут первые патентные иски.
>>1013776
Погоди, няша. Поясни-ка за 10bit идиоту.
Он переоценён? Тоесть вся его заявленная супер-пупер функциональность маркетинговый ход? И то что там пишут аля "В ХАЙ ДИСИТЬ БЫТ МОЖНО СЖОТЬ С ТОКИМЖО БЫТРИЙТОМ, НО КОЧЕСТВО БУДУТ КАК В КРУЗИСЕ НА МОКСЕМАЛАЧКАХ" - пиздёшь?
А то я собрался прегонять свою медиатеку в 10 для экономии места (на совместимость похуй, смотрю только на полноценных пеках/ноутах), но ты заронил в меня червя сомнения.
>>1013835
> Поясни-ка за 10bit идиоту.
Все ДКП-преобразования внутри будут с 10-битной точностью. Если исходный материал и выходное устройство при воспроизведении имели точность в 8 бит, с ростом точности преобразований будет наблюдаться побочный эффект, выражающийся в шумовой маскировке искажений квантизации шумом квантования, оставшимся после интерполяции 10-битных отсчётов в 8-битные.
Работает так:
- ты даёшь на вдод отсчёты в форме 8-битных чисел, кодек их сдвигает влево на два разряда (умножает на 4),
- потом находит почленные корреляции с косинусом, значения которого выражены числами с 10-битной точностью, складывает их, чтобы осуществить ДКП-преобразование,
- потом происходит низкочастотная фильтрация, которая сглаживает пространственные градиенты интенсивности;
- потом происходит воспроизведение, обратное ДКП и интерполяция 10-битных отсчётов в 8 бит.
На примере выглядит так:
- у тебя был в исходных 16 отсчётах градиент от 0 до 15/255, и между двумя соседними отсчётами разница в один младший бит, т.е. 1/255 от полной интенсивности,
- после сдвига разница стала 4/1023 (градиент от 0 до 60/1023), а минимально достижимая разница может быть 1/1023,
- после низкочастотной фильтрации и обратного ДКП, градиент сгладится и будет от 0 до 20/1023, например, и будет более-менее аккуратно размазан по 16 отсчётам с шагом 1/1023, а если бы ДКП был 8-разрядным, то случилось бы вот что: появились бы заметные на глаз области с одинаковой интенсивностью (несколько видимых полосок вместо плавного градиента) из-за ошибки округления;
- при интерполяции 10-битных значений происходит тоже происходит округление, но т.к. пространственное распределение интенсивности известно более точно, то можно применять специальные приёмы пространственной фильтрации, зашумляющие преобразованные отсчёты (например, диффузионным методом), создавая иллюзию плавного градиента при использовании отсчётов 8-разрядной точности.
Кроме того, в процессе оптимальной низкочастотной фильтрации меньше шанс потерять градиенты выраженные не ярко, например градиент от 0 до 20/1023 примерно соответствует градиенту от 0 до 5/255, который на 16 отсчётов кроме как шестью полосками не растянешь, а градиент от 0 до 3/1024 и вовсе при 8-разрядных преобразованиях будет потерян (возвратится ряд отсчётов одного и того же уровня).
Примерно так в весьма грубом приближении это выглядит. Изнутри. Снаружи это выглядит так: чтобы остались видны йоба-градиенты для 8-разрядных преобразований необходимо использовать чуть менее жёсткую низкочастотную фильтрацию, т.е. занижать квантователь, следовательно, увеличивать поток данных на 10-20%.
> Он переоценён?
Несомненно. Следует понимать, что при использовании 10-разрядных преобразований и занижении потока данных информации в сигнале становится меньше, отношение сигнал-шум (сигнал-искажения) уменьшается. Текстуры и перепады деградируют сильнее, и только градиенты смягчаются.
> свою медиатеку в 10 для экономии места
Никакого практического смысла. Просто потратишь много времени и электроэнергии, если медиатека большая, то выгоднее может оказаться купить ещё один винт.
>>1013848
Спасибо тебе за помощь, няш. Но раз ты уж всё-таки здесь, проясни ещё пару-тройку вопросиков, если не сложно, нубу.
Как тогда поступить с битрейтом? Что лучше - фиксированный или переменный (в отношении качество/вес)? А то я вот (будучи анимублядью конечно), взял Салендервский ЙОБА 10бит рип Евы по ~750 метров на серию: http://pastebin.com/ihdjDzJP и перегнал в обычный: http://pastebin.com/A3NDPYgT по ~200 на серию (звуковую дорогу просто копировал без перекодирования).
В итоге, субъективно, нихуя не поменялось качество. Даже немного сочнее стало (из-за пресета для аниму).
Я всё правильно сделал? Или всё-таки соснул?
>>1013863
> Ширина : 768 пикселей
> Высота : 576 пикселей
> Частота кадров : 23,976 кадра/сек
Внезапно. Т.е. это апскейл (720×576->768×576) апскейла (720×480->720×576) с DVD. И перекод перекода. Если тебе норм, то я не возражаю. Кстати, количество фагготрии у тебя уменьшилось, количество здравого смысла возросло.
>>1013877
> Т.е. это апскейл
А вот хуй знает. Даже не задумывался об этом (до твоего комментария). Но я ок с этим. Морды вроде не растянуты и не вытянуты. Бока необрезаны. Так что я даже незамечал.
> перекод перекода
В том и суть. Мне влом качать ДвД и рипать самому (тем более я нуб в этом). Поэтому скачал самый-самый "пиздатый" рип, какой смог найти, и пережал его. Вот и прошу советов мудрых, по поводу "Стоила ли овчинка выделки?".
> количество фагготрии у тебя уменьшилось
> тебя
Ты меня с кем-то путаешь. Я пишу в ИТТ первый раз (начиная с вопроса про 10бит).
>>1013686
> если претендуешь на распространённость и, тем паче, массовость, то строгая стандартизация и широкая совместимость абсолютно необходимы.
Я в этом плане следую ещё более жёстким принципам: стараюсь не отходить от стандартов даже при написании скриптов личного пользования. Исключение — когда отход от них даёт ощутимый профит.
> А вот ON2 — быдлокодеры, пренебрегающие хорошо известными и проверенными десятилетиями стадиями разработки.
Мало того, они ещё и заявляли про свои кодеки несусветную чушь вроде 50% превосходства VP8 над H.264.
> Я тебе указал вполне конкретные инструменты адаптации эффективного сжатия к материалу. Если инструменты есть, то есть гипотетическая возможность повысить эффективность.
В случае с VP8 и H.264 это верно, да, т.к. речь не идёт о форматах на основе принципиально разных моделей представления данных.
> При такой совместимости с аппаратными декодерами (которые без настоящей спецификации если и будут изготавливать, то неохотно)
Их делают таки. Есть 4 энкодера и 1 декодер: http://wiki.webmproject.org/vp8-implementations.
> Давай ты исправишь это заявление на истину, а я не буду тебя пристыжать! Скажем так: ты невнимательно отнёсся к столь обширной экспериментальной базе.
Извиняюсь, сидел тогда на gprs, загрузилась только половина таблицы.
>>1013848
Отложил радугу с объяснения. Но причину лучшего сохранения тёмных сцен (где HiP даёт квадраты, Hi10P — вполне приличную картинку) в нём не нашёл.
>>1013883
> Я пишу в ИТТ первый раз (начиная с вопроса про 10бит).
Фагготрии в параметрах. Тот, кто делал 10-битный рип испытывает к настройкам x264 лютую оккультную тягу. Ничем иным иррациональное завышение объяснить нельзя.
> А вот хуй знает.
Не хуй, а лично я. 23,976 — это FILM для 3:2 телекино, которое для NTSC на 480 строк, в т.ч. и на ДВД. Но в ролике фигурируют 576 строк, которые для PAL, который на 25 кадров/с. А ещё оба перечисленных стандарта имеют неквадратные пиксели, если бы масштабирование было единоразовым, то разрешение было бы 640×480, но кто-то упрлс (а «Евангелион» кагбэ символизирует) и твёрдо решил, что строк должно быть 576, бит должно быть десять. Короче, при случае избегай этого поехавшего.
> самый-самый "пиздатый" рип
Насчёт «пиздатый» не скажу, но ты нашёл самый ебанутый.
> Стоила ли овчинка выделки?
Если работает и занимает места столько, сколько тебе надо, а внешний вид устраивает, но стоила, разумеется.
>>1013891
> Их делают таки. Есть 4 энкодера и 1 декодер
Неплохо.
> на основе принципиально разных моделей представления данных
Да, например, компенсация движения в SNOW или Daala сделана иначе, чем в MPEG и кодеках On2.
> Отложил радугу с объяснения.
Я же ни одной формулы не нарисовал даже, а ты уже испугался!
> причину лучшего сохранения тёмных сцен
> в нём не нашёл
Я тебе выделю:
>> оптимальной низкочастотной фильтрации меньше шанс потерять градиенты выраженные не ярко, например градиент от 0 до 20/1023 примерно соответствует градиенту от 0 до 5/255, который на 16 отсчётов кроме как шестью полосками не растянешь, а градиент от 0 до 3/1024 и вовсе при 8-разрядных преобразованиях будет потерян (возвратится ряд отсчётов одного и того же уровня)
Тут ничего сложного. Там, где после подбора квантователя (оптимальной низкочастотной фильтрации) от восьмиразрядных коэффициентов ДКП останется одна постоянная составляющая (равномерный фон на весь блок, не совпадающий, разумеется с таковым в соседнем блоке, если градиент был длиннее блока), то от 10-разрадного отсчёта могут остаться ещё и переменные составляющие, дающие таки градиент с пространственным распределением интенсивности, стыкующимся на границах блоков. А если у вас там совсем ровный фон был и появились блоки, то тут нужно уметь использовать петлевой фильтр.
>>1013942
> а ты уже испугался!
Ты неправильно понял. Я таким образом пытался выразить восторг.
> Я тебе выделю:
> …
Но речь не о градиентах, а о более сложных изображениях. Позже попробую найти или соорудить пример.
>>1013863
>Что лучше - фиксированный или переменный (в отношении качество/вес)?
Ты для начала ответь на вопрос.
Зачем ты каким то пересжатием занимаешься если имеешь такое смутное представления о всем этом?
И почему не читаешь базовые доки по x264?
Постоянный битрейт имеет смысл только в том случае, если тебе нужен постоянный битрейт.
Если ты не знаешь зачем он тебе - он тебе ненужен.
Если тебе нужно ужать файл в определенный размер - ты используешь средний битрейт и 2 прохода.
Если тебе нужно постоянное качество - CRF
>взял рип и перегнал
Зачем?
Почему бы тебе просто не скачать уже готовый рип подходящего тебе размера и качества?
Серьезно, анон. Я тебе даю очень дельный совет.
Очевидно же что ты не мастер этого дела, зачем ты вообще этим пытаешься заниматься?
Лучше поучи что нибудь полезное.
>>1013835
>Тоесть вся его заявленная супер-пупер функциональность маркетинговый ход?
Ты совсем поехавший. Какой еще маркетинговый ход. Это же чудо опенсорс пилит. Функциональность такая же как и 8 бит x264.
>А то я собрался прегонять свою медиатеку в 10 для экономии места (на совместимость похуй, смотрю только на полноценных пеках/ноутах)
Если твоя коллекция состоит из рипов, то перегонять ее во что-то верх долбоебизма.
Если у тебя блюрей и ДВД пользуй 10 бит.
Хуже от этого не станет.
>>1013776
>Среди этой аудитории не так давно стала нормой двойка по русскому языку. Норма — это статистическая характеристика, само по себе попадание в норму не является чем-то хорошим или правильным.
>Невежды и дилетанты взяли числом.
Вот ненужно только тут дешевой демагогии и обмазывания дерьмо. Не позорься.
10 бит на том же битрейте дает хуже качество чем 8 бит?
А как насчет работы с изображениями имеющими большие монотонные области?
>>1013946
> выразить восторг.
Спасибо. Было более-менее понятно?
> Но речь не о градиентах, а о более сложных изображениях.
А ты никогда не видел сетчатых градиентов? Они и двумерными могут быть. Я использую градиент как абстракцию. Для ДКП, как для всех Фурье-подобных преобразований принципиально отличается только постоянная составляющая, т. е. ровный однотонный фон, а все остальные даются инвариантно через гармонические составляющие, сложность градиента для них не является принципиальной. Лишь как отдельные случаи можно рассмотреть: текстуры как квазипериодические и эффективно представляемые через ДКП и резкие границы, которые являются бросками с насыщенным спектром (и дают «звон» вокруг из-за отсечения высокочастотных гармоник).
>>1013863
> Что лучше - фиксированный или переменный (в отношении качество/вес)?
Ничего. Модуль контроля ширины потока в x264 на удивление гибок и обладает одной из лучших систем адаптации из всего остального распространённого. Это к тому, что даже неграмотная настройка даёт хороший результат, а от режима контроля ширины потока, за исключением крайних случаев, эффективность сжатия заметно не страдает. Другими словами, несколько режимов модуля контроля ширины потока существуют для твоего удобства: CQP — для тестирования, CRF — для однопроходного с переменной шириной потока и консервативными QP (квантователями), ABR — для однопроходного с переменной и консервативной шириной потока, многопроходный VBR — для точного попадания в размер файла, CBR — для исключительного случая, например, трансляции по синхронному каналу связи. Эффективность сжатия VBR и CRF отличается незначительно, время потраченное на два прохода больше в 1,5 раза, зато в размер файла можно точно попасть. Вот и весь выбор.
>>1013948
> И почему не читаешь базовые доки по x264?
Кстати да, что там за базовая документация?
> Вот ненужно только тут дешевой демагогии и обмазывания дерьмо. Не позорься.
Как ты мог меня заподозрить в ассоциативной вине. Просто пример того, что нормальность и распространённость — не аргумент в пользу правильности. Могу предложить альтернативный: самонесовместимые форматы майкрософт это распространённая норма, но это неправильно.
> 10 бит на том же битрейте дает хуже качество чем 8 бит?
Не обязательно. Качество в этом деле — весьма неопределённая категория. Вопрос некорректный.
> А как насчет работы с изображениями имеющими большие монотонные области?
Ох, для этого кроме High10 в x264 внезапно есть ещё инструменты, не повышающие профиль. Я лишь настаиваю на необоснованности использования high10 во многих случаях.
>>1014103
>Как ты мог меня заподозрить в ассоциативной вине
Та вот так вот.
>Просто пример того, что нормальность и распространённость — не аргумент в пользу правильности
Правильность разная бывает.
Зависит от того как и чем мерить.
Ты говоришь о критерии максимально возможной совместимости. Так это не единственный критерий во вселенной.
>Не обязательно. Качество в этом деле — весьма неопределённая категория. Вопрос некорректный.
Пф. Под качеством я подразумеваю объясненную дисперсию.
Ну или какой либо другой метод позволяющий посчитать общее отклонение сжатого видео от оригинала в каких-то условных единицах.
При равном битрейте и типом исходного видео - анимация, больше информации сохранить 10бит версия, или 8 бит?
Если не знаешь, подскажи как тем же ффмпегом разницу между 2мя видевами посчитать.
>Я лишь настаиваю на необоснованности использования high10 во многих случаях.
В каких случаях его использовать обоснованно?
>Ох, для этого кроме High10 в x264 внезапно есть ещё инструменты, не повышающие профиль.
Какие?
>Кстати да, что там за базовая документация?
Хз.
https://trac.ffmpeg.org/wiki/Encode/H.264
Гуглится например сразу же.
На русском дофига статей тоже.
>>1013486
>В /b/ проходила специальная олимпиада по деинтерлейсингу и запиливанию WebM из http://rutracker.org/forum/viewtopic.php?t=4290607, но хорошего результата ни у кого не вышло — у всех остались наложенные друг на друга кадры — например, двоящийся рыбий глаз. Мб тут у кого получится?
Вариант 1.
Используется "yadif=send_field:tff:all, mcdeint=medium:tff"
Кстати. Видео действительно плохо деинтерлейсится. Медия плеер классик вместе с радивоном вроде как справляется хорошо, но в один момент всеравно какая-то херня вылазит.
Так или иначе.
Проблема тут в размере файла.
Запихнуть 2хминутный клип в 6 мегабайт - ну никак нельзя. Разве что x264 еще можно было бы попробовать.
>>1014180
С ресайзом получше конечно.
>>1014183
снизил
>>1014185
Еще один тест макс размера
>>1014180
Все.
Финальный вариант!
Видео было заинтерлейсино вот так:
-filter:v "yadif=send_field:tff:all, mcdeint=extra_slow:tff"
Затем ресайзнуто с фрейм бропом до 25фпс вот так:
-r 25 -filter:v "scale=360:-1" -sws_flags lanczos
Затем сжато вот так:
set video_encoder=-vcodec libvpx -qmin 0 -qmax 63 -quality best -b:v 300k
set audio_encoder=-ac 1 -acodec libvorbis -b:a 45k
В 2 прохода.
Правда небольшая рябь в начале на тексте немного раздражает.
Быть может этот >>1014186 вариант лучше, тобишь mcdeint=medium:tff
>>1014153
> Правильность разная бывает.
Правильность не бывает разной правильность решения в его обоснованности.
> Ты говоришь о критерии максимально возможной совместимости. Так это не единственный критерий во вселенной.
Со стандартами это, внезапно, основной критерий.
> При равном битрейте и типом исходного видео - анимация, больше информации сохранить 10бит версия, или 8 бит?
Разумеется, в 8 бит. Т.к. информация представлена более компактно.
> Ну или какой либо другой метод позволяющий посчитать общее отклонение сжатого видео от оригинала в каких-то условных единицах.
Практических для видео всего два: PSNR (пиковое отношение сигнал-шум, которое используется повсеместно в измерительной технике, оно простое, но, к сожалению, оптимизация по этому критерию расходится с субъективной оценкой «качества», как при шумовой маскировке в психоакустике, так и при передаче изображений с потерями, когда сильно искажённая текстура воспринимая как текстура, и размазня, не воспринимаемая как текстура имеют одинаковое отношение сигнал-шум) и SSIM.
> В каких случаях его использовать обоснованно?
Когда у тебя исходный материал квантован 10 разрядами/канал.
> Какие?
Как минимум, адаптация квантователя, петлевой фильтр и мёртвая зона, а есть ещё несколько ручек психовизуальной оптимизации и заказные матрицы для квантователя. Просто это решение сложнее, за него не всякий возьмётся. Кстати, в x264 гораздо больше инструментов для снижения блочности на квазимонотонных участках, нежели, например, в ffmpeg2 (это MPEG-2 кодер в составе lavc), тогда мне пришлось серьёзно повозиться, дошло до подбора фильтров к исходнику.
> Хз.
Вот и я тоже не вижу методичку. Только статьи, только HOW-TO.
> Если не знаешь, подскажи как тем же ффмпегом разницу между 2мя видевами посчитать.
Ни разу не считал при помощи ffmpeg. Считал при помощи SSIM-плагина к avisynth. Но там только 8 бит, и только хардкор. Насколько знаю, x264 считает для тебя сырые ssim-ы при кодировании, если попросить. Попробуй им. Учти, что у сырых ssim псевдологарифмическая шкала, чтобы получить альтернативную шкалу SSIM (как у меня на пике была) нужно значение возвести в восьмую степень и умножить на 100.
Зацените, что у меня получилось.
tfm(order=1).tdecimate(mode=1,hybrid=3)
>>1014240
Кто бы сомневался что avisynth и tivtc умеют в заебись. Ну, разумеется, из тех, кто знает, что такое avisynth и tivtc.
>>1013257
Юзай HandBrake
>>1014240
С уменьшением разрешения и фпс любой осел сможет (просто отбрасываешь одно поле и все). Попробуй все это сохранить.
Только скачал, много лет не занимался. Сейчас гляну сам.
Ладно, сорри, там и правда сложный случай, надо еще и мусор удалить.
Кстати зведы с облаками например, по-моему, движутся на частоте 48 кадров в секунду. Слабо сохранить, мастера деинтерлейса?
Я сам никогда на кино и аниме не специализировался, работал с телевизионными 50i
>>1019687
> С уменьшением разрешения и фпс любой осел сможет (просто отбрасываешь одно поле и все).
Какие ваши доказательства?
Судя по приведённым фильтрам сопоставлены поля, выделены и выброшены дубликаты, а для 3:2-последовательностям применено смешивание.
>>1019705
> Я сам никогда на кино и аниме не специализировался, работал с телевизионными 50i
Т.е. про телекино ты не знаешь?
>>1019713
Знаю-знаю, не работал просто. Уже выше признал, что не все так просто. При отбросе некоторые кадры отсаются с гостингом.
>>1019720
> отсаются с гостингом.
Со смешанными полями же.
>>1019713
> а для последовательностей, не являющихся 3:2-телекино
fix
Нужна помощь знающих людей. Решил заделаться мамкиным рипером и начать делать рипы хентая лоликона. Посоветуйте хороший гайд по этому процессу, чтобы не было потерь в качестве и без всяких ненужных плагинов которые лишь губят изображение.