Bug #2080

Too much OMX corrupt stream messages in debug log on JPEG acceleration (RPi)

Added by Leonid Protasov about 7 years ago. Updated almost 7 years ago.

Status:FixedStart date:03/23/2014
Priority:HighDue date:
Assignee:Andreas Smas% Done:

100%

Category:Photos/Images
Target version:4.6
Found in version:All Platform:RPi

Description

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


Related issues

Related to Bug #2083: Large size JPEGs are blackscreen when open (but look good... Fixed 03/24/2014

Associated revisions

Revision 6ce93431
Added by Andreas Smas almost 7 years ago

rpi: Avoid trying to decode progressive JPEGs and JPEGS without exactly three color channels

Fixes #2080

Change included in version 4.5.346

History

#1 Updated by Leonid Protasov about 7 years ago

To sum up optimal algo should:
1. While loading JPEG into buffer from http/drive etc detecting components number and progressiveness.
2. After loading correspondingly decode it via GPU or software decoder...

#2 Updated by Leonid Protasov about 7 years ago

  • Subject changed from Too much OMX corrup stream on JPEG acceleration (RPi) to Too much OMX corrupt stream messages in debug log on JPEG acceleration (RPi)

#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.

https://github.com/raspberrypi/firmware/issues/261

#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).

#5 Updated by Leonid Protasov about 7 years ago

  • Related to Bug #2083: Large size JPEGs are blackscreen when open (but look good in preview) (RPi) added

#6 Updated by Andreas Smas almost 7 years ago

  • Status changed from New to Fixed
  • % Done changed from 0 to 100

Also available in: Atom PDF