#directshow #encoder #high-resolution
#directshow #кодировщик
Вопрос:
Я использую два пользовательских push-фильтра для ввода аудио и видео (несжатый RGB) в график DirectShow. Я создаю приложение для захвата видео, поэтому я хотел бы кодировать кадры по мере их поступления и сохранять их в файле.
До сих пор я использовал ASF Writer для кодирования входных данных в WMV-файл, но, похоже, средство визуализации слишком медленно обрабатывает входные данные с высоким разрешением (например, 1920x1200x32). По крайней мере, FillBuffer() кажется, что он способен обрабатывать только около 6-15 кадров в секунду, что, очевидно, недостаточно быстро.
Я пытался увеличить cBuffers количество в DecideBufferSize() , но это, конечно, только отодвигает проблему на более поздний этап.
Какие у меня есть варианты ускорить процесс? Как правильно выполнять кодирование в реальном времени с высоким разрешением через DirectShow? В конечном итоге я хочу получить WMV-видео, но, возможно, это должен быть этап постобработки.
Ответ №1:
Здесь размещены отличные ответы на ваш вопрос: захват в высоком разрешении и кодирование слишком медленное. Задача слишком сложна для процессора вашей системы, который просто недостаточно быстр для выполнения кодирования видео в реальном времени в конфигурации, которую вы настроили для его работы.
Комментарии:
1. Да, ответы на MSDN пришли быстрее, чем здесь (это впервые 🙂 Из любопытства, у вас есть ответ на последний вопрос, который я там задал (тот, что касается частоты кадров)?
2. Очевидно, что часть, требующая больших затрат процессора, — это кодировщик. И encoder должен использовать несколько ядер процессора для обработки данных и затрачивать как можно меньше времени на обработку — вы мало что можете сделать, настраивая только настройки программного обеспечения, если encoder не может вовремя предоставить вам сжатый контент. Возможно, наиболее очевидным является меньшая сложность кодирования — таким образом, вывод происходит быстрее при сохранении всех остальных параметров.
3. Извините, я имел в виду следующий вопрос в моем последнем посте, то есть вопрос о времени захвата отдельных кадров. Должен ли я всегда пытаться попадать в целевую метку видео, т. Е. каждые 1/30 секунды с момента первой временной метки кадра, или мне следует просто переходить на 1/30 секунды с момента последнего захвата кадра (при условии, что я снимаю со скоростью 30 кадров в секунду)?
4. Учитывая, что кодировщик не может выполнять сжатие в режиме реального времени, чего именно вы пытаетесь достичь? (а) найти другой режим, менее трудоемкий с точки зрения вычислений (б) снизить частоту кадров (в) накапливать необработанные данные и сжимать полный фрагмент медленнее, чем в режиме реального времени?
5. Вопрос, который я задаю в конце темы, на которую вы ссылались выше, касается не быстрой передачи кадров через кодировщик, а вместо этого захвата кадров. Поскольку я не контролирую частоту кадров в приложении, из которого я их получаю, я пытаюсь захватывать кадры в наилучшее возможное время, чтобы закодированное видео выглядело как можно более гладким.