So basically, it seems the driver/firmware is giving some error, but I have no idea what the "1" means. I've looked in that method (going to get low level here), and it seems to be on line 2642 when calling VpuReadReg, and to get the error, it calls the same VpuReadReg with the flag of RET_DEC_SEQ_ERR_REASON with a value of 1. At the moment, when we load up one of our H264 videos, this mxc_vpu_test comes back with an error when calling vpu_DecGetInitialInfo. Only trouble is, it only works on certain videos. We have a prototype working by opening up the port (/dev/graphics/fb1) directly and piping video there directly, but it's really high on CPU and gets even worse if we need to scale it.Īlong game this mxc_vpu_test, where it loaded a test video and played it.scaled and all with very low CPU. The requirement is to pipe the video to the 2nd monitor via HDMI. We have a custom C++ video player in Android to play videos with an adjustable frame rate, it currently uses FFMPEG to decode the frames, then uses libyuv to display them to the surface. I'm helping Henry in getting this VPU direct access to work.
0 kommentar(er)
