Кодек или параметры кодирования на точках разреза не совпадают
Обновлено: 07.07.2024
Добавлено (29 Марта 2013, 02:12)
---------------------------------------------
Рип концерт нужен именно в AVI, а не в MP4, MKV или OGV. В тех контейнерах оптимальную связку я знаю какую надо, но сейчас ищу лучшую для AVI!
Без обид, но вы же не засовываете в контейнер MP4 аудио поток OGG Vorbis? Просто контейнер AVI, по изначальной спецификации, поддерживает видео кодеки спецификации MPEG-4 Part 2 (это сам видео кодек MP4 и его усовершенствования XVID и DIVX) и аудио спецификаций вплоть до MPEG-4 Part 2 (а это PCM, MP1, MP2, MP3, AC3), но при условии, что поток данных в них CBR (VBR и ABR тоже изначально не поддерживает, а если вставлять с переменным битрейтом, то получим раcсинхрон во времени длины видео и аудио потока при декодировании). А для кодеков вроде H264 и AAC есть специальные контейнеры вроде MP4 и MKV, которые и по своим возможностям лучше AVI)))
Проблема в том, что далеко не все плееры (особенно железные) будут это воспроизводить, а для тех что будут для них, все же, правильней mp4 или mkv с такой начинкой делать. Для классического AVI, максимально совместимого со старым железом, лучше XVID+AC3/MP3(Lame) ничего нет. Но придется увеличить bpp, чтоб получить качество, сравнимое с исходным кодеком VC-1.А это ближе к истине. Но не стоит забывать о матрицах квантов. Для такой динамической картинки пришлось использовать матрицу H263, которая хоть как то сгладила картинку. Но за совет спасибо! )))
Добавлено (29 Марта 2013, 21:45)
---------------------------------------------
Может в дальнейшем создать темы по работе с видео, для помощи народу?
мне вот нужно как-то перевернуть на 90 градусов видео, снятое на телефон. Пробовал через Virtual Dub, но он не поддерживает контейнер mp4. Попробовал создать AVS-скрипт и спомощью него же повернуть видос - вроде получилось, подсовываю Дубу сохраняю, но видео и аудио уходит в рассинхрон. Скорее всего потому, что телефон мой снимает почему-то с Variable Frame Rate.
В одной статье не давно я прочёл простое правило и у меня буквально отлегло:
- Если стремимся к определённому размеру (ограничение носителя), то используем кодирование с указанием битрейта с двумя проходами для того, чтобы качество видео получиолсь максимальным.
- Если к размеру ограничений жёстких нет, то лучше использовать параметр качества, его эффективность так же высока, как при кодировании с двумя проходами, а необходимость в двух проходах отпадает, поэтому скорость кодирования вырастает на 40%.
Как только я это прочитал, просто стал ставить качество на 20 и всё. Получаешь одинаковое качество что на быстрых что на медленных пресетах. Просто быстрые пресеты увеличивают размер видео, а медленные уменьшают. Все эти рассчёты битрейта, высчитывание какой битрейт подойдёт лучше для этого видео и долгие двухпроходные кодирования остались позади.
Quantizer в настройках называется, переводится примерно как "степень деградации изображения".Я тоже забил на двухпроходное, смысл в нем есть только если нужно уложиться в размер. Для качества лучше указывать квантизер и применять шумодавы, если видео шумное
Избыточное качество для глаза человеческого начинается ниже 16, но 18 самое оптимальное. Сильная деградация начинается свыше 23.
Поэтому 23 значение по умолчанию, дающее оптимальное значение сжатие без сильной потери в качестве.
За все года, что я изучал настройки x264 и результаты, скажу прямо, ставьте --preset veryslow --crf 20 и не заморачивайтесь, можно подкрутить еще --psy-rd, но это для эстетов.
А вот флаг --no-mbtree лучше использовать, если CRF меньше 20
Но все это ерунда, если вы кодируете для себя, то как мною было сказано выше заморачиваться сверх настроек veryslow и crf=20 не имеет смысла и пожалейте свои нервы и время
QP это надстройка над битрейтом, а CRF это надстройка над QP.
CRF более продвинутая техника - там где всё двигается и человек меньше обращает внимание на детали, QP немного ухудшается, а при статичной картине, где человек начинает обращать внимание на детали, QP улучшается.
Таким образом, CRF математически может даст худший результат чем QP (PSNR), но для человека CRF даст более высокое качество по ощущениям.
Intel QSV не поддерживает CRF, поддерживается только Constant Quality к сожалению.
Добавлено (05 Декабря 2014, 19:01)
---------------------------------------------
Разница между CUDA и QuickSync - CUDA кодирует в два раза медленнее, поддерживает более продвинутый CRF (не поддерживает QP)
QuickSync быстрее в 2 раза, не поддерживает CRF, только QP.
сравнил CUDA CRF=23 и Intel QP=23.
CUDA использует более продвинутый CRF, получается в двое меньший размер на выходе. минус - в два раза ниже скорость.
а это результаты на процессоре. Кодирование в 5 раз медленнее чем CUDA (в 8 раз медленнее Quick Sync), но размер ещё меньше. 63 против 80
Добавлено (05 Декабря 2014, 19:41)
---------------------------------------------
Видео высокой четкости радует красивой и детализированной картинкой, однако оно занимает много места на диске. CHIP расскажет, как сократить объем файлов и сэкономить место в домашнем архиве.
Видео высокой четкости радует красивой и детализированной картинкой, однако оно занимает много места на диске. CHIP расскажет, как сократить объем файлов и сэкономить место в домашнем архиве.
CHIP расскажет, как сократить объем файлов и сэкономить место в домашнем архиве Лето подошло к концу, и наступила пора разобраться с отснятыми в отпуске фото- и видеоматериалами. Причем современные фотокамеры уже позволяют снимать видео в формате высокой четкости. Однако отличное качество снимков и видеороликов имеет и обратную сторону: файлы стали более объемными и в большом количестве уже с трудом могут помещаться на жесткий диск ПК. А значит, прежде чем поделиться впечатлениями с друзьями, выложив видеоролики в Сеть, а затем разместить их в домашнем видеоархиве, необходимо позаботиться о том, чтобы полученные файлы все же занимали поменьше места. Но как сделать так, чтобы все эти красивые и яркие пейзажи не были испорчены применяемыми в видеоконвертерах алгоритмами сжатия? Первое, что при ходит в голову, — найти в Интернете надежные методики компрессии без потерь. Однако чаще всего под этим понятием подразумеваются вовсе не lossless-форматы, а способы кодирования с потерями, позволяющие визуально не ухудшать качество изображения.
Стандарт для сжатия видео
Своеобразным «стандартом» в сфере кодирования видео является кодек H.264. Он поддерживается в рамках стандартов Blu-ray и HD DVD. Кроме того, с ним работают Apple QuickTime и Adobe Flash Player. Такая мощная поддержка профессионального сообщества, наряду с ростом вычислительных мощностей ПК, обеспечила ему широчайшие возможности использования в видеотехнике и программных продуктах.
Главным достоинством кодека H.264 является высокая возможная степень сжатия видеопотока без значительных визуальных изменений картинки. Достигается это за счет анализа не только каждого кадра в отдельности, но и их последовательности. В типичном видеоролике, где изображение в кадре быстро меняется лишь изредка, применяются методики предсказания сразу нескольких последующих кадров, что дает существенный выигрыш при кодировании разного рода движения. Кроме того, определенный выигрыш получается от экономии на цветовом пространстве (4:2:0 YUV вместо RGB). Это позволяет кодировать видео «на лету» без особых вычислительных затрат. Именно поэтому кодек H.264 используется в большинстве современных потребительских камер, смартфонах и видеорегистраторах.
Идеальное сжатие и высокое качество
Вкратце опишем процесс настройки бесплатного кодека ffdshow tryouts (есть на CHIP DVD) построенного на базе H.264. Наша цель — продемонстрировать основные возможности, поэтому мы остановимся лишь на нескольких базовых параметрах. Для конвертирования видео мы выбрали бесплатную программу MeGUI и пакет кодеков K-Lite Codec Pack (есть на CHIP DVD). После того как вы установите эти два пакета, откройте MeGUI. На вкладке «Input» в меню «Encoder setting» выберите вариант «x264» и кликните по кнопке справа «Config». Теперь можно заняться настройкой параметров кодека. Они разделены на несколько закладок.
MAIN — здесь можно задать «Preset» кодирования. Для «домашнего» видео имеет смысл выбирать медленные пресеты («Slow», «Slower» и т. п.). Кроме того, в меню «Tuning» можно выбрать характер кодируемого ролика. Это тоже своего рода пресет, «включающий» определенные параметры оптимизации.
FRAME-TYPE — группа параметров, управляющих качеством сжатия. H.264 поддерживает многопроходное кодирование. Опытные пользователи считают, что для перекодирования фильмов оптимально использовать два прохода. Ниже задается требуемая степень сжатия. Все зависит от выбранного режима: можно указать либо битрейт, либо индекс качества.
MISC — здесь в поле «Custom command line» опытные пользователи могут задать дополнительные параметры кодирования. Доступные команды можно найти в спецификации метода.
Хотя H.264 и относится к стандарту «сжатие с потерями», в нем не применяются методики обратимой архивации. В частности, в H.264 позволяется выбрать способ сжатия без потерь по итогам всей обработки: CABAC (Context adaptive binary arythmetic codes) или CAVLC (Сontext adaptive variable length codes). Правда, стоит отметить, что в использованной нами в качестве примера бесплатной библиотеке ffdshow эта настройка из графического интерфейса недоступна.
Сохраняем видео в архив и на YouTube
Отснятые в отпуске видеоролики в высоком разрешении, как правило, занимают много места на диске. Хранить их в таком виде в домашнем видеоархиве не очень экономно. К тому же многие предпочитают делиться впечатлениями с друзьями, выкладывая наиболее интересные ролики на популярный видеохостинг YouTube. Мы предлагаем совместить архивирование контента и подготовку роликов к закачке на видеосервис, воспользовавшись нашими советами по сжатию роликов без ощутимых потерь и адаптируя их для размещения в Сети.
YouTube, как и многие другие онлайн-сервисы, применяет методику сжатия H.264. При этом для эффективной передачи видео по Сети, в том числе на мобильные устройства, ресурс задействует строго определенный набор параметров. При загрузке ролика на сервер осуществляется его перекодирование с учетом этих параметров. Наилучшего качества удастся достичь вовсе не наибольшим потоком или индексом качества, заданными при кодировании, а наиболее удачным подбором параметров под требования видеохостинга. Иными словами, если вы хотите в итоге разместить видео на YouTube, сжатие без потерь для вас будет означать следование следующим рекомендациям.
КОНТЕЙНЕР MPEG-4. Для сохранения видео YouTube рекомендует использовать контейнер MPEG-4, который является в каком-то смысле «родным» для H.264. Для этого воспользуйтесь бесплатной программой Avidemux (есть на CHIP DVD).
«ВЫСОКИЙ» ПРОФИЛЬ (HIGH QUALITY). В базовых параметрах кодека надо указать «Высокий» профиль (High). Для кодирования видео HD качества следует использовать уровень не ниже 4: лишь начиная с него поддерживается разрешение 1920×1080 точек с частотой до 30 кадров/с. Цветовое пространство — 4.2.0. Уровень можно выбирать самому.
В Avidemux в разделе «Video Output» выберите кодек MPEG-4 AVC (x264) и в настройках последнего задайте профиль «High Quality» СРЕДНИЙ БИТРЕЙТ. Для видео высокой четкости (разрешение 1920×1080 точек при 29,97 кадра/с) YouTube рекомендует устанавливать средний битрейт от 5 до 8 Мбит/с. Его можно задать вручную, выбрав на первой вкладке метод кодирования «Average Bitrate». Это уменьшит размер файла с сохранением того же качества.
Чтобы вручную указать битрейт, в настройках кодека x264 на вкладке «General» задайте метод кодирования «Average Bitrate» B-КАДРЫ. При кодировании видео на ресурсе задействованы так называемые B-кадры — кадры, предсказанные с помощью специального алгоритма по двум соседним. Рекомендуем указывать присутствие двух последовательных B-кадров. При этом закрытая группа изображений (GOP) должна составлять не более половины кадровой частоты (15, если речь идет о 29,97 кадра/с).
На вкладке «Frame» установите значение последовательных B-кадров (B-Frame), равное двум СЖАТИЕ CABAC. В качестве дополнительного метода сжатия без потерь используется не самый эффективный, зато применимый на мобильных устройствах CABAC (Context adaptive binary arythmetic codes).
Для улучшения качества кодирования видео на вкладке «Frame» можно задать дополнительный метод сжатия без потерь CABAC ЗВУК В AAC-LC. Для аудио следует задействовать кодек AAC-LC (в Avidemux применяется тип AAC lav) при частоте дискретизации 48 или 96 кГц.
Для домашнего архива звук в видеоролике можно оставить без обработки. Для YouTube необходимо применить кодек AAC-LC
Сжатие без потерь: lossless-форматы
Методика сжатия видео без потерь — это обратимая архивация, аналогичная той, что мы применяем, к примеру, при упаковке в архив текстовых и других документов для пересылки по электронной почте. Она позволяет получить исходные данные в неизменном виде после распаковки. При работе с видео наибольшей степени компрессии можно добиться, применяя специальные алгоритмы. Наиболее известными считаются следующие из них.
MOTION JPEG 2000 — коммерческий кодек для видео (около 1200 руб., демоверсия есть на CHIP DVD), построенный на принципах сжатии без потерь статических изображений JPEG2000.
Коммерческий кодек MJPEG2000 позволяет кодировать видео без потерь в качестве, обеспечивая высокую степень сжатия HUFFYUV — достаточно быстрый и эффективный свободный кодек, основанный на методике побитового предсказания следующего пикселя в потоке и архивации данных (есть на CHIP DVD).
Свободно распространяемый кодек Huffyuv также обеспечивает высокую степень сжатия видео без ощутимых потерь в его качестве LAGARITH — «продолжатель» идеи кодирования Huffyuv (есть на CHIP DVD). Авторам удалось добиться большей степени сжатия, в частности, за счет добавления методов работы с почти статическими изображениями. Обращение с роликами, сжатыми с помощью lossless-алгоритмов, осложнено тем, что они занимают много места на диске и поддерживаются ограниченным числом плееров и бытовых устройств. При этом они действительно нужны, только если камера позволяет скопировать несжатые данные (так называемые RAW, по аналогии с фотографией) либо по каким-то причинам важна высокая точность передачи этого изображения. Из специальных областей это могут быть медицина и картография.
Кодек Lagarith можно бесплатно использовать для «домашнего» кодирования — например, с помощью программы VirtualDubMod
Так ли необходимо сжатие без потерь?
Применительно к цифровому видео понятие «сжатие без потерь» подразумевает, что алгоритм позволяет архивировать каждую картинку в том виде, в каком она была получена с записывающего устройства. При этом стоит отметить, что фото и видео, снятые даже полупрофессиональной видеокамерой, не требуют столь бережного отношения к себе. В кадре почти всегда присутствуют шумы, аберрации и искажения, которые в целом не влияют на наше восприятие картинки — иными словами, картинка, как правило, сама по себе не идеальна. Применяя методики сжатия с потерями, вы, конечно, еще немного «испортите» ее, сэкономив на избыточности как в рамках отдельных кадров, так и внутри их последовательности. Но при этом вы добьетесь значительно большей степени компрессии, то есть в десятки раз меньшего размера файла на жестком диске.
А что будет дальше?
Различные видеосервисы, в частности «видео по запросу», уже задумываются о переходе на следующую версию стандарта — H.265, эффективность сжатия которого гораздо выше. Используемый кодек даст возможность гибко управлять качественными потерями. Кроме того, он позволит работать с непостоянной частотой кадров.
Важно! Статья рассчитана на опытных пользователей Windows, которые самостоятельно смогут установить себе FFmpeg и vlc, изменить программу по умолчанию, задать переменную окружения, отредактировать в определённой кодировке и запустить пакетный файл, а также впоследствии изменить некоторые параметры кодирования в соответствии со своими предпочтениями. Ещё следует обратить внимание на то, для каких целей и при каких условиях разрешается такая обработка видео правообладателем. В любом случае, наверняка, нельзя видео, если оно не принадлежит вам, передавать кому-либо или распространять в интернете, а после просмотра на Smart TV, который, например, не может самостоятельно его воспроизвести, следует сразу же удалить с компьютера.
Зачем это бывает нужно и при каких условиях видео кодируется быстро
Лет пять назад, когда на сайтах наших федеральных телеканалов выкладывались ещё не все записи передач, записывал по расписанию IP TV передачи некоторых каналов, которые наш интернет провайдер в тестовом режиме и тогда и сейчас бесплатно транслировал и разрешал к просмотру на компьютере (пользователям IP адрес и порт трансляции нужного канала предоставлен в плейлисте для vlc на сайте этого местного интернет провайдера). Сейчас я купил телевизионную приставку, докупил у провайдера ещё платные каналы и возможность отложенного просмотра в течение трёх дней. Пользуюсь приставкой для обычного просмотра телепередач теперь и если не получается получить на компьютер запись интересной передачи (не выкладывают или когда сталкиваюсь с неустранимыми сбоями при скачивании). А раньше единственной возможностью у меня (кроме захвата видео кабельного телевидения тюнером) была запись IP TV при помощи бесплатного медиаплеера vlc (кстати, он воспроизводит практически всё) с ПК или миникомпьютера Raspberry Pi с последующей обработкой. Если записывал на компьютере с Windows, то примерно так (для просмотра этого пакетного файла не требуется регистрация или вход в аккаунт облачного сервиса DropBox, не нашёл как здесь иначе показать cmd файл без переносов строк и с подсветкой синтаксиса). Практически всегда после записи обрабатывал видео при помощи купленного тогда TS-Doctor , чтобы сбои трансляции не вызывали потом остановок воспроизведения. Но когда купил не так давно новый компьютер с неплохой видеокартой GeForce, необходимость в платном обновлении TS-Doctor до новой версии отпала, поскольку теперь похожую обработку можно делать быстро и бесплатно при помощи этой видеокарты. Если кодировать видео только процессором, это может занять очень много времени, кодирование же видеокартой даёт значительный прирост скорости. Ещё перекодирование в mp4 может быть полезным, если у вас есть архив старых домашних видеозаписей, которые планируете просматривать в будущем и хранить их достаточно долго. В настоящее время mp4 - самый распространённый формат и, возможно, старые видео имеет смысл перекодировать в него. Не исключено, что при этом размер видео даже уменьшится, особенно, если при кодировании применить перспективный кодек h.265, а не наиболее популярный сейчас h.264. Но не стоит сильно рассчитывать на сокращение размера видео, если оно, например, получено с видеокассеты и содержит шумы.
Использование FFmpeg для кодирования видео
Сначала простая задача по выделению не просмотренного остатка видео
Для кодирования видео, если нужно задействовать при этом все возможности установленной видеокарты GeForce (а даже и Intel, только у меня настройки для неё в скрипте не приведены, но они без особых проблем находятся в интернете), можно использовать бесплатный FFmpeg , для чего следует распаковать скачанный с указанной страницы архив в некоторую доступную для записи папку на жёстком диске компьютера. Приведу здесь вариант моего пакетного файла encode.cmd, который запускает FFmpeg с определёнными параметрами. Рассмотрим этот cmd файл подробнее. В данном случае он предназначен для быстрого и точного нахождения стартового ключевого кадра, с которого будет начинаться оставшаяся часть видео. Предполагается, что примерно один час записи мы уже посмотрели, перематывать видео на телевизоре с пульта неудобно (именно это, как раз, довольно протяжённое по времени), а в дальнейшем мы хотим видеть только не просмотренную его часть. После завершения работы скрипта запустим полученный видеофайл (имя которого заданно в переменной output) для просмотра плеером vlc (если нужно, установим его как программу по умолчанию для такого типа файлов) и подкорректируем немного (в несколько итераций) момент начала получившейся записи в последней строке пакетного файла, заданное параметром -ss, например до "59:58" или, например "1:00:10", как вам кажется более естественным для сюжета.
Когда точное значение параметра -ss будет подобрано, можно будет убрать параметр -t 0:30, который определяет, что длительность результирующего видео равна 30 секундам, чтобы получить желаемый остаток видео от стартового кадра до самого конца записи. Как видно на скриншоте, видео обрабатывалось в 462 раза быстрее обычной скорости его воспроизведения. Для такого варианта работы (без перекодирования) это обычный по скорости результат. Обращаю внимание, что в последней строке этого моего пакетного файла файл на самом деле не перекодируется (задана соответствующая группа параметров через значение переменной %copystreams%). Также важно, что параметры -ss и -t в этой строке расположены непосредственно перед параметром -i, чтобы они влияли именно на входной файл. Иногда важно при обработке записанного IP TV применение параметра -fflags +genpts. Я использую этот параметр всегда. Подробности его применения найдите самостоятельно, если интересно. На что ещё можно обратить внимание в этой строке пакетного файла, так это на способ вызова ffmpeg.exe из папки, которая не находится у меня в пути поиска, а задана переменной окружения %FFmpegPath%. Я так сделал потому, что периодически обновляю FFmpeg, просто распаковывая в подпапку с содержащимся в архиве названием, которое от версии к версии меняется. Можно было бы не использовать такую переменную окружения, но у меня FFmpeg вызывается из нескольких пакетных файлов и подобный вариант достаточно для этого удобен. Впрочем, вы можете придумать на замену какой-нибудь свой вариант вызова и использовать его в вашем пакетном файле. Ну и ещё отмечу, что в переменной output расширение выходного файла установлено как .ts, поскольку файл предназначен для отправки на Smart TV. Это же расширение (и соответствующий контейнер) применяется также и в первом приведённом здесь скрипте (предназначенном для записи IP TV из интернета в сети моего провайдера). Контейнер MPEG-TS обычно и используется для потокового видео.
Задача чуть посложнее: разбиение видео на части и слияние аналогичных по параметрам частей
Разбиение видео на части почти не отличается от варианта, рассмотренного выше. Только вместо параметра -t используется параметр -to, в котором указывается момент времени, до которого длится в исходном видео требующаяся нам в качестве выходного файла часть.
Слияние видео достаточно просто и интуитивно понятно. Привожу здесь пакетный файл и настройки к нему. Оба файла должны быть согласованы, находиться в одной папке и иметь заданные здесь кодировки текста, причём разные для каждого из файлов, чтобы можно было без проблем использовать названия видеофайлов на русском языке. Этот вариант слияния подходит нам только тогда, когда параметры кодирования (используемые кодеки и их настройки) всех файлов одинаковы. Это бывает, как в этом случае, когда файлы взяты из одного источника и являются частями разбитого на части большого исходного файла. Посмотреть параметры кодирования файла (используемый контейнер, видео- и аудио- кодек, а также ряд других параметров подробнее) можно при помощи MediaInfo . Также без проблем склеиваются видео, перекодированные с применением одних и тех же параметров в рассмотренном здесь моём пакетном файле encode.cmd. Подробности найдёте в интернете.
И, наконец, кодирование видео
Если вы разобрались с написанным выше, то перекодирование видео не составит труда. Для этого немного изменим пакетный файл encode.cmd: в последней строке его уберём, если необходимо, параметры -ss и -t и заменим переменную %copystreams% на, например, %encode_h264_nvenc% или %encode_h264_HD_nvenc% для кодирования видео в стандартном или высоком качестве соответственно и зададим в переменной output расширение выходного файла как mp4. Вот и все настройки. Теперь запускаем пакетный файл и ждём завершения процесса кодирования. В зависимости от класса видеокарты GeForce процесс кодирования может занять больше или меньше времени, но всё равно это должно быть намного быстрее, чем с применением только процессора компьютера (при использовании параметров из переменной %encode% вместо %copystreams%). Так же кодируется видео в h265, соответствующие настройки есть в переменных этого пакетного файла. Для начала можно кодировать с заданными мной параметрами, а затем при необходимости поменять на более пригодные именно для вас. Все параметры кодирования с помощью видеокарты можно посмотреть, чтобы затем подобрать подходящие настройки, выполнив команду:
Важно, что во время кодирования с применением видеокарты, она не должна заснуть, а быть постоянно в рабочем состоянии, то есть если обычно на компьютере задано время отключения экрана в параметрах управления электропитанием, то нужно установить его в "Никогда" на время перекодирования.
Надеюсь, что статья и приведённые в качестве примера файлы помогут опытному пользователю начать разбираться в кодировании при помощи установленной на его компьютере видеокарты.
все чаще упоминается другой параметр, который настоятельно рекомендуется использовать при кодировании с помощью x264. Параметр называется - crf
-x264encopts crf=xxx (можно тестировать на значениях 17-21). Преимущества - один проход, значит выше скорость кодирования, высокое качество кодирования.
Реально кто-то ощутил преимущества этого параметра при кодировании с помощью x264 ?
crf=<1.0-50.0>
Задействует режим постоянного качества и выбирает его уровень.
Шкала такая же, как и для QP. Как и в режимах, основанных на
битпотоке, эта опция позволяет каждому кадру использовать
собственный QP, основанный на сложности кадра.
помните crf не совместим с qp и bitrate и pass=2 параметрами. Но модет использоваться в первом проходе, в то время как для второго прохода его не сипользуем, а используем bitrate
При обычном однопроходном кодировании размер файла получается заданным, но за счет непостоянного качества (т.е. наличия как сцен с выраженными артефактами сжатия, так и сцен с безупречным качеством, которые только зря тратят биты). При двухпроходном кодировании получается как предсказуемый размер файла, так и постоянное в пределах файла качество (ровно такое, какое нужно для получения нужного размера - т.е. непредсказуемое).
Если кодируешь для записи на болванки, используй 2pass. Для всех других целей - crf или qp.
Качество будет хуже. Слова не мои, знакомого, который постоянно энкодит БД и не только на протяжении двух лет.
>>Если кодируешь для записи на болванки, используй 2pass. Для всех других целей - crf или qp.
в той же рассылке пишут, что не надо использовать qp - типа это был экспериментальный параметр и лучше использовать crf
Для всех других целей - crf или qp.
а если во главу угла стоит качество, то 2pass советуете ?
> а если во главу угла стоит качество, то 2pass советуете ?
Если размер файла совершенно не важен, то 2pass - лишняя трата времени по сравнению с crf. Мало того, что он кодирует весь фильм два раза, так еще и не даст посмотреть, что получится, пока не закодирует все (а с crf можно оценить результат сразу по маленькому кусочку фильма).
а какой битрейт для 576i@50 преобразованного с помощью yadif в 576p@50 вы посоветуете для 2pass ? 2500 килобит/c хватит ?
> а какой битрейт для 576i@50 преобразованного с помощью yadif в 576p@50 вы посоветуете для 2pass ? 2500 килобит/c хватит ?
>>Качество будет хуже. Слова не мои, знакомого, который постоянно энкодит БД и не только на протяжении двух лет.
а что он может энкодить в блюрее, если он уже сжат x.264 (или он просто в другой контейнер переводит, оставляя сам сжатый контент без изменения ?)
Там MPEG4, подробности в вики. У БД-плееров числодробилки не отрасли еще x264 щелкать. В DVD тоже не несжатый поток.
>>Там MPEG4, подробности в вики.
ну так и я про MPEG-4 H.264/AVC глаголю. Именно он или (что реже) VC-1 на блю-рее встречается.
У БД-плееров числодробилки не отрасли еще x264 щелкать.
Читайте также: