[CuBox] jpeg HW decoding issue
Home › Forums › GeeXboX on ARM SoCs › [CuBox] jpeg HW decoding issue
This topic contains 6 replies, has 2 voices, and was last updated by
togath 2 months, 2 weeks ago.
-
AuthorPosts
-
Hi,
just updated to the latest snap shot from 08th Febuary due to the nice hw-jpeg-decoding. But when I use my default wallpaper for cuebox, it crashes instantly. Recovery is possible only through serial interface.
It works if hw-jpeg-decoding is turned off.
@Rudi, I’ll send you a pm in the solid-run form with a link to my wallpaper
togath
-
This topic was modified 2 months, 2 weeks ago by
togath.
For some reason the hardware decoder doesn’t like this file. An I made a mistake that is causing an infinite loop in this situation
I’ve fixed that in r16848. Now we gracefully fall back to software decoding in such a case. I have an idea what is causing the hardware to choke. Maybe it’s possible to detect this an patch the data in memory before sending it down to the decoder…Is it a bug in the silicon? Does the fallback disable the hw-decoding until Cubox is rebooted, or does it become disabled just for the one image? Most of my images (even the one I took with camera) are encoded the same way
-
This reply was modified 2 months, 2 weeks ago by
togath.
Unfortunately first test did not confirm my suspicion about the reason. Needs more investigation… The fallback works on per picture base. The failing sample you provided appears to be written by GIMP. Pictures from my camera (Sony) work fine.
O.K., I think I’ve found something: The problematic picture is a so-called “Progressive JPEG”. Maybe the hardware decoder does support only “Baseline DCT”. Will do some more testing this evening…
It turned out that the hardware does indeed not support “Progressive DCT” and “Arithmetic coding”. Consequently, r16853 will no longer pass pictures that make use of these features down the the hw decoder. This avoids the penalty time introduced by the hw trying to decode and fail.
BTW, generally, progressive JPEGs should not be used as skin elements in XBMC. While they have advantages when presented in a web page, the image loader in XBMC cannot make any use of that. And even worse: According to this article, libjpeg-turbo can only accelerate baseline JPEGs.
OTOH it was good that you ran this test, because it revealed a bug which we hit when trying to load corrupted files.
Ineed, the ‘Progressive’ flag is set, when I save jpegs. This means I have to check how to disable it in the future…
Thanks for the good explanation
Will read the libjpeg-turbo articele tonight. -
This topic was modified 2 months, 2 weeks ago by
-
AuthorPosts
You must be logged in to reply to this topic.