LINUX.ORG.RU

mplayer, качественное воспроизведение видео


0

0

Если в mplayer смотреть видео с большим разрешением (например 1280хсколько-то-там) то заметно, что иногда словно содержимое окна не успевает перерисовываться. То есть выше какой-то линии уже новый кадр, а ниже - еще предыдущий. Таким образом, на сценах с быстрым движением изображение словно немного разрывается по горизонтали. Такое и с -vo xv и c -vo x11 и с -vo gl и c -vo gl2...
Да, это, конечно, мелочь и заметно только если смотреть внимательно, но, блин, неужели на intel core 2 duo и nvidia 8600 нельзя добиться качественного, "плавного" видео? Ладно, на моем предыдущем компе процессор мог не "вытягивать", но сейчас-то с чего? А то хотел понаслаждаться hdtv...
ЗЫ: В винде, кстати, такого нет. По крайней мере я не замечал.

Deleted

mplayer не использую, но может там есть чего нибудь типа --vsync ?

ip ★★★★
()

конфиги в студию - это раз,
man mplayer в зубы - это два...

после этого можно подумать об использовании -dr -double и -vo xvmc

для активации последнего параметра сходите в вики...

sda00 ★★★
()

Отключай всяческие Composite manager'ы. С ними sync to vblank не работает.

Эта мерзость называется tearing. Вызвана тем, что драйвер xv честно рисует кадр, вовремя, но с composite manager оно рисуется в буфер, а потом, с задержкой, на экран.

Для обычных окон делать sync to vblank никому в голову, кроме разработчиков beryl/compiz, вероятно, не пришло :(

Потом экспортируй переменную XV_SYNC_TO_VBLANK=1 и в путь

В google инфа по этой теме ищется по фразе linux video tearing

adarovsky ★★★★
()

Когда смотришь на проекторе, эта "мелочь" становится невыносимой... И сильно заметна становится другая гадость, по ключевым словам pulldown и telecine. Связана с тем, что вся техника работает на 59.94 fps, а видео-поток идёт в 23.97 fps. Равномерно на 30 или 60 кадров это не растягивается, и становятся заметны продёргивания сцены. Называется это judder. Пока лекарства против этой напасти под linux я не нашёл. В железныъ плеерах и маке её также нет. Виндузоиды пугали словами trimension, но показать не смогли. Всё равно дёргается, хоть и процессор жрёт :)

adarovsky ★★★★
()
Ответ на: комментарий от adarovsky

>В железныъ плеерах и маке её также нет

в смысле, лекарства нет, а дерготня есть. Не будет дёргаться только видео с 29.97fps.

adarovsky ★★★★
()
Ответ на: комментарий от adarovsky

Спасибо, попробую. Хотя сomposite extension действительно был включен в xorg.conf, но не использовался (то есть не было никаких композитных манагеров).

Deleted
()
Ответ на: комментарий от Deleted

тогда обращай внимание на всяческие vsync и прочая. В гугле есть ссылка на тред, где эту проблему решают. mplayer -benchmark должен рисовать 60fps. Если рисует сильно больше, значит, sync не включен. Если рисует 72fps, значит, включен, но работает криво :)

adarovsky ★★★★
()
Ответ на: комментарий от adarovsky

>> adarovsky

imho - вы много написали, но всё не по делу. наличие загруженного Composite Xorg Extension без активации собственно композитного менеджера (xcompmgr, compiz, и т.д.) вообще никаким боком к данному случаю. вам ясно написали, что это происходит и при выводе через OpenGL.

>> Потом экспортируй переменную XV_SYNC_TO_VBLANK=1 и в путь

в путь куда? imho - в man mplayer. опять же imho - первым делом надо включать двойную буферизацию (-double), не помогло -> добавить (-dr), опять не то -> собрать с xvmc и научиться с ней дружить при -vo xvmc, опять плохо -> собрать под машину из svn, и только потом, если всё осталось на "кругах своя" - прыгать с вертикальной синхронизацией. про особенности её при -vo gl* - дорога в ман.

>> Называется это judder. Пока лекарства против этой напасти под linux я не нашёл.

а в man mplayer не заглядывали? (-vf decimate, detc, ivtc, pullup и т.п.) есть комбинации с деинтерлейсингом.

также помогает тупой -framedrop, как это ни странно...

sda00 ★★★
()
Ответ на: комментарий от sda00

Кстати, ман mplayer я читал. Судя по нему vsync при xv и gl* включается по умолчанию. С -dr -double и -framedrop давно уже поигрался, никакой разницы, иначе бы здесь не спрашивал. И каким образом мне поможет xvmc, который умеет только mpeg1/2, а меня интересует в первую очередь h264 (который в .mkv обычно пихают)?
Помогло, кстати, снижение частоты обновления монитора с 60гц до 50, стало ощутимо лучше, но tearing до конца не исчез.

Deleted
()
Ответ на: комментарий от Deleted

