Проблемы с памятью при видеопереходах в службах редактирования DirectShow - PullRequest
0 голосов
/ 18 января 2011

Я столкнулся со странной, по-видимому, связанной с памятью проблемой при использовании DES для перехода между перекрывающимися видеоклипами или неподвижными изображениями, и мне любопытно узнать, обнаружили ли другие пользователи DES ту же проблему или это какая-то ошибка мой собственный, который я не смог найти.

Я обнаружил, что как только временная шкала имеет достаточное количество переходов, временная шкала перестанет воспроизводиться частично в процессе воспроизведения. Ошибки DirectShow не возникают, и DirectShow не сообщает, что воспроизведение завершено, но IVMRWindowlessControl9 :: RepaintVideo вернет S_OK, ничего не рисуя, и фильтр преобразования, который я вставил в цепочку фильтров, перестанет вызывать свой метод Transform ().

Если я продолжу добавлять переходы (что также означает добавление новых клипов для перехода между ними), воспроизведение будет прерываться раньше и раньше на временной шкале, пока в конечном итоге DirectShow вообще ничего не отобразит.

Диспетчер задач Windows указывает на постоянное увеличение использования памяти во время воспроизведения, причем скачок каждый раз, когда воспроизведение достигает перехода, достигает пика при увеличении использования памяти примерно на 150 Мб в момент сбоя рендеринга. После этой точки вызовы new или fopen иногда будут неудачными, хотя это ненадежное поведение. Воспроизведение одних и тех же клипов, но без переходов между ними приведет к увеличению объема используемой памяти примерно на 50 МБ по сравнению с первыми тремя или четырьмя клипами, но больше не увеличивается, и рендеринг никогда не прерывается.

Ключом к тому, как быстро происходит сбой, являются размеры носителя ввода. При использовании неподвижных изображений 1920 x 1080 сбой начнется примерно с 35 переходами на временной шкале; с 640 x 480 видеоклипами требуется около 80. Другие факторы - неподвижные изображения и видеоклипы, длительность перехода, конкретный используемый переход - похоже, не имеют значения.

150 МБ в дополнительной памяти будут освобождены, когда я перезапущу воспроизведение (но не когда я остановлю его), и я могу добавить или удалить переходы в течение одного сеанса, чтобы проблема появлялась и исчезала, что, казалось бы, указывает на чистая утечка памяти, хотя я пока не готов абсолютно ничего исключать.

На всякий случай, если это хоть что-то освещает, моя машина для разработки работает под управлением 64-битной Windows 7.

Подводя итог: я пытаюсь выяснить, является ли это ошибкой DES, с которой мне придется работать, или же, как это часто бывает, это моя собственная ошибка. Удалось ли другим разработчикам создавать временные шкалы DES с большим количеством переходов (50-100), которые успешно воспроизводятся? Или столкнулись с такой же проблемой и выяснили, как с ней бороться? Или есть какие-нибудь сотрудники Microsoft, которые могут подтвердить это как ошибку DES и предложить обходные пути?

Спасибо, что нашли время прочитать это длинное сообщение, и заранее спасибо за ваши ответы.

Ответы [ 2 ]

0 голосов
/ 01 декабря 2016

Не уверен, что это может помочь, но если это проблема с памятью, попробуйте сделать ваше приложение LARGE ADDRESS AWARE.Мы столкнулись с проблемой при перекодировании с использованием DES для добавления оверлея, и при работе с видеоизображениями с разрешением 1 920 × 1 200 мы всегда получали сообщение об ошибке «Нет больше памяти».Для настройки Studio 2010 в главном проекте проекта в Linker-> System установите для параметра «Включить большой адрес» значение «Да» и повторите проверку.Возможно, это исправит вашу ситуацию.Для приложения c # это делается с помощью пост-событий, см. Эту ссылку для получения дополнительной информации.

https://blogs.msdn.microsoft.com/calvin_hsia/2010/09/27/out-of-memory-easy-ways-to-increase-the-memory-available-to-your-program/

С уважением, Ник.

Надеюсь, что это полезно!

0 голосов
/ 06 ноября 2011

Я немного опоздал с ответом, я думаю, но вы включили динамическое переподключение с IRenderEngine::SetDynamicReconnectLevel()?

...