Xineliboutput - VDR xine-lib output device

Цитата

Со слов пользователя free-x
это в каких школах такому учат под rootом системой пользоваться? ?.

Это ко мне вопрос? Если да - как-то исторически сложилось
Надо ж показать кто в доме хозяин

Я разобрался, почему xineliboutput тормозит и БУДЕТ тормозить по сравнению со связкой vdr-xine. Можно удалить файл config_xineliboutput и ничего не изменится. Так же будет работать, но тормозить. Значит, этот файл создаётся при необходимости и читается изредка. По сути он и не нужен, если в нём нет ничего полезного или, не дай бог, он противоречащие настройки вызовет.
Но в чём же тогда причина тормозов?
А причина в том, что xineliboutput, сам по себе, не умеет использовать из OSD все необходимые настройки xine. Другими словами, то, что умеет xineliboutput не умеет vdr-xine и наоборот. Комбинация их настроек даёт наилучший результат использования настроек xine.

Предлагаю запускать его просто, как -P'xineliboutput', без всяких опций.
Все полезные настройки будут храниться в двух файлах, что в прицепе.

В принципе, неплохой результат. Осталость с регулировками чёткости раобраться.

Пожалуйста зарегистрируйся для просмотра данного изображения.

Именно с указанными в этих конфигах настройками всё замечательно работает.

Цитата

ты сам эти комментарии убрал ?

Конечно, всё лишнее СПЕЦИАЛЬНО просто убрал и оставил принципиально важное (там же комментарий сверху). Это и есть четыре строчки config_xineliboutput, благотворно влияющие на скорость декодирования. Остальное можно добавлять по желанию.

Цитата

какие конкрентно настройки из ОСД/setup.conf он реально не использует ?

Я не сказал, что не используются некие настройки в setup.conf, который юзает плагин xineliboutput, а говорю, что плагин xineliboutput, не умеет использовать из OSD все необходимые настройки xine. Их значительно больше, чем доступно из OSD плагина и содержимого этих нужных 4 строчек в OSD плагина просто нет. А почему бы и не вывести?

А не передашь на vdr листе слёзную просьбу добавить масштабирование по образу и подобию vdr-xine?
Там это называется "4:3 скалирование" и "16:9 скалирование". Осуществляется раздельно мелкими шагами по X и Y без заметной потери чёткости.
Может, автор xineliboutput проникнется пониманием, что оверскан весьма распространённое явление. А так, как сейчас сделано масштабирование, это сильно отнимает ресурсы CPU и не позволяет точно вписать картинку в экран. Заточено-то всё в xineliboutput под обычный 4:3 телевизор для приёма SDTV. В данный момент функция "масштабировать с потерей качества" абсолютно точно передаёт ситуацию.
Дёргает картинку сильнее, чем vdr-xine, как ни крути настройки. Юзал 1.0.9-CVS на разных дистрах.
Посему остаюсь на vdr-xine. Оно хоть и не развивается, но мне ближе.

Без вспышки, как видишь, сегодня не получается: Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу.
Так что, без неё придётся... Но это не надо им показывать.

В качестве примера можно показать, что при использовании плагина vdr-xine имеется возможность регулировать размеры независимо по X и Y, как на фото: Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу.
Изменение размера происходит сразу же после изменения парамтра в OSD.

На фото Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу. показан плагин xineliboutput с настройками для устранения оверскана в моём случае. Это испытательная таблица, но фактически надо чуть увеличить размеры из-за нестандартности контента у провайдеров. К сожалению, это может и не получиться.
Можно регулировать размеры изображения, но... только с калькулятором в руках.
На фото видно, что установленное соотношение Y/X равно 16:9. Но фактически, это отношение может и не соответствовать 16:9 если мы изменяем только один размер X или Y.
Другими словами, изменение только одного размера, приводит к общему изменению диагонали изображения. Это не правильно. Уловить смысл этих настроек очень сложно и поэтому приходится применять экспериментальный метод.

Иллюстрация того, что написано выше.
Попробуем изменить только один размер. При сохранении и даже при последующем новом запуске vdr размеры изображения не меняются: Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу.
Это снова не правильно!

Некоторые другие недостатки:

1. Зелёная полоска.
Через 1 шаг (в настройках X или Y) появляется зелёная окантовка изображения в виде тонкой линии (особенно справа). Таким образом, нужно настроить так, чтобы зелёной полоски не было видно.

2. Неудобство настройки.
Изменение размеров не происходит сразу после изменения высоты и ширины, что затрудняет настройку.

3. Скалирование вниз и ухудшение чёткости.
Хотелось бы узнать у автора, чем отличается механизм скалирования xineliboutput от vdr-xine, если библиотека xine-lib одна и та же?

4. Опция Allow Downscaling.
Параметр Allow Downscaling не будет работать отдельно, если выключить change video size. Может быть лучше, чтобы он вообще пропадал при выключенном параметре change video size?

5. Несколько более неравномерная передача движения.
Не удаётся подобрать такую комбинацию параметров в config-xineliboutput, чтобы при равной загрузке CPU была такая же плавность движения на одном и том же HD канале, как в случае использования vdr-xine.

Особенно не торопись писать в vdr лист, не горит. А то предвкушаю вопрос, понял ли я сам, что написал.

А.. Вот ещё... Лого и no signal поменять бы на что-то более достойное.

Цитата

именно эту фичу - для 4:3 и для 16:9 ты и хочешь видеть

