Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 52
Вопрос: где скачать приложение.
приложение работает только для абонентов «СС» и пока что находится на стадии тестирования. Как только оно пройдет тестирование, я могу дать ссылку, но видео показываться все равно не будет, если ты не абонент компании…
Для абонентов СС? На людях тестируете?
у вас список урлов каналов забит в код? Или все-таки хранится где-то во внешнем файле или настройках?
Вы кстати собираетесь соблюдать условия лицензии на VLC? Исходники там и все такое?
GPL все-таки.
GPL все-таки.
Сори но какого фи… эта статья делает в общаке. Раз уж она доступна для пользователей «СС» (данная аббревиатура мне мало о чем говорит), край ей песочница.
Чисто моё имхо.
Чисто моё имхо.
Нужно отдать должное, программа выглядит приятно и современно. Мне кажется дизайном и эргономикой занимались профессионалы.
дизайн разрабатывал Wonder
А почему используется DirectX? Vlc — кроссплатформенный, Qt — тоже, зачем так сужать платформы? Есть предложение: использовать OpenGL и получить красивый и функциональный кроссплатформенный плеер.
красивый
кроссплатформенный
Так бывает?
да изначально так и планировалось, но оценив скорость работы OGL под windows мы решили все-таки заюзать DirectX. Изначально плеер был предназначен под Windows. А насчет кроссплатформенности — вполне себе реализуемо.
Гм, простите конечно, но OGL в силу своих особенностей вообще обычно работает на пару процентиков быстрее(ибо сильно low-level во всех проявлениях).
В вашем случае может отработать даже раза в два быстрее. Так как умеет лить поток видео напрямую в текстуру, без различных там сурфесов, и не требует ресета при ресайзе.
А раз шейдеры вам разные не нужны то проблем с различными архитектурами конвееров вас тоже не затронут.
В любом случае сильно хотелось бы узнать с какими проблема Вы столкнулись.
В вашем случае может отработать даже раза в два быстрее. Так как умеет лить поток видео напрямую в текстуру, без различных там сурфесов, и не требует ресета при ресайзе.
А раз шейдеры вам разные не нужны то проблем с различными архитектурами конвееров вас тоже не затронут.
В любом случае сильно хотелось бы узнать с какими проблема Вы столкнулись.
сильнее low-level чем directX? я конечно могу ошибаться но как раз таки directx более низкоуровневый, и поэтому для начинающих рекомендуют использовать OGL(в нем таких заморочек как местоположение ресурса в памяти, потеря ресурсов). А насчет скорости, мы просто написали тестовый пример с HDTV потоком, и визуально приложение работало медленнее чем на DirectX, хотя там было только отображение видео потока без наложения контролов. Шейдеры в отрисовке не использовал, хотя в будущем возможно их задействую
>(в нем таких заморочек как местоположение ресурса в памяти, потеря ресурсов
Да — там вы просто говорите ЧТО вы будете хранить в буфере. А где будет находиться буффер и КАК — вообще это дело драйвера.
DX предоставляет унифицированный интерфейс высокоуровневых абстракций над реальными объектами и методы работы с ними.
В OGL же делай чего хош. Сделал не так, или не в той последовательности — прощай.
Обычно требуется написать еще пару тысяч строчек различных враперов и графов чтобы хоть как-то нормально отработать.
Насчет видео — PBO, то есть прямой стриминг в видеопамять.
Когда я в последний раз проверял эту технологию( это было 5 лет назад на G6xxx) получалось далеко за 300 FPS для предварительно частично-декодированного видео(другой тред с опережением)
Да — там вы просто говорите ЧТО вы будете хранить в буфере. А где будет находиться буффер и КАК — вообще это дело драйвера.
DX предоставляет унифицированный интерфейс высокоуровневых абстракций над реальными объектами и методы работы с ними.
В OGL же делай чего хош. Сделал не так, или не в той последовательности — прощай.
Обычно требуется написать еще пару тысяч строчек различных враперов и графов чтобы хоть как-то нормально отработать.
Насчет видео — PBO, то есть прямой стриминг в видеопамять.
Когда я в последний раз проверял эту технологию( это было 5 лет назад на G6xxx) получалось далеко за 300 FPS для предварительно частично-декодированного видео(другой тред с опережением)
Да — там вы просто говорите ЧТО вы будете хранить в буфере. А где будет находиться буффер и КАК — вообще это дело драйвера.
Вот именно, что в некоторых случаях лучше самому управлять ресурсами, если знаешь что делать.
DX предоставляет унифицированный интерфейс высокоуровневых абстракций над реальными объектами и методы работы с ними.
Ну не настолько уж прямо высокоуровневых. Просто функции по отрисовке и прочему сгруппированы по интерфейсам и вместо glBegin ты вызываешь device->beginScene. или вместо биндинга текстур ты используешь класс IDirect3DTexture9.
Насчет видео — PBO, то есть прямой стриминг в видеопамять.
Ок, возможно я не до конца использовал возможности OGL, но по сути PBO это тот же Offscreen Plain Surface с D3DPOOL_DEFAUL + StretchRect для копирования в текстуру через GPU
[оффтоп]
Люди добрые, подскажите!
За сколько можно заказать плагин для VLC, который бы понилал тайм-код из dv avi и mov -файлов и оверлеем накладывал его на видео, да две кнопки покадровой перемотки в стандартный интерфейс добавил?
Люди добрые, подскажите!
За сколько можно заказать плагин для VLC, который бы понилал тайм-код из dv avi и mov -файлов и оверлеем накладывал его на видео, да две кнопки покадровой перемотки в стандартный интерфейс добавил?
А Вы не хотели бы написать библиотеку GUI контролов на DirectX? Работал над D3D рендерером в коммерческом проекте и долго мучался с GUI. Идея спрайтов, состояний, как вообще все это делается — понятна. Но хотелось бы вынести всё это в удобный фреймворк. Просто предлагаю, если Вам интересно.
мой коллега по работе уже начал делать что-то подобное… разрабатывает систему GUI с возможность рендера на Qt, DirectX и прочим. Данные о контролах выносятся в скриптовый файл(синтаксис наподобие JSON + его собственные навороты). Уже создали репозиторий на google code. Может объединимся?
Для плоских интерфейсов есть WPF.
Кроме того, кажется что то подобное я видел в DirectX SDK.
Для реального 3D, если это не просто 2D с 3D эффектами надо крепко думать прежде чем делать библиотеку GUI. В смысле простор для фантазии очень большой.
Кроме того, кажется что то подобное я видел в DirectX SDK.
Для реального 3D, если это не просто 2D с 3D эффектами надо крепко думать прежде чем делать библиотеку GUI. В смысле простор для фантазии очень большой.
для всех: «СС» — аббревиатура от названия компании «Сибирские сети» — провайдер в Новосибирске.
Может перезалейте скрины на хабровский файлохостинг? А то дропбокс периодически пишет на ваши скрины, что слишком много траффика на них идет.
Немного хочу добавить по поводу перерисовки GUI. Кроме предложенный двух вариантов:
— вызов принудительной отрисовки при изменении GUI
— всегда перерисовывать экран.
Есть еще один метод, который используется практически везде (в WebKit, QWS, X например).
Это гибрид двух этих метдов. Когда GUI элемент меняется, то он себя помечает как «грязный» (или же часть себя — dirty region). В гравном цикле приложения, когда идет перерисовка интерфейса экран не перерисовывается, а перерисовываются только «грязные» участки. Таким образом, если ничего не меняется, то ничего и не перерисовывается. Мезанизм немного усложняется при альфа блендинге, так как грязным помечается не только сам регион, а так-же те слои, которые нужно будет смешать с этим регионом заново. Но в общем идея та же.
— вызов принудительной отрисовки при изменении GUI
— всегда перерисовывать экран.
Есть еще один метод, который используется практически везде (в WebKit, QWS, X например).
Это гибрид двух этих метдов. Когда GUI элемент меняется, то он себя помечает как «грязный» (или же часть себя — dirty region). В гравном цикле приложения, когда идет перерисовка интерфейса экран не перерисовывается, а перерисовываются только «грязные» участки. Таким образом, если ничего не меняется, то ничего и не перерисовывается. Мезанизм немного усложняется при альфа блендинге, так как грязным помечается не только сам регион, а так-же те слои, которые нужно будет смешать с этим регионом заново. Но в общем идея та же.
Учитывая, что там на заднем фоне крутится видео, во время проигрывания видео перерисовывать все-равно приходится каждый кадр. Кроме того, при двойной буферизации все немного сложнее: если что-то не поменялось, то это еще не означает, что его можно не перерисовывать.
ну и что, что на заднм фоне крутится видео. Если GUI не прозрачный, то можно и не перерисовывать ни видео и GUI. В представленном примере альфаканал есьт на всех элементах, поэтому прийдется перерисовывать и блендить все (именно для этого нужен DirectX/OpenGL — для быстрого бленда).
Если что-то не поменялось на самом верхнем уровне иерархии не прозрачного слоя — это однозначно определяет, что этот регион перерисовывать не нужно.
Если что-то не поменялось на самом верхнем уровне иерархии не прозрачного слоя — это однозначно определяет, что этот регион перерисовывать не нужно.
Да, ты прав. Блендить надо постоянно — при анимации контролов или при смене видео кадра.
изначально была идея сделать два слоя — один под видео, другой под элементы. И смешивать. Меня смутила мысль, что будет высокий pixel cost для полноэкранного режима. Каюсь, что не хватило времени на полноценное тестирование какой метод будет лучше, но думаю в будущем я займусь этим — впринципе сама отрисовка работает, и переделать придется не очень много.
изначально была идея сделать два слоя — один под видео, другой под элементы. И смешивать. Меня смутила мысль, что будет высокий pixel cost для полноэкранного режима. Каюсь, что не хватило времени на полноценное тестирование какой метод будет лучше, но думаю в будущем я займусь этим — впринципе сама отрисовка работает, и переделать придется не очень много.
разделение на слои и смешивание слоев апаратно, а не програмно — это единственный правильный путь. Например на ТВ приставках очень маленький ресурс CPU, но там отлично блендится видео с GUI. И практически во всех приставках используется одна схема: три аппаратных видеобуфера: видео, гуи, курсор. И вот они все аппаратными средствами блендятся.
Тут нужно делать то-же самое. По умолчанию все видобуферы DirectX находятся в видеопамяти и поэтому запись в нее в разы быстрее чем в обычную и операции по смешиванию двух видеобуферов производятся аппаратно. Это как раз соответсвует тому, как реализовано это на приставках.
Так что двигаетесь в правильном направлении.
Тут нужно делать то-же самое. По умолчанию все видобуферы DirectX находятся в видеопамяти и поэтому запись в нее в разы быстрее чем в обычную и операции по смешиванию двух видеобуферов производятся аппаратно. Это как раз соответсвует тому, как реализовано это на приставках.
Так что двигаетесь в правильном направлении.
я вспомнил кстати проблемы, с которыми я столкнулся при реализации двух слоев: там проблема со шрифтом. Когда я отрисовывал текст через ID3DXFont на альфа текстуру a8r8g8b8, то на граничных пикселях текста альфа значения имели некоторое промежуточное значение между 0 и 255, а потом при отрисовке с включенным блендингом к этим пограничным пикселям повторно применялось смешивание — в результате текст выглядел убого а регулировать параметры смешивания при отрисовке id3dxfont::drawtext не представляется возможным
Делаю что то похожее но для Digital Signage.
У меня правда получилось нечто похожее на браузер :-). И тут велосипед.
В общем сцена описывается в XML, элементами изображения могут быть видео, картинки, текст.
Все с альфаканалом. Из интерактивных элементов есть пока только кнопки.
Тут же прикручен JavaScript.
В качестве видео может быть — DirectShow источник, VLClib источник, просто устройство захвата видео.
Кроме того там же прямо в XML можно задать шейдер — для обрезки видео картинки по маске или наложения WaterMark на видео, в общем там много чего шейдерами делать можно.
А и да вся статика и сам XML подгружается по HTTP.
У меня правда получилось нечто похожее на браузер :-). И тут велосипед.
В общем сцена описывается в XML, элементами изображения могут быть видео, картинки, текст.
Все с альфаканалом. Из интерактивных элементов есть пока только кнопки.
Тут же прикручен JavaScript.
В качестве видео может быть — DirectShow источник, VLClib источник, просто устройство захвата видео.
Кроме того там же прямо в XML можно задать шейдер — для обрезки видео картинки по маске или наложения WaterMark на видео, в общем там много чего шейдерами делать можно.
А и да вся статика и сам XML подгружается по HTTP.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Видео-плеер на основе VLC. Часть 2: используем Direct3D