Статья о развитии X Window System

Размер - видеопоток с экрана :) Тупо дамп экрана, 1280 x 1024

Все iptv и прочие бантики - уже внутри потока, на экране

Ах просто поток с экрана? Это doable (хотя и кошмарно по нагрузке на сетку) - до тех пор, пока Вы не захотите интерактивности. В игрушки, например, поиграть.

В любом случае - это уже НЕ иксы, по сути;)

А, ну да, по обратной связи лаги начнутся :) Но ничего, мы сеточку еще пожирнее заведем. Асимметричную, гигабит сюда - сотка отсюда :)

> В любом случае - это уже НЕ иксы, по сути;)

Дык! Зато народ - счастлив :)

> как жестко синхронизировать вывод звука при открытии окна?

Легко. На звуковой сервер предварительно загружается сэмпл, который надо будет сыграть в случае необходимости. А window manager когда ловит событие открытия окна, отправляет на звуковой сервер одну команду "играть вот этот сэмпл". Тепрь иди проверяй.

> Нормально они работают локально. На удаленных иксах Вы их видели?

Ты не поверишь - но я на удаленных иксах в кваку (OpenGL-ную) играл и телевизор смотрел. Со звуком. :-)

>покажи мне способ, как из своей программы я могу покрасить заданную область экрана в некий цвет. Или как мне скопировать содержимое одной области видеопамяти в другую (для скроллинга).

тебе почитать вслух API по fb/DirectFB?

Кого интересует счастье народа? Стройность архитектуры - вот что важно!;)

Абалдеть! Можно подробнее - что за сетка, какие компы, видяхи и пр? И как звук передавался?

В общем в результате дискуссии было выяснено, что тру юникс вей - отсутствие звука и/или гимор в настройке :) Аргументация была проста, но изящна - нельзя допускать появление целостного унитаза, ибо технология утилизации отходов юниксовых гуру будет тем самым разрушена.

А если говорить серьёзно, то почему нельзя взять этот самый nas, esd, arts и прочие костыли, интегрировать всё это дело в некий extension к XOrg (которых и без того немало)? Тем самым можно было бы добиться желаемого результата по перенаправлению звука через DISPLAY, не затронув религиозные чувства пользователей звуковых приложений в консоли.

> Можно подробнее - что за сетка, какие компы, видяхи и пр?

В общем дело было так.

Задача 1: запустить Quake2, c рендерингом посредством OpenGL.

Начальные условия - ноутбук с I830GM на борту (это где квака запускается) и Celeron 2400 с NVidia GForce 5200 - это "боевой комп", за которым сижу я и на котором квака рисует. Сетка между ними 100 мегабит (реально использовалось примерно 30), разрешение кваки 640x480. В общем играбельно.

Задача 2: посмотреть телевизер на ноутбуке (тот же самый ноут). TV-тюнер на стационарном компе. На ноутбуке поднимается arts, на стационарном говорится "mplayer -ao arts -vo xv -tv immediatemode=0:<и_еще_много_опций>. В общем-то все показывается нормально до размера картинки 512x384 (изначальный формат телесигнала). В принципе, на 640x480 тоже вполне нормально, если картинка не бешено мелькает (судя пор всему, XV гонит только "дельту" картинки).

> Стройность архитектуры - вот что важно!;)

Именно! Лучше идти на двух ногах, чем бежать на одной руке, одной ноге и трех костылях :-)

Дело не в том, можно или нельзя сделать extension. А в том, что это будет realtime extension к протоколу, который по сути своей не realtime-овый. Пока условия "хорошие" (локальные иксы или сетка быстрая) - все будет хорошо. В случае медленной сетки (ну или высокой загрузки проца) начнутся проблемы с синхронизацией.

Лучше - сидеть. А еще лучше - лежать;)

Ну тады понятно. Быстрая сетка и захват большей части канала. Интересно, кроме Вас кто-нибудь в это время по сети мог что-то передавать?;)

> это будет realtime extension к протоколу, который по сути своей не realtime-овый. Пока условия "хорошие" (локальные иксы или сетка быстрая) - все будет хорошо. В случае медленной сетки (ну или высокой загрузки проца) начнутся проблемы с синхронизацией.

Начнутся, конечно - ну и что? Если API этого расширения будет возвращать соответствующие коды ошибок/предупреждений, то всё нормально.

Дык в том-то и дело - не будет. Потому что нет способа детекции.

>> Стройность архитектуры - вот что важно!;)

> Именно! Лучше идти на двух ногах, чем бежать на одной руке, одной ноге и трех костылях :-)

Собственно, если прикинуть во что выльется стоит сеточка для массового гоняния по ей дампов изображения и звука, то может народ и сам расхочет такое счастье? :) Такое счастье как бульканье в колонках на сворачивание окошка, ради которого нужна реальная такая сеточка :)

> Дык в том-то и дело - не будет. Потому что нет способа детекции.

