|
|
|
Ноusе
Стаж: 15 лет 9 месяцев Сообщений: 968
|
Ноusе ·
09-Дек-11 12:30
(13 лет 9 месяцев назад)
Не думаю что есть смысл экономить место и при этом понижать качество. Винты сейчас дешевые(ну были, и скоро тоже упадут надеюсь). А на это ваше лишнее кодирование уходит много ресурсов типа электроэнергии и еще нужно собирать мощную систему.
|
|
|
|
Tim68
Стаж: 15 лет 7 месяцев Сообщений: 712
|
Tim68 ·
10-Дек-11 08:34
(спустя 20 часов, ред. 10-Дек-11 08:34)
MasterNobody писал(а):
Напишете же как правильно читать вашу картинку с пояснением к каждому элементу картинки.
Картинка неправильная, но насколько сейчас разбираюсь. Только вот в каком виде более информационно, в виде пирамиды или последовательности IBbbPBbb...?
MasterNobody писал(а):
Tim68 писал(а):
.....
1.) Методы создания промежуточных кадров, используя MVTools, прописано выше
MasterNobody писал(а):
Как я уже писал, это совсем другое и мало что имеет общего с видео кодированием, кроме того что там используется ME.
Это не одно и то же, но общее безусловно есть и кроме ME:
MasterNobody писал(а):
Для справки ME - это Motion Estimation, .... а то что вы привели, это просто параметры поиска
Вижу, что Вы это тоже знаете, не обижайтесь, какой вопрос -такой ответ.
Подобные параментры поиска присутствуют и в MVTools.
MasterNobody писал(а):
Советую вам сначала подтянуть свои базисные знания по принципам видео кодеков (почитайте например вот эту книжу)
Подобные советы всегда принимаются в какой бы форме они не были. За литературу спасибо, правда способностью свободного чтения не обладаю, но буковки за прошедшие четверть века с лишним незабыл.
MasterNobody писал(а):
структура IIIII... не будет беспотерьным сжатием (не верите на слово, попробуйте "--keyint 1 --qp 51" и сравните с оригиналом). 2) сравните с GOP стремящимся к бесконечности (--keyint infinite --no-scenecut --qp 16)
Верю, но мы оба прекрасно понимаем, что разговор ведется о беспотерьном межкадровом сжатии и составляющая внутрикадрового сжатия здесь нерассматривалась.
Между прочим, сравнение "--keyint 1 --qp X" и "--keyint infinite --no-scenecut --qp X" с одинаковыми значениями --qp может быть весьма показательным. Спасибо.
MasterNobody писал(а):
Tim68 писал(а):3.) Детская игра "Глухой телефон" (для детей дошкольного возраста) .
MasterNobody писал(а):
Как и 1-й пункт ничего общего с видео кодированием.
Шутка конечно, но в каждой шутке есть доля правды, и там и здесь потерьная последовательность передачи информации. Вы просто не хотите обобщать, т.к. Вам в данном случае это не выгодно, хотя к этому часто прибегаете (VBV и бассейн).
MasterNobody писал(а):
Может-может, так как P/B-кадры могут все, что может I-кадр. Советую все же почитать книжку. И даже если запретить им использовать Intra-макроблоки, то все равно может, просто будет нужно еще больше бит.
"Вечный двигатель" не обсуждается. Вопрос стоит о том, что более потерьно длинные или короткие группы, что оптимально, а что экстримально?
За commit спасибо.
скрытый текст
Make B-pyramid spec-compliant
......
Two modes are now available:
1) strict b-pyramid, while worse for compression, follows the rule mandated by Blu-ray (no P-frames can reference B-frames)
2) normal b-pyramid, which is like the old mode except fully compliant.
Запрет ссылаться Р кадрам на ссылочные B кадры при маленьких подгруппах (группах) действительно полезная вещь, т.к. предыдущий I или Р кадр, более высокого качества, находится рядышком, чего не скажешь о длинных ... , да и ссылочный B кадр окажется скорее всего последующим после I или P кадра или первым в подгруппе B кадров.
Ноusе писал(а):
Не думаю что есть смысл экономить место и при этом понижать качество. Винты сейчас дешевые(ну были, и скоро тоже упадут надеюсь).
Вы о чем, да и после всем известного потопа все куда удручающе. Недолече как менее полгода назад Я случайно отформатировал винт и что, ах да, Вы убеждены,что с Вами такого неслучиться.
|
|
|
|
MasterNobody
Стаж: 17 лет 1 месяц Сообщений: 158
|
MasterNobody ·
10-Дек-11 11:23
(спустя 2 часа 49 мин., ред. 10-Дек-11 11:23)
Tim68 писал(а):
Верю, но мы оба прекрасно понимаем, что разговор ведется о беспотерьном межкадровом сжатии и составляющая внутрикадрового сжатия здесь нерассматривалась.
Если речь велась о беспотерьном сжатии, то с какого фига вдруг длинный GOP стал с потерями. "--keyint infinite --no-scenecut --qp 0" будет настолько же беспотерьным, насколько и "--keyint 1 --qp 0", да и место наверняка будет занимать меньше.
Цитата:
Между прочим, сравнение "--keyint 1 --qp X" и "--keyint infinite --no-scenecut --qp X" с одинаковыми значениями --qp может быть весьма показательным. Спасибо.
Если хотите действительно одинаковый QP в таком тестировании, то не забудьте об "--ipratio 1.0 --pbratio 1.0"
Tim68 писал(а):
Вы просто не хотите обобщать, т.к. Вам в данном случае это не выгодно, хотя к этому часто прибегаете (VBV и бассейн).
Я не против аналогий (и как вы видели, сам ими пользуюсь), но они должны быть действительно похожими (а данная аналогия таковой не является, видимо из-за неправильной вами трактовки принципов межкадрового сжатия в H.264).
Tim68 писал(а):
Запрет ссылаться Р кадрам на ссылочные B кадры при маленьких подгруппах (группах) действительно полезная вещь, т.к. предыдущий I или Р кадр, более высокого качества, находится рядышком, чего не скажешь о длинных ... , да и ссылочный B кадр окажется скорее всего последующим после I или P кадра или первым в подгруппе B кадров.
Ничего полезного в этом нет, так как это ограничение, а уж использовать этот кадр для предсказания или нет мог бы решить кодек (если он полезен то использовал бы, если нет - то нет), а здесь уже без вариантов. Насчет более высокого качества предыдущего I или P кадра тоже не факт, так как этот B-кадр будет хронологически ближе к предсказываемому, а значит между ними меньше разница (движения), так что пусть кодек решает какой лучше.
|
|
|
|
Tim68
Стаж: 15 лет 7 месяцев Сообщений: 712
|
Tim68 ·
10-Дек-11 18:08
(спустя 6 часов)
MasterNobody писал(а):
Если речь велась о беспотерьном сжатии, то с какого фига вдруг длинный GOP стал с потерями.
Не переворачивайте, речь шла об отправной точке соответствующей беспотерьному межкадровому сжатию. Повторюсь.
Tim68 писал(а):
2.) При стремлении GOP к 1-це получаем структуру IIIII... , т.е. беспотерьное межкадровое сжатие, при стремлении к бесконечности - полная потеря информации, по какому бы алгоритму мы не соединили две крайнии точки (1 и бесконечность), то по мере удаления от 1-цы будет расти потерьность
....
P.S.
Незабыть о применяемых коэффициентах снижения качества при межкадровом сжатии ......
Предлагая выставить --qp 0, --ipratio 1.0 и --pbratio 1.0 Вы сознательно ведете к I=P=B, что эвивалентно IIIII...последовательности, т.е. к полному отсутствию результата. Безусловно, для получения явно видимого результата необходимо использовать некие средние значения --qp и лучше умолчательные для --ipratio и --pbratio.
MasterNobody писал(а):
Я не против аналогий..., но они должны быть действительно похожими
Похоже, похоже. Даже ребенок, игравший в "Глухой телефон" поймет общий процесс потерьного сжатия информации, все остальное это уже детали хотя и важные.
MasterNobody писал(а):
Ничего полезного в этом нет, так как это ограничение, а уж использовать этот кадр для предсказания или нет мог бы решить кодек (если он полезен то использовал бы, если нет - то нет), а здесь уже без вариантов. Насчет более высокого качества предыдущего I или P кадра тоже не факт, так как этот B-кадр будет хронологически ближе к предсказываемому, а значит между ними меньше разница (движения), так что пусть кодек решает какой лучше.
При маленькой подгруппе, если кадры рядом ..PBbb PBbb... ,т.е. временное различие кадров незначительно, то всегда лучше сослаться на более качественный Р кадр, т.к. в реалиях --pbratio отличен от единицы - в данном случае strict имеет положительное действие. При длинных подгруппах strict заставит сослаться на очень удаленный по времени кадр, лучше выбрать менее качественный B кадр, но рядышком - в данном случае strict явный минус.
|
|
|
|
MasterNobody
Стаж: 17 лет 1 месяц Сообщений: 158
|
MasterNobody ·
10-Дек-11 19:37
(спустя 1 час 28 мин.)
Tim68 писал(а):
Не переворачивайте, речь шла об отправной точке соответствующей беспотерьному межкадровому сжатию.
В данном случае переворачиваете только вы. То вы говорите что IIII... - это беспотерьное сжатие, когда же я показал что это не так, то вдруг придумали какие-то кривые отмазы о "беспотерьном межкадровом сжатии" (нет такого термина отдельно от беспотерьного сжатия). Когда же я показал вам, как на самом деле выглядит беспотерьное сжатие, и что оно может быть и для последовательности IPPPP, то вам и это не понравилось. Дайте же наконец четкое развернутое определение (но без воды) вашего "беспотерьного межкадрового сжатия", но которое на самом деле не является беспотерьным сжатием.
Tim68 писал(а):
Предлагая выставить --qp 0, --ipratio 1.0 и --pbratio 1.0 Вы сознательно ведете к I=P=B, что эвивалентно IIIII...последовательности, т.е. к полному отсутствию результата.
Ну для --qp 0 их выставлять я не просил (они там все равно не используются). И "I=P=B, что эвивалентно IIIII...последовательности" тоже неверно (размер-то сравните). Для других же тестов (с --qp > 0) я предложил поставить "--ipratio 1.0 --pbratio 1.0", чтобы получить действительно одинаковый QP на все длине последовательности в обоих случаях.
Tim68 писал(а):
Похоже, похоже. Даже ребенок, игравший в "Глухой телефон" поймет общий процесс потерьного сжатия информации, все остальное это уже детали хотя и важные.
Вовсе не похоже, потому что в "испорченном телефончике" (полагаю, вы подразумевали эти правил игры или вариант с текстом вместо слова, так как правила схожих по названию игр вообще мало похожи на процесс кодирования; если же я ошибся, то приведите правила той игры что вы подразумевали) каждый следующий игрок получает лишь одно подверженное искажениям слово (кадр который используется для предсказания), но не знает оригинального слова (сжимаемый сейчас кадр). Кодек же знает их оба, и может как переставлять слоги (макроблоки) из испорченного слова (процесс предсказание движения), так и заменить некоторое количество букв после перестановки на такие чтобы слово было больше похоже на оригинальное слово (он ведь его знает) используя бюджет таких замен (бюджет битрейта). Так что это не детали, а кардинальные различия.
Tim68 писал(а):
При маленькой подгруппе, если кадры рядом ..PBbbPBbb... ,т.е. временное различие кадров незначительно, то всегда лучше сослаться на более качественный Р кадр, т.к. в реалиях --pbratio отличен от единицы - в данном случае strict имеет положительное действие. При длинных подгруппах strict заставит сослаться на очень удаленный по времени кадр, лучше выбрать менее качественный B кадр, но рядышком - в данном случае strict явный минус.
Как я говорил ваше предположение о большем качестве более удаленных кадров не верно (и они требуют большее число бит из-за большего различия). Возьмите да проведите тестирование метриками PSNR/SSIM закодировав с --b-pyramid strict/normal, на вашем коротком GOP, только не забываете про одинаковый битрейт (размер) файлов и про то что PSNR/SSIM лучше измерять отключив психовизуальные оптимизации.
|
|
|
|
Tim68
Стаж: 15 лет 7 месяцев Сообщений: 712
|
Tim68 ·
10-Дек-11 23:08
(спустя 3 часа, ред. 10-Дек-11 23:08)
MasterNobody писал(а):
Дайте же наконец четкое развернутое определение (но без воды) вашего "беспотерьного межкадрового сжатия", но которое на самом деле не является беспотерьным сжатием.
На самом деле написать четкое развернутое определение весьма сложно и неблагодарно т.к. всегда появятся люди способные цепляться за слова, вроде Вас. Хотя уже наверно Все кто прочитал все поняли, рискну пояснить по другому.
Фотография представлена каждым своим пикселем и ее можно сохранить с разной степенью сжатия - внутрикадровое сжатие (внутрикадровые потери). Аналогом является I кадр видеопоследовательности.
P и B кадры видеопоследовательности имеют другую природу и относятся к межкадровому сжатию (межкадровые потери). Если из видеопоследовательности, состоящей из кадров, имеющих как внутрикадровое (I), так и межкадровое сжатие (P,B) удалить P и B кадры (GOP=1), то остануться только I кадры и только внутрикадровые потери. Нет P и B кадров - нет и межкадровых потерь => сжатие без межкадровых потерь.
MasterNobody писал(а):
И "I=P=B, что эвивалентно IIIII...последовательности" тоже неверно (размер-то сравните).
Верно. Качественное понятие. Размер будет действительно разный.
MasterNobody писал(а):
приведите правила той игры что вы подразумевали
В 70-е игра весьма была популярна у детворы. На входе некое предложение, имеющее конкретный смысл, далее нашептывается по цепочке, кто поменяет порядок слов, кто пропустит слово, кто заменит слово своим и т.д. Чем больше участвующих в цепочке, тем менее предсказуем результат на выходе даже смысл теряется, хотя на каждом звене особых потерь нет, ошибка имеет свойство накапливаться.
MasterNobody писал(а):
Как я говорил ваше предположение о большем качестве более удаленных кадров не верно (и они требуют большее число бит из-за большего различия).
В основе предположение верно, ссылка на более качественный, более информативный кадр сама посебе потребует большее число бит, а величина различий будет зависить от динамичности источника. Надо большее число бит, значить надо их дать, вцелом результат от этого только выиграет. В случае --b-pyramid normal ссылочный B кадр, стоящий перед P кадром (... PBbbP..) будет сам состоять в большинстве своем из ссылок на МВ предыдущего P кадра да еще и --pbratio...
MasterNobody
С Вашего позволения сноску на литературу в первый пост?
|
|
|
|
MasterNobody
Стаж: 17 лет 1 месяц Сообщений: 158
|
MasterNobody ·
11-Дек-11 00:47
(спустя 1 час 39 мин., ред. 11-Дек-11 00:47)
Tim68 писал(а):
На самом деле написать четкое развернутое определение весьма сложно и неблагодарно т.к. всегда появятся люди способные цепляться за слова, вроде Вас.
Т.е. именно определения не будет, так и запишем.
Tim68 писал(а):
Хотя уже наверно Все кто прочитал все поняли, рискну пояснить по другому.
Фотография представлена каждым своим пикселем и ее можно сохранить с разной степенью сжатия - внутрикадровое сжатие (внутрикадровые потери). Аналогом является I кадр видеопоследовательности.
P и B кадры видеопоследовательности имеют другую природу и относятся к межкадровому сжатию (межкадровые потери). Если из видеопоследовательности, состоящей из кадров, имеющих как внутрикадровое (I), так и межкадровое сжатие (P,B) удалить P и B кадры (GOP=1), то остануться только I кадры и только внутрикадровые потери. Нет P и B кадров - нет и межкадровых потерь => сжатие без межкадровых потерь.
Дак вот это называется не "беспотерьным межкадровым сжатием", а просто отсутствием межкадрового сжатия (чистое Intra сжатие), и беспотерьного в нем ничего нет.
Tim68 писал(а):
Качественное понятие.
В чем же выражается эта "качественность" понятия?
Tim68 писал(а):
В 70-е игра весьма была популярна у детворы. На входе некое предложение, имеющее конкретный смысл, далее нашептывается по цепочке, кто поменяет порядок слов, кто пропустит слово, кто заменит слово своим и т.д. Чем больше участвующих в цепочке, тем менее предсказуем результат на выходе даже смысл теряется, хотя на каждом звене особых потерь нет, ошибка имеет свойство накапливаться.
Ну это по сути и есть "испорченный телефон", который я описал, а не "глухой телефон", под которым чаще понимают что-то типа этого, т.е. когда один игрок другому описывает слово не называя его. В любом случае и та и другая игра мало похожи на видео сжатие и не подходят как аналогии, так как там отсутствует процесс восстановления (внесения исправлений в полученное на основе эталонного образца).
Tim68 писал(а):
В основе предположение верно, ссылка на более качественный, более информативный кадр сама посебе потребует большее число бит, а величина различий будет зависить от динамичности источника. Надо большее число бит, значить надо их дать, вцелом результат от этого только выиграет. В случае --b-pyramid normal ссылочный B кадр, стоящий перед P кадром (...PBbbP..) будет сам состоять в большинстве своем из ссылок на МВ предыдущего P кадра да еще и --pbratio...
Вы оперируете не фактами, а лишь предположениями (а я уже высказался, что они неверны ИМХО). Не верите, проведите все-таки тестирование.
Tim68 писал(а):
С Вашего позволения сноску на литературу в первый пост?
Ссылку на книжку, что я постил? Да пожалуйста.
|
|
|
|
Tim68
Стаж: 15 лет 7 месяцев Сообщений: 712
|
Tim68 ·
11-Дек-11 09:13
(спустя 8 часов, ред. 11-Дек-11 09:13)
MasterNobody писал(а):
Т.е. именно определения не будет
Нет необходимости. Похоже мы договорились см. ниже, да и определения на фундаментальные понятия должны быть уже написаны, или нет?
Tim68 писал(а):
Нет P и B кадров - нет и межкадровых потерь => сжатие без межкадровых потерь
MasterNobody писал(а):
а просто отсутствием межкадрового сжатия (чистое Intra сжатие)
Далее...
MasterNobody писал(а):
В чем же выражается эта "качественность" понятия?
Приводя --ipratio и --pbratio к единице Мы отказываемся от снижения межкадрового качества => Качественное понятие.
MasterNobody писал(а):
та и другая игра мало похожи на видео сжатие и не подходят как аналогии, так как там отсутствует процесс восстановления (внесения исправлений в полученное на основе эталонного образца).
Никогда и ни у кого не получалось подобрать аналогию полностью учитывающую все детали. Процесс восстановления неучитываемая деталь.
MasterNobody писал(а):
проведите все-таки тестирование.
Намериваюсь в ближайшее время, по мере возможности, этим позаниматься. Обдумываю детали тестирования. Выравнивать битрейт нельзя, т.к. изначально полагаю, что для ссылок на Р кадры необходимо большее колличество бит, качество требует жертв. Режим заданного качества и двухпроходку тоже нельзя. Результат бедет по метрикам PSNR/SSIM. Психовизуальные оптимизации отключаем, какие?
Да, также незабыл о тестировании по вопросу, что более потерьно длинные или короткие группы.
P.S. Вернемся немного назад.
MasterNobody писал(а):
Про DPB у вас тоже неверно написано.
Более конкретно, что? Загружаються ли в DPB простые B кадры?
Еще вариант базовой картинки для поста с которого все началось.
|
|
|
|
MasterNobody
Стаж: 17 лет 1 месяц Сообщений: 158
|
MasterNobody ·
11-Дек-11 13:01
(спустя 3 часа)
Tim68 писал(а):
Никогда и ни у кого не получалось подобрать аналогию полностью учитывающую все детали. Процесс восстановления неучитываемая деталь.
Вот по этому такую аналогию использовать и нельзя, так как вместо прояснения ситуации, она наоборот запутывает, ведя читающего в неправильном направлении мысли. Кстати, не стоит использовать такие обобщения в своих постах как "Никогда и ни у кого" (вы ведь не знаете это наверняка, или вы каждого человека уже спросили есть ли у него такая аналогия).
Tim68 писал(а):
Выравнивать битрейт нельзя, т.к. изначально полагаю, что для ссылок на Р кадры необходимо большее колличество бит, качество требует жертв.
Так вот может выделить это большее число бит на что-нибудь другое (полезное), раз качество требует жертв, глядишь и получите больше качества, чем расходуя эти биты где не надо. Вот поэтому и следует проводить сравнение на одинаковом битрейте/размере файлов.
Tim68 писал(а):
Загружаються ли в DPB простые B кадры?
Нет, простые туда не загружаются. Туда попадают только ссылочные кадры, т.е. I/P и ссылочные/пирамидные B-кадры.
Tim68 писал(а):
Еще вариант базовой картинки для поста с которого все началось.
Уже лучше если предположить, что это OpenGOP (иначе ссылаться на последний I-кадр B-кадры не могли бы).
|
|
|
|
Tim68
Стаж: 15 лет 7 месяцев Сообщений: 712
|
Tim68 ·
11-Дек-11 21:39
(спустя 8 часов, ред. 11-Дек-11 21:39)
MasterNobody писал(а):
не стоит использовать такие обобщения в своих постах как "Никогда и ни у кого"
Любая аналогия подразумевает неточность в деталях => допущение "Никогда и ни у кого".
MasterNobody писал(а):
Так вот может выделить это большее число бит на что-нибудь другое (полезное), раз качество требует жертв, глядишь и получите больше качества, чем расходуя эти биты где не надо. Вот поэтому и следует проводить сравнение на одинаковом битрейте/размере файлов.
Может быть, а может и не быть. Существуют значения strict и normal параметра --b-pyramid и целью тестирования будет выяснить как они влияют на изменение метрик PSNR/SSIM при компрессии на малых GOP-ах в зависимости от динамичности источника. Если использование значения strict по отношению к normal способно дать прирост качества на малодинамичных сценах, при снижении на динамике, параметр можно будет считать положительным. Выравнивание битрейта/размера файлов только испортит чистоту эксперимента.
|
|
|
|
Tim68
Стаж: 15 лет 7 месяцев Сообщений: 712
|
Tim68 ·
14-Дек-11 23:10
(спустя 3 дня, ред. 08-Янв-12 22:47)
MasterNobody писал(а):
Вы оперируете не фактами, а лишь предположениями (а я уже высказался, что они неверны ИМХО). Не верите, проведите все-таки тестирование.
Tim68 писал(а):
Существуют значения strict и normal параметра --b-pyramid и целью тестирования будет выяснить как они влияют на изменение метрик PSNR/SSIM при компрессии на малых GOP-ах в зависимости от динамичности источника.
Логи проделанных тестов:
скрытый текст
D:\>x264_r1995.exe --crf 23 --keyint 24 --b-adapt 2 --trellis 2 --deblock -2,-1
--tune ssim --bframes 3 --b-pyramid normal --ref 6 --weightp 1 --vbv-maxrate 140
00 --vbv-bufsize 14500 --level 4.0 --fullrange "on" --open-gop --slices 1 --me
umh --subme 10 --no-mbtree --colorprim "bt709" --transfer "bt709" --colormatrix
"bt709" --sar 1:1 --ssim --output "F:\Videos\T_1.BluRay\resalt\042110-042282_ssim_normal_crf.264" "F:\Videos\T_1.BluRay\ssim.avs"
avs [info]: 1280x720p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowCTZ SlowAtom
x264 [info]: profile High, level 4.0
x264 [info]: frame I:8 Avg QP:19.99 size: 23329
x264 [info]: frame P:57 Avg QP:22.22 size: 14950
x264 [info]: frame B:108 Avg QP:24.91 size: 7740
x264 [info]: consecutive B-frames: 4.6% 13.9% 67.6% 13.9%
x264 [info]: mb I I16..4: 26.6% 68.6% 4.8%
x264 [info]: mb P I16..4: 30.6% 45.2% 1.2% P16..4: 14.9% 2.7% 0.5% 0.0% 0
.0% skip: 4.9%
x264 [info]: mb B I16..4: 8.0% 9.7% 0.1% B16..8: 32.6% 7.2% 1.0% direct:
2.3% skip:39.1% L0:42.9% L1:52.6% BI: 4.4%
x264 [info]: 8x8 transform intra:58.7% inter:98.2%
x264 [info]: coded y,uvDC,uvAC intra: 36.5% 38.6% 3.5% inter: 12.4% 12.0% 0.2%
x264 [info]: i16 v,h,dc,p: 29% 24% 19% 28%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 15% 24% 6% 6% 9% 6% 7% 6%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 28% 21% 24% 3% 7% 7% 4% 3% 3%
x264 [info]: i8c dc,h,v,p: 26% 41% 21% 12%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: ref P L0: 67.2% 17.1% 8.3% 3.7% 2.5% 1.2%
x264 [info]: ref B L0: 82.3% 11.8% 4.2% 1.1% 0.6%
x264 [info]: ref B L1: 90.4% 9.6%
x264 [info]: SSIM Mean Y:0.9841348 (17.996db)
x264 [info]: kb/s:2078.55
encoded 173 frames, 0.95 fps, 2078.55 kb/s
D:\>x264_r1995.exe --crf 23 --keyint 24 --b-adapt 2 --trellis 2 --deblock -2,-1
--tune ssim --bframes 3 --b-pyramid strict --ref 6 --weightp 1 --vbv-maxrate 140
00 --vbv-bufsize 14500 --level 4.0 --fullrange "on" --open-gop --slices 1 --me
umh --subme 10 --no-mbtree --colorprim "bt709" --transfer "bt709" --colormatrix
"bt709" --sar 1:1 --ssim --output "F:\Videos\T_1.BluRay\resalt\042110-042282_ssim_strict_crf.264" "F:\Videos\T_1.BluRay\ssim.avs"
avs [info]: 1280x720p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowCTZ SlowAtom
x264 [info]: profile High, level 4.0
x264 [info]: frame I:8 Avg QP:19.99 size: 23329
x264 [info]: frame P:57 Avg QP:22.22 size: 14993
x264 [info]: frame B:108 Avg QP:24.83 size: 7800
x264 [info]: consecutive B-frames: 4.6% 13.9% 67.6% 13.9%
x264 [info]: mb I I16..4: 26.6% 68.6% 4.8%
x264 [info]: mb P I16..4: 31.1% 45.7% 1.2% P16..4: 13.8% 2.7% 0.4% 0.0% 0
.0% skip: 5.0%
x264 [info]: mb B I16..4: 8.2% 10.0% 0.2% B16..8: 32.2% 7.2% 1.0% direct:
2.4% skip:38.9% L0:41.7% L1:53.8% BI: 4.5%
x264 [info]: 8x8 transform intra:58.6% inter:98.2%
x264 [info]: coded y,uvDC,uvAC intra: 36.5% 38.7% 3.5% inter: 12.5% 12.2% 0.2%
x264 [info]: i16 v,h,dc,p: 30% 24% 19% 27%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 15% 24% 6% 7% 9% 6% 7% 6%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 29% 21% 23% 4% 7% 7% 5% 3% 3%
x264 [info]: i8c dc,h,v,p: 25% 42% 21% 12%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: ref P L0: 80.2% 11.7% 6.2% 1.7% 0.2%
x264 [info]: ref B L0: 90.3% 6.9% 2.2% 0.6%
x264 [info]: ref B L1: 90.3% 9.7%
x264 [info]: SSIM Mean Y:0.9841427 (17.998db)
x264 [info]: kb/s:2088.50
encoded 173 frames, 1.06 fps, 2088.50 kb/s
D:\>x264_r1995.exe --crf 23 --keyint 24 --b-adapt 2 --trellis 2 --deblock -2,-1
--tune ssim --bframes 3 --b-pyramid strict --ref 6 --weightp 1 --vbv-maxrate 140
00 --vbv-bufsize 14500 --level 4.0 --fullrange "on" --open-gop --slices 1 --me
umh --subme 10 --no-mbtree --colorprim "bt709" --transfer "bt709" --colormatrix
"bt709" --sar 1:1 --ssim --output "F:\Videos\T_1.BluRay\resalt\058812-059043_ssim_strict_crf.264" "F:\Videos\T_1.BluRay\ssim.avs"
avs [info]: 1280x720p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowCTZ SlowAtom
x264 [info]: profile High, level 4.0
x264 [info]: frame I:11 Avg QP:21.19 size: 24803
x264 [info]: frame P:91 Avg QP:23.31 size: 16341
x264 [info]: frame B:130 Avg QP:26.38 size: 9744
x264 [info]: consecutive B-frames: 13.4% 15.5% 60.8% 10.3%
x264 [info]: mb I I16..4: 29.1% 65.9% 5.0%
x264 [info]: mb P I16..4: 30.1% 48.1% 2.2% P16..4: 9.0% 2.2% 0.4% 0.0% 0
.0% skip: 8.0%
x264 [info]: mb B I16..4: 10.2% 12.1% 0.5% B16..8: 28.3% 7.4% 1.2% direct:
3.7% skip:36.7% L0:41.6% L1:51.9% BI: 6.5%
x264 [info]: 8x8 transform intra:58.7% inter:95.2%
x264 [info]: coded y,uvDC,uvAC intra: 39.9% 33.5% 4.8% inter: 15.5% 10.6% 0.5%
x264 [info]: i16 v,h,dc,p: 26% 29% 17% 28%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 21% 25% 25% 4% 4% 5% 5% 4% 6%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 20% 32% 26% 3% 5% 4% 5% 3% 4%
x264 [info]: i8c dc,h,v,p: 31% 43% 16% 9%
x264 [info]: Weighted P-Frames: Y:1.1% UV:1.1%
x264 [info]: ref P L0: 79.2% 12.7% 5.6% 2.1% 0.5%
x264 [info]: ref B L0: 91.0% 6.2% 2.3% 0.5%
x264 [info]: ref B L1: 92.8% 7.2%
x264 [info]: SSIM Mean Y:0.9805627 (17.114db)
x264 [info]: kb/s:2502.32
encoded 232 frames, 1.01 fps, 2502.32 kb/s
D:\>x264_r1995.exe --crf 23 --keyint 24 --b-adapt 2 --trellis 2 --deblock -2,-1
--tune ssim --bframes 3 --b-pyramid normal --ref 6 --weightp 1 --vbv-maxrate 140
00 --vbv-bufsize 14500 --level 4.0 --fullrange "on" --open-gop --slices 1 --me
umh --subme 10 --no-mbtree --colorprim "bt709" --transfer "bt709" --colormatrix
"bt709" --sar 1:1 --ssim --output "F:\Videos\T_1.BluRay\resalt\058812-059043_ssim_normal_crf.264" "F:\Videos\T_1.BluRay\ssim.avs"
avs [info]: 1280x720p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowCTZ SlowAtom
x264 [info]: profile High, level 4.0
x264 [info]: frame I:11 Avg QP:21.19 size: 24803
x264 [info]: frame P:91 Avg QP:23.35 size: 16318
x264 [info]: frame B:130 Avg QP:26.37 size: 9739
x264 [info]: consecutive B-frames: 13.4% 15.5% 60.8% 10.3%
x264 [info]: mb I I16..4: 29.1% 65.9% 5.0%
x264 [info]: mb P I16..4: 29.9% 47.7% 2.1% P16..4: 9.5% 2.2% 0.4% 0.0% 0
.0% skip: 8.1%
x264 [info]: mb B I16..4: 10.1% 11.9% 0.4% B16..8: 28.6% 7.6% 1.2% direct:
3.6% skip:36.6% L0:42.6% L1:51.0% BI: 6.3%
x264 [info]: 8x8 transform intra:58.7% inter:95.3%
x264 [info]: coded y,uvDC,uvAC intra: 39.8% 33.3% 4.8% inter: 15.5% 10.8% 0.5%
x264 [info]: i16 v,h,dc,p: 26% 29% 17% 28%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 21% 25% 26% 4% 4% 5% 5% 4% 6%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 20% 31% 26% 3% 5% 4% 5% 3% 4%
x264 [info]: i8c dc,h,v,p: 32% 43% 16% 9%
x264 [info]: Weighted P-Frames: Y:1.1% UV:1.1%
x264 [info]: ref P L0: 69.8% 15.4% 8.1% 3.3% 2.5% 1.0%
x264 [info]: ref B L0: 86.1% 8.8% 3.3% 1.3% 0.4%
x264 [info]: ref B L1: 92.8% 7.2%
x264 [info]: SSIM Mean Y:0.9805617 (17.113db)
x264 [info]: kb/s:2500.04
encoded 232 frames, 0.93 fps, 2500.04 kb/s
D:\>x264_r1995.exe --crf 23 --keyint 24 --b-adapt 2 --trellis 2 --deblock -2,-1
--tune ssim --bframes 3 --b-pyramid strict --ref 6 --weightp 1 --vbv-maxrate 140
00 --vbv-bufsize 14500 --level 4.0 --fullrange "on" --open-gop --slices 1 --me
umh --subme 10 --no-mbtree --colorprim "bt709" --transfer "bt709" --colormatrix
"bt709" --sar 1:1 --ssim --output "F:\Videos\T_1.BluRay\resalt\073123-073306_ssim_strict_crf.264" "F:\Videos\T_1.BluRay\ssim.avs"
avs [info]: 1280x720p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowCTZ SlowAtom
x264 [info]: profile High, level 4.0
x264 [info]: frame I:8 Avg QP:23.51 size: 50194
x264 [info]: frame P:45 Avg QP:25.85 size: 16248
x264 [info]: frame B:131 Avg QP:28.64 size: 3014
x264 [info]: consecutive B-frames: 1.1% 4.3% 22.8% 71.7%
x264 [info]: mb I I16..4: 8.9% 84.5% 6.7%
x264 [info]: mb P I16..4: 4.2% 8.6% 0.3% P16..4: 45.0% 20.4% 5.5% 0.0% 0
.0% skip:15.9%
x264 [info]: mb B I16..4: 0.1% 0.3% 0.0% B16..8: 33.0% 4.3% 0.5% direct:
1.1% skip:60.7% L0:31.4% L1:56.9% BI:11.8%
x264 [info]: 8x8 transform intra:75.9% inter:88.2%
x264 [info]: coded y,uvDC,uvAC intra: 66.8% 46.7% 7.2% inter: 11.1% 3.1% 0.0%
x264 [info]: i16 v,h,dc,p: 27% 19% 27% 27%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 20% 14% 17% 7% 7% 8% 7% 9% 9%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 19% 15% 5% 10% 10% 7% 6% 5%
x264 [info]: i8c dc,h,v,p: 32% 29% 23% 15%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: ref P L0: 86.1% 8.7% 3.7% 1.5%
x264 [info]: ref B L0: 95.6% 3.0% 1.1% 0.3%
x264 [info]: ref B L1: 97.2% 2.8%
x264 [info]: SSIM Mean Y:0.9680832 (14.960db)
x264 [info]: kb/s:1592.36
encoded 184 frames, 1.42 fps, 1592.36 kb/s
D:\>x264_r1995.exe --crf 23 --keyint 24 --b-adapt 2 --trellis 2 --deblock -2,-1
--tune ssim --bframes 3 --b-pyramid normal --ref 6 --weightp 1 --vbv-maxrate 140
00 --vbv-bufsize 14500 --level 4.0 --fullrange "on" --open-gop --slices 1 --me
umh --subme 10 --no-mbtree --colorprim "bt709" --transfer "bt709" --colormatrix
"bt709" --sar 1:1 --ssim --output "F:\Videos\T_1.BluRay\resalt\073123-073306_ssim_normal_crf.264" "F:\Videos\T_1.BluRay\ssim.avs"
avs [info]: 1280x720p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowCTZ SlowAtom
x264 [info]: profile High, level 4.0
x264 [info]: frame I:8 Avg QP:23.51 size: 50194
x264 [info]: frame P:45 Avg QP:25.86 size: 16258
x264 [info]: frame B:131 Avg QP:28.66 size: 3027
x264 [info]: consecutive B-frames: 1.1% 4.3% 22.8% 71.7%
x264 [info]: mb I I16..4: 8.9% 84.5% 6.7%
x264 [info]: mb P I16..4: 4.2% 8.5% 0.3% P16..4: 46.7% 19.8% 5.3% 0.0% 0
.0% skip:15.3%
x264 [info]: mb B I16..4: 0.1% 0.3% 0.0% B16..8: 33.0% 4.4% 0.5% direct:
1.0% skip:60.7% L0:31.9% L1:56.9% BI:11.2%
x264 [info]: 8x8 transform intra:75.9% inter:88.4%
x264 [info]: coded y,uvDC,uvAC intra: 66.7% 46.7% 7.1% inter: 11.0% 3.1% 0.0%
x264 [info]: i16 v,h,dc,p: 27% 20% 27% 26%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 20% 15% 17% 7% 7% 8% 7% 10% 9%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 19% 15% 5% 10% 9% 7% 6% 5%
x264 [info]: i8c dc,h,v,p: 32% 30% 23% 15%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: ref P L0: 71.7% 19.7% 4.7% 2.3% 1.3% 0.2%
x264 [info]: ref B L0: 90.7% 6.8% 1.7% 0.5% 0.3%
x264 [info]: ref B L1: 97.1% 2.9%
x264 [info]: SSIM Mean Y:0.9682331 (14.980db)
x264 [info]: kb/s:1594.60
encoded 184 frames, 1.34 fps, 1594.60 kb/s
Здесь можно взять тестовые ролики.
Имеет место закономерность, приведены не все тесты, на динамичных сценах более высокий ssim дает b-pyramid strict, а на молодинамичных b-pyramid normal. Думал, что будет наоборот. Результаты в любом случае зависят от исходника, но strict почти всегда дает чуть более высокий битрейт и более высокую скорость. Делать выводы, что лучше на малых группах (подгруппах) b-pyramid strict или normal как-то не получается, но если интересует совместимость с аппаратными декодерами, то использование b-pyramid strict является явно опраданным.
Tim68 писал(а):
Да, также незабыл о тестировании по вопросу, что более потерьно длинные или короткие группы.
Логи проделанных тестов:
скрытый текст
D:\>x264_r1995.exe --crf 23 --keyint 250 --b-adapt 2 --trellis 2 --deblock -2,-1
--tune ssim --bframes 3 --b-pyramid strict --ref 6 --weightp 1 --vbv-maxrate 14
000 --vbv-bufsize 14500 --level 4.0 --fullrange "on" --open-gop --slices 1 --me
umh --subme 10 --no-mbtree --colorprim "bt709" --transfer "bt709" --colormatri
x "bt709" --sar 1:1 --ssim --output "F:\Videos\T_1.BluRay\resalt\042110-042282_s
sim_keyint250_crf.264" "F:\Videos\T_1.BluRay\ssim.avs"
avs [info]: 1280x720p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowCTZ SlowAtom
x264 [info]: profile High, level 4.0
x264 [info]: frame I:1 Avg QP:17.23 size: 34936
x264 [info]: frame P:55 Avg QP:22.19 size: 14956
x264 [info]: frame B:117 Avg QP:24.81 size: 8090
x264 [info]: consecutive B-frames: 1.2% 6.9% 57.2% 34.7%
x264 [info]: mb I I16..4: 17.8% 70.8% 11.4%
x264 [info]: mb P I16..4: 30.9% 45.1% 1.2% P16..4: 14.6% 2.7% 0.4% 0.0% 0.0% skip: 5.1%
x264 [info]: mb B I16..4: 8.8% 11.2% 0.2% B16..8: 31.7% 6.9% 0.9% direct:
2.5% skip:37.8% L0:42.1% L1:53.3% BI: 4.6%
x264 [info]: 8x8 transform intra:57.5% inter:98.2%
x264 [info]: coded y,uvDC,uvAC intra: 34.6% 37.2% 3.1% inter: 12.8% 12.5% 0.2%
x264 [info]: i16 v,h,dc,p: 29% 24% 18% 28%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 15% 25% 6% 7% 9% 6% 7% 6%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 26% 21% 25% 3% 7% 7% 5% 3% 3%
x264 [info]: i8c dc,h,v,p: 26% 41% 21% 12%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: ref P L0: 78.6% 12.0% 5.9% 3.1% 0.3%
x264 [info]: ref B L0: 89.2% 6.8% 3.0% 1.0%
x264 [info]: ref B L1: 93.4% 6.6%
x264 [info]: SSIM Mean Y:0.9839132 (17.935db)
x264 [info]: kb/s:2000.21
encoded 173 frames, 0.95 fps, 2000.21 kb/s
D:\>x264_r1995.exe --crf 23 --keyint 250 --b-adapt 2 --trellis 2 --deblock -2,-1
--tune ssim --bframes 3 --b-pyramid strict --ref 6 --weightp 1 --vbv-maxrate 14
000 --vbv-bufsize 14500 --level 4.0 --fullrange "on" --open-gop --slices 1 --me
umh --subme 10 --no-mbtree --colorprim "bt709" --transfer "bt709" --colormatri
x "bt709" --sar 1:1 --ssim --output "F:\Videos\T_1.BluRay\resalt\058812-059043_s
sim_keyint250_crf.264" "F:\Videos\T_1.BluRay\ssim.avs"
avs [info]: 1280x720p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowCTZ SlowAtom
x264 [info]: profile High, level 4.0
x264 [info]: frame I:1 Avg QP:17.84 size: 45214
x264 [info]: frame P:88 Avg QP:23.38 size: 16474
x264 [info]: frame B:143 Avg QP:26.39 size: 9750
x264 [info]: consecutive B-frames: 6.5% 13.8% 60.8% 19.0%
x264 [info]: mb I I16..4: 18.4% 70.4% 11.2%
x264 [info]: mb P I16..4: 30.2% 49.4% 2.2% P16..4: 8.4% 2.0% 0.4% 0.0% 0.0% skip: 7.5%
x264 [info]: mb B I16..4: 10.3% 12.2% 0.4% B16..8: 28.3% 7.4% 1.1% direct:
3.6% skip:36.6% L0:42.1% L1:51.6% BI: 6.3%
x264 [info]: 8x8 transform intra:58.2% inter:95.3%
x264 [info]: coded y,uvDC,uvAC intra: 38.5% 32.5% 4.7% inter: 15.2% 10.4% 0.5%
x264 [info]: i16 v,h,dc,p: 25% 29% 17% 29%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 21% 25% 26% 4% 4% 5% 5% 4% 6%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 18% 32% 26% 3% 5% 4% 5% 3% 4%
x264 [info]: i8c dc,h,v,p: 32% 43% 16% 9%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: ref P L0: 73.3% 14.1% 7.9% 3.7% 0.9%
x264 [info]: ref B L0: 89.9% 6.5% 2.7% 0.9%
x264 [info]: ref B L1: 93.5% 6.5%
x264 [info]: SSIM Mean Y:0.9802180 (17.037db)
x264 [info]: kb/s:2388.66
encoded 232 frames, 0.90 fps, 2388.66 kb/s
D:\>x264_r1995.exe --crf 23 --keyint 250 --b-adapt 2 --trellis 2 --deblock -2,-1
--tune ssim --bframes 3 --b-pyramid strict --ref 6 --weightp 1 --vbv-maxrate 14
000 --vbv-bufsize 14500 --level 4.0 --fullrange "on" --open-gop --slices 1 --me
umh --subme 10 --no-mbtree --colorprim "bt709" --transfer "bt709" --colormatri
x "bt709" --sar 1:1 --ssim --output "F:\Videos\T_1.BluRay\resalt\073123-073306_s
sim_keyint250_crf.264" "F:\Videos\T_1.BluRay\ssim.avs"
avs [info]: 1280x720p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowCTZ SlowAtom
x264 [info]: profile High, level 4.0
x264 [info]: frame I:1 Avg QP:19.89 size: 70514
x264 [info]: frame P:49 Avg QP:25.58 size: 16858
x264 [info]: frame B:134 Avg QP:28.48 size: 3217
x264 [info]: consecutive B-frames: 0.5% 1.1% 17.9% 80.4%
x264 [info]: mb I I16..4: 6.6% 82.5% 10.9%
x264 [info]: mb P I16..4: 4.0% 8.5% 0.4% P16..4: 46.7% 20.3% 5.8% 0.0% 0.0% skip:14.3%
x264 [info]: mb B I16..4: 0.1% 0.3% 0.0% B16..8: 33.6% 4.7% 0.6% direct:
1.2% skip:59.5% L0:33.1% L1:55.7% BI:11.2%
x264 [info]: 8x8 transform intra:68.2% inter:87.3%
x264 [info]: coded y,uvDC,uvAC intra: 54.6% 37.0% 4.6% inter: 12.1% 3.4% 0.0%
x264 [info]: i16 v,h,dc,p: 30% 20% 24% 26%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 14% 20% 6% 7% 9% 7% 9% 8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 17% 19% 5% 9% 10% 7% 6% 5%
x264 [info]: i8c dc,h,v,p: 40% 25% 21% 13%
x264 [info]: Weighted P-Frames: Y:4.1% UV:0.0%
x264 [info]: ref P L0: 80.3% 9.7% 6.4% 3.6% 0.0%
x264 [info]: ref B L0: 94.4% 3.3% 1.8% 0.6%
x264 [info]: ref B L1: 97.2% 2.8%
x264 [info]: SSIM Mean Y:0.9678868 (14.933db)
x264 [info]: kb/s:1383.96
encoded 184 frames, 1.27 fps, 1383.96 kb/s
Здесь тестовые ролики.
Из сравнения файлов отчетности видно, что при всем равном кроме значений keyint, значение SSIM при коротких группах всегда выше, что и следовало ожидать, причем результат не зависит от исходника.
Код:
SSIM Mean Y:0.9841427 (17.998db)(042110-042282_ssim_strict_crf.264) и SSIM Mean Y:0.9839132 (17.935db)(042110-042282_ssim_keyint250_crf.264);
SSIM Mean Y:0.9805627 (17.114db)(058812-059043_ssim_strict_crf.264) и SSIM Mean Y:0.9802180 (17.037db)(058812-059043_ssim_keyint250_crf.264);
SSIM Mean Y:0.9680832 (14.960db)(073123-073306_ssim_strict_crf.264) и SSIM Mean Y:0.9678868 (14.933db)(073123-073306_ssim_keyint250_crf.264).
Ожидаемым также явилось некоторое снижение как битрейта, так и размера результирующего файла при использовании длинных групп (--keyint 250), т.к. вместо I фреймов компрессор использовал P или B фреймы меньшего размера. Особенностью явилось то, что при использовании более низких значений crf, эта разница уменьшается т.к. размеры различных типов кадров начинают приближаться друг к другу.
Привлекает к себе внимание изменение соотношений значений квантизеров P и I фреймов при использовании коротких и длинных групп,
например:
- для 073123-073306_ssim_keyint250_crf.264 - QP( P)/QP( I)=25.58/19.89=1,29 ~ 1,3;
- для 073123-073306_ssim_strict_crf.264 - QP( P)/QP( I)=25.85/23.51=1,0995 ~ 1,1.
На коротких группах компрессор сам по умолчанию использует более низкие коэффициенты снижения межкадрового качества, тем самым автоматически обеспечивая лучшую работу с тяжелыми (шумными) источниками.
|
|
|
|
Tim68
Стаж: 15 лет 7 месяцев Сообщений: 712
|
Tim68 ·
03-Июл-12 21:55
(спустя 6 месяцев)
Возвращаясь к технологии xvYCC или Extended-gamut YCC (Расширенный цветовой диапазон), вполне оффициальная информация от "тети Сони", спасибо Lenchik, объясняющая какое отношение имеет ITU-R BT.709 и ITU-R BT.601 к xvYCC и какая математика
формулы
YxvYCC(8) =219 x Y' + 16
CbxvYCC(8) =224 x Cb' + 128
CrxvYCC(8) =224 x Cr' + 128
лежит в основе 8-ми битной квантизации этого цветового пространства, описанного для формата AVCHD.
|
|
|
|
MasterNobody
Стаж: 17 лет 1 месяц Сообщений: 158
|
MasterNobody ·
04-Июл-12 00:26
(спустя 2 часа 31 мин.)
Tim68 писал(а):
формулы
YxvYCC(8) =219 x Y' + 16
CbxvYCC(8) =224 x Cb' + 128
CrxvYCC(8) =224 x Cr' + 128
лежит в основе 8-ми битной квантизации этого цветового пространства, описанного для формата AVCHD.
Вообще-то это стандартные формулы для BT.709 и BT.601 (о чем даже написано в вашей ссылке). Вся фишка именно во 2-м пункте, а не в формулах:
скрытый текст
The opto-electric transfer characteristics of signals not less than 0 and not greater than 1 are defined using the same formula as for BT.709, and signals above 1 are also defined using the same formula. Signals below 0 are defined to produce a transfer curve with origin symmetry.
Который расширят кривую за диапазон [0..1] (т.е. на отрицательные и большие единицы) при использовании значений 1..15 и 241..254
|
|
|
|
Tim68
Стаж: 15 лет 7 месяцев Сообщений: 712
|
Tim68 ·
16-Авг-12 14:11
(спустя 1 месяц 12 дней, ред. 17-Авг-12 09:41)
MasterNobody писал(а):
Вообще-то это стандартные формулы для BT.709 и BT.601
Все это так, было на 1-й странице:
MasterNobody писал(а):
Единственная зависимость от разрешения и то не обязательная - это соответствие BT.601 или BT.709, но они оба могу быть как TV range, так и PC range.
Само по себе графическое представление кривой расширенного цветового диапазона xvYCC очень интересно и нужно, кстати не получается найти эту кривую в нормальном для чтения увеличении. Просто хотелось, связанно с прошедшими дискуссиями в других ветках форума, акцентировать внимание на том, что указанная ссылка так же поясняет саму математику получения 8-ми битных значений YxvYCC, CbxvYCC и CrxVYCC этого пространства из стандартных значений Y’, Cb’ и Cr’ цветовых исчислений TV диапазона (BT.601, BT.709). Вносится ясность в понимание достаточности 8-ми битной компрессии для подачи расширенного цветового диапазона на вход аппаратному декодирующему устройству и выдачи на выходе сигнала в формате xvYCC на устройство отображения (TV приемник), способное выполнить внутреннюю многобитную обработку сигнала, Deep Color, на аппаратном уровне. Понятно, что использование этих технологий не улучшает уже существующее видео, а только улучшает его отображение на экране.
Думаю, что для "юзеров по жизни", забывших о том для чего нужен телевизор и бытовая теле-радио аппаратура, мечтающих провести остаток своей жизни за монитором это и не интересно. Получение мазохистского удовлетворения от “плясок с бубном” ради волшебной комбинации (сплиттер - тройка, рендер – семерка да и много чего еще другого - туз) вокруг жародышащего и воющего вентиляторами супер современного PC-монстра составляет едва ли не основную часть их бренного существования.
Что же касается остальных …… могли бы иметь многобитную обработку изображения еще в 2008-2009 годах, пускай тогда еще дорогую, но могли и без “плясок с бубном”. Камень в сторону упущенного внимания по отношению к формату AVCHD. Чем дальше, тем хуже.
На сегодня уже при покупке телека стоимостью до 20 тыр в нагрузку валят BD-плеер, см. рекламу на одном из центральных каналов. Сколько еще можно затыкать уши – “ничего не слышу”, закрывать глаза – “ничего не вижу” и вопить – “кому нужна эта аппаратная совместимость”? Может уже давно пора одним из основных требований к торрент-файлам считать их полную аппаратную совместимость?
P.S. Просто крик души.
Сказка на ночь
Посмотрела дочка в детской программе одну из серий “Маша и медведь” и говорит, давай папа посмотрим другие. Папа качает другие. Плеер TV приемника вообще отказался от файла, BD плеер с флехи хоть и заиграл, но с нескончаемыми лаганиями. Режим дня, как у папы, так и у PC-ка изменился, теперь папе надо успеть до сна скачать очередную серию, а PC-ку успеть до утра ее переделать. Наконец то наступила “тишь и благодать”, вот только папе во сне почему-то хочется “умелые ручки-закорючки” чудо-риперу выправить. Папа не злой, он добрый.
|
|
|
|
jacketeer
Стаж: 15 лет 9 месяцев Сообщений: 106
|
jacketeer ·
24-Июн-16 20:39
(спустя 3 года 10 месяцев)
Чем закончилась история с AVCHD? Жив еще? 
|
|
|
|
Tim68
Стаж: 15 лет 7 месяцев Сообщений: 712
|
Tim68 ·
24-Июн-16 22:15
(спустя 1 час 35 мин.)
jacketeer писал(а):
70945675Чем закончилась история с AVCHD? Жив еще?
Приветствую.
Для трекера ничем, но надеюсь продолжение возможно.
Если, что и делаю для себя, то максимальную совместимость с аппаратным декодированием ставлю во главе угла.
Были случаи когда и мои файлы глючили на аппаратниках при абсолютно нормальном программном воспроизведении.
Tim68 писал(а):
54115797Решил отдельно пережать участок (черный кадр) на котором плеер TV приемника выплевывал семпл, с 3000 по 3699 кадр. Данный участок TV плеер вообще отказался даже запускать.
Судя по логу компрессор обошелся вообще без B кадров. Может дело в этом?
MasterNobody писал(а):
67275528Здесь (для такого семпла) еще от части должен помочь --no-scenecut, который видимо, вмешивается при таком малом keyint:
x264 [info]: frame I:2 Avg QP:18.20 size: 90101
x264 [info]: frame P:10 Avg QP:19.63 size: 34409
x264 [info]: frame B:31 Avg QP:20.42 size: 11887
Действительно --no-scenecut наряду с --b-adapt 0 и --bframes 3 позволяет удерживать компрессор от отбрасывания итак столь немногочисленных В-кадров в коротких подгруппах, что в свою очередь позволяет не только добиваться совместимости с аппаратниками, но и реально снижать размер конечного файла на 15-20%.
Например как-то столкнулся с такой проблемой. Компрессор не смог удержать заданный в формате --vbv-maxrate 14000 --vbv-bufsize 14500 на финальной сцене концерта, когда по всему кадру разлеталось блестящее конфетти, точнее Я это проморгал. Проблема проявилась при воспроизведении AVCHD с DVD носителя на Blu-Ray плеере, в заданном месте плеер просто стал "заикаться".
Хочется упомянуть, что имеются и другие моменты, которые необходимо учитывать.
|
|
|
|
