Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[OMXPlayer] Frodo fixes #2575

Closed
wants to merge 2 commits into from
Closed

[OMXPlayer] Frodo fixes #2575

wants to merge 2 commits into from

Conversation

sraue
Copy link
Member

@sraue sraue commented Apr 9, 2013

more fixes see frodo thread

On a Pi, imageres and fanartres are set quite low (typically 512 and 720 or lower).
So, when caching the artwork there is a resize step involved.
The OMXImage jpeg decoder has the option to resize "for free".
Unfortunately this currently only limits the resize to current GUI resolution,
so there is often a second resize done by the ARM. This is very slow.
The larger decoded image also requires more RAM.

With fanartres=512, you currently get resize during decode of 1920x1080 to 1280x720 (gui res).
Then before encode there is a resize to 910x512. The two stage resize reduces image quality.

This fix takes a bit more care to include the imageres/fanartres resize during the decode.
I needed to make the 16:9 check a little more lax to also detect a 16:9 image after it's been resized.
I've gone for differs from 16:9 by 1%, rather than the existing exact match of 16:9.
I don't believe the lock=false call should ever be done unless caller already has lock
@davilla
Copy link
Contributor

davilla commented Apr 9, 2013

backported.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants