No, I don't have any benchmarks. I'm quite surprised that it is as slow as you are reporting, but haven't had time or energy to investigate.I also tested CPU memory transfer speed for decoded frames and speed is not an issue. If transfer between CPU and GPU is causing issues here, it would also be unusual. Do you have any benchmark on such transfer?
Yes, use multiple buffers to prevent buffer transfer stalling your pipeline.Would multiple buffers for encode help?
The simple issue is a lack of resource. As noted in my sig, I do not work for Pi Towers, so my playtime is limited. Pi Towers have limited resource too.Do you think this EmptyThisBuffer call implementation will ever be compliant to the 5 msec requirement?
Set nBufferCountActual to something bigger than nBufferCountMin in the PortDefinition. AllocateBuffer/UseBuffer then wants that number of buffers before the port will enable fully. You now have more buffers to fill and submit.sandboxvt wrote:1. Setting multiple buffers - Is this as simple as setting the number of buffers for the port? Both input and output ports?
It is maintained in the sense that there are some ongoing developments, but ILCS is likely to only get minor bug fixes where critical issues are identified. MMAL and the raspicam apps (host_applications/linux/apps/raspicam) are still being developed as we get the chance to expose new or otherwise improve functionality, as are the EGL stack and some of the other services. PRs always welcomesandboxvt wrote:2. userland project status - I considered working with the code. But I thought it might be actively maintained and therefore maybe I should be patient for further improvements or engaging its developer(s). Is current userland code relatively stable and up to date? Are developers still active on improving it?
There shouldn't be a huge issue with the GPU transfer. The memory bandwidth should be plenty high enough, even though it will be converting from an SG list to contiguous memory and therefore have to do multiple smaller copies.sandboxvt wrote:3. userland code - I browsed the EmptyThisBuffer code path briefly. It looks like the delay might be with mutex or semaphore block or transit to GPU or GPU response. Any insight to this is greatly appreciated. I just want to make sure (or as much as possible) that GPU hardware is not the limiting factor before I dive deep into this.
Check the news from back in July 2014. http://uk.reuters.com/article/us-broadc ... BS20140722 and the like. Broadcom pulled out of the baseband processor market and laid off almost the entire Cambridge team behind VideoCore (including myself). They pretty much have no further interest in developing software for the chip. They are turning the handle to produce the chips, and are very likely involved in any ongoing developments.sandboxvt wrote:4. Updates from Broadcom - Is it fair to infer from your reply that one should not expect updates in this area from Broadcom any time soon?
Users browsing this forum: No registered users and 2 guests