Обнаружил очень любопытную вещь и спешу поделиться. Проводил эксперименты с прозрачным окном, стиль WS_EX_LAYERED ‒ оказалось, что оно вообще никак не реагирует на GetDC(0), т.е. его содержимое не считывается прямо с экрана и на него нельзя наложить растр, но при этом всё, что есть под ним, считывается через GetDC(0). Получается довольно прикольная штука ‒ я могу накрыть этим окном всё что угодно и менять там растр, а окно всякий раз будет накрывать содержимое с той степенью прозрачности, что я указал. Видимо, для таких окон существует независимый буфер, который не пересекается с буфером экрана.
Кстати, SetForegroundWindow для фокуса - не панацея.
Предложите панацею.
По поводу вашего кода: GetMessage не работает в консольном приложении, в отличии от PeekMessage, вернее, сам хук будет работать, но приложение нет, оно "замёрзнет". А ещё после GetMessage нужна одна функция, надеюсь, вы знаете, какая. Поэтому для новичка PeekMessage будет универсальным вариантом, рабочим в любых условиях.
Вас вообще не смущает, что WNDCLASSEX wcx у вас локальная переменная? Что она на стеке, а там изначально может лежать любой мусор, потенциально могущий меняться от запуска к запуску? Вы не инициализируете один из элементов структуры, относящихся к фону окна, а потом удивляетесь. Да и hbrBackground вообще не о прозрачности.
Тут явно кто-то что-то не понимает, давайте разберёмся, но только спокойно, без ругани. Вот эта строка разве не является инициализацией структуры?
WNDCLASSEX wcx = {sizeof(WNDCLASSEX)};
Я и не задавался целью сделать фон прозрачным, просто у меня он становится прозрачным, когда hbrBackground явно не задана, вернее, задана значением по умолчанию, видимо 0. На другой винде фон белый.
Это вообще ни в какие ворота, тут просто косяк на косяке. Sleep(1) вызывает принудительное переключение контекста потока, а зачастую и между ядрами, что явно не разгружает процессор.
Явно вы настроены агрессивно, но меня это не задевает, я тёртый калач в форумных баталиях, но не люблю, когда со старта кто-то создаёт негативный фон.
Sleep(1) работает стабильно и очень эффективно разгружает процессор ‒ если в цикле идёт только прослушивание потока, то нагрузка меньше 1%; считывание экрана в буфер в цикле может занимать до 5%, но у меня старый комп.
Если вы такой опытный, то сможете использовать более эффективный код, но странно, что вы его не предложили читателям, ведь кроме вашей громкой критики он ничего полезного из вашего коммента не получит. Так есть у вас предложение лучше, чем Sleep(1)? И чтобы это было компактно и понятно новичку!
PeekMessage упирается в NtUserPeekMessage - соответствующий сисколл, переключение в режим ядра и соответствующее переключение контекста. Sleep(1) отработает как повезёт (хотя и почти всега так, как задумывается). А нормальный GetMessage спокойно висит на эвенте и не даёт практически никакого оверхеда.
Куда бы там ни упирался PeekMessage, но зачастую это единственно верный вариант, потому что не блокирует поток. GetMessage я тоже использую, но там есть свои нюансы. Кстати, а давайте проверим, знаете ли вы про эти нюансы ‒ покажите нам блок кода с GetMessage, который будет компактным и при этом работать в паре с хуком и без создания окна. Уверен, вы напишите его в момент и он сразу будет рабочим.
З.Ы. Признаю, что я не профи, а только учусь, но вот что интересно ‒ до меня никто на хабре толковой статьи на эти темы не создал, а почему, если здесь столько профи? Основной целью статьи является показать концепцию и основные пути реализации, а не чтобы научить новичка красиво писать код.
Судя по видео, алгоритм похож на опцию в кодеке x264 scenecut threshold (--scenecut) «порог изменения сцены». То есть в такой проге просто задаёшь значение порога и она собирает те блоки кадров, где переход отличается на значение порога. Если заранее неизвестно, насколько динамично видео, то можно начать с высокого порога и смотреть, какой процент видео останется
Собственная поправка. Дополнительные тесты показали, что блок Analysis с птичками frames partitions улучшает качество и даже уменьшает размер. Так что включайте все птички.
Нашёл ещё один лёгкий способ открытия неавишных файлов в VirtualDub. Здесь есть ссылки на Virtualdub FFMpeg Input Plugin. Только подберите нужную версию, а то у меня v0.7 пошла, а v0.8 нет. Из архива файл FFInputDriver.vdplugin и папку ffdlls нужно положить в папку plugins Virtualdub'а и всё. Пробовал на mkv, mp4, mov, полный список форматов указан на сайте.
Можно использовать способ FFMpeg через AviSynth, но новичкам придётся попотеть.
Почитал статьи про деблок по ссылкам sudzuharu, не нашёл прямых противоречий со своими словами. Если кто нашёл — пусть укажет цитату. К тому же я не теоретик, а практик. Я кодировал с деблоком и без и сравнивал картинки в масштабе 400. И всё вышло так, как и описал.
preset — это компромисс между скоростью и размером файла. Качество может только ухудшиться, но не улучшиться, потому что процесс кодирования с потерями это подразумевает. Высокий пресет уменьшает размер за счёт лучшего просчёта движения и применения фичей, которые ухудшают кадр и уменьшают его размер в байтах. B-кадры тому пример.
По поводу CRF и CQP, не понимаю, как вам ещё доступнее объяснить. CQP даёт стабильное качество, поэтому я выбрал его, CRF определяет качество на своё усмотрение, в зависимости от динамики сцены. Конечно, вы задаёте значение CRF, но это только приблизительный ориентир для кодека, и он лучше подходит для двухпроходного кодирования, потому что кодеку необходимо учесть соотношение многих параметров по статистике всего видео, иначе можно получить совершенно противоречивые результаты, о чём я и писал выше.
«Жрец Нефтиды» — не знаю такого. Он в розыске? :-)
Почитал, там на английском сказано то же самое, только раньше. И что-же? В чём суть вашего комментария? Ведь это только лишний раз подтверждает мои выводы, что качество на выходе непредсказуемо.
Остальное не комментируете, потому что нечего сказать?
Я автор статьи, на которую вы ссылаетесь, за что спасибо. Надеюсь, вы не обидитесь, если я выскажу свои замечания.
--preset. Вы сказали: «выше скорость — хуже качество». Это неправда, если читали документацию внимательно, должны знать почему.
--deblock. Вы сказали, что большие значения размывают линии. Это не вполне правда. deblock призван устранить квадратичность макроблоков, о чём вы забыли упомянуть. Квадратичность появляется как следствие увеличение квантизатора и именно она виновна в искривлении линий. deblock пытается соединить линии, которые проходят через смежные блоки и при максимальных значениях он делает это всегда. Так что психовизуальное восприятие человека не будет потрясено, а именно под это заточен x264. Как недостаток этой функции может быть замыливание резких линий, но уж лучше это, чем разрыв линии вовсе. Тем более, что можно включить резкость во время просмотра и нет проблем.
--trellis. Если вы читали документацию, то trellis имеет смысл в паре с --psy-rd. Это ещё одна фича для психовизуального восприятия, которая должна уменьшить размер файла. Когда я тестировал их, то у меня размер увеличивался, а качество не улучшалось. Поэтому резонно спросить: зачем оно надо и вы сами пробовали кодировать без этого?
CRF. Решил внять рекомендациям и попробовать закодировать в CRF. Подвох обнаружился, когда я смекнул, что значит «динамическая сцена» с точки зрения кодера. В VirtualDub я изменил частоту кадров и кодировал с теми же настройками CRF. В итоге стало ясно, что то же самое видео с меньшей частотой кадров воспринимается кодеком как slow-mo, а с большей частотой как «динамическая сцена». И естественно, что в первом случае размер файла стал больше, а во втором меньше. Такой фокус с CQP не проходит, поэтому это ещё одна причина не кодировать в CRF — слишком непредсказуемый результат.
Решил внять рекомендациям и попробовать закодировать в CRF. Подвох обнаружился, когда я смекнул, что значит «динамическая сцена» с точки зрения кодера. В VirtualDub я изменил частоту кадров и кодировал с теми же настройками CRF. В итоге стало ясно, что то же самое видео с меньшей частотой кадров воспринимается кодеком как slow-mo, а с большей частотой как «динамическая сцена». И естественно, что в первом случае размер файла стал больше, а во втором меньше. Такой фокус с CQP не проходит, поэтому это ещё одна причина не кодировать в CRF — слишком непредсказуемый результат.
Не имею доступа к серверу. Вы сначала объясните суть — какой размер и длительность, как проверять качество? Если длинный кусок, я не буду тратить время. Если вы с пресетами добавляете отдельные ключи — это уже другой разговор. Если диалог затягивается — пишите в лику.
Про эксперимент с пресетами я писал в комменте выше.
Ссылка на стрим не работает у меня. Если найдёте приличные настройки — скиньте. А вообще сильно сжать не проблема. Я кодировал в HD и качество получилось неплохое, при тех же требованиях сжать ещё больше — вот интересная задачка.
Если многие не используют CQP — это меня заинтересовало. Неужели мало кто понимает, что это за штука?
Обычно критиканы так и говорят: «всё у вас фигня, идите учите матчасть». А обосновать свою критику не могут. Я же в статье написал, почему я выбрал такие значения, и пользователь всегда может выбрать свои. Эта статья писалась не для вас, не для гуру, не для тех, кто сидит часами у консоли — она для тех, кто хочет получить нормальный результат быстро и без напряга.
CQP не может быть фигнёй в принципе — в данном случае это вам надо изучать матчасть, ибо вы, видимо, не знаете, зачем в x264 CQP, поэтому и говорите, что не используется.
DirectShowShource возможно хуже FFMpeg, но это мне простительно, статья вообще не об этом. Кстати, лагает он в основном на mkv, так что обычный пользователь может и не заметить разницы.
Вчера закодировал 100 минут фильм 1280х694 менее чем в 2 гига. Качество вполне пристойное. Если у вас получится лучше — скиньте настройки, буду благодарен.
Ну наконец-то я понял, что вы имели ввиду. Вы говорите о CRF, а я писал про CQP (Constant Rate Factor). Это не одно и то же. Да, CRF использует CQP, но на своё усмотрение, вы пребываете в некотором неведении относительно результата, когда кодируете через CRF, а с CQP такого казуса не произойдёт — он всегда даёт стабильный результат. Поэтому я новичкам советую именно его. А вам советую разобраться в определениях и не писать попусту. Кодирование без квантизатора вообще действительно невозможно, если говорить о ядре кодека.
Насчёт B-кадров сложный вопрос — если вы проигрываете в том же месте, что и кодировали, то проблем быть не должно. К тому же блоки из таких кадров усложняют декодирование и ухудшают качество видео, так что новичкам опять же не рекомендуется. Выигрыш в размере можно получить и другим способом, а иной пользы от B-кадров просто нет.
--merange 8, я не утверждаю, что он оптимальный, но при больших значениях заметно снижение скорости, а размер почти тот же. Так что экспериментально доказать, какое значение будет лучшим, не представляется мне возможным. Новичкам парить мозги тоже не стоит.
Deadzone лучше чем Trellis, потому что я протестировал результаты обоих. Trellis увеличивает размер и не всегда улучшает качество, а Deadzone всегда сглаживает в заданных пределах и всегда уменьшает размер. Deadzone точно по Гауссу, потому что я знаю, как выглядят картинки после такого фильтра — другим способом этого не достичь. Каким образом работает Trellis — не знаю, а потому резонно задаться вопросом: «на кой он такой кактус?»
--preset veryslow. Я писал, что пробовал версию 2274 с другим интерфейсом, там была одна вкладка и выбор пресетов. Я попробовал некоторые и результат был отстойным. Далее пробовать не было желания. А заполнять команды вручную после выбора пресета — разве это не маразм? Уж лучше учится работать в консоли.
Говорите про полноценные гайды? Если они доходчиво написаны и экспериментально подтверждены — киньте ссылку, буду благодарен.
Весьма сумбурный комментарий, если я не прав, объясните толково, где, и почему правы вы.
Мне показалось, что вы не вполне представляете себе, что такое CQP. CQP не может быть маразмом в принципе, ибо без него кодирование вообще невозможно, разве только вы придумаете и запатентируете иной принцип.
По поводу деблока я говорил, что по-умолчанию 0, компромисс 3, так что выбор есть. Особенно актуально на высоком квантизаторе.
Ключ subme — это Subpixel ME refinement, я описал его достаточно подробно. Сразу видно, что вы привыкли к консольному варианту.
И да, вы правы, GUI для тех, кто не хочет тратить время на изучение горы документации. И для них же мой пост. А насчёт честности спорный вопрос — поэтому юниксоиды и виндари совершенно из разных миров.
Собственная поправка. В первом посте я писал, что в матрице Inter важно число 12, а в этом посте я изменил его на 16, но это ошибка. Просто измените 16 на 12 в матрице Inter. В остальном матрица такая же, как в этом посте. В результате тестов я обнаружил, что мне не всегда понятна логика работы кодека, поэтому столько поправок. До сути можно дойти только «методом тыка», так что извините за неточности.
Обнаружил очень любопытную вещь и спешу поделиться. Проводил эксперименты с прозрачным окном, стиль WS_EX_LAYERED ‒ оказалось, что оно вообще никак не реагирует на GetDC(0), т.е. его содержимое не считывается прямо с экрана и на него нельзя наложить растр, но при этом всё, что есть под ним, считывается через GetDC(0). Получается довольно прикольная штука ‒ я могу накрыть этим окном всё что угодно и менять там растр, а окно всякий раз будет накрывать содержимое с той степенью прозрачности, что я указал. Видимо, для таких окон существует независимый буфер, который не пересекается с буфером экрана.
Есть ещё верный способ активировать окно: вывести его поверх всех и эмулировать по нему клик.
Я не понял, вы делаете активным окно, которое уже активно? Иначе какой тогда смысл этой функции?Предложите панацею.
По поводу вашего кода: GetMessage не работает в консольном приложении, в отличии от PeekMessage, вернее, сам хук будет работать, но приложение нет, оно "замёрзнет". А ещё после GetMessage нужна одна функция, надеюсь, вы знаете, какая. Поэтому для новичка PeekMessage будет универсальным вариантом, рабочим в любых условиях.
Тут явно кто-то что-то не понимает, давайте разберёмся, но только спокойно, без ругани. Вот эта строка разве не является инициализацией структуры?
WNDCLASSEX wcx = {sizeof(WNDCLASSEX)};Я и не задавался целью сделать фон прозрачным, просто у меня он становится прозрачным, когда hbrBackground явно не задана, вернее, задана значением по умолчанию, видимо 0. На другой винде фон белый.
Явно вы настроены агрессивно, но меня это не задевает, я тёртый калач в форумных баталиях, но не люблю, когда со старта кто-то создаёт негативный фон.
Sleep(1) работает стабильно и очень эффективно разгружает процессор ‒ если в цикле идёт только прослушивание потока, то нагрузка меньше 1%; считывание экрана в буфер в цикле может занимать до 5%, но у меня старый комп.
Если вы такой опытный, то сможете использовать более эффективный код, но странно, что вы его не предложили читателям, ведь кроме вашей громкой критики он ничего полезного из вашего коммента не получит. Так есть у вас предложение лучше, чем Sleep(1)? И чтобы это было компактно и понятно новичку!
Куда бы там ни упирался PeekMessage, но зачастую это единственно верный вариант, потому что не блокирует поток. GetMessage я тоже использую, но там есть свои нюансы. Кстати, а давайте проверим, знаете ли вы про эти нюансы ‒ покажите нам блок кода с GetMessage, который будет компактным и при этом работать в паре с хуком и без создания окна. Уверен, вы напишите его в момент и он сразу будет рабочим.
З.Ы. Признаю, что я не профи, а только учусь, но вот что интересно ‒ до меня никто на хабре толковой статьи на эти темы не создал, а почему, если здесь столько профи? Основной целью статьи является показать концепцию и основные пути реализации, а не чтобы научить новичка красиво писать код.
Можно использовать способ FFMpeg через AviSynth, но новичкам придётся попотеть.
preset — это компромисс между скоростью и размером файла. Качество может только ухудшиться, но не улучшиться, потому что процесс кодирования с потерями это подразумевает. Высокий пресет уменьшает размер за счёт лучшего просчёта движения и применения фичей, которые ухудшают кадр и уменьшают его размер в байтах. B-кадры тому пример.
По поводу CRF и CQP, не понимаю, как вам ещё доступнее объяснить. CQP даёт стабильное качество, поэтому я выбрал его, CRF определяет качество на своё усмотрение, в зависимости от динамики сцены. Конечно, вы задаёте значение CRF, но это только приблизительный ориентир для кодека, и он лучше подходит для двухпроходного кодирования, потому что кодеку необходимо учесть соотношение многих параметров по статистике всего видео, иначе можно получить совершенно противоречивые результаты, о чём я и писал выше.
«Жрец Нефтиды» — не знаю такого. Он в розыске? :-)
Остальное не комментируете, потому что нечего сказать?
--preset. Вы сказали: «выше скорость — хуже качество». Это неправда, если читали документацию внимательно, должны знать почему.
--deblock. Вы сказали, что большие значения размывают линии. Это не вполне правда. deblock призван устранить квадратичность макроблоков, о чём вы забыли упомянуть. Квадратичность появляется как следствие увеличение квантизатора и именно она виновна в искривлении линий. deblock пытается соединить линии, которые проходят через смежные блоки и при максимальных значениях он делает это всегда. Так что психовизуальное восприятие человека не будет потрясено, а именно под это заточен x264. Как недостаток этой функции может быть замыливание резких линий, но уж лучше это, чем разрыв линии вовсе. Тем более, что можно включить резкость во время просмотра и нет проблем.
--trellis. Если вы читали документацию, то trellis имеет смысл в паре с --psy-rd. Это ещё одна фича для психовизуального восприятия, которая должна уменьшить размер файла. Когда я тестировал их, то у меня размер увеличивался, а качество не улучшалось. Поэтому резонно спросить: зачем оно надо и вы сами пробовали кодировать без этого?
CRF. Решил внять рекомендациям и попробовать закодировать в CRF. Подвох обнаружился, когда я смекнул, что значит «динамическая сцена» с точки зрения кодера. В VirtualDub я изменил частоту кадров и кодировал с теми же настройками CRF. В итоге стало ясно, что то же самое видео с меньшей частотой кадров воспринимается кодеком как slow-mo, а с большей частотой как «динамическая сцена». И естественно, что в первом случае размер файла стал больше, а во втором меньше. Такой фокус с CQP не проходит, поэтому это ещё одна причина не кодировать в CRF — слишком непредсказуемый результат.
Ссылка на стрим не работает у меня. Если найдёте приличные настройки — скиньте. А вообще сильно сжать не проблема. Я кодировал в HD и качество получилось неплохое, при тех же требованиях сжать ещё больше — вот интересная задачка.
Если многие не используют CQP — это меня заинтересовало. Неужели мало кто понимает, что это за штука?
CQP не может быть фигнёй в принципе — в данном случае это вам надо изучать матчасть, ибо вы, видимо, не знаете, зачем в x264 CQP, поэтому и говорите, что не используется.
DirectShowShource возможно хуже FFMpeg, но это мне простительно, статья вообще не об этом. Кстати, лагает он в основном на mkv, так что обычный пользователь может и не заметить разницы.
Вчера закодировал 100 минут фильм 1280х694 менее чем в 2 гига. Качество вполне пристойное. Если у вас получится лучше — скиньте настройки, буду благодарен.
Насчёт B-кадров сложный вопрос — если вы проигрываете в том же месте, что и кодировали, то проблем быть не должно. К тому же блоки из таких кадров усложняют декодирование и ухудшают качество видео, так что новичкам опять же не рекомендуется. Выигрыш в размере можно получить и другим способом, а иной пользы от B-кадров просто нет.
--merange 8, я не утверждаю, что он оптимальный, но при больших значениях заметно снижение скорости, а размер почти тот же. Так что экспериментально доказать, какое значение будет лучшим, не представляется мне возможным. Новичкам парить мозги тоже не стоит.
Deadzone лучше чем Trellis, потому что я протестировал результаты обоих. Trellis увеличивает размер и не всегда улучшает качество, а Deadzone всегда сглаживает в заданных пределах и всегда уменьшает размер. Deadzone точно по Гауссу, потому что я знаю, как выглядят картинки после такого фильтра — другим способом этого не достичь. Каким образом работает Trellis — не знаю, а потому резонно задаться вопросом: «на кой он такой кактус?»
--preset veryslow. Я писал, что пробовал версию 2274 с другим интерфейсом, там была одна вкладка и выбор пресетов. Я попробовал некоторые и результат был отстойным. Далее пробовать не было желания. А заполнять команды вручную после выбора пресета — разве это не маразм? Уж лучше учится работать в консоли.
Говорите про полноценные гайды? Если они доходчиво написаны и экспериментально подтверждены — киньте ссылку, буду благодарен.
Мне показалось, что вы не вполне представляете себе, что такое CQP. CQP не может быть маразмом в принципе, ибо без него кодирование вообще невозможно, разве только вы придумаете и запатентируете иной принцип.
Ключ subme — это Subpixel ME refinement, я описал его достаточно подробно. Сразу видно, что вы привыкли к консольному варианту.
И да, вы правы, GUI для тех, кто не хочет тратить время на изучение горы документации. И для них же мой пост. А насчёт честности спорный вопрос — поэтому юниксоиды и виндари совершенно из разных миров.