Too much OMX corrupt stream messages in debug log on JPEG acceleration (RPi)
|Assignee:||Andreas Smas||% Done:|
|Found in version:||All||Platform:||RPi|
GPU accelerated decoding supports only non progressive YUV JPEG images. ST tries to load all JPEG into decoder which is resulting in:
1. Corrupt stream
2. Slows down decoding
So ST needs to detect only supported JPEG. Detection algo is here https://github.com/xbmc/xbmc/blob/master/xbmc/cores/omxplayer/OMXImage.cpp
in function OMX_IMAGE_CODINGTYPE COMXImageFile::GetCodingType
#3 Updated by Leonid Protasov about 7 years ago
Jpegs must be non-progressive and have 3 colour components (i.e. no CMKY). No size limit apart from memory.
#4 Updated by Leonid Protasov about 7 years ago
Danara wrote:When filling the buffer for image_decode, don't send more than one jpeg to the buffer at the time (especially for small images). This is the reason why my earlier code had trouble with smaller JPEGs.For better performance on larger images, increase the buffer size to be greater than the size of your JPEG. The default size on my system seems to be around 80KB, and I increase that to 250KB, which means the entire JPEG fits in the image decode input buffer 99.99% of the time.Set the flag OMX_BUFFERFLAG_ENDOFFRAME and OMX_BUFFERFLAG_EOS before the call to EmptyThisBuffer. Without the end of frame flag, the frame doesn't get forwarded to the video_render / egl_render (so the output stalls).