Уже в пути

svn co svn://svn.mplayerhq.hu/soc/wmapro/

Играет потихоньку.

Очень кстати, с учётом удаления win32codecs. (в wmv3/wmapro изредка, но попадаются документальные фильмы).

http://multimedia.cx/eggs/got-a-cheap-mips-subnotebook/#more-839 А это кажется её процессор/чипсет http://www.rockbox.org/twiki/bin/view/Main/IngenicJz47xx

Забавная машинка.

А также в ядро включили-таки squashfs. Одним патчем меньше. 3 hours ago Linus Torvalds Merge git://git./linux/kernel/git/pkl/squashfs-linus

Навеяно http://www.haiku-os.org/blog/mmu_man/2008-11-03/say_what_you_want_from_us_but...

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

Решил вот поделится своим мнением по поводу открытых архитектур. Я не обладаю достаточными знаниями чтобы утверждать чем MIPS, ARM, SH4 (используемые во многих устройствах бытовой электроники) лучше один другого. Но я могу судить с точки зрения продвинутого пользователя, который не чурается заглядывать в исходники, но при этом желает иметь систему чуть быстрее чем z80.

Ассоциация с z80 не случайна - даже этот крайне маломощный (8 бит регистры и шина данных, 7Mhz тактовая - максимальная скорость переброски данных в районе 1 Мегабайта в секунду, меньше миллиона операций в секунду) процессор был достаточным для однозадачного пргограммирования многих довольно ресурсоёмких задач, и моё первое знакомство с причудами схемотехники и понятием "архитектура компьютера" пришло именно со знакомства с разными русскими Спектрум-ориентированными сайтами в районе 2000-го года.

