Ru-Board.club
← Вернуться в раздел «Программы»

» VirtualDub (часть 4)

Автор: unreal666
Дата сообщения: 17.04.2012 00:27
SlavikCash
Ну так разрядность VD и разрядность ffdshow одинаковые?

Автор: Gideon Vi
Дата сообщения: 17.04.2012 04:53
кто-нибудь знает о назначении AACACM? В avi его ни кто не пихает, так зачем козе баян

Цитата:
Для поноценной работы Matroska, QuickTime и FLV плагинов.

ясно, спасибо
Автор: V0lt
Дата сообщения: 17.04.2012 05:44
Gideon Vi
Цитата:
кто-нибудь знает о назначении AACACM?

Для поноценной работы Matroska, QuickTime и FLV плагинов.
Автор: Xant1k
Дата сообщения: 17.04.2012 10:33

Цитата:
Если исходник без черных полос тогда:
720x480(16:9) -> 720x400
720x576(16:9) -> 720x400
Нечего тут мудрить.

Почему до 400 по высоте сократили, а ширину оставили?

Вообще изначально рипер имея исходник NTSC 16:9 (720x480) VBR Auto Letterboxed
для своих рипов делает размер
640 x 352
вот кусочек исходника всей папки VIDEO_TS
http://ifolder.ru/29968769

другой при кодирований, только в x264, оставляет исходные размеры 720х480(более того узнал что нельзя сохранять такую пропорцию)

Вот мне и не понятно - почему релизер сделал ресайз и для чего? А главное как его делать правильно с учётом просмотра как на компе так и на всех телевизорах как 4:3 так и 16:9?!
Читая про всякие DAR, PAR, AR ничего не понял. Ну кроме AR разве что...высчитывается он так ширину делим на длину. И еще что ширина должна быть кратна 32, а высота 16, но для чего и почему так и не понял.
Автор: unreal666
Дата сообщения: 17.04.2012 11:26
Xant1k

Цитата:
И еще что ширина должна быть кратна 32, а высота 16, но для чего и почему так и не понял.

для допотопных DVD-плееров.

Цитата:
Читая про всякие DAR, PAR, AR ничего не понял.

На рутрекере.
Но там мелкая неразбериха с SAR. У SAR есть минимум два понятия: то, что ниже, и Sample Aspect Ratio.
2-ое понятие = PAR из формулы ниже.

DAR = PAR*SAR
где:
DAR - Display Aspect Ratio. Он же IAR - Image Aspect Ratio. Отношение геометрической ширины к геометрической высоте "правильного" кадра. Для DVD может быть или 16/9 или 4/3.
PAR - Pixel Aspect Ratio. Соотношение сторон пикселя (он же параметр --sar в x264).
SAR - Storage Aspect Ratio. Отношение ширины кадра в пикселях к высоте в пискселях (он же просто AR).

Цитата:
Вот мне и не понятно - почему релизер сделал ресайз и для чего?

Чтобы сохранить DAR. Т.к. обрезки для твоего видео нет, то и конечный DAR = оригинальному DAR. Только непонятно почему так мелко он сделал (скорее всего для подгонки в какой-то конкретный размер файла без явного ухудшения качества). Можно было 720x400 - ближайшее соотношение к 16:9 и кратное 16.

Цитата:
другой при кодирований, только в x264, оставляет исходные размеры 720х480(более того узнал что нельзя сохранять такую пропорцию)

можно такие пропорции, но с прописыванием "--sar нужный_sar" при кодировании. Такое видео наз-ся анаморфным.
Автор: Xant1k
Дата сообщения: 17.04.2012 14:09
unreal666
С расчётом на подопытные плееры и собираюсь делать.
А на рутрекере информацию первым делом после википедии читал, только толку 0...не доходит до меня. Смирился с этим и буду ждать пока найдётся человек который мне детально на пальцах объяснят НЕ со своей колокольни.


Цитата:
можно такие пропорции, но с прописыванием "--sar нужный_sar" при кодировании. Такое видео наз-ся анаморфным.

Тобишь спокойну могу оставлять исходное разрешение. Хм...а в дабе возможно как-то прописать --sar? Не хотелось бы к мегуи прибегать.

Кстати, если делать с этим самым --sar видео нормально будет воспроизводится на TV?
Автор: unreal666
Дата сообщения: 17.04.2012 14:28

Цитата:
Хм...а в дабе возможно как-то прописать --sar?

для x264 там и так есть на странице Main справа вверху.
только как ты будет прописывать, если еще не разобрался, как его рассчитывать?

Цитата:
Кстати, если делать с этим самым --sar видео нормально будет воспроизводится на TV?