mplayer собран из svn под конкретную машину, или пакет из дистрибутива? дрова на nvidia из дистра или .run с офсайта?

sda00 ★★★
()
Ответ на: комментарий от sda00

loopfilter - это же специфичная только для h264 и еще чего-то там опция
для других кодеков она роли не играет

Deleted
()
Ответ на: комментарий от sda00

>вам ясно написали, что это происходит и при выводе через OpenGL

а GL в этом случае разве напрямую рисует?

>в путь куда?

смотреть фильму :) Мне помогло отключение композитного менеждера и установка галочки "sync xvideo to vblank" для CRT моника (у меня twinview) в nvidia-settings.а

>в man mplayer не заглядывали? (-vf decimate, detc, ivtc, pullup и т.п.) есть комбинации с деинтерлейсингом

заглядывал, перед походом в гугль. Никакие фильтры не помогли. Всё равно дрожит. Не помог и плагин tvtime для xine, там тоже есть выравнивание 24fps материала...

>также помогает тупой -framedrop, как это ни странно...

А что нужно выбрасывать для варианта 24-30? И что тогда останется? :)

adarovsky ★★★★
()
Ответ на: комментарий от Deleted

>>а меня интересует в первую очередь h264

дык, барин, чего заказывали - то и принесли :).

ffmpeg -i film

mplayer -v film

на pastebin если не трудно. а лучше вырежи секунд 30 и в обменник

sda00 ★★★
()
Ответ на: комментарий от sda00

>также помогает тупой -framedrop, как это ни странно...

-framedrop (also see -hardframedrop)
              Skip displaying some frames to maintain A/V sync on slow systems.

Это вообще не в кассу имхо. Я тестировался на DVD и на HD rip 720p.
То есть, процессор не загружен совершенно. И -benchmark бегал как
ошпаренный, пока ему vblank не сказали

adarovsky ★★★★
()
Ответ на: комментарий от adarovsky

>> а GL в этом случае разве напрямую рисует?

imho и afaik - GL всегда рисует в "обход" в соответствии с настройкой драйвера (в данном случае - nvidia)

>> отключение композитного менеждера

Именно! Но никак не выкидывание Composite Xorg Extension

>> xine

"не делайте мне смешно..." (c)

>> А что нужно выбрасывать для варианта 24-30? И что тогда останется? :)

а вот теперь вопрос на "засыпку": какое отношение имеет частота вертикальной синхронизации Xorg-а к выводу fps на LCD (или например драйвером gl*)? Поскольку у вас CRT - то ответ очевиден кстати только на первый взгляд (вроде как разрыв между фреймбуфером и собсно выводом). Позвольте напомнить о тупом параметре -fps и предложить вашему вниманию не менее тупенький скриншот:

http://www.mediafire.com/?y3j9sewwsa9

я ещё раз подчеркну, что всё сказанное - сугубо моё imho. также подразумеваю вывод через DVI.

sda00 ★★★
()
Ответ на: комментарий от adarovsky

> mplayer -double Elive_Gem_1.0_divx_good-quality.avi -fps 75

Playing Elive_Gem_1.0_divx_good-quality.avi.
Cache fill: 16.08% (1646592 bytes)   
AVI file format detected.
[aviheader] Video stream found, -vid 0
[aviheader] Audio stream found, -aid 1
VIDEO:  [XVID]  512x384  24bpp  25.000 fps  1193.4 kbps (145.7 kbyte/s)
**************
FPS forced to be 75.000  (ftime: 0.013).
**************
VO: [xv] 512x384 => 512x384 Planar YV12
**************

ась?

sda00 ★★★
()
Ответ на: комментарий от sda00

>"не делайте мне смешно..." (c)

А что с ним не так? DVD меню понимает без приседаний, во всяком случае :) UI у kaffeine вообще рулит, понимает смену разрешения экрана и дружит с xinerama

>а вот теперь вопрос на "засыпку": какое отношение имеет частота вертикальной синхронизации Xorg-а к выводу fps на LCD (или например драйвером gl*)?

ну, если они совпадают, то tearing'а мы не будет наблюдать. Если отличаются, то tearing появится из-за рассинхронизации фреймбуффера и потрохов проектора

>Позвольте напомнить о тупом параметре -fps

он какой-то и правда странный. Во всяком случае, синхронизация со звуком сделала ручкой :)

>также подразумеваю вывод через DVI

tearing при включённом composite manager'е виден и на DVI, и на CRT. Принципиальной разницы я не заметил. Вообще, субъективно, DVI интереснее только тем, что не надо настраивать всякие overscan и прочую муть, всё и так кажет точно и красиво.

adarovsky ★★★★
()
Ответ на: комментарий от adarovsky

Кстати, пару недель назад приносили третью соньку, пробовал новомодный синий луч. Через HDMI есть tearing, а через аналоговый компонентный провод — нету. Заговор, не иначе ,)

adarovsky ★★★★
()
Ответ на: комментарий от adarovsky

>> А что с ним не так?

