|
@cyberbeing,
according to the log the key problem is that the GPU render queue doesn't fill up. So it seems that the subtitle rendering somehow affects GPU rendering performance in your case. I find that a bit weird, to be honest, seeing that rendering is mostly limited by the GPU and subtitle rendering should be strictly CPU. However, looking at the log, I'm having a wild guess why this might occur:
The renderer asks the subtitle item about the "yuvMatrix". And my impression is that this simple information retrieval often blocks for a looooong time. Is it possible that asking a subtitle item about its yuvMatrix internally runs into some critical sections? And this could stop the renderer from proceeding while the subtitle thread is busy rendering subtitles?
If my guess is right, this is not a problem with the size of the subtitle/decoder queue at all. Instead it indicates a design flaw in xy-vsfilter: Asking a simple property like yuvMatrix should not need critical sections, because it's a static information field which never changes (for one subtitle frame). xy-vsfilter should be double checked to limit the use of critical sections to where it is absolutely needed. Also xy-vsfilter shouldn't use just one critical section for everything. That's a sure way to slow multi-threading down. There should be dedicated critical sections to protect specific things. That allows different threads to hold different critical sections while accessing different resources, without negatively affecting each other. Of course the whole design must be perfectly thread safe. But it is very important to also write the code in a way that doesn't slow multi-threading down to a crawl...
|