Понятия не имею. У меня нет ни ЖК-телика, ни тем более телика со встроенным плеером (на встроенные мне вообще с большой колокольни)
Автор: Xant1k
Дата сообщения: 17.04.2012 15:07

Цитата:
для x264 там и так есть на странице Main справа вверху.

У меня xvid.

Цитата:
только как ты будет прописывать, если еще не разобрался, как его рассчитывать?

PAR определяется как в моём случае (16/9) / (720/480) = 1,2(ну или ~1,18)
PAR - нашли. Исходя из формулы DAR=PAR*SAR выведем SAR. SAR=DAR/PAR = 1,5
Верно?

И всё таки нужно делать ресайз или можно оставить при кодировании исходный размер? Просто вчера случайно наткнулся в статье(непомню уже какой...их не один десяток было прочтено) что условия ресайза обязательны иначе какие-то там проблемы могут быть потом с картинкой.
Автор: Dimitr1s
Дата сообщения: 17.04.2012 15:25
Xant1k

Цитата:
...как его рассчитывать?

Если будешь кодировать AS IS без ресайза, не надо ничего рассчитывать, смотри SAR исходного видео и выставляй такой же.
Автор: unreal666
Дата сообщения: 17.04.2012 16:04
Xant1k

Для xvid анаморф не используется. Хоть у него и в настройках есть какой-то AR, только толку от нет, т.к. или все или большинство железных плееров его не понимает. А для ПК лучше в x264 кодить.

Цитата:
PAR определяется как в моём случае (16/9) / (720/480) = 1,2(ну или ~1,18)

для NTSC 16/9 используется PAR=32/27

Цитата:
PAR - нашли. Исходя из формулы DAR=PAR*SAR выведем SAR. SAR=DAR/PAR = 1,5

SAR = 720/480=1.5

ЗЫ.
- после ресайза меняется PAR и SAR.
- после кропа меняется DAR и SAR.

Dimitr1s

Цитата:
смотри SAR исходного видео и выставляй такой же.

В MediaInfo оно выдается как число с запятой, а не как дробь. Поэтому точно не узнаешь.
Автор: Dimitr1s
Дата сообщения: 17.04.2012 16:21
unreal666

Цитата:
В MediaInfo оно выдается как число с запятой, а не как дробь. Поэтому точно не узнаешь.

Точно узнать легко и через MediaInfo, взглянув (и поделив дробь) на стандартную таблицу SAR:
PAL 4:3 ITU - 12:11 NON ITU - 16:15
PAL 16:9 ITU - 16:11 NON ITU - 64:45
NTSC 4:3 ITU - 10:11 NON ITU - 8:9
NTSC 16:9 ITU - 40:33 NON ITU - 32:27
Ещё таблица (H264):

ffprobe выдаёт инфу в "нормальном" виде, можно как то так:
Код: ffprobe -v quiet -show_format -show_streams -show_error -pretty -print_format json -i Пример.vob
Автор: unreal666
Дата сообщения: 17.04.2012 16:41
Dimitr1s

Цитата:
Точно узнать легко и через MediaInfo, взглянув (и поделив дробь) на стандартную таблицу SAR:

- в формуле выше - это PAR, а не SAR (но --sar в x264)
- делить ничего и не надо. И DAR и разрешение в MI и так видно.

ЗЫ.
Кстати, судя по словам какого-то кантика на рутрекере, NON ITU на самом деле тоже является частью ITU. Поэтому фраза NON ITU не совсем корректна.

Добавлено:

Цитата:
ffprobe выдаёт инфу в "нормальном" виде, можно как то так:

много телодвижений. У меня нужные PAR'ы уже забиты в профили в MeGUI.
Автор: Dimitr1s
Дата сообщения: 17.04.2012 17:24
unreal666

Цитата:
- в формуле выше - это PAR, а не SAR (но --sar в x264)

В терминологии x264, SAR = (Pixel Aspect Ratio) соотношение сторон пикселя, тут как не пиши, совсем правильно не будет, но о чём речь понятно. MediaInfo выдаёт как: Pixel aspect ratio. ffprobe тоже самое соотношение сторон пикселя выдаёт уже как: sample_aspect_ratio.
Цитата:
- делить ничего и не надо. И DAR и разрешение в MI и так видно.
Разговор про "MediaInfo -> Pixel aspect ratio" которое, цитирую: "...выдается как число с запятой, а не как дробь. Поэтому точно не узнаешь." Поделив дробные значения из таблицы, не сложно получить коэффициент который выдал MediaInfo.
Цитата:
много телодвижений. У меня нужные PAR'ы уже забиты в профили в MeGUI.
При чём тут профили и что в них уже вбито? Разговор про то, как получить (узнать) соотношение сторон пикселя из исходного файла.
Автор: unreal666
Дата сообщения: 18.04.2012 04:03

