Intel как раз на 720p должен что-то уметь, может не все модели (их там много), но точно может. А судя по размеру — это наверняка 720p или низкий битрейт для 1080p.
Есть такой факт — очень сложно обновлять библиотеку в бинарном виде, сохраняя ее API и при этом не вызвать проблем. Даже исправление ошибки может привести к проблеме в пользовательском коде. Поэтому, то что делают с libc — это нечто героическое. Я слышал на эту тему историю с приложениями под meego — был апдейт qt библиотек, который привел к проблемам с частью софта. Идея была та-же — мы ничего не меняли, а только улучшили, не меняя версию. Вот это пример таких граблей. Конечно libc меняют реже и очень тщательно вылизывают, но гарантий все равно нет. Надежный способ — это версионирование, так поступают и в managed языках, компоненты четко версионируются, включая базовые библиотеки.
Теперь о культуре. Есть API и он реализуется библиотекой, это первое, второе — авторы сразу сказали, что версии будут меняться, при этом максимально сохраняя преемственость. Тут все ясно и понятно, такой путь реализуют большинство разработчиков компонент.
Про стандарты тут спорить не буду. Microsoft развязал себе руки, сделал так как им удобнее и гибче, плюс политические мотивы. Но надо сказать, что в мире UNIX наличие стандартов не решает всех проблем, портирование все равно является головной болью.
В windows они оставили за собой право менять версии библиотек и при этом не сохранять бинарную совместимость и я считаю, что это верно, иначе никакого развития библиотеки не получилось бы. Одна из сторон DLL hell как раз состоит в том, что иногда пытались подменить одну библиотеку на другую якобы сохраняя совместимость. На практике это очень и очень сложно, т.к. код может быть завязан даже на ошибки, которые после исправления приведут к проблемам. Короче говоря должно быть четкое версионирование, это было сразу заложено в имени библиотеки, но это и другая культура разработки, надо понимать, что каждый модуль имеет свою CRT и надо думать об аллокаторах, не использовать FILE* и пр.
С другой стороны DLL hell забороли тотальным версионированием, которое уже давно работает для DLL. Рекомендуется private развертывание, когда копируется все в папку с кодом, остальное работает через winsxs куда попадает куча разных вариантов зарегистрированных библиотек.
Кстати механизм форсированной подмены есть и в winsxs и наверное его иногда применяют.
1) Попробовать форсировать MS H.264, он есть в Windows 7 (View/Options/External Filters – добавить MS DTV-DVD Video Decoder, сделать его Prefer, в Internal Filters отключить встроенный H264)
2) Render pipeline в Windows 7 по умолчанию должен быть EVR Custom Pres, можно еще попробовать EVR Custom Sync
3) Поставить текущий directx runtime — он без перезагрузки ставится с MS. При установке MPC-HC предупреждает, что надо обновить, видимо были у пользователей проблемы.
Ну и еще вопрос — как на других H.264 видео работает?
Сейчас проверил на машине с Windows 7 x64, на которой не было MPC-HC. Видеокарта AMD HD6850.
1) Поставил MPC-HC x64
2) Запустил, он предупредил, что нужно обновить directx, поставил с MS текущий directx runtime.
3) Снова запустил MPC-HC, обратил внимание, что рендер он выставил EVR Custom Pres (там в сноске написано, что нужен для титров)
4) Открыл full hd фильм, титры работают, но в строке статуса нет DXVA, и в опциях фильтра ffdshow серая галочка у DXVA, видимо поток посчитал не подходящим
5) В опциях добавил prefer для MS DTV-DVD H.264
6) Перезапустил — все работает, пишет в строке статуса, что DXVA задействовано
Вот кстати столкнулся с проблемой о которой забыл — иногда DXVA не врубается, если сам кодек не хочет брать поток. Такое я раньше видел, но с MS H.264 вроде этого не замечал. И с VLC тоже.
Тут безусловно есть некое трюкачество, но это очень простой и компактный вариант, удобен тем, что не приходится выделять еще один модуль, экспортировать ф-ии и пр. только ради утсановки окружения. Зашаривать это решение не нужно и не думаю что когда либо потребуется. Выходит, что это делается ради единственной цели и в таком случае наше решение на мой взгляд оправдано. Приложение небольшое, пока библиотеки не грузит, поэтому первый экземпляр никому не мешает. Все это живет только на время выполнения некоторого непродолжительного действия.
Если есть видеокарта amd или nvidia, то наверняка будет хорошо работать dxva (тут лучше все-таки уточнить вашу видеокарту, может старая). Если есть dxva, то будет все гладко.
1) MPC-HC имеет встроенные кодеки dxva
2) MPC-HC плюс опция для использования MS H.264 (только Windows 7) (см. текст поста)
2) vlc, включить опцию GPU… (см текст поста) — будет задействовать dxva
3) wmp использует MS кодек с dxva
Если dxva нет, то можно попробовать искать быстрый декодер. Вот тут хвалят coreavc, но это не дает никаких гарантий, все равно могут выпадать кадры.
QT — это MOV, если я верно понял, т.е. QuickTime? Очень странно, обязано работать, я и сам иногда смотрю трейлеры в mov контейнере. Вот тут список фич:
Этот процесс уже был отдельным (был и родитель) и служил только одной цели — выполнить некое сложное действие с использованием сторонней библиотеки. Дело в том, что настройка окружения этой библиотеки дело не очень простое, там десяток переменных и ряд других настроек, поэтому все было в этот модуль помещено. Родитель не знает специфику и там эти настройки архитектурно делать неверно. Сделать их один раз перманентно и сохранить тоже нельзя, т.к. раз от раза могут меняться параметры.
В итоге сделали так — этот процесс в начале конфигурируется потом запускает второй экземпляр самого себя и уже в нужном окружении делает загрузку библиотеки и остальные шаги.
Я выше отметил, что для MPC-HC под Windows 7 такого вроде не происходит, все по умолчанию верно выбирается. Мне кажется MPC просто иначе тут себя ведет.
Можно конечно, но это уже слишком изощренно. К тому-же та библиотека тоже обновляется и они могут вдруг перейти на другую версию CRT. Проще и правильнее все установить в родителе.
Т.е. и в Linux может возникать проблема с разными библиотеками? К примеру сторонняя библиотека давно не менялась и зависит от одной версии libc, а разрабатываемая уже от другой. Или такое на практике пресекается и никто это не поддерживает?
Выбор render pipeline у него есть, но я такого окна вроде не замечал. Тут две версии — вы ставите MPC, а не MPC-HC — это разные все-таки плееры. Мне кажется что как минимум под Windows 7 ставится EVR рендер по умолчанию и никаких вопросов не возникает.
По вашим замечаниям — согласен, если для вас критично это, то это недостатки. Ну тогда про любой плеер можно много чего сказать. В wikipedia можно открыть таблицу сравнения плееров, там будет на несколько экранов опций. Работают эти опции по разному и юзабилити разный.
Вроде бы ситуация была такая — поддержка DVD в mplayer не полная (работа с интерактивным меню), поэтому они и стали использовать DVDPlayer. Что же касается H.264, то там DVDPlayer не причем. Я могу ошибаться, но у меня такое впечатление было, т.к. я читаю некоторые новости по этим проектам.
Спорить не буду, можно сказать что в корне, все зависит от расстановки акцентов. Я понимаю, что это дальнейшее развитие, добавление новых функций, но большая часть кода там от MPC-HC и интерфейс тоже.
Теперь о культуре. Есть API и он реализуется библиотекой, это первое, второе — авторы сразу сказали, что версии будут меняться, при этом максимально сохраняя преемственость. Тут все ясно и понятно, такой путь реализуют большинство разработчиков компонент.
Про стандарты тут спорить не буду. Microsoft развязал себе руки, сделал так как им удобнее и гибче, плюс политические мотивы. Но надо сказать, что в мире UNIX наличие стандартов не решает всех проблем, портирование все равно является головной болью.
С другой стороны DLL hell забороли тотальным версионированием, которое уже давно работает для DLL. Рекомендуется private развертывание, когда копируется все в папку с кодом, остальное работает через winsxs куда попадает куча разных вариантов зарегистрированных библиотек.
Кстати механизм форсированной подмены есть и в winsxs и наверное его иногда применяют.
1) Попробовать форсировать MS H.264, он есть в Windows 7 (View/Options/External Filters – добавить MS DTV-DVD Video Decoder, сделать его Prefer, в Internal Filters отключить встроенный H264)
2) Render pipeline в Windows 7 по умолчанию должен быть EVR Custom Pres, можно еще попробовать EVR Custom Sync
3) Поставить текущий directx runtime — он без перезагрузки ставится с MS. При установке MPC-HC предупреждает, что надо обновить, видимо были у пользователей проблемы.
Ну и еще вопрос — как на других H.264 видео работает?
1) Поставил MPC-HC x64
2) Запустил, он предупредил, что нужно обновить directx, поставил с MS текущий directx runtime.
3) Снова запустил MPC-HC, обратил внимание, что рендер он выставил EVR Custom Pres (там в сноске написано, что нужен для титров)
4) Открыл full hd фильм, титры работают, но в строке статуса нет DXVA, и в опциях фильтра ffdshow серая галочка у DXVA, видимо поток посчитал не подходящим
5) В опциях добавил prefer для MS DTV-DVD H.264
6) Перезапустил — все работает, пишет в строке статуса, что DXVA задействовано
Вот кстати столкнулся с проблемой о которой забыл — иногда DXVA не врубается, если сам кодек не хочет брать поток. Такое я раньше видел, но с MS H.264 вроде этого не замечал. И с VLC тоже.
1) MPC-HC имеет встроенные кодеки dxva
2) MPC-HC плюс опция для использования MS H.264 (только Windows 7) (см. текст поста)
2) vlc, включить опцию GPU… (см текст поста) — будет задействовать dxva
3) wmp использует MS кодек с dxva
Если dxva нет, то можно попробовать искать быстрый декодер. Вот тут хвалят coreavc, но это не дает никаких гарантий, все равно могут выпадать кадры.
mpc-hc.sourceforge.net/media-player-features.html
В итоге сделали так — этот процесс в начале конфигурируется потом запускает второй экземпляр самого себя и уже в нужном окружении делает загрузку библиотеки и остальные шаги.
По вашим замечаниям — согласен, если для вас критично это, то это недостатки. Ну тогда про любой плеер можно много чего сказать. В wikipedia можно открыть таблицу сравнения плееров, там будет на несколько экранов опций. Работают эти опции по разному и юзабилити разный.