А можно подробнее - почему не будет? Гипотетическое расширение Xorg будет знать, когда команда на отрисовку выполнилась. Если звуковой сервер сообщает о том, когда выполнилась команда на воспроизведение, то всё можно отследить (по крайней мере, для случая, когда видео и аудио воспроизводится на одной машине). Я что-то упустил?

"Звуковой сервер сообщает о том, когда выполнилась команда на воспроизведение" - а синхронизацию часов на системах - до миллисекунд - кто-нибудь гарантирует? Или время от время будем передавать сигналы синхронизации (heartbeat) - и все времена отсчитывать от них?

В общем, пожалуй, да, технологически можно навесить на иксовый протокол кучу рюшечек и сделать практически рилтаймовое расширение. А может, не выпендриваться, и оставить иксовый протокол в покое? Из иксов можно вытащить информацию о том, где находится терминал (хост, порт для звукового сервера) - а дальше использовать нормальные существующие звуковые протоколы (которые вообще лучше работают не на TCP, а на UDP) - типа RTSP?

>> покажи мне способ, как из своей программы я могу покрасить заданную область экрана в некий цвет. Или как мне скопировать содержимое одной области видеопамяти в другую (для скроллинга).

> тебе почитать вслух API по fb/DirectFB?

Ссылка меня вполне устроит (DirectFB не надо). Потому что в исходниках драйверов fb я лично не наблюдаю такого API (именно для ускоренных видеоадаптером операций, а не для mmap).

Вместо ссылки можно указать имя файла в /usr/src/linux/drivers/video и имя функции внутри этого файла.

> "Звуковой сервер сообщает о том, когда выполнилась команда на воспроизведение" - а синхронизацию часов на системах - до миллисекунд - кто-нибудь гарантирует?

В случае нахождения аудио и видео на одной системе - да. Если на разных - NTP (по обещаниям - синхронизация с точностью до нескольких миллисекунд).

> Или время от время будем передавать сигналы синхронизации (heartbeat) - и все времена отсчитывать от них?

Нет - это тупик.

> А может, не выпендриваться, и оставить иксовый протокол в покое? Из иксов можно вытащить информацию о том, где находится терминал (хост, порт для звукового сервера) - а дальше использовать нормальные существующие звуковые протоколы

Насколько я понимаю, X-сервер никак не сообщает о завершении операции отрисовки, так что какие-то расширения делать придется (если вообще браться за решение задачи синхронизированного воспроизведения аудио и видео в сети).

Ну здоровско. Теперь мы еще будем ставить NTP жестким требованием (неужто миллисекунды гарантирует?)

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

Вообще, неплохо-бы определится с задачей. Бульк на сворачивание окна - это одно, видеопоток со звуком - это другое, интерактивная программа (например игра) - это третье.

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

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

> Теперь мы еще будем ставить NTP жестким требованием

Для экзотической задачи (видео и аудио на разных машинах) - почему нет? У меня и без этого запущен NTP :)

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

ИМХО, "всё" - это какой-то способ извещения клиента о завершении отрисовки.

>Ссылка меня вполне устроит (DirectFB не надо).

Тебе шашешки или ехать? Ну "не надо" так "не надо":)

Кстати, гаткая Убунта напрочь игнорирует установку NTP сервера, выдаваемую ей по DHCP.

> видео и аудио на разных машинах

Видео и аудио на одной, приложение и вывод - на разных?

> По второму - есть вопросы об оптимальности с т.зр. трафика.

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

Трафик-то будет. Хочется наилучшего возможного решения, учитывающего интересы всех сторон. Чтобы другие люди тоже могли пользовать сеть. Чтобы выкидывание кадров и кусков звука было максимально незаметным (а не большими кусками).

>> видео и аудио на разных машинах

>Видео и аудио на одной, приложение и вывод - на разных?

Синхронизировать нужно видео- и аудиопоток, поэтому только относящиеся к ним события должны иметь совпадающую шкалу времени. И время должно течь с одинаковой скоростью везде :)

Наверно это вопрос организации контейнера?

И актуально это, наверно, будет не часто. Разве, когда на тонком клиенте кино будут смотреть.

> Тебе шашешки или ехать? Ну "не надо" так "не надо":)

Слив засчитан? Или таки будет ссылка на аппаратно ускоренный API для fb?

> Быстрая сетка и захват большей части канала.

Ну - далеко не большей. Самба смело съедает 70..80 мегабит - и поверьте, сеть не умирает. Так что от 30 мегабит уж точно никто не загнется.

>Слив засчитан? Или таки будет ссылка на аппаратно ускоренный API для fb?

http://directfb.org/

Разумеется, контейнер тут решает очень многое. А также кодек и пр.

Кстати, почему именно на тонком клиенте? На любом клиенте, самом толстом, канала не резиновый (а народу в сетке обычно >1).

Ок, не большей. Существенной. А 30 мегабит _на_клиента_ - сетка тут же загнется, если в ней клиентов будет несколько человек.

Соббсно, это даже не важно. Спор о числах - вторичен. Основной пойнт - система должна выдавать наилучший возможный результат даже в условиях недостаточного диаметра трубы.