[link block 0 http://zx.pk.ru/ "Спринтер" и всё такое. ]

Именно тогда я узнал про кульный компьютер Amiga и его подход к мультимедиа (графика высокого разрешения, цифровой звук, видео) как к спец-задачам, лучше всего выполянемым спец-процессорами. Намного позже я узнал некоторые подробности про высокопроизводительные рабочие станции SGI. Используя очень умно запрограммированные спец-контроллеры для повторяющихся вычислений 3D-графики на разных этапах построения картинки + специализированное железо для перевода векторного представления графики в растровое первые графические терминалы SGI показывали крайне интересные результаты на очень маломощном по сегодняшним меркам процессоре. Но наверное самое главное - в поисках информации о работе этих древних по нынешним меркам машин я нашел большое количество информации по теории работы с 3-d графикой на _не очень сложных_ примерах, и самое важное - как это сделано в железе. То есть - более всестороннее и глубокое понимание того, как это делается. Вообще, понимание того как работает информационная машина (компьютер), умение модифицировать его поведение, то есть умение быть когда надо чуть-чуть программистом я считаю важнейшм преимуществом пользователя открытых опереационных систем. А воспитание и "разгон" (к вершинам знаний) такого пользователя - важной задачей ПО с открытми исходниками и лицензиями. К сожалению, когда радость творчества перерастает в рутину (нет дров на контроллер винчестера, нет дров на контроллер USB, нет дров на контроллер сетевой карты, нет дров на .... ) у многих хороших программистов опускаются руки. Вот чтобы такое не происходило и важны открытые спецификации на железо. (плюс разумеется умение и желание работать сообща, иногда талантливые разработчики ведут себя не очень честно и проталкивают собственное решение проблем технических с помощью социального давления. Пример есть в листе v4l , не говоря уже про тоже имеющюй отношение к личности разработчика пример с Гансом Рейзером).

[ link blok 1 http://www.futuretech.blinkenlights.nl/o2/ http://www.futuretech.blinkenlights.nl/iris-faq.html http://www.archive.org/details/Computer1984_6

В Гугле например находится статья "The Geometry Engine: A VLSI Geometry System for Graphics", с картинками и пояснениями (англ, естественно) Было очень познавательно. ]

К сожалнию или к счастью, сегодня на дворе самый конец (окнец? намёк на вездесущие пока винды ....) 2008-го года, и просто красивой 3d-картинкой или _цифровым_ звуком никого не удивишь. Огромные потоки цифровой информации генерируются самим домашним пользователем, и он желает чтобы компютер на его столе был не просто игрушкой для программирования самого себя, но и помогал в обработке этой цифровой информации. И тут спектрум-подобные машины к примеру просто остаются за бортом, потому что даже с использованием всех возможных ухищрений объёмы информации измеряемые в мегабайтах в секунду, с жестким условием реалтайм-отображения им просто не по зубам. Картинка размером 1024*768*24 бит - мой рабочий монитор сейчас - занимает больше двух мегабайт в памяти. С учетом того что таких и даже бОльших картинок обычно не одна, а к примеру 4 (четыре рабочих стола в E16 - очень удобно), то объем необходимой оперативной памяти автоматически устремляется в самом идеальном случае к десяткам мегабайт. Необходимость совершать какие-то действия над подобными картинками приводит к необходимости очень высокого быстродействия памяти, шины данных, процессора. (что получается когда шина становится бутылочным горлышком - можно наблюдать на примере открытого смартфона Neo FreeRunner и его видеоподсистемы, где экран 640*480*16 бит подсоединен к видеоакселератору, который черпает данные из памяти через канал шириной меньше чем ISA-шина. 8 мегабайт в секунду, примерно. Подробности в листе рассылки OpenMoko. Или нечто аналогичное для шины Zorro II на Амиге, про которую я узнал из линксового драйвера для фреймбуфера, drivers/video/fm2fb.c) А это - усложнение схемотехники за пределы доступного обычному юзеру с паяльником. Слишком высокие частоты, слишком большое количество проводников. Нет, продвинутый пользователь, кто на работе имеет дело с подобными высоокочастотыми устройствами может и в домашних условиях нарисовать платку, способную работать, и даже стабльно. Но пока такое умение довольно редкое. А значит, железо по-любому будет производить кто-то другой, пользователь же должен просто иметь возможность собрать из блоков то что ему нужно (для экспериментов, удовольствия, или помощи в работе) и запрограммировать получившийся агрегат в меру своих умений (а это обычно для сложных много(суб)процессорных машин выливается в использование идей, алгоритмов и кода других разработчиков - иначе просто не получается.)

Мне кажется, архитектура графстанции начального уровня SGI O2 очень хорошо отражает идею использования дополнительного программируемого элемента (Image Co-Processor), выделенного для быстрой переброски графических и видео данных, с конвертацией на лету по фиксированным (YUV <-> RGB) и/или по загружаемым алгоритмам. Оригинальное (и к сожалению - проприетарное, закрытое и фактически утерянное для масс) программное обеспечениие в составе ОС Irix использовало данный сопроцессор для декодирования сжатых видео потоков, работы с изображениями, OpenGL. На данный момент существует только крайне экспериментальный и заброшенный драйвер для этого сопроцессора, вместе с очень сырым патчем к старым binutils для использования в качестве именно _программируемого_ элемента. Не говоря уже про систему _отображения_, дисплейный контроллер, знания о работе и программировании которого (необходимо для работы Xfree/Xorg с современными библиотеками GUI поверх с приемлимой скоростью) появились в открытом доступе только в этом году, благодаря старанию разработчика из NetBSD.

http://my.opera.com/Macallan/blog/index.dml/tag/O2

сама новость укладывается в несколько строчек:

-------
Make VSync for EXA and Xv configurable Alex Deucher
Optimise RADEONWaitForVLine Pierre Ossman
Improve tearing avoidance for Xvideo in two steps Pierre Ossman
First pass at tear-free accel Alex Deucher
Switch r200 Xv to use rect lists rather than quads to avoid tearing
-------

что в переводе с технического на русский означает что изображение, выводимое через Xvideo на видеокартах r200-r500 не должно теперь (по идее) "разрываться" при просмотре, в комментарии сказано что радеоны от r300 и выше теперь используют один большой треугольник с видео, обрезанный аппаратно до прямоугольника - так получается рендерить видео в один проход, что совместно с изменениями в EXA позволяет синхронизировать изображение с разверткой. Есть специальная опция которая это включает: EXAVSync

А также чуть раньше была добавлена возможность автоматического включения бикубического масштабирования при масштабировании больше 200% (при меньших значениях изображение от бикубической фильтрации было замыленным). Ставится через атрибут xvideo XV_BICUBIC (ставим xvattr, если еще не установлен)

Тестируем, радуемся (или плачемся в багзиллу)

В недавно выпущенной бета версии драйверов 180.06 появилась поддержка PureVideo-подобных (VDPAU API) возможностей для декодирования видео (MPEG-1, MPEG-2, H.264, VC-1) с помощью GPU. Есть поддержка деинтерлейсинга (пространственного и/или временного), преобразования частоты кадров (полей) - inverse telecine, шумоподавления и воспроизведения потоков с синхронизацией по меткам времени. Пока что единственным поддерживающим VDPAU плеером является mplayer, благодаря патчам, опубликованным nVidia. Текущие ограничения: поддерживаются только один видеопоток и не все типы файлов.

>>> Бенчмарк

>>> Описание

>>> Подробности на Phoronix.com

lxdream — эмулятор платформы Dreamcast для Linux и MacOS X. Изменения в этой версии относительно 0.8.4:

• Повышенная точность эмуляции и совместимость
• Отбрасывание теней по алгоритму shadow volumes
• Рендеринг в текстуру
• Туман
• Поддержка светового пистолета

Известные проблемы:

• Артефакты (при пересечении прозрачных полигонов и/или связанные с сортировкой по глубине)
• Код, использующий MMU (Linux, wince ...) работает ОЧЕНЬ медленно
• Код эмуляции SH4 не является точным, и по умолчанию исполняется медленее, чем на реальной системе. Это может привести к проблемам и полной неработоспособности программ. Иногда обходится ключом -m (подстройка скорости эмуляции процессора)
• Звук можно назвать плохим или отвратительным, с иногда проскакивающими фрагментами, похожими на нормальный звук

Системные требования

• Linux
• GTK 2.6+
• Последние (2008 или позже) бинарные драйверы ATI или Nvidia
• Для тех, кто желает использовать свободные драйвера — добавьте в них поддержку EXT_framebuffer_object или GLX_SGIX_pbuffer
• MacOS X 10.4 или более поздняя

Тестировано только на Linux и MacOS X, но должно компилироваться и на относительно новых *BSD. Однако не-x86 платформы НЕ поддерживаются на данный момент (известные проблемы с порядком представления чисел).

>>>Cписок изменений

>>> Cтраница закачки

http://groups.google.com/group/comp.sys.sgi/browse_thread/thread/418d43968608...#

Лётчики-самолётчики.

При отсутствии другого компа можно было развлекаться убийством себя своей же ракетой ... А владельцы "мощной тачки" всегда имели преимущество в реакции (больше FPS). Так что до какой-то степени авиасимы - классика игр. Linux'а тогда еще не было - зато уже было(о) GNU и был Emacs.

>>>

Нашел такую штуку:

http://gitorious.org/projects/ffmpeg/repos/ffmpeg-mt

И там к примеру за 14 октября Add multithreading for PAFF/MBAFF.

Скачал, собрал (были проблемы с libswscale). Вроде работает, но у меня одноядерник. Кто может с реальной многоядерной или многопроцессорной системой проверить? Там есть патчик простенький для mplayer - его пока не пробовал, не успел.

>>>

Хм. А машинка-то оказывается даже без своего знаменитого аппаратного ускорения видео и OpenGL весьма неплоха ....

http://home.tal.org/~milang/o2/

особенно вот это, http://home.tal.org/~milang/o2/7.html (gnome, mplayer -vo x11, 352x240 mpeg1 clip, sound enabled, no scaling) И это все на mips 180 Mhz, 512 kb L2 cache, 128Mb ram, 2.5Gb SCSI disk

http://www.in4tec-mbh.com/O2@600/advantage.html Или вот тут модифицированная машинка - 600Mhz cpu-mod, потребляет в целом, по словам автора 70 ватт. Почти достаточно для просмотра DVD - правда под родной Irix (но mplayer судя по всему тот самый, линуксовый)

В принципе есть маленький шанс допилить аппаратный видеоускоритель для простейших (2d/xv) задач - но таких машин раз два и все .... может лет через 10 будет реплика на FPGA, как сейчас NATAMI или Minimig (amiga-like компы)

>>>

http://img70.imageshack.us/my.php?image=nv40xvmc2ra9.png

Работает, работает :) Первый раз, когда я вижу аппаратно ускоренное (замедленное в данном случае, ибо все сыро до невозможности) видео в открытом драйвере, не просто CSC and scaling (преобразование цвета и масштабирование) а настоящий видеодекодинг!

