Создание HTPC: что для этого необходимо?

badguy,

Блин встроенный в видеокарту кодек не всегда лучший по качеству. Если погуглите - легко найдете сравнение кодеков mpeg2.

Wolfheart, для мпег2 в разрешении ХД разницы вы фактически не увидите. вот для SD - да. там она может быть коллосальной при правильной программной постобработке. а на ХД - фиг. ибо кодек такой, не точился он под высокие разрешения изначально. поэтому испоганить картинку сильно не могёт, но при этом зато поток весьма толстый получается. для ХД нужны совсем другие кодеки, которые для него гораздо более приспособлены. вот они дают при малом потоке весьма качественную картинку. а с мпег2 ХД - либо зажмёшь до низкой скорости и никакая постобработка не спасёт, либо толстый поток и постобработка уже не нужна. к тому же пользуют его только единицы, типа кривых сат-провайдеров. поэтому повода для написания декодера под мпег2 с использованием cuda для софтописателей особого смысла нету. вот энкодеры - да. пишут, и весьма активно. ибо это позволяет получить ускорение в кодировании видео в 5-10 раз. а распаковка видео - главное что бы в реалтайме успевало. 45% загрузки - это двойной запас для реалтайма.

bogeyman, разница скорее всего в прошивке декодера. точнее в алгоритме. плюс зашитых параметрах по умолчанию. точно так же как два ЖКИ телевизора с одной и той же матрицей (матрицы делают не так много производителей), но от разных производителей и на разных шасси - будут выдавать разную картинку.

да и у тех же самсунгов или лыж настройки картинки по умолчанию для европы и для азии разные. хотя телевизоры могут быть ну абсолютно одинаковые в плане железа.

да и что говорить - та же картинка на одном и том же компе с одним и тем же монитором при использовании аппаратного декодирования в зависимости от видеокарты будет разной. даже в пределах одного производителя видюх. вот если пару монитор-видюха откалибровать по цветовым схемам и использовать программное декодирование - тогда да. картинка будет одинаковая.

bogeyman, так как кодирование видео в рассматрвиаемом нами случае - это кодирование с потерями. то логично предположить что при восстановлении картинки могут применятся различные алгоритмы (точнее их различные реализации которые оптимизированы под разные мощности). которые зависят от некоторых заложенных разработчиком констант плюс основываясь на некоторых ранее полученных результатах обработки. плюс к этому - каждая железная реализация - есть оптимизация исходного алгоритма под мощности железа. часть кода могут просто напросто убрать, дабы увеличить быстродействие либо уменьшить объём используемой памяти. при этом мы получим небольшое ухудшение картинки. а другие могут например наоборот - за счет того что железо имеет больший потенциал - реализовать дополнительные фичи, типа улучшайзерных фильтров.

и всё это основано на том что картинка сжата с потерями. ибо видео сжатое без потер занимает в разы больше места. при этом качество не настолько становится лучше чем сжатое спецалгоритмами. это как картинка в pcx или сжатом bmp и в jpeg. на экране разница видна только при пристальном изучении (если не переборщить к качеством). а размер - в разы, иногда в десятки а то и сотни раз.

badguy,

вот для SD - да. там она может быть коллосальной при правильной программной постобработке.

Я в общем-то в курсе. Именно поэтому и говорю, что можно было бы и реализовать средствами CUDA. Хотя, учитывая повальный переход на HD - едва ли кому-то из коммерческих производителей это интересно. Если только ffdshow реализует...

То есть декодер должен восстановить один к одному поток, сформированный кодером. Другое дело, что один декодер требует большей вычислительной мощности, а другой - меньшей.

еще постпроцессинг есть в ряде чипов - правда работает ли он для HD я не в курсе

