Да ты и вправду не в теме. Я понимаю, что это не в традициях ЛОРа, но все же, прежде, чем критиковать, нужно хотя бы поверхностно ознакомиться с предметом обсуждения.
1) Gstreamer уже не раз ломал API. Что проще - переделать Phonon или переделать все программы, которые используют Gstreamer
2) Можно использовать "родные" способы воспроизведения медиа на других платформах, чместо того, чтобы тащить туда Gst
3) Вдруг завтра появится что-то, что заткнёт за пояс Gst по возможностям? Или Gst не будет поддерживать какой-то формат, поддерживаемый, например, Xine'ом?
ты не в теме, иначе не сравнивал бы примитивную обертку вокруг нескольких кодеков и модульный фреймворк, позволяющий единообразно работать не только с многими медиаформатами и медиаконтейнерами, но и со многими протоколами передачи медиа и устройствами воспроизведения/записи
Ладно, не буду спорить - Gst гораздо богаче по возможностям и более правильный идеологически. Что не отменяет того факта, что Xine является его аналогом, и что Phonon аналогом Gst _*НЕ ЯВЛЯЕТСЯ*_.
>Gstreamer уже не раз ломал API. Что проще - переделать Phonon или переделать все программы, которые используют Gstreamer
для этого не надо абстрагировать уровень абстракции =) gtk-приложения как-то работают. Кстати, стабилизировали API в 2005-м, если мне склероз не изменяет
>Можно использовать "родные" способы воспроизведения медиа на других платформах, чместо того, чтобы тащить туда Gst
ога, то, что для этого надо тащить туда Phonon - скромно умолчим. А если на таргет платформе нет xine - то и gst =)
>Вдруг завтра появится что-то, что заткнёт за пояс Gst по возможностям? Или Gst не будет поддерживать какой-то формат, поддерживаемый, например, Xine'ом?
плагин напишут. Если ты не в курсе - gst модульный насквозь.
Это какой-то неправильный танцор, который с чужими яйцами танцует. А сваливать свои проблемы на другого - это, конечно, очень круто. "Если в кране нет воды..."
>> Можно использовать "родные" способы воспроизведения медиа на других платформах, чместо того, чтобы тащить туда Gst
> ога, то, что для этого надо тащить туда Phonon - скромно умолчим.
А вот здесь товарищ blaster999 совершенно прав. Во-первых, на целевой машине может быть своё собственноё API для медиа (DirectSound/DirectShow/QuickTime). Во-вторых, тащить туда Phonon не нужно - он уже есть в составе Qt, так как мы говорим о разработке Qt приложений.
И что - это что-то меняет? Какая разница через что он по виндой выводит, если он остаётся _кроссплатформенным_ и выводит на каждой платформе чем удобно?
> Сначала разработчики Qt вместо того, чтобы продвигать OpenGL в массы, обернули отрисовку в оффтопике поверх быдлодиректикса.
Ну вы даёте, OpenGL в Windows никто не отменял по понятным причинам, для него существует отдельный модуль, отвечающий за некроссплатформенную функциональность (создание контекста, пиксельнын буферы). Через этот модуль можно использовать _СВОИ_ вызовы OpenGL.
А то о чём вы говорите предназначено для Артура, а не для программирования на чистом DirectX. Вас же не смущает что под MacOS X используется реализация через Quartz, о котором вы можете даже ничего не знать.
> Теперь хотят обернуть мультимедиа поверх быдлодиректшоу.
Слова DirectShow придумал я. Пока слыхом не слыхивал чтобы кто-то про него заикался, имелась в виду только теоретическая возможность. Сейчас в исходниках лежит реализация аудио бекенда через DirectSound, что я считаю вполне разумно.
а почему собственно нет если это бэкенд, разве плохо когда можно выбрать наболее производительный или доступный в условиях данной платформы и не забывай что Qt это совсем не только Linux, и то что программистам не придется лепить костыль на каждую платформу только плюс (например - реализация треиконы в старой псе и вроде гажиме), если for fun все понятно, хочешь - костыляй или шли всех в гугл, но трольтехи свой труд еще и продают, а тут конкуреция (с дотентом тем же) и если программисту удобнее (быстрее - дешевле) разрабатывать кроссплатформенные приложение не вникая особенно в особенности (фичи) платформы, то надо дать ему такую возможность. Это намного больше похоже на концепцию reusable code. А фонон, артур, вебкит это как минимум единый API (ну или с минимальными и преодолимыми без грязных хаков на всех платформах отличиями).
Для джавы например особой статьей идут модули "in pure Java" как наиболее кошерные. Да и просто на C++ и проч. биндинги почему-то никто не плюется, а можно ведь и на пайпах все связать и получить тру юниксвей. У Qt немного свой диалект (не похож на гткмм, флтк и некоторые C++) и вполне логично завернуть некоторые вещи в подобные обертки подцепив их к Qtшной модели (те же сигналы/слоты) особенно не изобретая велсипедов. Они же не переписывают директикс и директсаунд, получается один и вас ругается на изобретательство велосипеда в виде фонона, а ты на то что они дали возможность использовать директикс наряду с OpenGL не изобретая что-то такое-же, вы уж давайте разберитесь между собой.
З. Ы. видеоплеер планируется, насколько я читал, какой-то очень простенький и базовый, что-то вроде кодеина (может даже на его коде или фром скратч)
А кто-то пробовал этот Codeine? Как он по возможностям?
Сам раньше юзал связку KMPlayer+xine-lib, но недавно подсел на smplayer. Очень порадовало автосохранение текущей позиции при выходе (маленькая, но очень приятная фича:)).
Кодеин это такая насмешка над гномерами, т.е. видеопроигрыватеть с одной -двумя кнопками, причем этого вполне хватало:) ... пока мне не понадобилось поменять кодировку в титрах, наверное он цепляет зиновские параметры, я не стал разбираться ибо под рукой был кафеин. А так обычный себе (ну да минималистичный) ui к зинолибам, были какие-то мелкие глюки, но версия то была не стабильная.