|
|
|
Andy Rok
Стаж: 14 лет 2 месяца Сообщений: 237
|
Andy Rok ·
05-Фев-12 23:51
(13 лет 7 месяцев назад)
Mikky72
Цитата:
Увеличить же картинку на современной широкоэкранной панели на весь экран не составит никакого труда.
За счет чего? Преобразования из 4/3 (я знаю что железный плеер это может)? Или железо это "сделает" и с имеющимся обрезаным кадром 16:9? И еще, если перекодировать в 4/3 в source Carbon Codera оставить 4:3 (как это определяет ffms-2.16 после индексации) или выставить 16:9 (как это определяет MediaInfo?
Areyou
Спасибо за Ваши предельно ясные и , быстрые ответы. А как Вы определили что черные поля составляют 77+77?
|
|
|
|
Mikky72
Стаж: 18 лет 6 месяцев Сообщений: 8498
|
Mikky72 ·
06-Фев-12 00:28
(спустя 36 мин., ред. 06-Фев-12 00:28)
Andy Rok
Надо в скрипте обрезать полосы по бокам, потом добавить сверху/снизу.
Полученный 720х576 (или 480) открыть в Карбоне и выставить Сорс 4:3 и Таргет 4:3.
За счет микропроцессора, реализующего кучу всяких разных режимов увеличения и растягивания.
|
|
|
|
Andy Rok
Стаж: 14 лет 2 месяца Сообщений: 237
|
Andy Rok ·
06-Фев-12 02:01
(спустя 1 час 32 мин., ред. 06-Фев-12 02:01)
Mikky72
Какой из вариантов ресайза посоветуете сделать:
1. Spline36Resize(720,576,77,43.3,-77,-43.3) или
2. Spline36Resize(720,470,77,0,-77,0).AddBorders(0,50,0,56) или
3. Если учесть, что имеются вертикальные черные полосы 77+77, полезный размер кадра = 1766х1080. Тогда по инструкции для PAL (720х576):
BicubicResize(720,472,0,05)
AddBorders(0,52,0,52) #bbb=52
4. BicubicResize с параметрами из 1 или2 варианта? (цифры которые там указаны мне не совсем понятны - это совет Areyou)
Спасибо.
|
|
|
|
Areyou
Стаж: 16 лет 9 месяцев Сообщений: 1724
|
Areyou ·
06-Фев-12 08:22
(спустя 6 часов, ред. 06-Фев-12 08:22)
Andy Rok писал(а):
как Вы определили что черные поля составляют 77+77
Экранным штангелем Calipers, перед этим в свойствах картинки посмотрел, что кадр в натуральную BD величину.
P.S.
Как получается цифра 470. Когда мы отрезаем поля, предполагается, что позже горизонталь будет увеличена под стандартный формат кадра в пропорции 1920/(1920-154)=1920/1766. Для сохранения пропорций изображения с этим же коэффициентом нужно будет увеличить и вертикаль. Это удобнее применить к высоте леттербокса (полезной части), которая для случая вписывания 16:9 (до кропа и растягивания горизонтали по нашим данным) в 4:3 для PAL равна 432 (=3/4 полной высоты 576). Скорректированная высота: (1920/1766)x432=469,67. Дальше можно оптимизировать (подводить под числа, кратные 4 или 8), при этом кроп исходных вертикальных полей для строгого сохранения пропорций можно увеличить. Например, в случае задания высоты 472 (вместо 469,67) это число можно подставить в последнее уравнение вместо 469,67 и найти новое число вместо 1766 (горизонталь после кропа), получится x=1920x432/472=1757,3 (= отрезать нужно 162,7 - вместо 154) и т. д.
|
|
|
|
Andy Rok
Стаж: 14 лет 2 месяца Сообщений: 237
|
Andy Rok ·
06-Фев-12 10:35
(спустя 2 часа 13 мин., ред. 06-Фев-12 10:35)
Areyou
Зачем определять пропорции изображения, если они известны - 4:3? Надо просто подогнать размеры кадра под эти пропорции по известной формуле расчета. Новая ширина исходного кадра (с учетом отрезания черных полос) составит 1766. Тогда все остальные размеры определятся по формуле: высота = 576х4/3х1080/1766. Получаем 469,6715... С учетом округления до кратности 8 - имеем 472. Ширина, естественно 720 (это залощено пропорцией 4:3 и имеет свое отражение в формуле расчета) . Ширина добавляемых черных полос (верхней инижней) определяется по формуле (576-472)/2=52. В итоге имеем 2 строчки в скрипте
BicubicResize(720,472,0,05)
AddBorders(0,52,0,52) #bbb=52
Так, по крайней мере предписано расчитывать ресайз в инструкции.
Мне непонятна формула
Цитата:
x=1920x432/472=1757,3 (= отрезать нужно 162,7
Это решение пропорции, но почему с такими числами? Логичнее было бы так: 1766х472/1080?
|
|
|
|
Mikky72
Стаж: 18 лет 6 месяцев Сообщений: 8498
|
Mikky72 ·
06-Фев-12 11:43
(спустя 1 час 8 мин., ред. 06-Фев-12 11:43)
Andy Rok
Порядок операций
1) обрезание черных полос
2) неравномерный (анаморфирующий) ресайз до ширины 720, так как на DVD - анаморф.
3) добавление в анаморфированное изображение анаморфированных черных полос (полосы уже будут "толще").
|
|
|
|
Andy Rok
Стаж: 14 лет 2 месяца Сообщений: 237
|
Andy Rok ·
06-Фев-12 11:54
(спустя 10 мин.)
Mikky72
Так?:
Spline36Resize(720,470,77,0,-77,0)
AddBorders(0,53,0,53)
|
|
|
|
Mikky72
Стаж: 18 лет 6 месяцев Сообщений: 8498
|
Mikky72 ·
06-Фев-12 12:10
(спустя 16 мин.)
Andy Rok
crop (77,0,-77,0)
BicubicResize(720,472,0,05)
AddBorders(0,52,0,52) #bbb=52
Как-то так... (472 не считал, поверил постам выше)
|
|
|
|
DreadMaster
Стаж: 16 лет 10 месяцев Сообщений: 710
|
DreadMaster ·
06-Фев-12 12:14
(спустя 4 мин.)
Следующий вопрос будет почему не делается crop (77,0,-77,0) 
|
|
|
|
Andy Rok
Стаж: 14 лет 2 месяца Сообщений: 237
|
Andy Rok ·
06-Фев-12 12:28
(спустя 14 мин.)
Mikky72
Спасибо.
DreadMaster
Марсианский юмор?
|
|
|
|
Areyou
Стаж: 16 лет 9 месяцев Сообщений: 1724
|
Areyou ·
07-Фев-12 21:54
(спустя 1 день 9 часов)
Andy Rok писал(а):
Зачем определять пропорции изображения, если они известны - 4:3?
Пропорции видимой части изображения не 4:3 (гораздо шире), их нужно вписать в этот формат с горизонтальными полями.
Цитата:
Мне непонятна формула
Цитата:
x=1920x432/472=1757,3 (= отрезать нужно 162,7
Это решение пропорции, но почему с такими числами? Логичнее было бы так: 1766х472/1080?
Соотношение, из которого получена высота для PAL (в кадре с полной высотой 576):
(1920/1766)x432=469,67
В нем коэффициент 1920/1766 компенсирует горизонтальную растяжку после кропа таким же пропорциональным увеличение высоты вписываемого изображения. Если вместо округления (в принципе, ошибка округления невелика, 0,5%, но ее несложно исключить) заменить число 469,67в правой части на 472, то этот коэффициент изменится за счет изменения числа 1766, а не константы 1920. И вот почему. Увеличение высоты при такой корректировке должно компенсироваться увеличением длины, но горизонталь предшествующими действиями уже вписана в формат, поэтому ее увеличение требует дополнительного кропа (он уже приходится на видимую часть горизонтали), который делать нужно на исходном видео, по данным, которые получатся при этом уточняющем пересчете. Т. е. изменится (уменьшится) число 1766 - оно раньше было получено вычитанием величины кропа 2x77, теперь величина кропа больше, а число меньше, его и следует заменять искомой переменной в уравнении. Т.е. при изначальном кропе уточненной величины (примерно 2x81 вместо 2x77), вы из того же уравнения получили бы сразу 472.
|
|
|
|
Mikky72
Стаж: 18 лет 6 месяцев Сообщений: 8498
|
Mikky72 ·
08-Фев-12 11:08
(спустя 13 часов)
Andy Rok писал(а):
DreadMaster
Марсианский юмор?
Нет. 77 может не сработать. Может не станет воспринимать НЕчетное число. Тогда 78 или как написано выше - 82, но и вертикальный ресайз чуть побольше - до 472.
|
|
|
|
Andy Rok
Стаж: 14 лет 2 месяца Сообщений: 237
|
Andy Rok ·
08-Фев-12 18:27
(спустя 7 часов)
Areyou
Я подумал-подумал, и сделал 16:9 по Вашему рецепту - Spline36Resize(720,576,77,43.3,-77,-43.3). Все получилось отлично, причем с минимальными потерями изображения. Для 4:3 слишком противоречивые мнения даже у таких специалистов как Вы и Mikky 72. Получилась очень интересная дискуссия. Ради интереса сделаю несколько вариантов 4:3, но на это нужно время. Но как объективно (не на глаз) оценить который из результатов будет будет более правильный?
Mikky72
А действительно, зачем делать дополнительный кроп, если в формулу расчета вертикального размера заложен коэффициент 1080/1766? В инструкции, ведь тоже рассматривается перекодирование кадра с нестандартными размерами (1280х536), и там никакого дополнительного кропа нет. В формулу закладывается коэффициент 536/1280, и все.
|
|
|
|
giveaway
Стаж: 16 лет 3 месяца Сообщений: 507
|
giveaway ·
08-Фев-12 20:09
(спустя 1 час 41 мин., ред. 08-Фев-12 20:09)
Помогите, пжлст, распознать, что это такое может быть с исходником (mpeg2, PAL)? Вот скриншот динамичной сцены:
Страшно ли это? Если да, то как сие "лечить" при изготовлении рипа? Спасибо.
|
|
|
|
Mikky72
Стаж: 18 лет 6 месяцев Сообщений: 8498
|
Mikky72 ·
08-Фев-12 23:06
(спустя 2 часа 56 мин.)
giveaway
Это перевод из старого формата (16 или 20 кадров в секунду) в современный киноформат 24 кад/сек. Лечить при изготовлении рипа можно так - полностью просмотреть подряд сотню кадров и попытаться выявить закономерность (например, между пятым и шестым кадром вставлена их комбинация) и период её повторения. После этого с помощью функции SelectEvery отбирать из пачки в 24 кадра только 20 (или 16) полноценных. В полученном рипе выставить скорость воспроизведения 20 (или 16) fps.
|
|
|
|
Andy Rok
Стаж: 14 лет 2 месяца Сообщений: 237
|
Andy Rok ·
09-Фев-12 12:11
(спустя 13 часов, ред. 09-Фев-12 12:11)
извиняюсь, вопрос не по теме, просто не знаю у кого спросить. Последние 2-3 дня возникли проблеммы с загрузкой этого сайта (с другими проблемы нет). Пишут - ошибка сети, ошибка подключения, форум временно отключен. Если кто нибудь знает в чем дело, отпишите плз на e mail sv_arok@rambler.ru Сюда попадаю случайно на 1-3 минуты затем при попытке перейти на любой другой форум вновь возникают вышеописанные проблеммы. Може какие то настройки сбились? Или эта проблемма у всех? Даже не знаю, удастся ли отправить это сообщение....
|
|
|
|
Areyou
Стаж: 16 лет 9 месяцев Сообщений: 1724
|
Areyou ·
09-Фев-12 20:52
(спустя 8 часов)
Andy Rok
Вчера в сети нашел гуглом, что были кибер-атаки (хакеры перегружали сервер запросами), сейчас вроде улеглось.
|
|
|
|
Andy Rok
Стаж: 14 лет 2 месяца Сообщений: 237
|
Andy Rok ·
15-Фев-12 20:11
(спустя 5 дней, ред. 15-Фев-12 20:11)
Areyou
Я уже и сам все нашел. Но тем не менее, спасибо. Хотел Вас спросить: - как Вы расчитываете средний и максимальный битрейт при кодировании в MPEG 2? У меня с этим иногда случаются заморочки, хотя я подстраховываюсь VideoCalc'ом. В инструкции есть формула, но она для расчера среднего битрейта. Предположим, я его расчитал (делов то), а что на счет максимального? Иногда VideoСalc показывает максимальный битрейт, который гораздо ниже расчитаного среднего. Хотелось бы как-то определиться с этим вопросом, чтобы не заниматься повторными прогонами одного и того же материала (MuxMan - свидетель). Хотелось бы, что бы болванка при этом не была наполовину пустой (шутка). Заранее спасибо.
PS: Пользуюсь Carbon Coder'ом. На CCE переходить не хочется (почему-то...).
|
|
|
|
darth_san
Стаж: 17 лет 5 месяцев Сообщений: 875
|
darth_san ·
15-Фев-12 20:25
(спустя 13 мин., ред. 15-Фев-12 20:25)
Andy Rok
Я пользуюсь ProCoder 3 и у меня никогда не было проблем с размером полученого видеофайла.
Главное расчитать средний битрейт, а максимальный битрейт никак не влияет на размер и расчитывать его не нужно, а просто указать в пределах разумного.
И максимальный битрейт никак не может быть ниже среднего битрейта.
Например я указал средний 5250 и максимальный 8000, после кодирования загрузил файл в Bitrate Viewer и всё показывает как я и задавал.
|
|
|
|
Andy Rok
Стаж: 14 лет 2 месяца Сообщений: 237
|
Andy Rok ·
15-Фев-12 21:06
(спустя 40 мин., ред. 15-Фев-12 21:06)
darth_san
Цитата:
И максимальный битрейт никак не может быть ниже среднего битрейта.
Это очевидно, просто иногда расчитаный средний битрейт оказывается больше, чем максимальный, который выдает VideoCalc - это такая программа для расчета битрейта.
Цитата:
максимальный битрейт никак не влияет на размер и расчитывать его не нужно
А здесь я не согласен - максимальный битрейт не должен превышать 9800 минус суммарный битрейт аудио дорог и сабов. У меня проблема в том, что несмотря на то, что я стараюсь все эти тонкости учесть, микс зачастую еле еле превышает 7 гигов. А хотелось бы под завязку. Вот я и спросил, - как это сделать? Посмотришь на чужие раздачи - там все в порядке (причем сделаны они ProCoderom), а у меня чего-то так не всегда получается.
|
|
|
|
darth_san
Стаж: 17 лет 5 месяцев Сообщений: 875
|
darth_san ·
15-Фев-12 21:13
(спустя 7 мин.)
Andy Rok
Тогда советую кодировать одним проходом на максимальном битрейте 9800 минус битрейт дорожки и не париться.
|
|
|
|
Andy Rok
Стаж: 14 лет 2 месяца Сообщений: 237
|
Andy Rok ·
15-Фев-12 21:49
(спустя 36 мин.)
darth_san
На динамичных сценах с большой вероятностью могут появиться артефакты.
|
|
|
|
darth_san
Стаж: 17 лет 5 месяцев Сообщений: 875
|
darth_san ·
15-Фев-12 22:17
(спустя 27 мин., ред. 15-Фев-12 22:17)
Andy Rok Откуда они возьмутся, если битрейт будет постоянно максимальным. Или вы явно чего-то не понимаете?
|
|
|
|
Mikky72
Стаж: 18 лет 6 месяцев Сообщений: 8498
|
Mikky72 ·
15-Фев-12 22:19
(спустя 1 мин.)
Точно не помню, но приходилось читать что-то типа того, что Прокодер не соблюдает точно выставленный битрейт. Он его округляет, что вызывает определенные ошибки в размере...
|
|
|
|
darth_san
Стаж: 17 лет 5 месяцев Сообщений: 875
|
darth_san ·
15-Фев-12 22:23
(спустя 4 мин.)
Mikky72 Ничего подобного - проверенно опытным путем на более чем 30 дисках. Битрейт получаеться тютелька в тютельку. График BitrateViewer тому доказательство.
|
|
|
|
Mikky72
Стаж: 18 лет 6 месяцев Сообщений: 8498
|
Mikky72 ·
15-Фев-12 22:33
(спустя 10 мин.)
Не-не. Точно было. Даже тесты помню. Сравнивали размер файла (из одного исходника) у разных версий прокодера при одинаково выставленном битрейте. Он получался разный.
|
|
|
|
darth_san
Стаж: 17 лет 5 месяцев Сообщений: 875
|
darth_san ·
15-Фев-12 22:37
(спустя 3 мин.)
Mikky72 Может это в старых версиях было, но в последней все идеально. Единственное ограничение, что битрейт должен быть кратным 50.
Я когда расчитываю битрейт видео, исходя из размера будущего диска, то в результате получаю то, что мне было нужно - мегабайт в мегабайт. Прокодер еще не подводил.
|
|
|
|
Mikky72
Стаж: 18 лет 6 месяцев Сообщений: 8498
|
Mikky72 ·
15-Фев-12 22:44
(спустя 7 мин.)
darth_san писал(а):
быть кратным 50
Вот-вот. Причем округляет он его вроде в меньшую сторону автоматически. В результате для двухчасового фильма это выливается в недобор на 44 мегабайта. Это, конечно не сотни, но...
|
|
|
|
darth_san
Стаж: 17 лет 5 месяцев Сообщений: 875
|
darth_san ·
15-Фев-12 22:53
(спустя 9 мин., ред. 15-Фев-12 22:53)
Mikky72 Так он и не даст ввести в качестве ср. битрейта число не кратное 50. А с указанным битрейтом он кодирует предельно точно.
Неужели 40 Мб недобора в пределах размера DVD - это существенная погрешность (хотя это не погрешность, а особенность)?
|
|
|
|
Andy Rok
Стаж: 14 лет 2 месяца Сообщений: 237
|
Andy Rok ·
15-Фев-12 23:46
(спустя 52 мин., ред. 15-Фев-12 23:46)
darth_san
Я делаю проект: 4 аудио дорожки по 448Kbhs, 3 потока сабов. Расчитываю видео для двуслойной болванки. Беру для перестраховки объем 7,85Гб. Получаю размер файла 7850-(325х4)=6550 Вычитаю еще 150Мб на меню и сабы. Получаем 6400. Продолжительность фильма 102 мин, или 6120 сек. 6400000/6120х8=8336rbps - средний битрейт. Но этого не может быть т. к. 9800-(448х4)=8008- именно такой максимальный битрейт мне выдает VidejCalc/ Вот и получается средний битрейт больше максимального. А скорее всего я что то делаю не так. Кстати, я ввел полученные от VideoCalc данные битрейта - макс 8000, средний 7700 (VBR) и получил файл размером 5,46Гб, вместо 6,4Гб, на которые я расчитывал и даже не 5982Мб, которые мне "обещал" VideoCalc. Здесь уже ошибка от 500Мб до 1Гб (смотря как считать битрейт). Объясните мне, что я сделал неправильно? Спасибо.
|
|
|
|