Цитата:
При чём тут профили и что в них уже вбито?

В смысле что вбито? Ясно же написано "нужные PAR'ы уже забиты".

Добавлено:

Цитата:
Поделив дробные значения из таблицы, не сложно получить коэффициент который выдал MediaInfo.

зачем что-то делить, если в в MI есть DAR и разрешение, из которых с помощью таблицы и получишь нужный PAR в виде дроби? Если делить, то и таблица не нужна. Достаточно калькулятора с возможностью вывода результата операций в виде дроби (например, NumLock Calculator). Ну кроме 32/27, т.к. более точное значение для NTSC 16:9 - 11851851/10000000.
Автор: Dimitr1s
Дата сообщения: 18.04.2012 05:43
unreal666

Цитата:
Ясно же написано "нужные PAR'ы уже забиты".

Какое отношения имеет, что забито в профилях, к определению соотношения сторон пикселя в исходном файле?

Цитата:
зачем что-то делить, если в в MI есть DAR и разрешение, из которых с помощью таблицы и получишь нужный PAR в виде дроби?
Я не даром упомянул ffprobe, т.к. если исходник более-менее стандартный то ещё ничего, если не стандартный, то MediaInfo часто лажает и высчитать (PAR) по DAR и разрешению становится проблематично. Пример. ffprobe чаще выдаёт более вменяемые результаты, но как минимум оба инструмента неплохо иметь для сравнения результата.
Цитата:
Если делить, то и таблица не нужна. Достаточно калькулятора с возможностью вывода результата операций в виде дроби (например, NumLock Calculator).
По мне, тут много телодвижений по сравнению с одной командой. Или [more=кнопка]TOTALCMD#BAR#DATA
%ComSpec% /k chcp 65001 && E:\FFmpeg\ffprobe.exe
-v quiet -show_format -show_streams -show_error -pretty -print_format json -i %P%S1
E:\icon.ico
FFprobe
E:\FFmpeg\

-1

[/more] для Total'а.
Автор: unreal666
Дата сообщения: 18.04.2012 07:12

Цитата:
Какое отношения имеет, что забито в профилях, к определению соотношения сторон пикселя в исходном файле?

Прямое. Мне определять ничего не надо. У меня профили так и наз-ся: NTSC (16:9), NTSC (4:3), PAL (16:9), PAL (4:3). В каждом из них забит соответствующий PAR (--sar). Правда это в MeGUI. В VD почему-то не догадались для x264 vfw сделать профили.

Цитата:
Я не даром упомянул ffprobe, т.к. если исходник более-менее стандартный то ещё ничего, если не стандартный, то MediaInfo часто лажает и высчитать (PAR) по DAR и разрешению становится проблематично. Пример. ffprobe чаще выдаёт более вменяемые результаты, но как минимум оба инструмента неплохо иметь для сравнения результата.

вообще какой-то левый исходник. DAR:
MI - 1,304
ffprobe - 1958:1467 = 1,3347
DGIndex = 4:3,625 (с этим значением вообще непонятно что делать. MeGUI выдает для этого d2v-файла все те же 1,304).
Так что не факт, что ffprobe выдает корректное значение.

Цитата:
По мне, тут много телодвижений по сравнению с одной командой. Или кнопка для Total'а.

- команду надо еще набрать, так что телодвижений не меньше. А набирать цифры чисто на цифровой клавиатуре проще, по крайней мере для тех, кто часто ее юзает.
- Total тоже еще надо запустить и перейти на нужный файл. Не все Total'ом на постоянку пользуются.
Автор: Xant1k
Дата сообщения: 18.04.2012 08:28
День добрый Перечитав, проанализировав и сравнив свой рип с рипом релизера понял примерно что к чему и как варить. Но про DAR, PAR и SAR понял частично

Ресайз нужен для того что бы сохранить исходный AR 16:9, иначе при кодирований будет медиаинфо показывать AR 3:2, что вчера и случилось когда не сделал ресайз, и по всей видимости это негативно скажется на просмотре через TV. И вот тут то моё своеобразное мышление начало работать, а т.к я по работе отчасти аналитикой рекламного пространства занимаюсь то взглянув на свой рип и сравнив его с рипом автора
быстро смекнул что к чему. Всё-таки теория теорией, а практика иногда вот наталкивает на определённые мысли которые наш мозг генерирует) В итоге вот что выдал:

Разрешение 720х480 что равно в десятичном варианте 1,5 - нельзя оставлять таким т.к оно не соответствует 16:9=1,78, но тут следует округлить до 1,8 т.к есть условие, что ширина должна делится ровно на 16, и если взять 720x404 то, 404/16 не будет четным числом. Откуда следует что нужно делать ресайз и полученное разрешение должно при делений получить те заветные 1,8, либо как понял быть близким к этому значению. Так что 720х400. Хотя, можно и по ширине сократить до 688x384 скажем, будет ~1,79

В итоге было решено(да и вроде так заведено что уменьшаем только ширину), отрезать по ширине. Подобрал 720x400.
V0lt, на пред. странице как всегда неожиданно появился и стрельнул метко
Так что можно было послушать его, но я захотел идти дальше и сам разобраться во всём.

Сейчас чашечка горячего какао, немного свежего воздуха и радость малышей из детского,
сада который под окном, и можно приступать к кодированию и изучению I,B,P-frame quantizer)

Всем огромнейшее спасибо за участие!

P.s. вопрос по поводу фрапса на пред.странице актуален.
Автор: unreal666
Дата сообщения: 18.04.2012 10:50
Xant1k

Цитата:
Кроппинг нужен для того что бы сохранить исходный AR 16:9

может ресайз, а не кроппинг?

Цитата:
Подобрал 720x400.

Если видео 16:9 и черных полей нет (т.е. кроппинг не нужен), то обычно такое разрешение и делают. 4% искажений - это мелочь.
Автор: Xant1k
Дата сообщения: 18.04.2012 11:31
unreal666
Да, пардон, ресайз Путаться уже начинаю в терминах. Подправил.

Кстати, вспомнил еще что хотел узнать...для даба есть более продуктивный дескать ресайз фильтр чем Lanczos3?
Автор: Dimitr1s
Дата сообщения: 18.04.2012 13:35
unreal666

Цитата:
Прямое. Мне определять ничего не надо. У меня профили так и наз-ся: NTSC (16:9), NTSC (4:3), PAL (16:9), PAL (4:3). В каждом из них забит соответствующий PAR (--sar).
У тебя, другие соотношения сторон исходников не попадаются, как и не существуют различные PAR для выше перечисленных соотношений сторон. MeGUI у тебя ни когда ошибается открывая, к примеру, исходник PAL 4:3 (1.333333) как ITU PAL 4:3 (1.367521) и ты на 100% правильно угадываешь выбирая профиль. Так что ли?
Цитата:
вообще какой-то левый исходник.
Подобных достаточно встречается, вопрос в другом, как с помощью только MediaInfo и калькулятора считать?
Цитата:
Так что не факт, что ffprobe выдает корректное значение.
Если посмотришь, то на этом исходнике MI выдаёт коэффициент Pixel aspect ratio = 1.067 (16:15), т.е. при выдаваемом ей же DAR 4:3 (1.304), рассчитывает PAR как от 4:3 (1.333), что уже точно не верно. У ffprobe по крайней мере концы с концами сходятся: (178:163 = 1,092) = ((1958:1467) / (352:288) = 1,092).
Цитата:
- команду надо еще набрать, так что телодвижений не меньше.
Её можно, как вариант, скопипастить.
Автор: unreal666
Дата сообщения: 18.04.2012 14:03
Dimitr1s

Цитата:
У тебя, другие соотношения сторон исходников не попадаются, как и не существуют различные PAR для выше перечисленных соотношений сторон.

DVD с DAR, отличающимся от 16:9, 4:3 или 1:1, уже является левым. А MPEG-2 я кодирую только или с нормального DVD или HDTV. Поэтому мне другие и не попадаются и маловероятно, что попадутся.

Цитата:
Подобных достаточно встречается, вопрос в другом, как с помощью только MediaInfo и калькулятора считать?

Вопрос в другом. Кто прав по части DAR: MI, ffprobe или DGIndex?

Цитата:
Если посмотришь, то на этом исходнике MI выдаёт коэффициент Pixel aspect ratio = 1.067 (16:15), т.е. при выдаваемом ей же DAR 4:3 (1.304), рассчитывает PAR как от 4:3 (1.333), что уже точно не верно.

Хм. 1.304/(352/288)=1.0669. Так что не по ITU все верно.

Цитата:
Её можно, как вариант, скопипастить.

Для этого сначала надо открыть прогу, из которой скопипастить

Добавлено:
Xant1k

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

Продуктивней по части качества? Не встречал.

Автор: Dimitr1s
Дата сообщения: 18.04.2012 15:25
unreal666