правда не смешно. продукт для быдломассы - лишь бы показывало. при уровне Master of the known universe настройки гуя ещё представляют какой-то академический интерес... для антропологии...

>> ну, ... из-за рассинхронизации фреймбуффера и потрохов проектора

у вас аналоговый проектор без цифрового входа? мои соболезнования... в противном случае даём на вход именно то, что оно хочет и наслаждаемся.

>> он какой-то и правда странный. Во всяком случае, синхронизация со звуком сделала ручкой :)

поэтому читать и перечитывать man перед сном

>> tearing при включённом composite manager'е

да забудьте вы про composite manager наконец. это совершенно другая технология отрисовки и вывода, которую на серьёзных пьянках никто не потребляет... (по крайней мере у меня нет такой информации).

давайте вернёмся к нашим баранам. фраза "в винде этого нет" сразу же указывает на отсутствие аппаратного декодирования контента видюхой. только VIA Unichrome аппаратно декодирует h264 в Linux. то есть надо садиться и не торопясь разбораться на пальцах.

теперь о Screen tearing: привязку к vblank за лекарство не считаю, поскольку надо находить именно "узкие места", что приводят к этому безобразию. суть его - это нарушение очереди фреймов при декодировании видео и последующие проблемы с аудио синхронизацией. как вы пишите, сонька схавала с аналоговый вход - нет ничего удивительного. уверен, что кто-то прокатился на качественном DAC конверторе, что в наше время - сплошь и рядом, а сонька тупенько подгребла вход под себя, ещё и в режиме чтоб не особо напрягаться. imho - ключевое звено здесь - это именно тот поток, по которому выстраивается синхронизация контента. от этого и надо плясать, а не упираться лбом в стену, которой давно уже нет.

автору - жду инфо как запрашивал и прогони с -nosound и потом смотри на -autosync помимо всего того, о чём я тут разорялся...

sda00 ★★★
()

Ой понаписали... домой приду, еще поэкспериментирую, если совсем лень не будет.

Deleted
()

-vo sdl уже советовали?

maloi ★★★★★
()
Ответ на: комментарий от adarovsky

>http://www.nvnews.net/vbulletin/showthread.php?t=85301

Протестил как там сказано.
mplayer -benchmark -vo gl2 и glxgears учитывают "sync to vblank" в nvidia-settings. Если включено - оба выдают 55fps (какого, кстати, фига? у меня ж 50гц стоит), иначе - наматывают бешеные цифры.
mplayer -benchmark -vo xv кладет на соответствующую настройку и всегда выдает 65fps (причем само изображение в плеере в это время похоже на слайдшоу). Хотя xvinfo показывает что XV_SYNC_TO_VBLANK действительно меняет свое значение.

Deleted
()
Ответ на: комментарий от Deleted

извини, но imho - ты делаешь не совсем то, что приведёт к победе. выложи плиз на pastebin

ffmpeg -i film
mplayer -v film
mplayer -nosound film
mplayer -vc help
mplayer -ac help

и было бы вообще супер если бы отрезал минуты две-три...

sda00 ★★★
()
Ответ на: комментарий от sda00

Мне этот метод помог. Но интересно посмотреть на другое решение проблемы. Если не трудно, чтобы ещё и judder победить :)

adarovsky ★★★★
()
Ответ на: комментарий от adarovsky

да, кстати: http://www.nvnews.net/vbulletin/showthread.php?t=97602

лучше таки выключить Composite Extension вообще, потому как драйвер, судя по всему, выключает sync to vblank, если видит это расширение:

This needs to get fixed in the composite manager. Syncing to vblank when drawing into an offscreen buffer makes no sense. (This is what the driver did at first and it caused even worse tearing).

попробуй убить расширение в xorg.conf. Мне помогло, и XVideo теперь не рвётся

adarovsky ★★★★
()
Ответ на: комментарий от sda00

>как вы пишите, сонька схавала с аналоговый вход

не, я писал про PS3 + проектор. С HDMI есть tearing, а с композитным аналоговым соединением — нет. Это просто для примера, что и в понтовых железяках не всё шоколад

adarovsky ★★★★
()
Ответ на: комментарий от KRoN73

>>>включать двойную буферизацию (-double)

>>Судя по ману оно работает только с -vo svga, directfb или dfbmga.

imho - оно работает со всеми -vo, которые это могут поддержать (включая gl* и macosx). функция именно в мане очень слабо документирована, подразумевается, что её использование не очень-то и нужно. могу соврать, но видел куски кода по включению тройной буферизации. поскольку проблем с mplayer-ом не имею - то не следил за их "судьбой".

>> не, я писал про PS3 + проектор. С HDMI есть tearing, а с композитным аналоговым соединением — нет. Это просто для примера, что и в понтовых железяках не всё шоколад

извините за недопонимание, но смысл моего ответа при этом не меняется. либо дерьмовый DAC у соньки, либо у проектора, либо, что более вероятно, у обоих.

sda00 ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.