Нужен видеоконвертер под окна, обязательно с поддержкой h.265 и обязательно через GPU (750Ti), чтобы не нагружать проц. Нужно перекодировать очень много видео с камер, сжать без потери качества, как можно больше, так что h.265 идеальный кодек. Но при этом нужно работать за ПК в это время, ибо кодирование через CPU конкретно подвешивает фоновые программы раз в N секунд. Гуглил, не нашел.
И да, выставь приоритет не катит, оно и так долго кодируется, надеюсь, что через GPU будет быстрее.
> h.265 и обязательно через GPU (750Ti)
Таких нет.
> Нужно перекодировать очень много видео с камер, сжать без потери качества
Это невозможно сделать в виду природы процесса кодирования видео.
Бля, ну ясен пень, что без заметной потери качества, зачем эти придирки? А почему нет?
>Это невозможно сделать
гугли loseless кодирование
>h.265
Забудь о нем еще на пару лет. Сейчас проще купить дисков для h264, чем тратится на железо способное с ним работать.
>гугли loseless кодирование
h26x - не loseless формат.
Ты еще джепегом в loseless жать предложи.
>Бля, ну ясен пень, что без заметной потери качества, зачем эти придирки? А почему нет?
Не ясень.
Каким кодеком видео твои закодированы?
И зачем тебе перекодировать их вообще?
> h.265 идеальный кодек
H.265 — это не кодек, а формат. А кодек — это то, что ты ищешь.
> кодирование через CPU конкретно подвешивает фоновые программы раз в N секунд.
Спермопроблемы. Поставь ОС с нормальным шедулером.
> h.265 и обязательно через GPU (750Ti)
Смотри спеки своей железяки. Если в ней нет аппаратного декодера этого формата, то ты в пролёте. GPGPU даже теоретически можно использовать очень ограниченно, т.к. сжатие в форматы H.264, VP9 и H.265 не поддаётся сильному распараллеливанию.
Олсо, аппаратные энкодеры обычно проигрывают программным по соотношению битрейт/качество.
> Это невозможно сделать в виду природы процесса кодирования видео.
Неверно. Все три перечисленных выше формата имеют lossless-режимы, в которых картинка передаётся с точностью до бита.
> без заметной потери качества
Расплывчатая формулировка. На разных экранах и при разных манерах воспроизведения (будет ли нажиматься пауза?) потери заметны по-разному.
> h26x - не loseless формат.
Где это написано?
То, что твой мокрописечный софт не умеет работать с lossless H.264 и H.265, не имеет никакого отношения к возможностям формата.
>Где это написано?
>То, что твой мокрописечный софт не умеет работать с lossless H.264 и H.265, не имеет никакого отношения к возможностям формата.
Ой, не юродствуй.
Ну да, есть в формате возможность, а толку от нее?
> Ой, не юродствуй.
Что ты, и в мыслях не было.
> Ну да, есть в формате возможность, а толку от нее?
Можно сохранять лосслесс. Я использую для промежуточных файлов, в т.ч. при захвате экрана для последующего кодирования в VP9 двумя проходами.
>Гуглил, не нашел.
Посмотрите на дебила!
Ночью всё это запусти, когда комп не юзаешь
Все новые телевизоры, все компьютеры
Щито? nVidia GT 620, копеечная видеокарта, и то в него может без проблем.
С h265 может работать только Максвеллы. Причем 900 серия.
Забрал, спасибо!
Хуяквеллы. Asus GT 620.
Ну да. Ты ведь говорил про декодирование.
Ладно. Тред создавть не буду. Анон, подскажи годный конвертер из g2m в h.264.
> Ты
На юзерагенты смотри хотя бы.
Тема треда — кодирование.
ffmpeg
Жертвы современного образования!
Три факта для тебя:
- психовизуальное сжатие с потерями — алгоритм с обратной связью;
- слотовые затычки получают большую вычислительную производительность за счёт массовых параллельных однообразных вычислений (тому що самое медленное устройство — память и для эффективного ввода-вывода требуется исходные числа и результаты читать и писать пачками, а для этого крайне желательно, чтобы пачка параллельных вычислений завершалась одновременно);
- алгоритмы с обратной связью не имеют эффективного решения при параллелизме — с ростом числа вычислительных потоков снижается эффективность.
Из этого вполне очевидно, что MPEG-подобные (с поиском и компенсацией движения) кодеры с ускорением на GPU работать хорошо НЕ БУДУТ. Вообще. Никогда.
Коэффициенты сжатия при примерно одинаковом качестве видео можно обеспечить при сравнимых скоростях на CPU и GPU — причём, даже однозначно сказать нельзя, есть ли вообще преимущество у GPU-ускорения, т.к. на CPU примерно такого же говёного качества можно примерно с той же скоростью или быстрее (данные для libx264).
> Нужно перекодировать очень много видео с камер, сжать без потери качества, как можно больше, так что h.265 идеальный кодек.
Во-первых, перегруженное вычислениями и плохо поддерживаемое разрабатываемое поделие не может быть лучшим. Во-вторых, предложение «очень много видео с камер, сжать без потери качества» не имеет смысла.
> Но при этом нужно работать за ПК в это время
А что ты там ещё делаешь? Тридемоделируешь? В видеоигры работаешь? При нормальных планировщиках процессов и ввода-вывода (в операционных системах, а не в Windows) можно вполне сносно работать при сильной нагрузке на процессор и ввод-вывод.
> ибо кодирование через CPU конкретно подвешивает фоновые программы раз в N секунд
Узнаю Windows. В твоём случае, я бы поставил отдельную пекарню для кодирования. Сегодня в этом большой проблемы нет — у многих осталось полно старого вычислительного хлама, который ещё можно запустить на круглосуточную работу без участия человека.
> Гуглил, не нашел.
Потому, что нет того, чего не может быть.
Немного не аргумент. Диавол кроется в поддерживаемых профилях и уровнях. Так, как правило, перечень весьма скромный.
> Ты еще джепегом в loseless жать предложи.
> h26x - не loseless формат.
И у того и у другого есть профили для сжатия без потерь. Матчастью не владеете.
> Олсо, аппаратные энкодеры обычно проигрывают программным по соотношению битрейт/качество.
Причём настолько, что можно облегчить искалку движения программного кодера настолько, что он будет шустрее аппаратного.
Тоже использую так. libx264 с самой простой искалкой движения, коротенькой GOP даёт сжатие лучше, чем huffyuv, и разрешение по цветоразности можно не терять. Отлично подходит мне как раз для захвата с экрана.
test
Я тебе про это уже ответил здесь
Хватит свои модные скриншоты кидать в качестве пруфа.
>Из этого вполне очевидно, что MPEG-подобные (с поиском и компенсацией движения) кодеры с ускорением на GPU работать хорошо НЕ БУДУТ
На уровне x264/x265 medium работают. Но не из-за «массовых параллельных однообразных вычислений», а потому что в карточках отдельный блок для энкодинга стоит. По сути что-то вроде ASIC. На карточках без него CUDA ни на энкодинге, ни на декодинге особого выиграша не даёт.
Вот ещё инфа: http://forum.doom9.org/showthread.php?t=171219
>Диавол кроется в поддерживаемых профилях и уровнях
Ну HEVC 10 бит вроде как все бытовые устройства поддерживают. По сравнению с H.264 10bit, который так нигде аппаратно и не прижился.
>разрешение по цветоразности можно не терять
Потеряешь на конвертации цветовых моделей. x264rgb можно :3
> Потеряешь на конвертации цветовых моделей. x264rgb можно
Шум округления? Он всё равно при сжатии с потерями потом будет замазан. Не критично.
> На уровне x264/x265 medium работают. Но не из-за «массовых параллельных однообразных вычислений», а потому что в карточках отдельный блок для энкодинга стоит.
Да. Я обосрался. Всё время забываю про это уродство. Про этот уровень даже статья в закладках есть: http://www.hardware.fr/articles/828-1/encodage-h-264-cpu-vs-gpu-nvidia-cuda-amd-stream-intel-mediasdk-x264-test.html
> По сути что-то вроде ASIC. На карточках без него CUDA ни на энкодинге, ни на декодинге особого выиграша не даёт.
Да-да. Знаю. Давайте добавим кучку транзисторов сомнительной полезности и наши продажи при хорошей рекламе поползут вверх.
>H.264 10bit, который так нигде аппаратно и не прижился
Не плачь, няшечка, всё равно рекомендуемый режим для аппаратных декодеров в плеере это DXVA2-copy (на виндоузе), а с ним выигрыш вообще минимален: https://arhivach.org/thread/109411/#1428247
лови
http://rghost.ru/8nJ64CtXN
h.264 работает. Максвелла у меня нет чтобы h.265 проверить, но nvenc_hevc включен
> Каким кодеком видео твои закодированы?
MJPEG
Сам пердолься, даун.
Есть ли быстрые способы перекодировать h264 hi10p в восьмибитку с сохранением исходных значений?
>h.265 и обязательно через GPU (750Ti)
Твоя печь не может в h.265, нужна GTX 960, GTX 970, GTX 980.
Всё прально расписал, токо не соглашусь с этим
>перегруженное вычислениями и плохо поддерживаемое разрабатываемое поделие
перегруженное вычислениями оно не будет хотя бы потому, что в задаче ОПа речь не о 4К, а с фуллхд любой комп последних 10 лет справится.
Ты долбоёб? Будь это вебм-тред, тебя бы уже обоссали. Впрочем, ты и сам с этим отлично справился.
Ладно, прийдется через CPU гонять, вроде ВидеоМастер неплохой конвертер, хоть и звучит как УСКОРИТЕЛЬ ИНТЕРНЕТА, но тем не менее, удобно и настроечки есть.
Буду ждать Паскаль, может там выкатят что-то малопотребляющее на уровне 750Ti, но с производительностью повыше и поддержкой h.265
Буду ждать Паскаль, может там выкатят что-то малопотребляющее на уровне 750Ti, но с производительностью повыше и поддержкой h.265
>4000 Кбит битрейд при 1080р
Мда, о каком качестве ты говорил?
