Так, практически разобрался с PAR.
Оказывается, есть два разных способа указать PAR:
1) при кодировании в Vdub:XviD(или xvidencraw):Aspect:PAR<>1 (т. е. не квадратные пикселы),
2) при сохранении в AVI в стандарте AVI2.0 (OpenDML).
VDub и xvidencraw на выходе выдают avi (для 1 или 2ГБ, avi1.1 или всё же AVI2.0, не разобрался) не выставив в его заголовке значение PAR, только флажки в поток видео xvid (aspect_ratio_info). Но вот какая штука, старые плееры, работающие через DirectShow и декодер ffdshow и выводящие через Overlay (искл. VLC, KMP, но у них внутренние декодеры), не принимают флажки из xvid. Плееры же, выводящие через VMR7/9, принимают значение PAR из флажков через ffdshow (там галочку output:overlay_mixer (Set pixel aspect ratio in output media type) в “серое” среднее положение нужно поставить или полностью включить, а так же выключить (снять галочку) или в среднее положение (серая галочка) - output:Allow output format changes during playback).
Т.е., вот закодировал с флажками PAR в xvid: Insomnia_720x368 и для AVI1.0 (без OpenDML) это так. Но всё путём, когда есть PAR в AVI2.0 заголовке — 864x368. Чтобы получить такой avi, нужно его пересохранить (прогнать) через ”ffmpeg -vcodec copy”. Он прочтёт PAR из флажков xvid и пропишет его в заголовок avi (ещё говорят, что то же делает mencoder, но у меня никаких изменений после него). Последние опыты показывают, что, похоже, xvid прописывает PAR где-то ещё (читаем дальше, на этом этапе я ещё не знал, что виноват не xvid).
И если PAR был выставлен правильно при кодировании, то всё нормально получится. Но если был неправильный, как это было с двумя первыми моими анаморфными рипами: 1) Nausicaa_xvid_672x520_anamorf — указан как 66:65, т.е. 682x520 (66/65*672=682), а должно быть 239:168, т.е. 956x520 (и тут ошибочка, нацело не делится на 16, ниже разбор) ; 2) We_Were_Soldiers_xvid608x368_anamorf221x100 (тут та же ошибка), то, даже после выставления через MPEG4Modifier правильных флажков в xvid, остаётся в каком-то месте первоначальное значение (читаем дальше). И хоть ffmpeg в статистике показывает правильное значение PAR, после изменения в MPEG4Modifier, но вписывает в заголовок avi именно то самое первоначальное значение (как оказалось, вывод неверный — он просто не меняет его, если уже видит в заголовке, об этом читаем дальше).
Как это выяснилось? Тестом.
Test.avi: 720x368, PAR=60:45., т. е. с восстановленными пропорциями: 960x368.
Обозначим вывод через overlay (заголовок avi, OpenDML) = OVL, а через VMR7/9 (xvid PAR флажки,) = VMR.
Тогда плееры, что выводят в OVL: Crystal, BSPlay:OVL, LA, MPC:OVL.
Выводят в VMR: MPC:VMR, VLC:OVL (искл.), KMP:OVL(искл.).
Результаты: 1) xvidPAR (кодирование) → OVL:720x / VMR:960x; 2) ffmpeg -vcodec copy (копирование) → OVL:960x / VMR:960x; 3) MPEG4Modifier (просто уменьшил, т. е. изменил PAR) → OVL:960x / VMR:864x; 4) ffmpeg -vcodec copy (повторное копирование) → OVL:960x / VMR:864x (т.е. изменения во флажках он видит, но ставит из другого места с прежним PAR выставленном в xvid, или вообще не меняет, видя уже прописанное ранее значение). Приплыли, т.е. неправильно выставил PAR в xvid и в OVL уже не изменить (об этом далее).
27.07.09
Опыты с Навсикаей - неправильно закодированный PAR.
Nausicca_672x520_anamorph (неправильный xvidPAR = 66:65)
VOB:PAL=720x576 (16:9); 16/9=DAR=1.78; 576*16/9=1024 => 1024/720=h*DAR/w=PAR=1.4(2)
crop: w=16, h=32 => 704x544; resize: 672x520 672*PAR(1.42)=956!, а в MPC и Crystal выставив 16/9 получается неправильно: 520*DAR(16/9)=924 – точность потеряна из-за кропа.
Новый DAR=956/520=1.839 (239:130); PAR=956/672=1.4(2) (239:168; для 1024 => 256:180, 128:90, 64:45)
Далее про AC3 interleaving.
VDub standard 500ms / 1 frame
Но, нашёл на форуме упоминание про соответствие kbps / chanels / Preload (ms) / Interleaving (ms):
448/6/128/128; 384/6/160/160; 256/2/48/48;
224/2/64/64; 192/80/80
Кто-то пишет, что для PAL надо 2 кадра (1000/50=20ms), другие, что блоки AC3 идут по 32ms, и надо кратно ему, т.е. 64ms, 96ms.
Прогон через ffmpeg даёт 32/32ms (0.80 frame).
Т.е. можно исправить в Навсикае хотя бы xvidPAR (через MPEG4Modifier прямо с AC3 ?), а потом пропустить через ffmpeg, чтобы он сремуксил до 32/32ms.
31.07.09
Новые результаты.
1024/720=PAR(64:45)
Т. к. 672*PAR=955.7(3)=956 не делится нацело ни на 8, ни на 16, то выбрал ближайшее 960.
Ошибка меньше 0.5%, зато всё делится на 8 и почти всё на 16 (кроме 520): 960/672=PAR(10:7); 960/520=DAR(24:13).
Но это не главное - важно, что теперь найден путь исправления не только флажков xvid с ошибочным PAR (через MPEG4Modifier) но и, после этого, ещё и PAR в заголовке avi. Видимо, ffmpeg только один раз вносит эту запись, а потом, сколько не меняй флажки xvid, толку уже не будет.
А способ такой. После исправления флажков vxid и открываем промежуточный avi в AVIMuxGUI, далее нажимаем generate и, щёлкнув ПКМ по видеодорожке, выбираем extract binary (raw), чтобы получить голую дорожку с расширением raw. Вот теперь её пропускаем через "ffmpeg -vcodec copy" и получаем avi уже с правильным (новым) PAR во вновь созданном заголовке. Тоже может и mencoder, но он не прописывает для avi его разрешение и fourcc (вид кодека). Впрочем, и ffmpeg прописывает свой fourcc=FM4, который лучше заменить на "XVID"любой программой, умеющей это делать (Nic's FourCC changer, abcAVI). Теперь осталось прикрепить аудио и вуаля!
