|
|
|
arentwe
Стаж: 3 года 4 месяца Сообщений: 1
|
arentwe ·
21-Июл-22 13:16
(2 года 5 месяцев назад, ред. 22-Июл-22 06:12)
Создаётся впечатление, что все эти dolby vision были сделаны не для того, чтобы сделать картинку ярче на новых девайсах.
А затем, чтобы сделать её бледнее на старых, и даже современных бюджетных моделях.
Так, вот синтетический тест.
1бит.
2бит.
3бит.
4бит.
5бит.
6бит.
7бит.
8бит - я не заметил никакой разницы с 7бит на моём мониторе.
Теперь не синтетический.
1бит.
2бит.
3бит.
4бит.
5бит. Не вижу никакой разницы с 4бит, дальнейшее чисто для примера.
6бит.
7бит.
8бит.
Палитры, dither - не использовались.
Интересно узнать, насколько ваш монитор точен.
|
|
|
|
jеnsen
Стаж: 14 лет 8 месяцев Сообщений: 2977
|
jеnsen ·
21-Июл-22 16:21
(спустя 3 часа)
Может проще понять, как это работает и перестать позориться?
|
|
|
|
johnowenemmet
Стаж: 14 лет 10 месяцев Сообщений: 131
|
johnowenemmet ·
21-Июл-22 18:01
(спустя 1 час 40 мин.)
arentwe, вы задаёте очень нужный и правильный вопрос. Плюс, мало того, что не видно разницы на ваших картинках, так ещё стало модным с 8 бит исходников кодировать в 10 бит, из ниоткуда добавляя 2 бита, т.е. раздувая рипы на 25% по бит-рейту. И все делают вид, что это нормально. 
|
|
|
|
GarfieldX
Стаж: 19 лет 10 месяцев Сообщений: 4016
|
GarfieldX ·
27-Июл-22 14:21
(спустя 5 дней, ред. 27-Июл-22 14:21)
arentwe писал(а):
83398295Создаётся впечатление, что все эти dolby vision были сделаны не для того, чтобы сделать картинку ярче на новых девайсах.
Это просто причина и следствие. Следствие прогресса.
Было SD, стало HD. Т.е. увеличение разрешающей способности заметно легко.
Был звук моно, стерео, теперь вот опять HD - сам, честно говоря, не особо чувствую разницы, но она есть.
Увеличение глубины цвета тоже должно иметь наглядный пример, но в определенных ситуациях. И уж точно не на ваших примерах. Глубины как правило не хватает на градиентах.
Так же естественно, что для отображения большей глубины цвета нужен соответствующий монитор.
Как и для отображения HD картинки нужен HD монитор чтобы отобразился каждый пиксель.
И так же, в случае попытки отобразить контент одного поколения на железе предыдущего, мы получаем потерю информации.
В случае HD->SD теряется детализация. В случае 10bit на мониторе 8bit теряем цвет, но теряем хитро, без масштабирования как с разрешением.
Получается примерно тоже самое, если бы мы на старом мониторе видели не отмасштабированную картинку целиком, а её часть, как будто смотрим через окно.
johnowenemmet писал(а):
83399291ещё стало модным с 8 бит исходников кодировать в 10 бит, из ниоткуда добавляя 2 бита, т.е. раздувая рипы на 25% по бит-рейту
Увы, это человеческая натура. Обычно от незнания. Когда появился h.264, то вместо того чтобы снижать битрейт его стали делать еще больше чем при сжатии xvid/divx.
Это из разряда научи дурака богу молиться так он лоб расшибет.
|
|
|
|
jеnsen
Стаж: 14 лет 8 месяцев Сообщений: 2977
|
jеnsen ·
27-Июл-22 22:49
(спустя 8 часов, ред. 27-Июл-22 22:49)
johnowenemmet писал(а):
83399291так ещё стало модным с 8 бит исходников кодировать в 10 бит, из ниоткуда добавляя 2 бита, т.е. раздувая рипы на 25% по бит-рейту. И все делают вид, что это нормально
Господи, вопросы из 2011 подъехали...
Практически 100% аниме это грубо говоря, линии + градиенты и цвета. Очень редко можно встретить качественный алгоритм дизеринга примененного при понижении битовой глубины с 16 битного мастера до 8 бит на бд издании. Порой дизеринг вообще не применяется и тогда результат еще ужаснее.
Все это безобразие обычно обрабатывается фильтрами, дебандинг или шумодав + дебанд и тд и тп. Обработка происходит в 16 бит и все давно сделали вполне логичный вывод, что гораздо проще весь этот результат сохранить в 10 бит, что позволит добавлять гораздо меньше шума в сигнал (дизеринг) для предотвращения возвращения эффекта бандинга. Да, внезапно, но шума для такого же эффекта на 8 битах потребуется намешать в сигнал больше, что зачастую даст больший размер конечного файла, чем у 10 битного кодирования. Такой вот парадокс, хотя чисто математически 10 бит обязаны иметь больший размер.
Помимо вышеописанного, многие фишки для кодирования в 264 добавлялись в те времена сперва только для 10 битного профиля и только потом адаптировались под старый 8 битный. Это тоже внесло свою лепту в популяризацию и распространение 10 бит среди энкодеров. Тогда, в 2011, тоже была куча вопросов наподобие "а чего это все рипы аниме резко стали 10 битными?" и "а как мне посмотреть это на тв?" Впрочем пользователь всегда мог посмотреть 10 бит 264 на пк или постримить его же с пк на тв по хдми. А с появлением 265 и эта проблема исчезла полностью.
Так что никто "просто так" 8 в 10 не превращает, фильмы (не аниме) вообще кодируют только в 8, так как там обычно не применяется дебандинг.
GarfieldX писал(а):
83423483Обычно от незнания.
Так что извините, но "незнание" - это ваша проблема в данном случае. Помимо этого довольно смешно слышать от человека с вашей лычкой заявления про
GarfieldX писал(а):
83423483Когда появился h.264, то вместо того чтобы снижать битрейт его стали делать еще больше чем при сжатии xvid/divx.
Вы осознаете, что сравниваете кодек для sd с кодеком для hd на основе потребляемого битрейта? Вполне естественно, что контент с более высоким разрешением потребляет больше битрейта.
Ну и на sd рипах у 264 обычно чутка задирали битрейт опять же из-за его склонности к рассыпанию картинки на блоки и усиливанию эффекта бандинга при низких битрейтах. 264 в принципе не изобретался с прицелом на экономию битрейта, его основная задача была в увеличении визуального качества видео. Поэтому он обычно потребляет его чуть больше, чем мпег2 или хвид с дивиксом. Собственно 265 и появился для снижения целевого битрейта с минимумом артефактов и на 60% базируется на алгоритмах все того же 264. Ну и наконец сменилось поколение оборудования и люди стали больше внимания обращать на такие вещи (артефакты изображения), чем во времена xvid/divx и ЭЛТ. А размер конечного файла перестал быть настолько важным, так как hdd стали дешевле, двд изжило себя и тд и тп.
|
|
|
|
GarfieldX
Стаж: 19 лет 10 месяцев Сообщений: 4016
|
GarfieldX ·
28-Июл-22 12:10
(спустя 13 часов, ред. 28-Июл-22 12:10)
jensen123321 писал(а):
83425308Так что извините, но "незнание" - это ваша проблема в данном случае.
Скорее это аниме частный случай, про который помнят только анимешники со своими заморочками.
Потому, не стоит эти особенности контента представлять как общий случай, а речь именно о нем.
Сам то аниме смотрю, но большинству дела нет что там и как.
jensen123321 писал(а):
83425308Вполне естественно, что контент с более высоким разрешением потребляет больше битрейта.
Где было сказано, что разное разрешение? Это ваши домыслы. Речь именно что об одинаковом разрешении.
Банально потому, что сначала был доступен только контент в SD, а BD появились уже позже. Поэтому народ активно пересжимал DVD.
И вроде бы сначала тенденция была правильная - битрейт был ниже, но потом что-то пошло не так и народ понесло с увеличением битрейта за пределы разумного.
Возможно, сыграли роль доступные инструкции, где не особо нужно было вникать в детали, а достаточно было повторить нужные действия.
Да и собственно, говоря под битрейтом подразумеваю бит на пиксель, т.к. сам битрейт без учета разрешения ни о чем не говорит.
jensen123321 писал(а):
83425308Поэтому он обычно потребляет его чуть больше, чем мпег2 или хвид с дивиксом.
В том то и дело, что не чуть.
Условно, если для xvid/divx использовалось значение bpp = 0.300, то для x264 умудрялись ставить 0.400 и более. Хотя по квантам там хватит 0.200 с головой.
На трекере есть единственная моя раздача в HD "Воспоминания неудачника". Так вот чтобы вписаться в правила пришлось раздуть битрейт раза в 1.5 минимум.
После этого у меня желание делать релизы в HD сразу и пропало.
jensen123321 писал(а):
83425308фильмы (не аниме) вообще кодируют только в 8
Выйдете наружу из своего раздела аниме, вы отстали от жизни 
|
|
|
|
jеnsen
Стаж: 14 лет 8 месяцев Сообщений: 2977
|
jеnsen ·
28-Июл-22 17:17
(спустя 5 часов, ред. 28-Июл-22 17:17)
GarfieldX
bpp это метрика "показывающяя погоду" и никак не связана с качеством видео или битрейтом напрямую. Просто некоторые источники склонны потреблять больше битрейта, а большие пики последнего в режиме vbr вызывают повышение bpp по понятным причинам. Тогда как в хвид и тд зачастую использовалость только cbr. Ваши слова про "было меньше, а стало больше" как раз и связаны с массовым переходом на vbr.
GarfieldX писал(а):
83426713Выйдете наружу из своего раздела аниме, вы отстали от жизни
Покажите хоть один рип кино или сериалов не hdr и не с 4к бд sdr в 10 бит. Не путайте настоящий контент в 10 и конверт из 8.
Не нужно вводить людей в заблуждение, единицы не очень умных людей кодируют 8 в 10 просто так без обработки. Собственно и до появления 10 бит хватало "энкодеров", любящих сломать железное декодирование идиотскими настройками и тд, но мы говорим не о частных случаях же, как вы сами сказали, а про "общюю тенденцию" ведь так?
|
|
|
|
GarfieldX
Стаж: 19 лет 10 месяцев Сообщений: 4016
|
GarfieldX ·
29-Июл-22 22:13
(спустя 1 день 4 часа, ред. 29-Июл-22 23:14)
Цитата:
bpp это метрика "показывающяя погоду" и никак не связана с качеством видео или битрейтом напрямую
bpp это бит на пиксель, т.е. битрейт пикселя, он с общепринятым битрейтом связан прямее некуда
И показывает он что надо, т.к. учитывает разрешение, которое никак не учитывает общепринятый битрейт.
И речь о среднем значении, так же как и о среднем общепринятом битрейте. VBR тут ни при чем.
И качество видео bpp описывает куда точнее чем общепринятый битрейт.
jensen123321 писал(а):
83427338Не путайте настоящий контент в 10 и конверт из 8.
Опять почему то все в контексте аниме.
Да, таким извращением занимаются только ярые адепты аниме.
jensen123321 писал(а):
83427338единицы не очень умных людей кодируют 8 в 10 просто так без обработки
За этим не следил, но раздувание битрейта при переходе на x264 происходило на моих глазах и этим занимались очень многие.
|
|
|
|
jеnsen
Стаж: 14 лет 8 месяцев Сообщений: 2977
|
jеnsen ·
29-Июл-22 22:41
(спустя 28 мин., ред. 29-Июл-22 22:41)
GarfieldX писал(а):
83433123И качество видео bpp описывает куда точнее чем общепринятый битр
Нет. И я уже описал почему. Все, что показывает эта метрика по поводу качества - возможность отсеять слишком сильно пожатые или слишком "расжатые" видео. Да и то только в том случае, если вы примерно представляете, качество и прожорливость по битрейту конкретного исходника. Потому как высокие значения вполне могут быть обусловлены пиками битрейта + наличием зерна в исходнике. А низкие могут обуславливать хорошо сжимаемый материал и совсем необязательно означать плохое качество. Ну и использовать ее можно только при рипах в размер. Если используется переменный битрейт - эта метрика бесполезна.
GarfieldX писал(а):
83433123Опять почему то все в контексте аниме.
Да, таким извращением занимаются только ярые адепты аниме.
Так это вы написали
GarfieldX писал(а):
83426713Выйдете наружу из своего раздела аниме, вы отстали от жизни
и
GarfieldX писал(а):
83423483Увы, это человеческая натура. Обычно от незнания.
в ответ на
johnowenemmet писал(а):
83399291стало модным с 8 бит исходников кодировать в 10 бит, из ниоткуда добавляя 2 бита
разве нет?
|
|
|
|
GarfieldX
Стаж: 19 лет 10 месяцев Сообщений: 4016
|
GarfieldX ·
29-Июл-22 23:54
(спустя 1 час 13 мин., ред. 29-Июл-22 23:54)
jensen123321 писал(а):
Ну и использовать ее можно только при рипах в размер. Если используется переменный битрейт - эта метрика бесполезна.
Эта метрика является уточнением битрейта. И если уж она по вашему бесполезна, то битрейт вообще ересь.
Еще раз. Битрейт никак не привязан к разрешению кадра, а бит на пиксель привязана. Потому является более точной.
Использовать её можно и нужно всегда. Эта метрика показывает средний объем затраченный на пиксель.
Она в принципе не может быть бесполезной при разных методах сжатия, т.к. она от них никак не зависит. Как и любая другая метрика.
Используется всегда среднее значение, так же как и у битрейта. И дает представление о затраченном объеме на пиксель.
Качество сжимаемости определяется по квантам и никак иначе.
Визуальное качество - только на глаз.
Допустим, битрейт видео = 3000. И что? Ничего.
В зависимости от разрешения этого может быть как мало, так и много, а может быть и в самый раз.
Допустим bpp = 0.300 и сразу станет понятно много/мало или в самый раз, т.к. эта величина уже учитывает разрешение и частоту кадров. Точнее некуда.
0.300 было хорошо для xvid/divx, для x264 достаточно 0.150-0.200 в среднем.
jensen123321 писал(а):
Так это вы написали
Верно. Только порядок ответов другой и это ключевой момент.
Это был ответ на ваше "фильмы (не аниме) вообще кодируют только в 8", которое не особо подразумевало что речь идет опять же о 8->10.
|
|
|
|
jеnsen
Стаж: 14 лет 8 месяцев Сообщений: 2977
|
jеnsen ·
30-Июл-22 00:45
(спустя 50 мин., ред. 30-Июл-22 00:45)
GarfieldX писал(а):
83433379Она в принципе не может быть бесполезной при разных методах сжатия, т.к. она от них никак не зависит. Как и любая другая метрика.
Еще как зависит. Причем не только она. https://videoprocessing.ai/metrics/ways-of-cheating-on-popular-objective-metrics.html
Вообще, любая метрика сама по себе это предсказание погоды и не более того. А вот куча методик в своей совокупности дают хороший результат. Например опыт + глаза (сравнение скриншотов), bpp и VMAF уже дадут довольно точный результат. А bpp с удовольствием покажет значение 0.402 на 576p с битрейтом в 3000 мегабит и 0.272 на том же видео, но с битрейтом в 1500 килобит. При этом качество у них будет различаться как небо и земля, а вовсе не на 130 bpp. А исходя из вашего
GarfieldX писал(а):
83433379для x264 достаточно 0.150-0.200 в среднем.
там должно быть что, менее 1 мегабита?
GarfieldX писал(а):
83433379Это был ответ на ваше "фильмы (не аниме) вообще кодируют только в 8", которое не особо подразумевало что речь идет опять же о 8->10.
Я для этого и объяснил, почему в аниме так, а в кино и тд никто таким не занимается. Ладно, мы вроде поняли друг друга.
|
|
|
|
GarfieldX
Стаж: 19 лет 10 месяцев Сообщений: 4016
|
GarfieldX ·
30-Июл-22 23:52
(спустя 23 часа, ред. 30-Июл-22 23:52)
jensen123321 писал(а):
bpp с удовольствием покажет значение 0.402 на 576p с битрейтом в 3000 мегабит и 0.272 на том же видео, но с битрейтом в 1500 килобит
bpp не про качество, а про расход битрейта и только.
Качество сжатия оценивается по квантам по факту сжатия.
Визуальное качество - только на глаз.
Чтобы оценить рип нужно оценивать эти показатели в совокупности.
Смущают ваши опечатки... циферки хоть бы посчитали чтобы бились.
Что такое битрейт в 3000 мегабит?
jensen123321 писал(а):
там должно быть что, менее 1 мегабита?
Все таки вы не понимаете что есть bpp. В этом вся проблема нашего диалога.
Ликбез: при кадре 1920*800, 24 к/с и bpp = 0.150 получаем битрейт - 1920*800*24*0.150 = 5529600 б/с ~ 5.5Мб/с
|
|
|
|
jеnsen
Стаж: 14 лет 8 месяцев Сообщений: 2977
|
jеnsen ·
31-Июл-22 00:58
(спустя 1 час 5 мин.)
GarfieldX писал(а):
83437812Чтобы оценить рип нужно оценивать эти показатели в совокупности.
О чем я написал уже 3 раза выше, в ответ на ваше
GarfieldX писал(а):
83423483Когда появился h.264, то вместо того чтобы снижать битрейт его стали делать еще больше чем при сжатии xvid/divx.
GarfieldX писал(а):
83437812Смущают ваши опечатки... циферки хоть бы посчитали чтобы бились.
Что такое битрейт в 3000 мегабит?
Килобит*
GarfieldX писал(а):
83437812Все таки вы не понимаете что есть bpp. В этом вся проблема нашего диалога.
Ликбез: при кадре 1920*800, 24 к/с и bpp = 0.150 получаем битрейт - 1920*800*24*0.150 = 5529600 б/с ~ 5.5Мб/с
Мы вроде говорим про sd и я все веду к
GarfieldX писал(а):
83437812Чтобы оценить рип нужно оценивать эти показатели в совокупности
но вы упорно повторяете мои слова об этом и только, хотя я уже объяснил почему у 264 обычно битрейт выше, чем у хвид и что это не является раздуванием.
|
|
|
|
GarfieldX
Стаж: 19 лет 10 месяцев Сообщений: 4016
|
GarfieldX ·
01-Авг-22 22:31
(спустя 1 день 21 час, ред. 01-Авг-22 22:31)
jensen123321 писал(а):
83437988вроде говорим про sd
Без проблем. Пускай будет SD. Так чем плох мегабит? Что за привязка такая к битрейту?
Если хватает по квантам, то без разницы.
jensen123321 писал(а):
83437988но вы упорно повторяете мои слова об этом и только
Не стоит себе приписывать.
jensen123321 писал(а):
83437988хотя я уже объяснил почему у 264 обычно битрейт выше, чем у хвид и что это не является раздуванием.
Это именно что раздувание битрейта. И ничем нельзя оправдать лишний битрейт. Речь разумеется о понятии бит на пиксель. Сравнивать SD и HD никто не собирается.
Уже приводил выше в пример рип фильма "Воспоминания неудачника". Так вот там было достаточно определенного битрейта, но он не вписывался по нижней границе и пришлось его раздуть более чем в 1.5 раза, что качества не прибавило, т.к. и так уже был максимум.
jensen123321 писал(а):
83437988264 в принципе не изобретался с прицелом на экономию битрейта, его основная задача была в увеличении визуального качества видео.
Ну-ну...
Так сказать, слов из песни не выкинешь...
У любого кодировщика главная цель всегда будет сжать посильнее чем было при сравнимом с предшественниками качестве. И второстепенно из этого вытекает увеличение качества при толстом битрейте.
jensen123321 писал(а):
83437988Поэтому он обычно потребляет его чуть больше, чем мпег2 или хвид с дивиксом.
Бред. Про какое разрешение идет речь?
Битрейт MPEG может быть очень разным. Вплоть до ~9Mbit.
Для ASP при bpp = 0.300 битрейт для SD составляет ~2Mbit.
Так о чем речь? Смешались в кучу кони, люди...
Еще раз. Про битрейт в чистом виде забываем, т.к. не учитывает разрешение кадра. Используем битрейт не потока, а пикселя - bit per pixel (bpp).
Для ASP диапазон был 0.250-0.350
Для AVC достаточно 0.150-0.200, но некоторые начали раздувать аж до 0.400.
Примеры:
Перебор с битрейтом
Универсальный солдат BDRip 1080p
Bits/(Pixel*Frame): 0.509
И по квантам это видно:
---[Information] [02.04.2022 23:53:10] x264 [info]: frame I:1001 Avg QP:17.56 size:217538
---[Information] [02.04.2022 23:53:10] x264 [info]: frame P:30768 Avg QP:17.83 size:115993
---[Information] [02.04.2022 23:53:10] x264 [info]: frame B:117041 Avg QP:18.84 size: 94282
Т.к. из параметров сжатия: crf=18.5
Это излишне... там бы и 20 хватило с избытком.
Если правильно нашел оригинал, то там поток видео 24 Мбита, а в рипе 19 Мбит. Это типо сжатие что ли? При таких делах я бы выбрал BDRemux.
Это и есть раздувание битрейта. Хватило бы и вполовину меньше, т.е. bpp = 0.250. Получилось бы ~10Мбит. Уже куда адекватнее.
|
|
|
|
jеnsen
Стаж: 14 лет 8 месяцев Сообщений: 2977
|
jеnsen ·
01-Авг-22 23:39
(спустя 1 час 8 мин.)
GarfieldX писал(а):
83445371Без проблем. Пускай будет SD. Так чем плох мегабит? Что за привязка такая к битрейту?
Если хватает по квантам, то без разницы.
GarfieldX писал(а):
83445371Ну-ну...
GarfieldX писал(а):
83445371Бред. Про какое разрешение идет речь?
264 очень плох на низких и сверхнизких битрейтах и начинает разваливать картинку. Поэтому приближаться к нижнему пределу значений квантов для 8 бит (21-22), если средний битрейт падает к единице нужно очень осторожно и лучше всего проверять результат своими глазами. А уж с увеличением разрешения он (264) начинает активно жрать битрейт и у пользователя есть лишь весьма грубые инструменты для его контроля, что не всегда дает качественный результат при занижении планки битрейта. Поэтому все предпочитают чутка завысить, что обычно лучше недостатка битрейта в любых случаях и на любых разрешениях. Правда иногда получается вот такое
GarfieldX писал(а):
83445371видео 24 Мбита, а в рипе 19 Мбит.
, это да.
GarfieldX писал(а):
83445371Не стоит себе приписывать
Да неужели?
jensen123321 писал(а):
83433605А вот куча методик в своей совокупности дают хороший результат.
GarfieldX писал(а):
83437812Чтобы оценить рип нужно оценивать эти показатели в совокупности.
Два сообщения подряд)
|
|
|
|
GarfieldX
Стаж: 19 лет 10 месяцев Сообщений: 4016
|
GarfieldX ·
03-Авг-22 15:56
(спустя 1 день 16 часов, ред. 03-Авг-22 15:56)
jensen123321 писал(а):
83445758264 очень плох на низких и сверхнизких битрейтах и начинает разваливать картинку
bpp = 0.150 - это вообще никак не сверхнизкие битрейты
jensen123321 писал(а):
83445758Поэтому все предпочитают чутка завысить, что обычно лучше недостатка битрейта в любых случаях и на любых разрешениях.
Если бы речь была об этом самом "чутка", так ведь завышают "будь здоров" и пример есть в моем сообщении выше.
jensen123321 писал(а):
Да неужели?
Не стоит себе приписывать высказанное, если другая сторона это просто не озвучила.
Это как изобретение колеса, которое мог сделать не один единственный человек, но первый озвучил.
|
|
|
|
jеnsen
Стаж: 14 лет 8 месяцев Сообщений: 2977
|
jеnsen ·
03-Авг-22 21:40
(спустя 5 часов)
GarfieldX
Аналогия с колесом вообще мимо кассы, вот прям полностью. И советую посмотреть в словаре значение слова "приписывать".
|
|
|
|
GarfieldX
Стаж: 19 лет 10 месяцев Сообщений: 4016
|
GarfieldX ·
26-Авг-22 15:25
(спустя 22 дня, ред. 26-Авг-22 15:25)
jensen123321 писал(а):
83452247GarfieldX
Аналогия с колесом вообще мимо кассы, вот прям полностью. И советую посмотреть в словаре значение слова "приписывать".
Хорошо, можете подать патент. Ведь никто до вас до этого еще не додумался
Ну а местные инструкции написанные еще до вашей регистрации и содержащие ту же суть наверное просто какое-то недоразумение.
Очень интересует что же такого должен был увидеть в словаре?
Объяснять что-либо чем-либо.
отт. Считать (какие-либо свойства, мысли, поступки и т.п.) принадлежащими кому-либо, совершенными кем-либо.
P.S.: По битрейтам то разобрались или наглядные примеры не возымели действия?
|
|
|
|
jеnsen
Стаж: 14 лет 8 месяцев Сообщений: 2977
|
jеnsen ·
26-Авг-22 22:49
(спустя 7 часов, ред. 26-Авг-22 22:49)
GarfieldX
Вы не повторили мои же слова, вы просто не озвучили их ранее, а я, указавший вам на это - себе не озвученную мысль приписал, я понял, да.  Что за чушь?
И при чем тут инструкции на трекере вообще? Там то как раз все верно написано зачастую.
GarfieldX
По битрейтам - я не знаю, как там в разделе кино, но такой ерундой, как в вашем примере обычно занимаются единицы, поэтому я бы не стал ровнять все под одну гребенку.
|
|
|
|
andrey vg
Стаж: 12 лет 4 месяца Сообщений: 807
|
andrey vg ·
13-Фев-24 07:17
(спустя 1 год 5 месяцев)
Почему только 10bit? А BT2020 то бишь Rec2020 это новая система цвета и она даёт больше оттенков и цветов.Причём это видно сильно.Один и тот же фильм в sdr смотрится бледным рядом с BT2020,10bit,HDR.
|
|
|
|