http://www.bitblit.org/gsoc/g3dvl/index.shtml - страничка проекта
http://gitweb.freedesktop.org/?p=nouveau/mesa.git;a=shortlog;h=gallium-0.1
- а это исходный код.

собрал, поправив makefiles, положил libnouveau_dri.so в /usr/local/lib, ldconfig, далее

LD_PRELOAD=/home/guest/source/nv-experimental/gallium-0.1/mesa/src/libXvMC/libX vMCg3dvl.so mplayer -fs /home/guest/documents/video/20070715-Full-Immersion.mpg -quiet -vo xvmc -vc ffmpeg12mc -vf-clr

В отличие от 3D драйвера оно не потребовало SSE, хотя в ходе грядущих оптимизаций может быть всякое.

Однако круто, круче наверное только вот этот коммит в 2d-драйвере:

nv50: support YUY2 in textured video adaptor

>>>

kernel 2.6.25.10 and suspend-to-disk

Задали тут вопросец на #radeon, у кого 
машина после обновления drm/libdrm  перестала нормально засыпать-просыпаться? Поскольку у меня 
радеон, хоть и старый (rv280, radeon9200se) 
решил проверить и понял что swap-partition 
у меня не наблюдается (256 Мб памяти).


прочитал 
Documentation/power/swsusp-and-swap-files.txt

скомпилировал и поставил suspend-0.8 с http://suspend.sourceforge.net/
(потребовал libx86 с http://www.codon.org.uk/~mjg59/libx86/downloads/, взял Libx86 1.1).

Потом сделал как советовалось в документации:
dd if=/dev/zero of=/swap.file bs=1024 count=400000 (у меня корень на /dev/hdc1 , у вас будет свое устройство, размер свап-файла в этом примере около 400 Мб)

mkswap /swap.file

swapon /swap.file
cd /home/guest/source/suspend-0.8 (тут у меня лежат сырцы суспенд-0.8)
./swap-offset /swap.file (узнал смещение начала файла)

А потом простое echo disk > /sys/power/state НЕ СРАБОТАЛО.

Оказалось нужно СНАЧАЛА было добавить в параметры ядру resume= and resume_offset= . 

Сделал в lilo.conf:
 append="nocd nopcmcia max_loop=255 nohotplug vt.default_utf8=0 resume=/dev/hdc1 resume_offset=168582"

(resume_offset сказала прога swap-offset, в инете видел патчик на -mm ядро который добавлял нужную инфу прямо в лог ядра, но в майнлайне его все еще нет, по крайней мере не в 2.6.25)

вот теперь (после перезагрузки с указанными параметрами)
echo disk > /sys/power/state

работает как надо!

>>>

http://nouveau.cvs.sourceforge.net/nouveau/nv40_xvmc/

как предупреждает разработчик, там даже вывода на экран пока не реализовано, либа просто делает Motion Compensation силами аппаратного декодера на nv4x. Подробнее процесс описан в исходниках, и тут: http://nouveau.freedesktop.org/wiki/jb17bsome

Еще один проект: http://www.bitblit.org/gsoc/g3dvl/index.shtml Железонезависимое (в известных пределах) аппаратное ускорение mpeg2, в перспективе и других форматов.

разработчик уже засветился на #nouveau.

А в ffmpeg добавили поддержку libdirac и libschroedinger, идет работа над MLP, E-AC3, rv30/40. Что не может не радовать....

>>>

Что-то он мне не очень понравился:

1. Для сборки зачем-то требует xcb-x11 (пришлось пересобрать libX11) 2. Для запуска на AIGLX надо указывать export LIBGL_ALWAYS_INDIRECT=1 3. Для настройки ему нужен gconf-editor, ибо ручками через gconftool-2 как-то совсем неудобно. 4. И все равно свою роль (крашнуть Х) он не выполнил. 5. И по-умолчанию фон там какой-то чёрный, я поначалу чуть терминал в этой темноте не потерял.

>>>

http://lists.freedesktop.org/archives/xorg/2008-March/034122.html

"HDMI places the audio data in the various video blanking intervals instead of using a separate wire (wire appears to be more expensive than I remember). Because of this, the available bandwidth for audio data depends on the video mode in use (!), so the video driver has to tell the audio driver about the current video mode."

Чем-то вин-модем по идеологии напоминает. Для уменьшения стоимости применяются весьма неудобные с точки зрения программирования на низком уровне решения.

>>>

С последними фиксами (на сейчас это git commit 68888189cf8d460ef6f8f2f1431a6ffe9fcd8134, for xf86-video-ati) вполне работоспособно на моей древней тачанке. (duron-950)



Radeon overclock 0.6e by Hasw (hasw@hasw.net)

Found ATI card on 01:00, device id: 0x5964
I/O base address: 0xc800
Video BIOS shadow found @ 0xc0000
Reference clock from BIOS: 27.0 MHz
Memory size: 65536 kB
Memory channels: 0, CD,CH only: 0
tRcdRD:   6
tRcdWR:   3
tRP:      6
tRAS:     14
tRRD:     3
tR2W-CL:  3
tWR:      4
tW2R:     2
tW2Rsb:   1
tR2R:     2
tRFC:     18
tWL(0.5): 2
tCAS:     3
tCMD:     0
tSTR:     1
XTAL: 27.0 MHz, RefDiv: 45

Core: 200.25 MHz, Mem: 265.50 MHz

root@slax:~# cat /proc/cpuinfo 
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 3
model name      : AMD Duron(tm) Processor
stepping        : 1
cpu MHz         : 950.122
cache size      : 64 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow up
bogomips        : 1902.15
clflush size    : 32

И бенчамарк:
mplayer -quiet -fs -benchmark first_200s.avi  -vo xv:port=58 -nosound

VDec: vo config request - 1920 x 1080 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [xv] 1920x1080 => 1920x1080 Planar YV12  [fs]
[ASPECT] Warning: No suitable new res found!
[ASPECT] Warning: No suitable new res found!
[ASPECT] Warning: No suitable new res found!
[ASPECT] Warning: No suitable new res found!
[ASPECT] Warning: No suitable new res found!


BENCHMARKs: VC: 161.898s VO: 105.340s A:   0.000s Sys:   2.943s =  270.182s
BENCHMARK%: VC: 59.9221% VO: 38.9885% A:  0.0000% Sys:  1.0894% = 100.0000%

для обычного оверлея то же самое, на порт 57:


Starting playback...
VDec: vo config request - 1920 x 1080 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [xv] 1920x1080 => 1920x1080 Planar YV12  [fs]
[ASPECT] Warning: No suitable new res found!
[ASPECT] Warning: No suitable new res found!
[ASPECT] Warning: No suitable new res found!
[ASPECT] Warning: No suitable new res found!
[ASPECT] Warning: No suitable new res found!


BENCHMARKs: VC: 152.683s VO:  73.113s A:   0.000s Sys:   2.552s =  228.348s
BENCHMARK%: VC: 66.8642% VO: 32.0180% A:  0.0000% Sys:  1.1177% = 100.0000%

Т.е. в 1.5 раза медленнее новый адаптер. И настроек яркости/контраста в нем пока нет. Однако прогресс огромный. За 4 дня из страшного тормоза получилась вполне юзабельная штука. Желающие могут посмотреть в исходниках как это произошло. Вот за это я и люблю open source. 

PS Сколько там официальная команда  линуксовых драйверописателей ATI осиливала textured video для своих чипов? Со всеми спеками .... 

>>>

http://lists.freedesktop.org/archives/xorg/2008-February/033090.html

Также внутри описано что изменялось в 3D железе этих видеокарт на протяжении "жизни" чипов серий r300/r400.

Ура!

PS: кто-нибудь еще год назад верил, что это будет возможно?

>>>

Тут кто-то грозился, что как только увидет q3 - начнет пробовать сабж. Пожалуйста - демонстрация OpenArena на ноуте с nvidia/nouveau.

http://mirror.linux.org.au/pub/linux.conf.au/2008/Fri/mel8-081.ogg

(у меня оно (nouveau @ nv44) в q3 demo имеет некоторые проблемы со стенами - они временами прозрачные. что неудобно. Однако по сравнению с 12 fps - 20 безусловный прогресс.)

>>>

http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/2008-February/011546.html

сижу, компилю....

Теперь из "больших" h264 задач для ffmpeg только распараллеливание на n ядер осталось нереализованным?

>>>

О 16 метрах видеорамы. Стоит в системе с Duron-950, в agp слоте, с программной стороны Nouveau сегодняшний, Х-сервер от 21 декабря, Mplayer тоже свежий. Крутит фильмы на ура. (DV pal 720*576, x264 640*480 ну и что попроще там) Единственное что пришлось сделать - добавить

Section "Extensions" Option "Composite" "disable" EndSection

в xorg.conf

Вот и спорь после это на ЛОРе с анонимусами....

>>>

http://img292.imageshack.us/my.php?image=radeonpaltvoutrv280fixeoq9.jpg

С час назад Alex Deucher зафиксил PAL tv-out. Я проверил - вроде работает, через тюнер :) Только radeon 9200se/64Mb vram неслабо тормозит с включенными композит-эффектами на разрешении 1824х768 (суммарное для моника 1024*768 и видеовыхода 800х600). Вращение десктопа (через 3D движок), OpenGL, xvideo - все вроде работает как надо.

>>>