[AlexB17]

Всётаки размеры должны быть кратны 16(минимум 8 но тоже не рекомендую) что бы не было у кодека заморочек. Да и первый проход напрасно полный делаешь - толку мизер а времени убивается уйма.

2 GreatWizard
У меня тоже в потоке как то странно прописывается - видео как бы сплющивается по вертикали в 2 раза. Для PAR никакой формулы грубо говоря не нужно - даже при обрезке если PAR 2.35:1 он такой же и останется. Прописывал в mkvtoolnix'e именно Aspect ratio а не Display W/H - все работает через все плееры - я думаю за это матрешкинский сплиттер отвечает а не декодер и плеер, попробуй обнови его - он недавно свежий выходил 1.6.60.23(у меня по крайней мере).

[SergeyNew]

AlexB17

сейчас хорошо помогает параметр --no-fast-pskip

<no-fast-pskip name="Fast P-frame Skip Detection">
<Advanced>Fast Skip detection increases speed but may cause slight blockiness in areas of solid colour or slight gradients such as dark scenes or sky.</Advanced>
<Basic>Enables early Skip detection on P-frames.</Basic>
<Recommended>Disabled</Recommended>
<Default>Enabled</Default>

2 AlexB17
Прочитал я про этот "фаст скип" и понял, что это как-раз то, что мне надо. Только маленькая проблема, как его отключить? Может подскажешь, а то я не силен...

[GreatWizard]

AlexB17

У меня тоже в потоке как то странно прописывается - видео как бы сплющивается по вертикали в 2 раза.

В tcpmp во всех случаях кроме mkv c прописанным AR, в режиме пропорций авто, тоже сплюшивает где-то в 2 раза...

Для PAR никакой формулы грубо говоря не нужно - даже при обрезке если PAR 2.35:1 он такой же и останется.

dar = par x sar
where
dar : display aspect ratio (what ratio to be displayed)
sar : stream/sample aspect ratio (the original/non-cropped aspect ratio of the stream)
par : pixel aspect ratio
note, these all are given if your source can be played correctly !
отсюда

Прописывал в mkvtoolnix'e именно Aspect ratio а не Display W/H - все работает через все плееры - я думаю за это матрешкинский сплиттер отвечает а не декодер и плеер, попробуй обнови его - он недавно свежий выходил 1.6.60.23(у меня по крайней мере).

Обновил до 1.6.60.23, ситуация с DS плеерами не изменилась

[RBF]

GreatWizard
PAR(SAR) высчитывается путем деления DAR на FAR.
DAR - это аспект с которым должна показываться картинка.
FAR - это реальное соотношение сторон картинки.
DS coreAVC нормально не поддерживает PAR. Он пока только может пропускать через себя инфу о PAR взаимодействуя с haali сплиттером, а декодер должен передавать в рендерер инфу о PAR независимо от сплиттера, потому что она содержится не в контейнере, а в самом потоке.
Mkvtoolnix вообще удаляет PAR из потока, что крайне не рекомендуется.
Правильно посчитай PAR, сохрани в mp4, и проверь поставлена ли при воспроизведении в настройках рендерера галгка "соблюдать аспект".

[GreatWizard]

RBF

PAR(SAR) высчитывается путем деления DAR на FAR.

http://trac.videolan.org/x264/file/trunk/doc/vui.txt - тут тоже самое по сути ?
-----------
Цепь была такая:
http://img401.imageshack.us/my.php?i...64chain6jv.jpg
Video Renderer у меня такой без настроек... Есть более совершенный ?
http://img401.imageshack.us/my.php?image=vrprop6so.jpg
ffdshow выбил из цепи отключением поддержи YV12 YUY RAW форматов...
Все получилось!!! Осталось только PAR переправить, есть способ не перекодируя? mp4box'om ?
----
А где можно взять др. декодеры RAW форматов типа i420.... вроде где-то одним архивом ложили?
Большое спасибо RBF ! И AlexB17 за поддержку...

[RBF]

-------

[RBF]

GreatWizard
Да там тоже самое, но считают сами цифры, а не соотношение.
DAR_x*FAR_y=SAR_x и DAR_y*FAR_x=SAR_y
У тебя старый рендер используется, с ним каши не сваришь У тебя что DX9 не установлен? Хотя нет, в графе то нормальный рендер стоит. Тогда кто же цепляет старье, уж не LightAlloy ли?
Поменять боксом PAR можно так:

mp4box -add C:\FILM.mp4:par=115:100 C:\FILM_2.mp4

Декодеры YV12/i420 нужны только для VfW. DirectShow 9 поддерживает их напрямую.
http://rbf.nm.ru/Yv12_I420_yuvcodecs-1.2.exe

[AlexB17]

2 SergeyNew
Fast P Skip этой строкой и отключается (--no-fast-pskip) или анологичной галочкой в свежих версиях MeGUI.

2 RBF & Great Wizard
Я в принципе видел эти формулы для расчётов AR но т.к. кодирую только фильмы и TV то для меня это не особо актуально, в фильмах AR жестко прописан, скажем 2.35:1 или 16:9 соответственно картинка растягивается под эти значения - а для TV это вообще не нужно. Или может мне пока просто фильмы не попадались с кривым AR? Я пока с анаморфным кодированием сделал только 2 фильма и везде они правильно показываются - даже через TCPMP и CoreAVC не говоря уж про MPC и BSPlayer через ffdshow. Может я что-то делаю не так?

[Force]

А почему вам так не нравится AQ? Я помимо --no-fast-pskip ещё и его использую, и всё становится ещё лучше. Главное значения подобрать неагрессивные.

А по поводу Fast First Pass - не согласен. Как то решил добиться офигительного качества при минимальном битрейте - 300. Сначала использовал быстрый первый проход. После первого сделал ещё 5 проходов с максимальнейшими настройками (esa 32 и всё такое), но это не дало такого офигенного результата, как просто 2 прохода esa 32. Так что это вы зря по поводу того, что качество не сильно меняется...

Может быть, конечно, мой случай слишком частный, но тем не менее, результаты не врут.

[RBF]

AlexB17

в фильмах AR жестко прописан, скажем 2.35:1 или 16:9 соответственно...

На ДВД не бывает прописано 2.35:1, только 4:3 или 16:9. Да и жестко это будет только если не обрезать черные полосы, а кодировать как есть (720х576 или 720х480). Если же обрезать, то тут может быть все, что угодно.
При захвате с TV, тоже аспект не нужен, только если хватать 768х576. А если хватать с родныи разрешением чипа, например 704х576 у филипса, то без аспекта не обойтись.

Может я что-то делаю не так?

Конечно не так , ты наверно пишешь аспект в матрешке, а мы говорим про прописывание его в самом битстриме, как по стандарту положено.