Двухпроходное кодирование в реальном времени (Имеется ли такой софт?)

[admiral]

Собственно вот таким вопросом задался, имеется ли софт, что бы в реальном времени кодировать видео в 2 прохода (например запись с ТВ-тюнера). Думаю современным компам с двухядерными процессорами вполне это под силу.

[Denjs]

гм.. не думаю что под силу... хотя может 320*200 и обработает real-time..
вот если 2-х процессорная система с 2-я двухядерными нагрузить под завязку тогда может быть ещё-как-то...

я мувики на наладонник перекодировываю - "ресайзинг" в 320*200 а потом кодирование... примерно за час часовой мувик и обрабатывается... на селероне одноядерном на 2500 мгц....
на 2-х ядерном при соответствующей оптимизации может и удастся получить real-time на 400*300 ...

[Xentrix]

Собственно вот таким вопросом задался, имеется ли софт, что бы в реальном времени кодировать видео в 2 прохода (например запись с ТВ-тюнера). Думаю современным компам с двухядерными процессорами вполне это под силу.

Нет. Не существует. И никогда не будет существовать. В силу самого смысла двухпроходного кодирования. Первый проход - тестирование записи. Второй - оптимизированное по времени-качеству декодирование на основе данных первого прохода.
Двухпроходное real-time-декодирование - это все равно, что одновременно подстригать волосы "под машинку на ноль" и при этом размышлять, какой длины оставить волосы - 10 или 20 сантиметров.

[admiral]

Собственно вот таким вопросом задался, имеется ли софт, что бы в реальном времени кодировать видео в 2 прохода (например запись с ТВ-тюнера). Думаю современным компам с двухядерными процессорами вполне это под силу.

Нет. Не существует. И никогда не будет существовать. В силу самого смысла двухпроходного кодирования. Первый проход - тестирование записи. Второй - оптимизированное по времени-качеству декодирование на основе данных первого прохода.
Двухпроходное real-time-декодирование - это все равно, что одновременно подстригать волосы "под машинку на ноль" и при этом размышлять, какой длины оставить волосы - 10 или 20 сантиметров.

Думаю ваше сравнение неверное.
Мне видится такая схема работы двухпроходного кодирования: внчале идет запись видео на максимальном качестве, можно даже без сжатия, в оперативу (думаю 1 минута видео телевизионной записи будет занимть порядка 1Гига - это очень грубый подсчет). Одновременно с этим происходит анализ этого видео. Где-то, к примеру, через минуту (думаю такого времени вполне достаточно, что бы оценить потребность конкретных сцен) начинается 2-й проход кодирования записанного видео с учетом полученных данных о записанном куске видео и запись результирующего видео на жесткий диск. Обработанное видео после 2-го прохода удаляется из ОЗУ.
Возможно это и нельзя назвать 2-х проходным кодированием в реальном времени, т.к. тут есть задержка на минуту, но думаю такую схему кодирования вполне реально можно реализовать.

[Alastis]

Думаю ваше сравнение неверное.
Мне видится такая схема работы двухпроходного кодирования: внчале идет запись видео на максимальном качестве, можно даже без сжатия, в оперативу (думаю 1 минута видео телевизионной записи будет занимть порядка 1Гига - это очень грубый подсчет). Одновременно с этим происходит анализ этого видео. Где-то, к примеру, через минуту (думаю такого времени вполне достаточно, что бы оценить потребность конкретных сцен) начинается 2-й проход кодирования записанного видео с учетом полученных данных о записанном куске видео и запись результирующего видео на жесткий диск. Обработанное видео после 2-го прохода удаляется из ОЗУ.
Возможно это и нельзя назвать 2-х проходным кодированием в реальном времени, т.к. тут есть задержка на минуту, но думаю такую схему кодирования вполне реально можно реализовать.

