0,0
рейтинг
20 февраля 2013 в 07:45

Администрирование → ATI+Fedora17 и желание посмотреть фильмы в хорошем качестве с привычной скоростью

Доброго времени суток! Решил поделиться с Вами историей, о совсем не тривиальном, как оказалось, решении проблемы воспроизведения качественного видео потока на Fedora 17 x86-64. До недавнего времени, проводя свободные часы за своим нетбуком (Asus 1215B, E-450, 8Gb RAM, 500Gb SATA), я считал, что меня всё устраивает. Хождение по интернетам, музыка, фильмы (в основном dvdrip'ы), игры (сейчас модно в старый-добрый Half-Life зарубить), всё работало без нареканий, пока мне не захотелось посмотреть фильм с пометкой 1080p. Стоявшая при покупке Windows 7 Home x64, в связке с K-Lite+MPC, без особых проблем справлялась с такими задачами, поэтому я, без задней мысли, дважды ткнул курсором в файл и приготовился к просмотру. Сказать что видео поток тормозил — ни сказать ничего! Небезызвестный параметр «Frames Per Second» превратился в «Seconds Per Frame», а настроение упало ниже плинтуса. И началось курение мануалов!

Первый же поисковой запрос, по аппаратному декодированию видео потока, отправил меня сюда. Всё просто и по пунктам:


Конечно, какие могут быть проблемы, если все пакеты есть в репозитории? Но это для Ubuntu. В репозиториях для Fedora, я нашел только проприетарный драйвер от AMD, он же fglrx. На XvBA не было и намёка.

Очередные поисковые запросы привели меня на страничку, на которой пользователь под ником canyon рассказывает где взять пакеты именно для Fedora17, и как их правильно установить. Он настаивал на установке драйвера fglrx именно с сайта AMD, так как по его опыту, тот, который в репозиториях — «сломан», в следствии чего, аппаратное декодирование не работает. С сайта, так с сайта. Тем более, что версия драйвера выгодно отличалась (13.1 vs 12.10). Загрузка прошла успешно:

$ wget -c http://www2.ati.com/drivers/linux/amd-driver-installer-catalyst-13.1-linux-x86.x86_64.zip
$ unzip amd-driver-installer-catalyst-13.1-linux-x86.x86_64.zip
$ chmod +x amd-driver-installer-catalyst-13.1-linux-x86.x86_64.run

И я приступил к выполнению пунктов мануала. Вся ирония его фразы «Quick How-To», была осознана мной в полной мере. Быстрый how-to, на практике оказался кратким how-to (видимо трудности перевода). Скажу сразу. Перед началом всех действий, в моей ОС, вместе с пакетом «mesa-libGL», стоял еще один пакет — «mesa-libGL-devel», который подтянул за собой многие зависимости (включая *.h файлы), требуемые для сборки XvBA драйвера с поддержкой GLX. И так, всё по порядку. Запуская установшик проприетарного драйвера от AMD:

$ sudo ./amd-driver-installer-catalyst-13.1-linux-x86.x86_64.run

Я получал крах за крахом. Зависимости наше всё! По итогу, лично моей системе, не хватало пакетов «kernel-headers» и «kernel-devel», но даже после их установки «/usr/share/ati/fglrx-install.log» был полон как никогда. Установщик ругался на отсутствие файла «/lib/modules/3.7.6-102.fc17.x86_64/build/include/linux/version.h». Рекурсивный поиск по папкам нашел «version.h» по адресу «/usr/include/linux/version.h». Убедившись, что этот файл принадлежит текущей версии ядра — я скопировал его по требуемому адресу.

$ uname -r
$ rpm -qf /usr/include/linux/version.h 
$ sudo cp /usr/include/linux/version.h /lib/modules/3.7.6-102.fc17.x86_64/build/include/linux/version.h

После этого, драйвер всё-таки установился, но перезапускать систему я не рискнул, так как всё в том же «fglrx-install.log» была запись (выдержка):

/usr/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c
ошибка: "VM_RESERVED" undeclared (first use in this function)
[Error] Kernel Module : Failed to compile kernel module - please consult readme.

Переменная не определена — модуль ядра не собран. Беда! Поиск и ещё раз поиск. Вот оно. Пользователь под ником lx6544 перепостил мануал, в котором эта проблема решалась так:

В фале «/usr/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c», после 100-й строки, добавлялось определение переменной «VM_RESERVED»:

#ifndef VM_RESERVED
#define VM_RESERVED (VM_DONTEXPAND | VM_DONTDUMP)
#endif

Следом, пересобирался и устанавливался модуль ядра:

$ cd /lib/modules/fglrx/build_mod/
$ sudo ./make.sh

$ cd /lib/modules/fglrx/
$ sudo ./make_install.sh

Обе пары команд вернули мне «done» и я выполнил перезагрузку ОС.

$ sudo aticonfig --initial -f
$ reboot

Проприетарный драйвер был установлен. Работал исправно. Далее, по мануалу от пользователя canyon, был rebuild и установка RPM пакета под текущую ОС:

$ sudo yum install rpm-build
$ rpmbuild --rebuild ~/libva-xvba-driver-0.8.0-2.fc17.src.rpm

И тут крах. В окне терминала красовалось «очень» информативное сообщение:

checking for XvBA... no
configure: error: you need XvBA to build this package

Не говорившее мне ничего особенного. В «~/rpmbuild/BUILD/xvba-driver-0.8.0/config.log» уже более конкретно было написано:

configure:13374: gcc -o conftest -O2 -g -I/usr/include  -L/usr/lib64 conftest.c -lrt -lpthread -lm  -lXvBAW -lX11 -lXext -lGL -ldl >&5 
conftest.c:44:21: fatal error: amdxvba.h: No such file or directory 
compilation terminated.

Файл «amdxvba.h»? Я уже читал про него!

$ wget -c http://developer.amd.com/wordpress/media/2012/10/xvba-sdk-0.74-404001.tar.gz
$ tar -xf xvba-sdk-0.74-404001.tar.gz include/amdxvba.h
$ sudo cp include/amdxvba.h /usr/include/

Следом, на всякий случай, я проверил все библиотеки указанные для «gcc» в предыдущей строке лога. Не хватало только двух symlink'ов на «-lXvBAW»

$ sudo ln -s /usr/lib/libXvBAW.so.1 /usr/lib/libXvBAW.so 
$ sudo ln -s /usr/lib64/libXvBAW.so.1 /usr/lib64/libXvBAW.so 

После создания symlink'ов конфигурация прошла успешно:

VA-API version ................... : 0.32.1
GLX support ...................... : yes
Cg compiler ...................... : no
Enable debugging information ..... : yes
Enable XvBA tracer ............... : yes

А вот сборка нет. Компилятор ругался на неизвестный тип переменной (PFNGLMULTITEXCOORD2FPROC), указанной в файле «utils_glx.h». Первая же ссылка в поисковой выдаче прояснила ситуацию. Да, действительно:

В файле «/usr/include/GL/gl.h», переменная «GL_VERSION_1_3», была однозначно определена:

#define GL_VERSION_1_3 1

В следствии чего, в файле «/usr/include/GL/glext.h» (версия 85), определение типа «PFNGLMULTITEXCOORD2FPROC» пропускалось:

#define GL_GLEXT_VERSION = 85
...
#ifndef GL_VERSION_1_3
...
typedef void (APIENTRYP PFNGLMULTITEXCOORD2FPROC) (GLenum target, GLfloat s, GLfloat t);
...
#endif

Хорошо, файл «/usr/include/GL/glext.h» был поправлен:

$ sudo gedit /usr/include/GL/glext.h

#if GL_GLEXT_VERSION >= 85
typedef void (*PFNGLMULTITEXCOORD2FPROC) (GLenum target, GLfloat s, GLfloat t);
#endif

А RPM пакет успешно собран и установлен.

$ rpmbuild --rebuild ~/libva-xvba-driver-0.8.0-2.fc17.src.rpm
$ sudo yum install libva-utils ~/rpmbuild/RPMS/x86_64/libva-xvba-driver-0.8.0-2.fc17.x86_64.rpm

Вызов команды «vainfo» больше не выдавал ошибку, а запуск VLC плеера с параметром «--ffmpeg-hw» убедил меня в том, что аппаратное декодирование заработало:

$ vainfo

libva: va_getDriverName() returns 0
libva: Trying to open /usr/lib64/dri/fglrx_drv_video.so
libva: va_openDriver() returns 0
vainfo: VA-API version: 0.32 (libva 1.0.16)
vainfo: Driver version: Splitted-Desktop Systems XvBA backend for VA-API - 0.8.0
vainfo: Supported profile and entrypoints
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD

$ vlc --ffmpeg-hw ~/1080p.mkv 

VLC media player 2.0.5 Twoflower (revision 2.0.5-0-g1661b7d)
...
libva: VA-API version 0.32.1
Xlib:  extension "XFree86-DRI" missing on display ":0".
libva: va_getDriverName() returns 0
libva: Trying to open /usr/lib64/dri/fglrx_drv_video.so
No accelerated IMDCT transform found
libva: va_openDriver() returns 0
xvba_video: XVBA_GetSurface(): status 2
[0x7f5628c1ada8] avcodec decoder: Using VA API version 0.32 for hardware decoding.

Воспроизведение было четкое и плавное. Вот теперь точно — PROFIT!

UPDATE1:
Как, правильно, заметил norguhtar, копировать файл «version.h» не есть хорошо, лучше править исходник. Поэтому, я набросал второй способ установки проприетарного драйвера от AMD:

$ wget -c http://www2.ati.com/drivers/linux/amd-driver-installer-catalyst-13.1-linux-x86.x86_64.zip
$ unzip amd-driver-installer-catalyst-13.1-linux-x86.x86_64.zip
$ chmod +x amd-driver-installer-catalyst-13.1-linux-x86.x86_64.run
$ sudo -s
# ./amd-driver-installer-catalyst-13.1-linux-x86.x86_64.run --force
# cp -a /usr/lib/modules/fglrx /usr/lib/modules/fglrx_backup
# for i in `find /usr/lib/modules/fglrx/ -type f`; do cat $i | sed -e "s/linux\/version\.h/generated\/uapi\/linux\/version\.h/g" > ${i}_tmpext; done
# for i in `find /usr/lib/modules/fglrx -name '*_tmpext'`; do mv -vf $i `echo $i | sed s/\_tmpext//`; done

# gedit /usr/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c

#ifndef VM_RESERVED
#define VM_RESERVED (VM_DONTEXPAND | VM_DONTDUMP)
#endif

# cd /usr/lib/modules/fglrx
# chmod +x make_install.sh build_mod/make.sh
# cd build_mod
# ./make.sh
# cd ..
# ./make_install
# aticonfig --initial -f
# exit
$ reboot

Этот способ оставляет в покое файл «version.h». Вместо него, правятся исходники модуля ядра. Перебираются все файлы в папке с исходником и каждое вхождение «linux/version.h» заменяется на «generated/uapi/linux/version.h». После чего, модуль собирается и устанавливается.

Файлы для загрузки:
libva-xvba-driver-0.8.0-2.fc17.x86_64.rpm
libva-xvba-driver-0.8.0-2.fc17.src.rpm

Список литературы:
Unified Video Decoder
Video Acceleration API
X-Video Bitstream Acceleration
Аппаратное декодирование видео на AMD Radeon в Ubuntu (mplayer)
Воспроизведение HD-video
Михаил Буриченко @paran01k
карма
22,0
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Администрирование

Комментарии (37)

  • 0
    Я так понял, что у Вас получилось собрать rpm-пакет, может, его тоже выложить?
    • +1
      Добавил.
  • +5
    Да… Помню сидел на Fedora раньше, чувствовал себя настоящим джедаем. Столько знаний по Linux'у получил пока проблемы решал… А потом перешел на Ubuntu и почувствовал себя человеком. Ну или почти человеком…
    • +2
      Чувствую то же самое, только перейдя с Ubuntu на Fedora :)
    • +1
      я вот тоже перевел домашний серв с федоры на убунту лтс. И… немного жалею. Но стабильность важнее. На IBM System X3200 M2 федора 18 то не хотела грузиться из-за странной ошибки об инициализации ERST (помог erst_disable в grub), то не хотела нормально перезагружаться уходя в panic.
      На убунту некоторые пакеты по-старее будут, но пока ни одного бага с оборудованием…

      оффтоп
      получается я изменил ей?..
  • 0
    А почему нельзя было просто обновиться до F18? Там как минимум 13.1 есть в репозиториях.
    • 0
      Для меня, прежде всего, важна стабильная работа. Поставив 18 релиз (в первые дни после выпуска), на моем железе то и дело что-нибудь да отваливалось. Поэтому, я решил немного подождать (пару месяцев) и откатился обратно. Что касается драйвера из репозитория, то canyon писал в своем блоге, что ему не удалось запустить на нем аппаратное декодирование. Правда версия была 12.10, а не 13.1. Может уже и поправили. Вообщем, в тот момент, я искал самый быстрый вариант.
      • 0
        пару месяцев

        Зачем так долго? Достаточно просто подождать обновлений ядра. Сейчас там уже 3.7.9 и оно очень стабильно, хотя через пару недель прикатит 3.8, где запросто может что-нибудь снова поломаться.
        • 0
          где запросто может что-нибудь снова поломаться.

          Так и живем!
      • 0
        Обновился до 18й в первую неделю релиза.
        Никаких проблем замечено не было.
        • 0
          А Хром нормально запускался? У меня на всех машинах работал только после переустановки.
          • 0
            я обновил через yum update
            Хром вначале отказался запускаться — точно не помню, кажется хотел какую-то другую версию какого-то файла. Я посмотрел, нужная версия на компе была, сделал симлинк на тот файл, на который смотрел хром и все заработало. Там делов на 2 минуты, я даже не придал этому значения, если бы вы сейчас не спросили, я бы даже не вспомнил.
            • 0
              На самом деле, достаточно было простого yum reinstall google-chrome-stable :)
  • +1
    Кстати, проблема с /usr/include/linux/version.h — известный апстримный баг ядра, и в 3.7.9 точно исправлен.
  • +1
    Пффф… Делов-то! )
  • 0
    Установщик ругался на отсутствие файла «/lib/modules/3.7.6-102.fc17.x86_64/build/include/linux/version.h». Рекурсивный поиск по папкам нашел «version.h» по адресу «/usr/include/linux/version.h». Убедившись, что этот файл принадлежит текущей версии ядра — я скопировал его по требуемому адресу.

    yum install kernel-devel и не надо придумывать ерунды.
    • 0
      Ерунду никто и не придумывает. Не знаю как у Вас, а у меня не было этого файла:

      $ rpm -ql kernel-headers | grep version.h
      

      /usr/include/linux/dvb/version.h
      /usr/include/linux/version.h
      

      $ rpm -ql kernel-devel | grep version.h
      

      /usr/src/kernels/3.7.6-102.fc17.x86_64/include/config/arch/want/compat/ipc/parse/version.h
      /usr/src/kernels/3.7.6-102.fc17.x86_64/include/config/isdn/diversion.h
      /usr/src/kernels/3.7.6-102.fc17.x86_64/include/config/localversion.h
      /usr/src/kernels/3.7.6-102.fc17.x86_64/include/generated/uapi/linux/version.h
      /usr/src/kernels/3.7.6-102.fc17.x86_64/include/uapi/linux/dvb/version.h
      /usr/src/kernels/3.7.6-102.fc17.x86_64/include/xen/interface/version.h
      

      Вот ссылка на bugzilla, где, хоть и для 3.7.1, но говорится, что файл «version.h» перемещен в "/usr/src/kernels/3.7.6-102.fc17.x86_64/include/generated/uapi/linux/version.h"
      • +1
        У вас ссылка есть такого вида
        lrwxrwxrwx. 1 root root 38 февр. 18 08:18 build -> /usr/src/kernels/3.7.8-202.fc18.x86_64

        И в fc17 тоже должно быть.
        • 0
          Конечно есть. Просто, как видно из лога команды «rpm -ql kernel-devel | grep version.h», файла «include/linux/version.h» в пакете нет. Его переместили, а установщик драйвера по прежнему пытается его найти по старому пути. Поэтому я и набросал скрипт, который правит исходник. Но, согласитесь, он выглядит более громоздко нежели копирование одного файла, который, после сборки, можно удалить.
          • 0
            Лучше исправить в исходнике путь, а не копировать файлы по системе.
            • 0
              Уже исправил. How-To добавлен в раздел «UPDATE1».
      • +3
        Ну и да надо класть не сюда файл /lib/modules/3.7.6-102.fc17.x86_64/build/include/linux/ а править исходник. А так вы вот своими действиями отлично загадили систему.
        • 0
          Конечно, я понимаю, что это не совсем «true linux way», но так было гораздо быстрее. Хотя, я не думаю, что один заголовочный файл мог сильно загадить систему, тем более, что после сборки модуля его можно удалить. Всё же, что бы дать людям выбор, набросал еще один вариант:

          $ wget -c http://www2.ati.com/drivers/linux/amd-driver-installer-catalyst-13.1-linux-x86.x86_64.zip
          $ unzip amd-driver-installer-catalyst-13.1-linux-x86.x86_64.zip
          $ chmod +x amd-driver-installer-catalyst-13.1-linux-x86.x86_64.run
          $ sudo -s
          # ./amd-driver-installer-catalyst-13.1-linux-x86.x86_64.run --force
          # cp -a /usr/lib/modules/fglrx /usr/lib/modules/fglrx_backup
          # for i in `find /lib/modules/fglrx/ -type f`; do cat $i | sed -e "s/linux\/version\.h/generated\/uapi\/linux\/version\.h/g" > ${i}_tmpext; doneup
          # for i in `find /lib/modules/fglrx -name '*_tmpext'`; do mv -vf $i `echo $i | sed s/\_tmpext//`; done
          

          # gedit /usr/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c
          

          #ifndef VM_RESERVED
          #define VM_RESERVED (VM_DONTEXPAND | VM_DONTDUMP)
          #endif
          

          # chmod +x make_install.sh build_mod/make.sh
          # cd build_mod
          # ./make.sh
          # cd ..
          # ./make_install
          # aticonfig --initial -f
          # exit
          $ reboot
          

          Всё, вроде, прошло успешно. Только вот перезагружаться боюсь! Ссыкотно.
  • +2
    И после этого мы — гентушники красноглазики? На стабильной генте вчера за ~15 минут перешел на проприетарный атишный драйвер:
    1) vi /etc/portage/make.conf (добавил fglrx в список VIDEO_CARDS)
    2) emerge -vabkDuN world
    3) eselect opengl set ati
    4) aticonfig --intitial
    Ребут и профит.

    Спасибо за наводку с xvba. Интересно на каких видюхах оно есть. А то у меня медиацентром ноут с каким-то древним радеоном.
    • –1
      [шутка] Вы же модуль fglrx в /etc/conf.d/modules не прописали. Непорядок! [/шутка]
      • +1
        Да я вообще половину утаил. Потом ведь еще в /etc/portage/package.use/x11-drivers_ati-drivers
        x11-drivers/ati-drivers disable-watermark вписал, так как в генте признаны стабильными 12.11_beta11.

        А fglrx иксы сами грузят. А открытый драйвер radeon, если он используется, у меня вообще dracut из initramfs грузит, чтоб консоль красивенькая была пораньше.
    • +1
      Unified Video Decoder, в разделе: «UVD enabled GPUs»
  • 0
    Ох. Я прямо вспомнил, как Ubuntu 6.06 ставил и разбирался (и тоже устанавливал драйвера вручную, в то время их ещё в пакетах не предоставляли, кажется). Судя по тому, что автор не знает, что для сборки модуля ядра нужны хедеры или исходники, линуксом он пользуется не так долго. Поэтому есть подозрение, что всё можно было проделать проще и с меньшим количеством драмы. Я, конечно, не знаю, как там в федоре, но всё равно вижу подозрительно много усилий.
  • 0
    вот расстраивает меня такой способ решения банальной пользовательской проблемы. Я тоже когда-то пытался настроить xvba для аппаратного ускорения, но не смог осилить весь путь. Неужели нельзя эту проблему решить попроще и для всех?
    Кто-нибудь пробовал использовать xvba в Федора 18, но только с меньшими танцами с бубном?
  • +1
    15 экранов текста, чтобы смотреть кино, «как в винде». Это успех.
  • 0
    симлинки? не, не слышал.
    • 0
      Изначально копировался файл, принадлежащий пакету «linux-headers», в директорию, где должен был лежать файл из пакета «kernel-devel». В случае обновления ядра, этот симлинк ссылался бы на совсем другой «version.h». С этой точки зрения — копирование безопасней. Можно, конечно, было сделать симлинк на «version.h» лежащий в "/usr/src/kernels/`uname -r`/include/generated/uapi/linux/". Вариантов много. В «UPDATE1», например, c файлом «version.h» вообще не нужно ничего делать. Поправил исходник и хорошо. При обновлении ядра, не нужно ничего менять. Но опять же, при установке новой версии проприетарного драйвера, придется заново править исходники модуля.
      • 0
        Понятно. У меня на Федоре была похожая проблема после обновления и установки нового ядра…
  • 0
    еще интересно сколько часов было потрачено на решение «проблемы» :)
    • 0
      Около 4 часов.
  • 0
    Спасибо за подробное описание, скомпилировал рпм для fc18.x86_64. Может кому то пригодится libva-xvba-driver-0.8.0-2.fc18.R.x86_64.rpm. На Lenovo s205 AMD E-300.
    • 0
      Для работы необходимы симлинки описанные в статье.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.