Do you mean that your H.264 decoding application takes 1.5 GB of virtual memory? Is it intended behaviour? Or, the memory is consumed by other applications and H.264 just suffers from lack of memory?
I mean the H264 decoding applicationconsumes 1.5 GB or more of physical memory. Iam able to play simulatenously around 20 h264 individual videos in the same application, in this condition my application consumesaround 1.5-1.6GB of physical memory and this condition worksfor me. But when Itry toplay simulatenously around 25 h264 individual videos in the same application, in this condition my application crashesby giving the errori explained firstly and the physical memory goes beyond 1.6GB approximately.
My h264 videofile is ofsize around 30.5MB and the resolutionof the video is 2560 * 1920.
You're the champion! )) May be better solution will be to spawn individual processes each to decode individual stream?
Seriously speaking, OpenMP manipulations will probably not help, since H.264 decoder (!) does not use OpenMP. H.264 encoder does, but not decoder. Could you describe the conditions? I am trying to understand where and how OMP gets into the game. Could you, by the way, say how many threads are created in your application in total (using task manager process statistics)?
OnWindows platforms a relatively small amount of memory is allocated for a stackwhen a new thread is
created and it is 1MB by default.
As soon as the thread is "alive" it could use lots of memory and lots of threads could use too much memory.
This is what you have now and the problem is not related to the number of threads. It is related to an
amount of memory allocated in total.
A "move" to a 64-bit environment is a good step but I don't think that you used all opportunities to
optimize / improveyour 32-bit application.