все это теория
первый проход кодирования - сбор информации о видеоматериале
второй проход - непосредственно само кодирование с использованием .stats файла
есть конечно у XviD одна интересная опция, ЕМНИП "Discard First Pass" [за ошибки просьба не пинать, давно этим не занимался], если ее отключить (включена по дефолту), то получим после первого прохода и видеоматериал, и stats-файл (а вот насчет качества - хз), все это дело желательно сохранить в raw, без всяких контейнеров, а потом через некоторое время после начала 1 прохода начать и 2.
так что теоретически вполне реализуемо, но вся эта связка неудобна и ненадежна (очень велика вероятность, что видео будет записываться с пропуском кадров, что не есть гут)
p.s. не легче ли в реалтайме записать видео в наилучшем качестве (ЕМНИП, ниже квантизер - выше качество), а потом запустить двухпроходное кодирование, никуда не торопясь?

[Denjs]

В общем случае - вынужден признать поправки Xentrix, но если флудить, так флудить....

предложу на уровне идеи идею такой программы:
блоками, скажем по 1 минуте мы обрабатяваем видео, статистика собирается в рамках одной минуты, потом митута прошедшая первый проход отправляется на второй проход? на выходе мы имеем потом в задержкой 1 минутя но "real-time".

Или динамически обновлять статистику скажем за последни 10 минут и пробовать использовать её для прогнозирования лучших режимов кодирования в ближайшем будущем?

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

[kreator]

ИМХО оптимальное решение x264 crf. Двух проходное кодирование интересно только тогда, когда нужно вписаться в строго определенный размер конечного файла при максимально достижимом качестве. Что бы получить реальное преимущество от двух проходов, при неизвестном конечном размере, нужно очень точно подобрать битрейт и он будет существенно отличаться для разного материала.

предложу на уровне идеи идею такой программы:
блоками, скажем по 1 минуте мы обрабатяваем видео, статистика собирается в рамках одной минуты, потом митута прошедшая первый проход отправляется на второй проход? на выходе мы имеем потом в задержкой 1 минутя но "real-time".

Минуты недостаточно, хотя бы 10-20 минут.

[-=SADKO=-]

Нет. Не существует. И никогда не будет существовать. В силу самого смысла двухпроходного кодирования. Первый проход - тестирование записи. Второй - оптимизированное по времени-качеству декодирование на основе данных первого прохода.
Двухпроходное real-time-декодирование - это все равно, что одновременно подстригать волосы "под машинку на ноль" и при этом размышлять, какой длины оставить волосы - 10 или 20 сантиметров.

Думаю ваше сравнение неверное.
Мне видится такая схема работы двухпроходного кодирования: внчале идет запись видео на максимальном качестве, можно даже без сжатия, в оперативу (думаю 1 минута видео телевизионной записи будет занимть порядка 1Гига - это очень грубый подсчет). Одновременно с этим происходит анализ этого видео. Где-то, к примеру, через минуту (думаю такого времени вполне достаточно, что бы оценить потребность конкретных сцен) начинается 2-й проход кодирования записанного видео с учетом полученных данных о записанном куске видео и запись результирующего видео на жесткий диск.

Нефига, всё абсолютно точно изложил Xentrix, а то что вам видится существует и называется вариабильным битрэйтом. Данные поступают непрерывным потоком и жмутся с неким битрейтом X но перед\после\одновременно (зависит от конкретной реализации) с этим ведётся статистика по энтропии этих данных и оная статистика уже используется для управления битрэйтом с которым происходит сжатие. И это всё счастье называется однопроходным сжатием с переменным битрэйтом и вы смело можете его использовать, по качеству оно может быть даже лучше двухпроходного! Двух проходное сжатие нужно дабы точно подогнать объём данных под ёмкость физического носителя, когда с запасом по качеству оно туды не лезет. Есть ещё трёх проходное сжатие, но это уже другая история.

PS. А объёмы после VBR кодирования не так уж и не предсказуемы, что бы не использовать оное для пережатия видео для мобильных устройств.

[kreator]

по качеству оно может быть даже лучше двухпроходного!

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

PS. А объёмы после VBR кодирования не так уж и не предсказуемы

Верно, так как кодек старается удержать средне заданный битрейт. Но имхо, гораздо удобнее задать постоянное качество и не подбирать битрейт каждый раз ;)

[sspphheerraa]

Есть ещё трёх проходное сжатие, но это уже другая история.

Расскажите... в теме Грамотный кодинг видео в Linux

[admiral]

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