2012-06-18 9 views
8

Recibo un H.264 stream de un DVR usando su SDK. Hubo pérdidas de memoria y pensé que era el SDK el que causaba todas las filtraciones. Pero cuando grabé la secuencia y reproduje los fotogramas uno por uno leyendo desde el disco (sin que haya dlls de terceros involucrados), noté que el problema no es el dll, sino la transmisión en sí.H.264 Filtra la pérdida de memoria con algunos decodificadores

Por extraño que parezca, DivX H264 Decoder es el único códec que no causa una pérdida de memoria, pero cuando la secuencia se ejecuta durante un tiempo prolongado, a veces el decodificador DivX se bloquea también. Preferiría usar Microsoft DTV-DVD Video Decoder pero causa grandes pérdidas de memoria y deja caer muchos marcos. Muchos otros decodificadores H.264 que he probado se comporta de la misma manera.

Examiné el h.264 frames usando h.264 parsers comparando con algunas otras transmisiones sin problemas pero no noté nada obvio de los registros.

Como mi problema es sobre la estructura de cuadros h.264, he preparado un filtro de fuente llamado FramesFromFileSourceFilter que puede descargar a continuación.

http://www.akaydin.com/directshow/FramesFromFileSourceFilter.zip

Es un proyecto Visual Studio 2008 y todas las dependencias se incluye en el archivo zip en carpetas relativamente localizados (incluyendo los marcos H.264). Entonces, todo lo que necesita hacer es compilar el proyecto, registrar la salida con regsvr32.exe y ejecutar el filtro con cualquier decodificador h.264 que desee desde GraphEdit o GraphStudio. Los gráficos de ejemplo están a continuación.

FramesFromFileSourceFilter with DivX

FramesFromFileSourceFilter with Microsoft DTV-DVD Video Decoder

También marcos h264 están disponibles como un único archivo h264 prima en el siguiente enlace, que se puede jugar por el VLC (con mal FPS original desde 12 FPS).

http://www.akaydin.com/directshow/stream.zip

Pregunta:

¿Cuál podría ser la causa de los problemas de pérdida de memoria con muchos famosos Decodificadores H264 excepto decodificador DivX. ¿Qué está mal con esta corriente?

Actualización 1

lectura hilo datos se elimina y la funcionalidad se movió en FillBuffer sin utilizar ningún tampones y banderas. El problema sigue siendo el mismo

http://www.akaydin.com/directshow/FramesFromFileSourceFilterUpdate1.zip

Actualización 2

Update1 estaba usando Sleep() en FillBuffer() función que estaba causando algunos problemas. Ahora quité el Sleep() y usé SetTime() para tener ~ 12 FPS. Esto también solucionó los problemas de caída de cuadros de Microsoft DTV-DVD Video Decoder, pero no resolvió los problemas de memoria.

http://www.akaydin.com/directshow/FramesFromFileSourceFilterUpdate2.zip

aumento de memoria se produce a tan sólo Working Set. Virtual Bytes y Private Bytes parecen ser estables.¿Qué podría estar causando el incremento continuo de la memoria Working Set que solo ocurre con Microsoft DTV-DVD Video Decoder?

Respuesta

3

no haces ninguna sincronización alrededor de sus variables de

BYTE* m_buffer; 
DWORD m_bufferSize; 
bool isFrameReady; 

y se utilizan a partir de dos procesos simultáneos. Simplemente filtra su memoria por esta asignación/desasignación incorrecta Y/O deja que su código falle en la violación de acceso. La creación de depuración de su DLL indica esto al mostrarle una alerta de "corrupción de montón" mientras ejecuta su prueba. El comportamiento del tiempo de ejecución puede variar con los decodificadores y el entorno, sin embargo, este es definitivamente un error grave que debe solucionarse.

Por ejemplo, puede usar CAutoLock cAutoLock(m_pLock); en el hilo que llena el búfer para evitar el acceso a la transmisión de subprocesos mientras está leyendo datos del archivo.

Tenga en cuenta que lea el siguiente cuadro en el mismo puntero del búfer sin verificar si la memoria previamente asignada está liberada o no, simplemente sobrescribe el puntero posiblemente dejando una fuga.

Pérdida de memoria/de Trabajo Conjunto de actualización: Ahora, cuando los problemas de códigos están ordenados a cabo, el comportamiento en tiempo de ejecución no deseado es un aumento en el tamaño Working Set. Esto no es una fuga Es una indicación de que Windows considera el proceso como una especie de prioridad (¿por qué no ?, está activo y funciona con la memoria) y arroja más páginas reales hacia este proceso para facilitar su desempeño. Consulte this answer para obtener una buena explicación de cómo las métricas de la memoria de proceso corresponden a fugas de memoria en una aplicación.

La diferencia entre los decodificadores que puede estar viendo es probable que sea causada por el hecho de que algunos decodificadores son buenos con una menor cantidad de almacenamientos intermedios, o los reutilizan más activamente, p. Prefiere sacar el mismo buffer de un pool en lugar de elegir uno por uno a través de todos los disponibles.

+0

En realidad, mi filtro real tiene un mecanismo mejor, este es el simplificado. pero dado que hay un período de espera de 83 milisegundos entre fotogramas, la concurrencia no debería ser el caso aquí. Además, DivX Decoder no causa ninguna pérdida de memoria. sigo creyendo que las transmisiones están causando este problema. Además, el mismo filtro funciona bien con otras transmisiones h.264 de otros dispositivos sin ninguna pérdida de memoria con los mismos decodificadores. –

+0

Tal vez su filtro real lo haga mejor, pero este código causa daños en el montón. En otra ejecución cuando logró pasar, no noté ninguna fuga (con MS DTV-DVD Decoder), ¿cómo se puede saber si se produjo la fuga? –

+0

la memoria sigue aumentando durante el proceso, siempre que el filtro se ejecute. por supuesto, en este ejemplo, hay un número limitado de cuadros. pero cuando se trabaja con una transmisión en vivo, el uso de la memoria alcanza gigabytes luego de unas pocas horas. ¿No notó ningún aumento de memoria de GraphEdit/GraphStudio cuando ejecuta el filtro con MS DTV-DVD Video Decoder? si es así, ¿cuál es su sistema operativo? He tratado esto en Win7 32 bits. –