|
|
|
WertyJ
Стаж: 15 лет 5 месяцев Сообщений: 96
|
WertyJ ·
14-Май-12 00:12
(13 лет 4 месяца назад)
GlintBeer
Сегодня все сделал повторно - не помогло.
Руки не кривые, эта инструкция г*8но.
А тебе спасибо, что потратил на меня свое время 
|
|
|
|
GlintBeer
Стаж: 16 лет Сообщений: 222
|
GlintBeer ·
14-Май-12 00:24
(спустя 11 мин.)
WertyJ
Другой плеер пробовал? Попробуй написать в ветке сборок КМП или Пот там есть люди которые на таких вещах собаку съели. Правда там и плееры соотвествующие обсуждаются.
или
Скачай новый, любой из плееров и не парься, должно и так работать
|
|
|
|
ъыь
Стаж: 17 лет 5 месяцев Сообщений: 337
|
ъыь ·
14-Май-12 01:12
(спустя 48 мин., ред. 14-Май-12 01:12)
|
|
|
|
GlintBeer
Стаж: 16 лет Сообщений: 222
|
GlintBeer ·
14-Май-12 01:30
(спустя 18 мин., ред. 14-Май-12 01:30)
ъыь Это полагаю с MadVR+DXVAcb? Ну у тебя там и понаоткрыто
600mhz это предел для ядра? думаю нет а теперь тоже самое для софдекодера.
А чего данные разные у мониторов?
|
|
|
|
ъыь
Стаж: 17 лет 5 месяцев Сообщений: 337
|
ъыь ·
14-Май-12 01:54
(спустя 23 мин., ред. 14-Май-12 01:54)
GlintBeer писал(а):
Это полагаю с MadVR+DXVAcb?
да
GlintBeer писал(а):
Ну у тебя там и понаоткрыто
это ещё мало 
GlintBeer писал(а):
600mhz это предел для ядра?
и снова отчёт аиды
Код:
[ PCI Express 2.0 x16: ATI Radeon HD 5570 ]
Свойства графического процессора:
Видеоадаптер ATI Radeon HD 5570
Версия BIOS 012.017.000.004.035522
Дата BIOS 12/13/09 22:22
Кодовое название ГП Redwood Pro
Шифр компонента 113-C02101-100
PCI-устройство 1002-68D9 / 1787-2293 (Rev 00)
Число транзисторов 627 млн.
Технологический процесс 40 nm
Размер кристалла 104 mm2
Тип шины PCI Express 2.0 x16 @ x16
Объем видеоОЗУ 1 Гб
Частота ГП 600 МГц (исходное: 650 MHz)
Частота RAMDAC 400 МГц
Пиксельные конвейеры 16
TMU на конвейер 1
Объединённые шейдеры 400 (v5.0)
Аппаратная поддержка DirectX DirectX v11
Пиксельная скорость заполнения 9600 Мпиксел/с
Свойства шины памяти:
Тип шины GDDR3
Ширина шины 128 бит
Реальная частота 899 МГц (DDR) (исходное: 900 MHz)
Эффективная частота 1798 МГц
Пропускная способность 28.1 Гб/с
Загрузка:
Графический процессор 15%
ATI PowerPlay (BIOS):
State #1 Графический процессор: 650 МГц, Память: 900 МГц (Boot)
State #2 Графический процессор: 650 МГц, Память: 900 МГц
State #3 Графический процессор: 600 МГц, Память: 900 МГц (UVD)
State #4 Графический процессор: 650 МГц, Память: 900 МГц
State #5 Графический процессор: 157 МГц, Память: 200 МГц
стоит полагать, что включился State #3
GlintBeer писал(а):
А чего данные разные у мониторов?
всмысле разные для двух скринов? это потому, что я gpu-z прогнал после первого скрина, минут через 5 интересно, что он показал бОльшую нагрузку на GPU. но если посмотреть на данные Engine 2 с первого скрина, то становится ясно, что он отдаёт самое большое значение, а не среднее по трём, эээ, ядрам (или что там подразумевается под engine?)
GlintBeer писал(а):
а теперь тоже самое для софдекодера
пожалуйте
значения на всех скринах хуже, чем есть на самом деле. когда окно плеера в фокусе, то дропов на софте практически нет
|
|
|
|
degifly
Стаж: 15 лет Сообщений: 951
|
degifly ·
14-Май-12 02:14
(спустя 20 мин., ред. 14-Май-12 02:14)
BalticX писал(а):
Так, а как насчёт EVR CP? Практически те же скейлеры и обработка до 32 float.
щито? Я что-то там ланкзос не вижу. Как и высокой точности обработки с дизерингом в конце. Как и поддержки форматов, отличных от 8-битного 4:2:0.
ъыь писал(а):
печально как-то. неужели там льётся поток в более чем (в случае с 1080p) 28 гектар в секунду?
реальные скорости гораздо ниже и зависят от очеень многих факторов.
Например по бенчмаркам тут моя 5870 показала ~700 МБ/c (а на некоторых системах было и <400), а 5570 у одного человека ~300 МБ/c. А 1920 x 1080 x 1,5 байт x 30фпс = 85 МБ/c. Так что скорости вполне сопоставимые (учитывая всякие туда-сюда и неоптимальности).
|
|
|
|
GlintBeer
Стаж: 16 лет Сообщений: 222
|
GlintBeer ·
14-Май-12 05:05
(спустя 2 часа 51 мин., ред. 14-Май-12 05:05)
Цитата:
не среднее по трём, эээ, ядрам (или что там подразумевается под engine)
Ядро одно, это в лучшем случае блоки (шейдерный, который кстати и занимается обработкой, и т.п.), но вряли. у тебя там встроенной нету видеокарты никакой? И на воспрозведение ничё не влияет? всякие там постобработки от ff.
Нагрузка на ядро нормальная, но теперь ясно, что вся проблема именно в связке 1080+DXVAcb+madvr. правда легче от этого не ставновится. DXVA слишком "узкий" кадры через него не пролазят. А так я у себя добился, чтобы играло 1080+MadVR: вырубил DXVA и поставил простую интерполяцию - билинейную. поёт правда с нагрузкой в 90% для СPU и 50 для GPU.
непонятно касательно DXVA или чегото пропускной способностью (хех, если дело всётаки в ней) делает: на себя тратит или просто косяк с совместимостью? или же он просто очмедленно декодирует (опять же изза совместимости)? Если софтово madvr+1080 работает нормально, оставь так. поставь скейлеры попроще (рекомендую для НАЧАЛА для яркости Бикубик 100, а для цвета софткубик 100), буферы можешь попробовать вообще на макс выкрутить, правда следи чтобы видеопамяти хватало. Вобщем настрой рендер под себя.
Странно, у меня при отключении DXVA карта выдаёт максчастоты и по памяти и по ядру, у тебя ядро же остаётся с 600 как и с ускорением. (правда там потолок на 50 больше)
EVR (и просто и CP) ещё умеют выводить в 4:2:2 и 4:4:4 (а кому это нада?), но вся обработка видео там "8битная", по этому он и выводит только в 8битных пространствах. У них лучший скейл бикубик, ксатити не самый плохой, а ланцош суров очень, там кошмарная (да ещё и модифицированная) функция для интерполяции используется. МadVR же наоборот только в 4:2:0 (обоснованно, тк почти всем пользователям другого не нада)"16битная" обработка жрёт очмного ресурсов +перевод "из" и "в", зато может выводить полноценные 16бит, только вот куда и кому :). Как следствие из-за высокой точности "кадры больше весят", возможно поэтому возникает большая разница между 1080 и 720.
|
|
|
|
degifly
Стаж: 15 лет Сообщений: 951
|
degifly ·
14-Май-12 08:09
(спустя 3 часа, ред. 14-Май-12 08:09)
GlintBeer писал(а):
EVR (и просто и CP) ещё умеют выводить в 4:2:2 и 4:4:4 (а кому это нада?), но вся обработка видео там "8битная", по этому он и выводит только в 8битных пространствах.
наркоманы сговорились что ли?
Все рендереры выводят на экран, а значит выводят они в RGB24 (RGB32). На вход же он может принимать только 8-битные 4:2:0 и 4:4:4 (во втором случае выводит мусор, так что реально поддерживает только первое).
GlintBeer писал(а):
ланцош суров очень, там кошмарная (да ещё и модифицированная) функция для интерполяции используется.
Что значит суров? Что значит "кошмарная"? Что значит "модифицированная"? Lanczos - это вполне определенный алгоритм.
Да и там есть большой выбор, кому что нравится...
Но бикубик в EVR - это, конечно, получше чем билинейный, но все равно не лучший вариант.
GlintBeer писал(а):
МadVR же наоборот только в 4:2:0 (обоснованно, тк почти всем пользователям другого не нада)"
Не обоснованно, да и на вход он принимает любые 4:2:0/4:2:2/4:4:4 8/10/16-битные пространства.
GlintBeer писал(а):
зато может выводить полноценные 16бит, только вот куда и кому
Никуда он не может, 16-бит - это внутренняя точность. А на вывод идет все тот же RGB24 (ну или RGB30 для редких обладателей 10-битных мониторов).
GlintBeer писал(а):
Как следствие из-за высокой точности "кадры больше весят", возможно поэтому возникает большая разница между 1080 и 720.
Эта большая точность существует только внутри видеокарты.
В общем мб имеет смысл попробовать Cyberlink HAM декодер, в режиме HAM... А еще в madVR включить эксклюзивный режим и "disable desktop composition" (aero будет отрубать) только в фуллскрине. И очередь GPU выкруть на максимум в 24 кадра.
|
|
|
|
BalticX
Стаж: 16 лет 2 месяца Сообщений: 1741
|
BalticX ·
14-Май-12 08:18
(спустя 8 мин.)
degifly писал(а):
Я что-то там ланкзос не вижу. Как и высокой точности обработки с дизерингом в конце. Как и поддержки форматов, отличных от 8-битного 4:2:0.
Я про моды Jan Willem. Сам, правда, давно перестал следить за прогрессом, сфокусировавшись на madVR. Но помню, что скейлеров немало он добавлял, обработка есть опционально во флоат (HFPP=16fp, FFPP=32fp) и в интеджер (с отключенными), опции дизеринга (рендом появился раньше, чем в LAV), вывод 10 бит есть в отличие от madVR. Есть даже корректировка chroma sampling для АТИ карт. Вот по входу, наверное, до сих пор только 8 бит 420 принимает, т.е. сабж надо делать предварительно.
|
|
|
|
Hydrogenium
Стаж: 15 лет 9 месяцев Сообщений: 1739
|
Hydrogenium ·
14-Май-12 08:28
(спустя 10 мин.)
Решил обновить кодеки, поставил последний K-Lite Codec Pack 8.7.8 и после этого видео 10-бит стало воспроизводиться с артефактами. А ведь на прошлой версии все было нормально! В чем проблема не подскажете?
|
|
|
|
BalticX
Стаж: 16 лет 2 месяца Сообщений: 1741
|
BalticX ·
14-Май-12 08:48
(спустя 19 мин.)
degifly писал(а):
мб имеет смысл попробовать Cyberlink HAM декодер, в режиме HAM
Cyberlink Video decoder in HAM mode. Собсно HAM декодер не сработает.
|
|
|
|
ъыь
Стаж: 17 лет 5 месяцев Сообщений: 337
|
ъыь ·
14-Май-12 10:06
(спустя 1 час 18 мин., ред. 14-Май-12 10:06)
GlintBeer писал(а):
у тебя там встроенной нету видеокарты никакой?
нет, нету
GlintBeer писал(а):
всякие там постобработки от ff.
у меня включен только ffmpeg audio, я через него гоняю аудиопоток, он лучше в этом смысле, чем LAV
GlintBeer писал(а):
DXVA слишком "узкий" кадры через него не пролазят
в режимe EVRcp+DXVA всё пролазит отлично 
GlintBeer писал(а):
поставь скейлеры попроще
да у меня и на умолчальной конфигурации нормально работает. дропаются кадры только на 10 битах и то редко
degifly писал(а):
для редких обладателей 10-битных мониторов
там даже обладать недостаточно, 10 бит никто кроме DisplayPort не успевает пропустить, афаик. количество моников с такими матрицами по пальцам пересчитать можно. как и видюх, умеющих DisplayPort
degifly писал(а):
В общем мб имеет смысл попробовать Cyberlink HAM декодер
к счастью он у меня стоит в системе, ибо больше блюреи никто не умеет. результат - перманентно пустой backbuffer короче не успевает copy back из-за 128 битной шины
|
|
|
|
GlintBeer
Стаж: 16 лет Сообщений: 222
|
GlintBeer ·
14-Май-12 12:07
(спустя 2 часа, ред. 14-Май-12 12:07)
Цитата:
Все рендереры выводят на экран, а значит выводят они в RGB24 (RGB32)
прежде чем выводить в RGB сначала идёт конверсия YCbCr->RGB, можно в декодере, можно в рендере. (в следствии экономии на ресурсах она идёт с потерями)
про 4:4:4, я зря, но EVR и тот и другой может выводить, например, в цветовом пространстве YUY2 у него цветовая субдискретизация 4:2:2.
Цитата:
Не обоснованно, да и на вход он принимает любые 4:2:0/4:2:2/4:4:4 8/10/16-битные пространства.
а как же это:
Цитата:
(2) madVR only accepts YCbCr 4:2:0 input (YV12, NV12, P010 and P016) and nothing else. So make sure that the decoder you're using actually outputs YCbCr 4:2:0, or else madVR will not work. I've intentionally limited madVR in this way because outputting YCbCr 4:2:0 is simply the best quality option for 99.9% of all content out there.
Цитата:
16-бит - это внутренняя точность
Цитата:
Эта большая точность существует только внутри видеокарты.
и это:
Цитата:
final 16bit processing result is dithered down to RGB output bitdepth
те может выводить в пространстве Р016, но как обсуждалась 100500 постов выше нужно соответстввующее устройство вывода.
Ланцош: суров потому что очень много ресурсов занимает: Кошмарная функция - кардинальный синус). Модифицированная - домножена сама на себя с немного другим аргументом.
И сильно помагает вырубать аеро?
ъыь
Цитата:
в режимe EVRcp+DXVA всё пролазит отлично
В курсе, но тут получается странный выбор либо софт+мад либо хард+евр
Цитата:
да у меня и на умолчальной конфигурации нормально работает
ну и забей тогда
Hydrogenium
попробуй переставь
|
|
|
|
Hydrogenium
Стаж: 15 лет 9 месяцев Сообщений: 1739
|
Hydrogenium ·
14-Май-12 13:55
(спустя 1 час 48 мин.)
GlintBeer писал(а):
Hydrogenium
попробуй переставь
Пробовал 2 раза - не помогает! Даже на более позднюю версию переходил - та же хрень! Там либо что-то еще настраивать надо? Я когда помню K-Lite Codec Pack 7.9.0 ставил - все нормально шло и сразу! Попробую его опять поставить...
|
|
|
|
GlintBeer
Стаж: 16 лет Сообщений: 222
|
GlintBeer ·
14-Май-12 14:38
(спустя 42 мин., ред. 14-Май-12 14:38)
Hydrogenium писал(а):
GlintBeer писал(а):
Hydrogenium
попробуй переставь
Пробовал 2 раза - не помогает! Даже на более позднюю версию переходил - та же хрень! Там либо что-то еще настраивать надо? Я когда помню K-Lite Codec Pack 7.9.0 ставил - все нормально шло и сразу! Попробую его опять поставить...
хм... я скачал, поставил и всё работает.
Какие настройки у плеера? Какие видеофильтры используются?
|
|
|
|
Hydrogenium
Стаж: 15 лет 9 месяцев Сообщений: 1739
|
Hydrogenium ·
14-Май-12 18:17
(спустя 3 часа, ред. 14-Май-12 18:17)
Ну как там по умолчанию мне поставилось: Outpit - EVR Custom Pres (хотя я ставил все подряд - такая же хрень, кроме MadVR), Filters - DirectVobSub, но я ставил и LAV Audio & Video. А MadVR меня не устраивает отсутствием возможности делать скрины и тем, что грузит долго. Поэтому, когда K light codec, начали по умолчанию поддерживать 10 бит, я был несказанно рад!
З.Ы. Забил на K Light, поставил СССР и все заработало
Хорошо, когда есть альтернатива)
|
|
|
|
degifly
Стаж: 15 лет Сообщений: 951
|
degifly ·
14-Май-12 18:25
(спустя 7 мин.)
GlintBeer писал(а):
прежде чем выводить в RGB сначала идёт конверсия YCbCr->RGB
Это очевидно, и?
GlintBeer писал(а):
можно в декодере, можно в рендере.
если это заставлять делать декодер - это не самый лучший вариант.
GlintBeer писал(а):
(в следствии экономии на ресурсах она идёт с потерями)
если так хотите поговорить о потерях - то дайте определения этим самым потерям.
GlintBeer писал(а):
про 4:4:4, я зря, но EVR и тот и другой может выводить
Еще раз - в природе не существует YCbCr дисплеев. Поэтому "рендерер может выводить 4:4:4" противоречит само себе. И мне еще раз запостить скриншот с красивыми полосочками?
GlintBeer писал(а):
а как же это:
Когда тот пост последний раз редактировался?
Из чейнджлога к v0.62
Цитата:
* added support for 8 bit 4:2:0 media types IYUV, I420, NV21, ICM*
* added support for 8 bit 4:2:2 media types YUY2, YVYU, UYVY, YV16, yuv2, ...
* added support for 8 bit 4:4:4 media types AYUV, YV24, I444, v308, v408
* added support for 8 bit RGB media types RGB32, RGB24, BGRA, ABGR, RGBA
* added support for 10 bit 4:2:2 media types P210, Y210, v210
* added support for 10 bit 4:4:4 media types Y410, v410
* added support for 16 bit 4:2:2 media types P216, Y216, v216
* added support for 16 bit 4:4:4 media types Y416, v416
* added support for 16 bit RGB media types RGB48, RGB64, b48r, b64a, ...
GlintBeer писал(а):
И сильно помагает вырубать аеро?
Кто его знает. Раньше, когда видяхи были совсем слабые кому то помогало, сейчас же и встроенной в проц интелловской графики c легкостью хватает на 1080p.
|
|
|
|
ъыь
Стаж: 17 лет 5 месяцев Сообщений: 337
|
ъыь ·
14-Май-12 18:50
(спустя 25 мин.)
Hydrogenium писал(а):
Забил на K Light, поставил СССР и все заработало
если б оно ещё обновлялось почаще раза в год 
|
|
|
|
GlintBeer
Стаж: 16 лет Сообщений: 222
|
GlintBeer ·
14-Май-12 19:47
(спустя 57 мин., ред. 14-Май-12 19:47)
сначала кадр создаётся в YCbCr потом конверсия в RGB и вывод. И если значальный кадр с цветовой судискретизацией 4:2:0, разве на выходе будет полноценный RGB "какбудто без субдискретизации и прочих ухищрений для экономии"??? Ясно что выводится почти всё в RGB, я когда писал про цветпространсва не имел ввиду, что вывод ведётся в прямо в YUY2. Разницу же можно заметить при соответствующем устройстве вывода.
Потери происходят, в таком случае: при конверсии YCbCr->RGB используется матрица 3х3, то есть [если я правильно помню как матрицы уножаются] ВТ.709(или ВТ.601)*YCbCr=RGB, результат который получается - это вектор элементы которого представлены вещественными числами, но обрабатывать вещественные числа, дело трудоёмкое (и не забываем что всё происходит потоком при просмотре видео) и поэтому их округляют до целых. Это можно поправить засчёт повышения битности (больше бит на элемент, вот он эффект от 10 бит, мы предоставляем бОльший объём информации на "элемент" и нет нужды подмешивать "шум"). отсюда и повышенные требования (к той же пропускной способности) железу. Поэтому я и говорил, что кадры "тяжеле". MadVR может делать до 16 на элемент (зафига только).
И понятно причём здесь цветовые пространства???
Hydrogenium
А видеофильтр та какой был? LAV?
Дело было точно не в рендере, декодер неправильные данные ему отправлял, но раз всё решилось то фиг с ними
|
|
|
|
degifly
Стаж: 15 лет Сообщений: 951
|
degifly ·
14-Май-12 20:37
(спустя 49 мин.)
GlintBeer писал(а):
И если значальный кадр с цветовой судискретизацией 4:2:0, разве на выходе будет полноценный RGB
Полноценный, не полноценный - но он будет RGB.
GlintBeer писал(а):
я когда писал про цветпространсва не имел ввиду, что вывод ведётся в прямо в YUY2
А там только так понять и можно. Учитывая что рендерер всегда выдает RGB на выходе, а про вход там речь не шла.
GlintBeer писал(а):
Разницу же можно заметить при соответствующем устройстве вывода.
Разницу между чем и чем?
GlintBeer писал(а):
Потери происходят, в таком случае: при конверсии YCbCr->RGB используется матрица 3х3, то есть [если я правильно помню как матрицы уножаются] ВТ.709(или ВТ.601)*YCbCr=RGB, результат который получается - это вектор элементы которого представлены вещественными числами, но обрабатывать вещественные числа, дело трудоёмкое (и не забываем что всё происходит потоком при просмотре видео) и поэтому их округляют до целых.
Значит речь идет о промежуточных потерях от окрыгления, которые можно избежать. Так бы сразу.
А то тут недавно один человек требовал преобразование из 4:2:0 в 4:2:2, "да чтоб без потерь!!11".
GlintBeer писал(а):
отсюда и повышенные требования (к той же пропускной способности)
еще раз, повышенная точность существует внутри видеокарты, никто в нее не загружает 16-битный поток. Хотя ради интереса можно попробовать (от 3-х 16-битных 4:4:4 потоков очередь аплоада просела. Да.).
GlintBeer писал(а):
Поэтому я и говорил, что кадры "тяжеле". MadVR может делать до 16 на элемент (зафига только).
и опять же они "тяжелее" внутри видеокарты (в нее поступает 8-битное 4:2:0), где есть своя шина, которая куда производительнее скачивания из оперативки. Там можно переключить точность внутренней обработки с 16-бит до 10 - это немного памяти освобдит, и только.
|
|
|
|
GlintBeer
Стаж: 16 лет Сообщений: 222
|
GlintBeer ·
14-Май-12 20:55
(спустя 17 мин.)
Цитата:
Полноценный, не полноценный - но он будет RGB.
суть в разнице между просто RGB и RGB полученное из YCbCr заметно будет, только если монитор (или ктонибудь за него) способен отразить RGB полностью.
Цитата:
А то тут недавно один человек требовал преобразование из 4:2:0 в 4:2:2, "да чтоб без потерь!!11".
Невозможно.
Цитата:
внутри видеокарты (в нее поступает 8-битное 4:2:0)
это если видео 8битное
если 10битное то туда поступает декодированный "10битный" кадр.
Чем больше приходится бит на элемент, тем сложнее обрабатывать кадр, приходится прогонять бОльший поток информации, причём нагрузка возрастает нелинейно.
|
|
|
|
BalticX
Стаж: 16 лет 2 месяца Сообщений: 1741
|
BalticX ·
15-Май-12 08:29
(спустя 11 часов)
GlintBeer писал(а):
но обрабатывать вещественные числа, дело трудоёмкое (и не забываем что всё происходит потоком при просмотре видео) и поэтому их округляют до целых.
Вообще-то, пересчёт YUV > RGB ведётся именно в вещественных значениях (madVR, EVR CP HFPP, FFPP), а вот результат с плавающей: 1) дизерится, 2) приводится к максимально допустимому диапазону чисел 0-255. Потерь при этом не избежать, но их удельный вес сводится к минимуму.
Что касается Dither:
Jan Willem с самого начала дал возможность выбора различных опций (random, static и по уровню).
Nevcairiel себе позднее добавил наиболее эффективный random.
Madshi заявил, что применяет научно обоснованный метод и не пожелал развивать эту тему, очевидно, не желая усложнять жизнь пользователям и себе. Хотя алгоритм, судя по отзывам, чуть изменил.
|
|
|
|
GlintBeer
Стаж: 16 лет Сообщений: 222
|
GlintBeer ·
15-Май-12 15:05
(спустя 6 часов)
Цитата:
пересчёт YUV > RGB ведётся именно в вещественных значениях
Ну а я про что? Результат округляют до чисел с плавающей запятой (тут я малость промахнулся), и дальше работают именно с ним.
|
|
|
|
monkalex
Стаж: 16 лет Сообщений: 576
|
monkalex ·
15-Май-12 15:32
(спустя 27 мин.)
Ребят, по сравнению с потоковым шифрование ваши преобразования - не трудоемки. Не ведите пространных речей о какой то херне. Вполне годная работоспособность 10-бит, на оптимизацию не советую надеяться.
|
|
|
|
GlintBeer
Стаж: 16 лет Сообщений: 222
|
GlintBeer ·
15-Май-12 15:52
(спустя 19 мин.)
monkalex писал(а):
Ребят, по сравнению с потоковым шифрование ваши преобразования - не трудоемки. Не ведите пространных речей о какой то херне. Вполне годная работоспособность 10-бит, на оптимизацию не советую надеяться.
А причём тут шифрование?Дело даже не в том, что эта тема про 10-битное видео. Кому на дому нужно шифровать что-то? Таких людей единцы.
и причём тут оптимизация?
|
|
|
|
BalticX
Стаж: 16 лет 2 месяца Сообщений: 1741
|
BalticX ·
15-Май-12 15:58
(спустя 5 мин.)
monkalex писал(а):
по сравнению с потоковым шифрованием
(аживляясь) чипом видеокарты?
|
|
|
|
monkalex
Стаж: 16 лет Сообщений: 576
|
monkalex ·
15-Май-12 18:03
(спустя 2 часа 5 мин.)
Угу, видюшкой гонял. В целом дает плюс при слабом проце. Загрузка намного выше, чем от потока видео того же объема.
GlintBeer
ну вы какую то херню в тему мусолите, мне показалось недовольны работой существующих алгоритмов. Вот и говорю, надеяться на лучшее - не стоит. Если ошибся - звиняйте.
|
|
|
|
degifly
Стаж: 15 лет Сообщений: 951
|
degifly ·
15-Май-12 22:46
(спустя 4 часа)
GlintBeer писал(а):
суть в разнице между просто RGB и RGB полученное из YCbCr заметно будет, только если монитор (или ктонибудь за него) способен отразить RGB полностью.
YCbCr разное бывает, если говорить про 4:4:4 - да, если говорить про 4:2:0 - то нет.
Цитата:
это если видео 8битное
если 10битное то туда поступает декодированный "10битный" кадр.
Пасибо, кэп. Только речь про 8-бит шла.
Цитата:
Чем больше приходится бит на элемент, тем сложнее обрабатывать кадр, приходится прогонять бОльший поток информации, причём нагрузка возрастает нелинейно.
Конкретно madVR'у - пофиг, т.к. рассчеты ведутся с 16-битной точностью, так что на входе 1 бит или 16 роли не играет. А вот на шину нагрзука больше - т.к. данных больше передается.
|
|
|
|
GlintBeer
Стаж: 16 лет Сообщений: 222
|
GlintBeer ·
15-Май-12 23:48
(спустя 1 час 1 мин.)
Цитата:
Пасибо, кэп. Только речь про 8-бит шла.
ты просто написал про 8битный кадр и я это прокментировал. а так как я не помню (да мне и вообщем-то всёравно) с чего вся эта билиберда, то мы имеем то что имеем
Цитата:
YCbCr разное бывает, если говорить про 4:4:4 - да, если говорить про 4:2:0 - то нет.
я, примерно, про это и говорил.
|
|
|
|
alfsuind
Стаж: 15 лет 5 месяцев Сообщений: 880
|
alfsuind ·
16-Май-12 11:50
(спустя 12 часов, ред. 16-Май-12 11:50)
Спрашиваю здесь как в ветке про новые PC-only навороты :).
Цветовое пространство YCgCo кроме MadVR что-то уже понимает?
(Пишут, что на 10% лучше сжимаемость, чем у YCbCr 601/709 c его "докомпьютерными" коэффициентами.)
|
|
|
|
