Профиль — это совокупность параметров закодированного потока, они могут меняться в довольно широких диапазонах. Изначально аппаратные декодировщики были заточены под параметры достаточные для стандарта blu-ray, но то что лежит на торрентах зачастую выходит за эти рамки. amd расширила возможности своего декодировщика достаточно давно и первой и добавила поддержку профиля high@L5.1 — это уже очень далеко выходит за рамки blu-ray. Это дало возможность воспроизводить почти все из того что на торрентах лежит. Что с этим у nvidia — я не знаю.
А в последнем абзаце я хотел сказать о том, что несмотря на то что железка переваривает профиль high@L5.1, препятствием к активации dxva ускорению может быть софт, который может посчитать, что данный поток не подейдет для dxva. Поделился тем, что с MS кодеком под mpc-hc с этим неплохо. Но эта ремарка уже по софту, а не железу.
Могу предложить из самого простого — например AMD HD6450. Самая дешевая карта из 6000-ой серии, много вариантов с пассивным охлаждением, hdmi почти на всех картах есть, а по декодированию — там стоит UVD3, который и на старших моделях. Сейчас разница в UVD чипах только от поколения к поколению, а так — от младшей до старшей модели с видео должно быть все примерно одинаково. Воспроизводить надо в плеерах с использованием аппаратного ускорения, загрузка на средних современных CPU будет порядка 5%.
Конечно можно и nvidia брать, единственный момент — amd первой ввела поддержку профиля High@L5.1, что дает больше шансов на то, что поток переварит аппаратный декодер. Я просто не в курсе как с этим сейчас у nvidia. nvidia может быть предпочтительней например для linux — у них там собственный api типа dxva, называется vdpau, его не поддерживает amd, amd вроде va-api поддерживает. Вобщем если linux — то там надо отталкиваться от плееров — будет ли он уметь делать акселерацию.
Бывает, что все-таки DXVA кодек отказывается принять поток, тогда два варианта — либо артефакты, либо будет осмысленный отказ и переключение на программный кодек. Я в основном сижу в mpc-hc с подключенным кодеком microsoft dtv-dvd h.264 и не замечал давно такого. А вот недавно поставил на другую машину mpc-hc и выяснил, что бывают потоки, которые отказывается принимать встроенный dxva кодек, а вот кодек microsoft прекрасно это дело обработал. Дело в том, что раньше многие просто отсекали от dxva потоки за пределами профиля L4.1 (blu-ray), ну или другая причина, просто не все фичи dxva покрыты во встроенном кодеке mpc-hc. Последний абзац — это уже не к оборудованию относится, а к выбору софта.
Речь изначально шла о WP. О планшетах я вспомнил в том ключе, что если ядра будут близки у WP8 и W8, то можно без особого труда запустить WP8 на x86. Запустить не для того, чтобы его использовать, а скорее для отладки, ведь когда речь шла о Hyper-V, то подразумевался сценарий отладки приложений на PC, но уже не в обычной виртуальной машине, а в гипервизоре, что намного быстрее. Но это все конечно гипотезы.
Что же касается перспектив Intel-а на рынке телефонов, то тут я согласен, что пока они только пытаются, конечных продуктов нет. Системы на чипе они тоже делают, графику давно интегрировали. Новый чип Atom Medfield, как раз будет SoC.
Я же не утверждаю, что у Intel-а это получится, но они пытаются. Прогресс с Atom-ом все же неверное есть за эти годы, хотя до телефонов он так и не дошел, это факт. Но есть еще планшеты, там intel то уж точно будет и если переход на общее ядро произойдет, то почему бы не запускать запустить Windows Phone на x86?
Кидать — это значит пообещать и не выполнить. В данном случае это обычная практика. В каких-то пределах обновления доступны, конечно же доступны фиксы, дальше — новая версия, новые функции, за это надо платить. Вот когда будет появляться софт, который разработан только для новой системы, то это будет не очень приятно пользователям, но это не будет сразу и к тому же производители софта должны тоже думать, чтобы не потерять рынок.
x86 пока вызвает ухмылку, потому как они так на рынок и не вышли. Очередной телефон показали на CES 2012, но журналистам его не дали и непонятно что там с батареей. С другой стороны — стоит только выпустить Intel нормальный процессор и какую-то часть рынка он завоюет, почему тогда WP туда не поставить?
Хороший вопрос. MS возможность обновления рекламировала и оно действительно работает, однако замена ядра — тут может быть посложнее. Хотя наверное с технической точки зрения это решаемый вопрос, но тут есть еще маркетинг. Новые устройства — новые продажи. Поживем, увидим. Конечно было бы неплохо обеспечить замену, как вариант — за деньги, если по функциям будет заметный скачок и железо будет подходить для новой системы.
Игры относятся к категории продуктов, которые разрабатываются огромным числом разработчиков, если их всех перевести в native окружение, то начнутся проблемы для платформы, при условии конечно, что это окружение выкидывает приложение за пределы песочницы.
Второй фактор — это портирование. Самим разработчикам игр не очень интересно прикладывать много усилий для переноса, поэтому managed окружение в этом смысле удобнее.
Специфика игр еще в том, что их запускают от раза к разу и поэтому стремительный расход батареи не так важен, как например при интенсивной работе того же skype чьи кодеки и шифрование весьма прожорливы и это даже на pc заметно. Игры конечно тоже имеют физику и AI, но довольно большой класс игр опирается в основном на графику, которая ускоряется аппаратно.
> Вы вообще ничего не поняли из моего первого комментария. Я нигде не предлагал грузить каждую динамическую библиотеку в отдельное адресное пространство.
Да, я неверно вас понял, вы говорили именно о хуках.
Но даже, если бы не было хука от Logitech, то в моем случае это не снимает проблемы которая описана в посте. Если исполняемый модуль зависел бы от нескольких компонент, а обычно так и есть, то нужно было бы следить, чтобы ни в коем случае не подгрузился msvcrt8 раньше явной подгрузки library.dll, что неудобно, т.к. те модули могут зависеть от других и т.д. Правильнее было бы полностью себя обезопасить от этого.
> Я сейчас специально посмотрел — в память редактора кода scite подгрузились сами собой такие библиотеки:
> dropboxext.13.dll
> thgshell.x86.dll (от TortoiseHg)
> intl3_tsvn.dll (от TortoiseSVN)
> libaprutil_tsvn.dll
> libapr_tsvn.dll
> tortoisesvn.dll
> tortoisestub.dll
> tortoiseoverlays.dll
> pshook.dll
Хуки были сделаны для перехвата очереди ввода, решение безусловно не самое удачное с точки зрения безопасности. Хотя сам механизм внедрения есть и в Linux — LD_PRELOAD, но не знаю используют ли его для перехвата ввода. В списке последняя dll видимо от punto switcher, другие может и не являются хуками, а грузятся по каким-то иным причнам? Тут надо взглянуть на дерево зависимостей. Не очень понятно зачем бы svn потребовалось перехватывать ввод. В целом мне кажется хуки не очень часто используются.
> В случае перехвата нажатий клавиш, то, что вы написали, это бред. Человек не способен нажимать клавиши с такой скоростью, чтобы это вызвало хоть сколько-нибудь значительные накладные расходы.
Я не говорил о перехвате нажатий клвиш, а в целом о любой задаче. Не все же существующие библиотеки обрабатывают нажатие клавиш. Даже в результате нажатия на клавишу может выполняться некое действие внутри которого будет обращение к десятку библиотек и если между ними всеми будет межроцессное взаимодействие, то время работы может неоправдано возрасти. Вызов становится тяжелым, требуется синхронизация, оборачивание и передача данных туда и обратно.
> Покажите мне, каким образом, например, браузер Opera зависит от модуля pshook.dll (PuntoSwitcher Hook), которые написали криворукие ребята из Яндекса?
Никаким. Забудем о хуках, таких библиотек может быть единицы в адресном пространстве. Кроме этого туда подгружена сотня других dll, с ними что прикажете делать?
И взаимодействовать с библиотеками только через межпроцессные каналы? Это влечет за собой слишком большие накладные расходы.
> В многозадачной системе процессы специально изолированы друг от друга, и эти виндовые трюки с подгрузкой чужих библиоткек (а также игры с вызовами типа read/writeprocessmemory) — нарушение этой изоляции.
Динамические библиотеки есть в unix (.so) и windows (.dll), непонятно чем здесь windows выделяется. Писать в адресное пространство чужого процесса конечно нехорошо, но причем здесь это?
Взять практически любой исполняемый модуль — он зависит от массы разных динамических библиотек, те в свою очередь от других. Это совершенно стандартная практика на всех платформах. Если я правильно понял вы предлагаете все грузить в отдельных процессах и пользоваться межпроцессным взаимодействием. По моему это неприемлемо в плане производительности.
> Я вообще не понимаю, как можно в код процесса подгружать стороннюю библиотеку
А куда ее тогда подгружать? Не понял смысла утверждения?
> Но справедливости ради, переменные окружения передаются в программу извне, и ставить их внутри самой программы через putenv() — это тоже неправильно. Вы должны конфигурировать библиотеку явно, через какую-нибудь функцию вроде fooLibraryInit({… configuration… } )
Такая вот библиотека, она получает конфигурацию частично через окружение. Там на самом деле еще хитрее — одна из подкомпонент, которая подгружается этой библиотекой так конфигурируется.
Да, я в курсе этих экспериментов с итераторами, мы вообще стараемся минимизировать использование STL. _SECURE_SCL=0 с самого начала везде поставили. Тут они пожертвовали производительностью в угоду безопасности. Согласен — делать по умолчанию это было нехорошо.
>Чтобы заставить четко работать медиатеку (распознавание названия и загрузка инф-ии из интернета), надо порядочно повозиться. Но > можно обойтись простой навигацией по файлам.
> Аж целый один раз назначить на папку обработчик. Проблемы начинаются в случае неправильных имен, тогда имена фильмов для поиска > нужно задавать вручную, а для серий сериалов да, прописывать строку обработки в конфиге.
Да, при большой коллекции часть определится неверно. У меня каждый фильм в отдельной папке, но часть документальных и мультфильмов сгруппированы, там получился бардак, т.к. название полезло из родительской папки. Коллекция на нескольких дисках и параллельное обновление почему-то прервалось (я добавил несколько источников) и пришлось перезапускать обновление. Потом с сериалами действительно надо еще разбираться. В какой-то момент появились дубли в медиатеке которые неудобно искать. Для удаления ссылок в пустоту надо специальную очистку запускать. Ну вобщем все объяснимо, но время придется потратить. Я ведь не хочу сказать что xbmc плохой, нет, очень даже отличный медиацентр, если не лучший.
>Навигация по медиатеке довольно разнообразна, но не хватает продвинутой фильтрации и поиска, это будет актуально, если фильмов много.
> O_o
> Поиск куда уж продвинутей. По жанру, по актерам, режиссерам, даже по описанию.
Поиск хотелось бы по комбинации параметров и чтобы они были видны. Было бы удобнее чтобы можно было задавать комбинацию фильтров и делать view на основе запроса. Например взять и быстро добавить фильтр по стране или актеру или разрешению. Это было бы прозрачно и удобно. Еще пример из описания фильма я вижу актера но не могу щелкнуть по нему и попасть на список фильмов с ним.
> Для медиатеки хотелось бы иметь поля пользователя, чтобы можно было более эффективно фильтровать.
> Имеющейся фильтрации лично мне предостаточно. Я даже не представляю, что вы за поля хотите добавить.
Обычно в медиаколлекциях дают такое делать и это правильно. Простой пример — посмотрел/не посмотрел — это они сделали, но ведь раньше вроде этого не было. Ну на вскидку я могу предложить такой вариант — тег с собственным рейтингом или пометка категории например хочет кто-то из близких посмотреть. Если в гости придет, сразу на это множество выходишь.
> Управление больше заточено под пульт, с клавиатуры не все можно быстро сделать.
> С клавиатуры можно сделать больше, чем с пульта, если что есть конфиг. А вот мышью да, особо не попрыгаешь.
Тут вобщем тоже все достаточно нормально, но например чтобы выбрать дорожку или субтитры было бы приятнее видеть список а не перебирать их циклически. Или например плавное масштабирование на кнопке а не через отдельный пункт в меню, или еще вариант — нет перемотки мышкой по полосе прокрутки.
Еще раз повторю — программа отличная, но я пока ощущаю некоторую несвободу находясь в ней. Может надо привыкнуть.
Профиль — это совокупность параметров закодированного потока, они могут меняться в довольно широких диапазонах. Изначально аппаратные декодировщики были заточены под параметры достаточные для стандарта blu-ray, но то что лежит на торрентах зачастую выходит за эти рамки. amd расширила возможности своего декодировщика достаточно давно и первой и добавила поддержку профиля high@L5.1 — это уже очень далеко выходит за рамки blu-ray. Это дало возможность воспроизводить почти все из того что на торрентах лежит. Что с этим у nvidia — я не знаю.
А в последнем абзаце я хотел сказать о том, что несмотря на то что железка переваривает профиль high@L5.1, препятствием к активации dxva ускорению может быть софт, который может посчитать, что данный поток не подейдет для dxva. Поделился тем, что с MS кодеком под mpc-hc с этим неплохо. Но эта ремарка уже по софту, а не железу.
Конечно можно и nvidia брать, единственный момент — amd первой ввела поддержку профиля High@L5.1, что дает больше шансов на то, что поток переварит аппаратный декодер. Я просто не в курсе как с этим сейчас у nvidia. nvidia может быть предпочтительней например для linux — у них там собственный api типа dxva, называется vdpau, его не поддерживает amd, amd вроде va-api поддерживает. Вобщем если linux — то там надо отталкиваться от плееров — будет ли он уметь делать акселерацию.
Бывает, что все-таки DXVA кодек отказывается принять поток, тогда два варианта — либо артефакты, либо будет осмысленный отказ и переключение на программный кодек. Я в основном сижу в mpc-hc с подключенным кодеком microsoft dtv-dvd h.264 и не замечал давно такого. А вот недавно поставил на другую машину mpc-hc и выяснил, что бывают потоки, которые отказывается принимать встроенный dxva кодек, а вот кодек microsoft прекрасно это дело обработал. Дело в том, что раньше многие просто отсекали от dxva потоки за пределами профиля L4.1 (blu-ray), ну или другая причина, просто не все фичи dxva покрыты во встроенном кодеке mpc-hc. Последний абзац — это уже не к оборудованию относится, а к выбору софта.
Что же касается перспектив Intel-а на рынке телефонов, то тут я согласен, что пока они только пытаются, конечных продуктов нет. Системы на чипе они тоже делают, графику давно интегрировали. Новый чип Atom Medfield, как раз будет SoC.
Второй фактор — это портирование. Самим разработчикам игр не очень интересно прикладывать много усилий для переноса, поэтому managed окружение в этом смысле удобнее.
Специфика игр еще в том, что их запускают от раза к разу и поэтому стремительный расход батареи не так важен, как например при интенсивной работе того же skype чьи кодеки и шифрование весьма прожорливы и это даже на pc заметно. Игры конечно тоже имеют физику и AI, но довольно большой класс игр опирается в основном на графику, которая ускоряется аппаратно.
Да, я неверно вас понял, вы говорили именно о хуках.
Но даже, если бы не было хука от Logitech, то в моем случае это не снимает проблемы которая описана в посте. Если исполняемый модуль зависел бы от нескольких компонент, а обычно так и есть, то нужно было бы следить, чтобы ни в коем случае не подгрузился msvcrt8 раньше явной подгрузки library.dll, что неудобно, т.к. те модули могут зависеть от других и т.д. Правильнее было бы полностью себя обезопасить от этого.
> Я сейчас специально посмотрел — в память редактора кода scite подгрузились сами собой такие библиотеки:
> dropboxext.13.dll
> thgshell.x86.dll (от TortoiseHg)
> intl3_tsvn.dll (от TortoiseSVN)
> libaprutil_tsvn.dll
> libapr_tsvn.dll
> tortoisesvn.dll
> tortoisestub.dll
> tortoiseoverlays.dll
> pshook.dll
Хуки были сделаны для перехвата очереди ввода, решение безусловно не самое удачное с точки зрения безопасности. Хотя сам механизм внедрения есть и в Linux — LD_PRELOAD, но не знаю используют ли его для перехвата ввода. В списке последняя dll видимо от punto switcher, другие может и не являются хуками, а грузятся по каким-то иным причнам? Тут надо взглянуть на дерево зависимостей. Не очень понятно зачем бы svn потребовалось перехватывать ввод. В целом мне кажется хуки не очень часто используются.
Я не говорил о перехвате нажатий клвиш, а в целом о любой задаче. Не все же существующие библиотеки обрабатывают нажатие клавиш. Даже в результате нажатия на клавишу может выполняться некое действие внутри которого будет обращение к десятку библиотек и если между ними всеми будет межроцессное взаимодействие, то время работы может неоправдано возрасти. Вызов становится тяжелым, требуется синхронизация, оборачивание и передача данных туда и обратно.
> Покажите мне, каким образом, например, браузер Opera зависит от модуля pshook.dll (PuntoSwitcher Hook), которые написали криворукие ребята из Яндекса?
Никаким. Забудем о хуках, таких библиотек может быть единицы в адресном пространстве. Кроме этого туда подгружена сотня других dll, с ними что прикажете делать?
И взаимодействовать с библиотеками только через межпроцессные каналы? Это влечет за собой слишком большие накладные расходы.
> В многозадачной системе процессы специально изолированы друг от друга, и эти виндовые трюки с подгрузкой чужих библиоткек (а также игры с вызовами типа read/writeprocessmemory) — нарушение этой изоляции.
Динамические библиотеки есть в unix (.so) и windows (.dll), непонятно чем здесь windows выделяется. Писать в адресное пространство чужого процесса конечно нехорошо, но причем здесь это?
Взять практически любой исполняемый модуль — он зависит от массы разных динамических библиотек, те в свою очередь от других. Это совершенно стандартная практика на всех платформах. Если я правильно понял вы предлагаете все грузить в отдельных процессах и пользоваться межпроцессным взаимодействием. По моему это неприемлемо в плане производительности.
А куда ее тогда подгружать? Не понял смысла утверждения?
> Но справедливости ради, переменные окружения передаются в программу извне, и ставить их внутри самой программы через putenv() — это тоже неправильно. Вы должны конфигурировать библиотеку явно, через какую-нибудь функцию вроде fooLibraryInit({… configuration… } )
Такая вот библиотека, она получает конфигурацию частично через окружение. Там на самом деле еще хитрее — одна из подкомпонент, которая подгружается этой библиотекой так конфигурируется.
> Аж целый один раз назначить на папку обработчик. Проблемы начинаются в случае неправильных имен, тогда имена фильмов для поиска > нужно задавать вручную, а для серий сериалов да, прописывать строку обработки в конфиге.
Да, при большой коллекции часть определится неверно. У меня каждый фильм в отдельной папке, но часть документальных и мультфильмов сгруппированы, там получился бардак, т.к. название полезло из родительской папки. Коллекция на нескольких дисках и параллельное обновление почему-то прервалось (я добавил несколько источников) и пришлось перезапускать обновление. Потом с сериалами действительно надо еще разбираться. В какой-то момент появились дубли в медиатеке которые неудобно искать. Для удаления ссылок в пустоту надо специальную очистку запускать. Ну вобщем все объяснимо, но время придется потратить. Я ведь не хочу сказать что xbmc плохой, нет, очень даже отличный медиацентр, если не лучший.
>Навигация по медиатеке довольно разнообразна, но не хватает продвинутой фильтрации и поиска, это будет актуально, если фильмов много.
> O_o
> Поиск куда уж продвинутей. По жанру, по актерам, режиссерам, даже по описанию.
Поиск хотелось бы по комбинации параметров и чтобы они были видны. Было бы удобнее чтобы можно было задавать комбинацию фильтров и делать view на основе запроса. Например взять и быстро добавить фильтр по стране или актеру или разрешению. Это было бы прозрачно и удобно. Еще пример из описания фильма я вижу актера но не могу щелкнуть по нему и попасть на список фильмов с ним.
> Для медиатеки хотелось бы иметь поля пользователя, чтобы можно было более эффективно фильтровать.
> Имеющейся фильтрации лично мне предостаточно. Я даже не представляю, что вы за поля хотите добавить.
Обычно в медиаколлекциях дают такое делать и это правильно. Простой пример — посмотрел/не посмотрел — это они сделали, но ведь раньше вроде этого не было. Ну на вскидку я могу предложить такой вариант — тег с собственным рейтингом или пометка категории например хочет кто-то из близких посмотреть. Если в гости придет, сразу на это множество выходишь.
> Управление больше заточено под пульт, с клавиатуры не все можно быстро сделать.
> С клавиатуры можно сделать больше, чем с пульта, если что есть конфиг. А вот мышью да, особо не попрыгаешь.
Тут вобщем тоже все достаточно нормально, но например чтобы выбрать дорожку или субтитры было бы приятнее видеть список а не перебирать их циклически. Или например плавное масштабирование на кнопке а не через отдельный пункт в меню, или еще вариант — нет перемотки мышкой по полосе прокрутки.
Еще раз повторю — программа отличная, но я пока ощущаю некоторую несвободу находясь в ней. Может надо привыкнуть.