Цитата:
DVD с DAR, отличающимся от 16:9, 4:3 или 1:1, уже является левым. А MPEG-2 я кодирую только или с нормального DVD или HDTV. Поэтому мне другие и не попадаются и маловероятно, что попадутся.
Ну ладно, бог с ними с "левыми", как насчёт ITU / NON ITU, при условии, что MeGUI чаще неправильно открывает с соотношением ITU, хотя в исходнике соотношение NON ITU. Не глядя кодируешь?
Цитата:
Хм. 1.304/(352/288)=1.0669. Так что не по ITU все верно.
Да, в этом случае я не прав, обсчитался жёстко.
Цитата:
Вопрос в другом. Кто прав по части DAR: MI, ffprobe или DGIndex?
Для чистоты эксперимента, закодировал х264 с обоими --sar:
Исходник:

16:15:

178:163:

Вот так сразу, разницы вообще не вижу .
Но в MediaInfo для расчёта дробного PAR телодвижений на порядок больше (включая сравнение с таблицей).
Автор: unreal666
Дата сообщения: 18.04.2012 15:41
Dimitr1s

Цитата:
как насчёт ITU / NON ITU, при условии, что MeGUI чаще неправильно открывает с соотношением ITU, хотя в исходнике соотношение NON ITU. Не глядя кодируешь?

Я вообще не смотрю на инфу, выдаваемую MeGUI. После скачивания DVD в 1-ую очередь через MI смотрю DAR. А ITU/NON ITU вообще относится к PAR, которого в MPEG-потоке кажется вообще нет (кто-то на рутрекере такое говорил), оно просто высчитывается. И всегда кодирую как NON ITU.
Да и еще потом DGIndex вручную тоже запускаю, индексирую и смотрю в нем тоже DAR.
В MeGUI юзаю только собственно кодирование и определение интерлейса. После его определения интерлейса на всякий случай разделяю на поля и смотрю вручную.
Автор: fire4x
Дата сообщения: 18.04.2012 15:55
Народ, подскажите где взять кодек 0х0162.
Автор: unreal666
Дата сообщения: 18.04.2012 16:02
fire4x

MediaInfo для этой аудиодорожки какой кодек показывает?

Добавлено:
fire4x
судя по гуглу:

Цитата:
0x0161 is WMA v2
0x0162 is WMA 9 pro (used for 5.1 multichannel)

You can use Divx WMA Audio to use directly in vdub for the 1st with the vdub wmv plugin, you cannot for the 2nd (nothing works)

The only way for decoding wma pro in vdub is to use in vdub is avisynth + DirectShowSource with WMAudio Decoder DMO installed from WMP11 or the SDK

так что только через avisynth + DirectShowSource для декодирования в wav.
Автор: Dimitr1s
Дата сообщения: 18.04.2012 16:22
unreal666
Что б поставить точку MediaInfo vs ffprobe в приведённом выше исходнике, закодил ещё с параметрами:
Input DAR = 1.304 --sar 16:15 /по данным MediaInfo
Input DAR = 1.335 --sar 178:163 /по данным ffprobe
Снял Print Screen, где собственно и работает PAR.
Итого:
Исходник:

DAR = 1.304 --sar 16:15:

DAR = 1.335 --sar 178:163:

Получается на нестандартных исходниках оба далеки от идеала. Так что старый способ: пробовать и смотреть в силе .
Автор: fire4x
Дата сообщения: 18.04.2012 16:55
unreal666

Цитата:
Цитата: 0x0161 is WMA v2
0x0162 is WMA 9 pro (used for 5.1 multichannel)

You can use Divx WMA Audio to use directly in vdub for the 1st with the vdub wmv plugin, you cannot for the 2nd (nothing works)

The only way for decoding wma pro in vdub is to use in vdub is avisynth + DirectShowSource with WMAudio Decoder DMO installed from WMP11 or the SDK


так что только через avisynth + DirectShowSource для декодирования в wav.

Через DirectShow input driver все работает. Без avisynth. Только инфа о файле не отображается.
Автор: unreal666
Дата сообщения: 18.04.2012 17:26
fire4x
какой вообще контейнер видео: avi, wmv ... ?
Автор: V0lt
Дата сообщения: 18.04.2012 17:38
Тут есть нерабочая ссылка на WMA ACM Codec 8.0.0.4487.zip (0x0160 0x0161). Кто бы перезалил.

Есть вероятность, что для WmaPro (0x0162) вообще не существует ACM-кодека в природе.
Автор: webern
Дата сообщения: 18.04.2012 19:57
V0lt
http://rghost.ru/37651098

Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179

Предыдущая тема: Pcad и монитор


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.