Search options (Page 216 of 236)

John_Wayne
гребёнка исчезает
Можно скриншоты? Без деинтерлейса и с ним? Подозреваю, что разговор не совсем про гребенку. Скриншоты покажут, что это. Скорее всего это неравномерность хромы. Исправлять тогда лучше вовсе не деинтерлейсом.

Rimsky
Ты не въехал. Я не про методы ДЕинтерлейса, а про разный интерлейс (чересстрочка). Какой он нафиг разный! Он один! Это формат записи видео отдельно по полям.

Либо чересстрочка есть, либо ее нет.

Зачем деинтерлейс после IVTC? После IVTC деинтерлейс не просто не нужен, он вреден.

---
sergioleon
Можете объяснить, что на скринах? И что такое 5-tap lowpass filter?

John_Wayne
Что нужно дописать в скрипт, чтобы аудиодорожка обрабатывалась ?
Это вопрос к тем, кто работал со звуком в Avisynth. Я не сторонник лишних преобразований и даже не пытался протаскивать звук через Avisynth. Соответственно вопросы выбора дорожки не решал.

Rimsky
Я надеялся про скорость что-нибудь услышать

---
x264 losless оказался еще медленней, чем x264 CRF=21, а размер файла получился еще больше, чем у MJPEG. Для ускорения процесса кодирования не подходит.

Rimsky
кодировать обязательно на ффд?
Вовсе нет. Просто ffdShow уже установлен, если установлен пакет SVP. Все остальные кодировщики необходимо скачивать и устанавливать отдельно.

x264 Losless не пробовал. Чем он лучше по сравнению с CRF=21 кроме качества?

Мой совет насчет сжатия в ffdShow H.263+ или ffdShow WMV V7 уже устарел. Таких форматов сжатия, присутствовавших раньше в ffdShow, теперь нет.
Причина, которую указывают разработчики ffdShow:

Перевод: Удалены некоторые кодировщики. Интерфейс, предоставляемый ffdShow для этих библиотек сжатия, не сопровождался и был "глючным". Команда разработчиков ffdShow рекомендует использовать вместо них официальные кодировщики (такие как x264VFW и Xvid). Они всегда имеют свежие версии, стабильны в работе и обладают полной функциональностью.

Вот какие форматы остались:

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

Noweol
тебе повезло
Ну я бы так не сказал

alekmyac
N/A - это нехороший звоночек. Это означает, что в процессе теста не все прошло, как полагается, шаг теста не добрался до своего завершения. Такое может быть, если измерение прервалось досрочно из-за переразгона процессора, например. Или, что куда хуже, из-за других проблем в системе. Если система проработала в разогнанном состоянии, вызывающем ошибки в вычислениях процессора, то нет гарантии, что в процессе работы она сама себя не попортила.

SVPMark разогревает процессор не меньше (а может даже и больше), чем известные прогревочные тесты.

Давайте-ка, снижайте разгон до тех пор, пока тест не станет проходить.
Ну и нужно будет проверить отсутствие тротлинга во время работы SVPMark. Это можно сделать, например, при помощи AIDA64.

John_Wayne
частота телесиненного видео не 30, а 29.97 fps
Не удивлюсь, если 29.97, несмотря на стандартные 25 fps поделить на 5 и умножить на 6 = 30 fps
Надо поглядеть статистику при воспроизведении. и 29.97 и 30 - это разрешенные стандартом частоты кадров.
Самое надежное - глянуть синхронизацию звука и видео в конце полученного ролика. Если звук отстает, значит надо указывать 29.97.

кодирование шло не быстрее реального времени
Это еще что! Я вчера многопоточный вариант запускал. Максимум добился скорости 1,37х. Начал разбираться - так это ограничение пропускной способности сетевой карточки (~8 МБ/сек), т.к. кинушку я тянул по сети, а не с локального диска.
Т.е. скорость обработки упиралась в скорость чтения видео.

какие кодеки нужно установить, чтобы в меню GDSMux появилась возможность кодировать в ffdShow H.263+ ?
Раньше в XP достаточно было установленного ffdShow. На Win7 попробовал - не заработало. Вечером поищу ответ.

KRATOS
Rimsky
Я не профессиональный кодер видео, поэтому мои советы исключительно по результатам собственных замеров скорости. Мыло я не оценивал, но думаю, что на любом кодеке можно получить идентичное качество, вопрос только в степени сжатия. В данном случае степень сжатия некритичный параметр.

H263+ быстрее жмется и быстрее распаковывается по сравнению с тяжелым H.264.