bogeyman, дык из потока цифры то и извлекаюццо одинаково у всех. но потом над этими цифрами специальными математическими алгоритмами производятся вычисления и уже потом строится картинка. если процессорной мощности и памяти у нас валом - можем разжать максимально близко к оригиналу. а если нет? ресивер то не совсем комп, там процессор имеет определённые пределы производительности и они не сильно велики. вот программеры и оптимизируют. например давайте вам дадут задание перемножить 5 десятичных дробей, у каждой из которых 5 знаков после запятой. а затем те же числа, но округлив до трёх знаков после запятой. и еще раз округлив до одной циферкой после запятой. теперь сравните скорость с какой вы это посчитаете на листике и итоговую точность. и в программировании часто так бывает. иногда точностью данных в расчетах можно пренебречь до определённого предела. и этим выгадать в скорости расчетов и/или объёме памяти. вот там алгоритм упростили, картинку получили, чуть хуже чем в оригинале. зато девайс - в полтора раза дешевле чем у конкурентов с чуть лучшей картинкой (которую всё равно 90% покупателей не отличат).

bogeyman,

Я всегда думал, что при декодировании изображение восстанавливается исключительно до тех цифр после запятой, которые были вложены в поток. То есть не путем алгоритмов восстановления с превнесением дополнительной информации, а путем тупого перевода цифр потока в яркость субпикселя и тд. (разумеется, после восстановления полных кадров)

Еще раз - все абсолютно все медиаисточники - будь то DVD, Blue Ray, Sat или что-то иное - содержат информацию, пожатую с потерями, поэтому восстановление пиксель-в-пиксель к исходному материалу - невозможно. Именно поэтому кодеки и отличаются по качеству.

Wolfheart, я понимаю, что пожатого с потерями. Но незаметными глазу. И восстанавливается декодером не до исходного видео, а до пожатого кодером. Но цифра в цифру. Поэтому я не понимаю, что собственно может один декодер сделать лучше другого в плане детализации, глубины цвета. Может только ухудшить (пропустить кадры или выдать искажения), если не хватит производительности. Но это мое мнение, возможно, ошибочное.

bogeyman, да забудьте вы про картинку. ни кодер, ни декодер вообще не знают что есть картинка. это программы. и у них есть набор цифр. по каком-то специальноразработанным алгоритмам эти цифры преобразуются и получаем другой набор, гораздо меньший по объёму. при этом если мы будет изменять параметры качества и прочего в настройках кодера - то и наборы мы получим на выходе разные. но - главное одно - все они соответствуют определённым правилам. и этот алгоритм сжатия весьма ресурсоёмкий.

а при раскодировке мы эти цифры должны восстановить по другим специальноразработанным алгоритмам. которые как раз и предназначены из этого набора получить в итоге картинку, максимально похожую на исходный набор данных (хотя в реальности ни в одной точке не будет совпадения по цвету). этот алгоритм тоже весьма ресурсоёмкий, если восстанавливать по максимуму. там много циклов в которых считаются какие-то числа, необходимые для вычисление конечных данных. и как я уже говорил - можно взять и цикл прокрутить меньшее число раз. для того кто хоть немного высшую математику в вузе слушал - для того не секрет например что существуют ряды (фурье, лагранжа и прочих). про то что при помощи рядов можно описать в принципе любую аналитическую функцию с определённым уровнем точности. и затем вычислить эту функцию. я не говорю уже про интегралы, особенно несобственные. во всех этих методах вычисления чем больше итераций мы сделаем - тем точнее результат получим. но! если нам хватает указанной точности, то можно сделать достаточно малое количество итераций. но это чистая математика. а у нас процессор, у которого есть пределы производительности, плюс у нас есть еще таймлимит, мы должны хоть сдохнуть, но выдать положенные 10-20-30 кадров в секунду. следовательно на вычисление кадра у нас есть не более определённого интервала времени. и согласитесь что процессор имеющий на порядок большую производительность сможет сделать итераций при расчетах на порядок больше. за ту же самую единицу времени. а раз точнее результат вычисления - следовательно и картинка итоговая будет ближе к оригиналу.