Нет, переключение формата в xineliboutput автоматическое (если установить это).

Цитата

так меняются размеры или нет

Да, меняются, но абсолютно невменяемо. Я подогнал размеры, но эта методика никуда не годится.

Цитата

не вижу никаой зеленой окантовки

Вероятно, ты не пробовал масштабировать. Только там это проявляется. Представь, что у тебя есть необходимость уменьшить размеры изображения примерно на 10% и сразу видно будет о чём речь.
Я прошу тебя уделить часок (когда будет время), повозиться с масштабированием в xineliboutput, будто стоит задача пропорционально уменьшить картинку на мониторе. Не думаю, что это доставит удовольствие, но во всяком случае, станет всё ясно.
Остальное пока оставим. Действительно не горит.

Можно сделать проще: подкидывать простые вопросы автору.
Например, может ли он сделать масштабирование так, как это сделано в vdr-xine. Это же простой вопрос.
Если он скажет, что не понимает зачем, то просто попросить его объяснить, как он сам делает масштабирование. Мол, не понимаем алгоритм действий.

Я имел в виду формат экрана 4:3 или 16:9. Это изменение при переключении с канала 4:3 на канал 16:9 происходит в xineliboutput автоматически, если в OSD этого плагина включить соотв. опцию.
Эта функция меня вполне устраивает. Тут менять ничего не надо, а надо чтобы изменение размера работало более просто (как в vdr-xine) и была видна реакция сразу после нажатия клавиши на пульте.

Я предлагаю продолжить эту тему позже, когда у тебя найдётся свободное время.

Просто хочу пояснить по поводу оверскана и возможности его устранения.

Масштабирование xineliboutput можно увидеть на HDMI, но на мониторе по VGA нельзя. Видимо поэтому, многие, не имеющие панели по HDMI и не подозревают о проблеме масштабирования и меня просто не понимают.

Да, xineliboutput становится всё лучше. Если в xineliboutput выключить скалирование, чтобы запретить масштабирование, то вообще никаких проблем нет!
НО... если включить скалирование и изменение размеров экрана, то изображение дёргается реально больше, чем в vdr-xine, в результате своеобразного программного пересчёта размеров. Загрузка CPU по сути та же, но что-то глючит и рвёт картинку. Именно поэтому я говорю, что xineliboutput "хуже", чем vdr-xine.

Многие программы имеют встроенное масштабирование. Например, MythTV. Наверное, неспроста. Но правильно ли это? А что если вообще отказаться от масштабирования силами плагинов или самих программ?
Так вот, не всё так просто. Огромное количество юзеров видеокарт имеет проблему оверскана по HDMI на самых разнообразных панелях. Даже приводится мнение, что это вообще нормально. Ага...
Ещё бы сказали, что это очень красиво смотрится.
В качестве иллюстрации: Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу.
Читать замучаешься...

Кстати, вот что думает по этому поводу nVIDIA: Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу.

Если ничего не предпринимать, то изображение по HDMI больше, чем экран панели. Оверскан:
Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу.
На снимке видно, что граница экрана попала почти по реперным точкам.

Убираю оверскан:
Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу.
С такими настройками в xineliboutput:
Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу.

Настройки масштабирования должны быть понятны. Например, изменил на единичку ширину или высоту - немедленно получил соотв. результат.
А сейчас при изменении только высоты или только ширины меняется вся диагональ. Причём меняется, слишком крупными и непредсказуемыми шагами. На единичку изменения размера ничего не происходит.

Я экспериментально менял высоту, каждый раз вычисляя ширину из отношения 9/16. Если потом произвольно менять только ширину, то изменение диагонали может вообще не произойти. Сколько единиц менять в значении размера - не выяснил.

Образно говоря, сейчас настройка масштабирования сродни полёту на самолёте с отказавшей гидравликой. Мне его посадить удалось, но удовольствия не доставило.

Поэтому было бы проще узнать у автора.
1. Как сам автор плагина пользуется масштабированием по HDMI.
2. Почему при использовании масштабирования и той же загрузке CPU (с большим запасом) теряется плавность движения картинки.

ты пробовал запустить xineliboutput с опцией -hud ?

Нет ещё. А что, решает проблему?
Мне казалось, там тема о масштабировании OSD, а не самого видео. Может, не прав. Но на вскидку, есть некоторые противоречия в тексте, касающиеся плавности видео:

Экранное меню масштабируется и смешивается аппаратно, поэтому не подгружает CPU сверх того, что требуется для видео.

Это вселяет надежду, что тормоза исчезнут.

Требования:
 - X-сервер с расширениями Composite и Xrender. Composite должен быть включен в конфигурации Xorg.

Блин, я выключил строку про Composite в xorg, чтобы глюков не было. Иначе, переключение каналов сопровождается эффектом "фэйд-ин, фэйд-аут". Оно красиво, конечно, но нужно для компиза и не более. Может, тогда просто не ставить компиз?

ПРИМЕЧАНИЕ:
     - Отрисовка видео (даже без OSD) может быть медленнее, когда композитное расширение включено.

Вот те раз... Выше было написано, что меньше грузит. Ну, так поэтому я и выключил composite.

- Попробуйте настроить размер OSD и смещение, чтобы избавиться от возможных графических ошибок видеовывода.
 - Для настоящего HD разрешения OSD программа VDR должна быть патченной.

А что, разве ошибки видеовывода как-то связаны с OSD? Пока без true color обойдусь. А так, интересно. Обязательно попробуем.