[adam.h.]

Really what you want is to be able to say: use 720x576, but assume that it's actually a 16:9 image (i.e. alter the pixel aspect ratio accordingly).

works perfect so far, I just need to make few more tests on it.

[adam.h.]

Maybe a digging in HDMI spec can be interesting for supported format

right, we could build a searching function which is trying to find best fit output resolution considering also frame ratio. It could be interesting enhancement, but it would be worth to see the final result - the question is really if 16x9 SD source like 720x304 would better look if upscaled by the AVR from 720x576 resolution (4:3) or from 1280x720 (16:9).

For now the patch is updated to stretch to the final screen frame ratio, and it works good. It waits for some more reviews.

[jpsdr]

Remember, 720x576 can be either a 4/3 or a 16/9 picture format, it's in the spec of DVD/Blu-Ray video format. Do not assume 720x576 is only 4/3, it's false.

[alfredo]

Finally, what's going on? Will it be merged or declined?

[sialivi]

Very important feature, so I'm also curious about the progress on this.

[sebj]

Would come in handy for the raspberry pi that's for sure!

[adam.h.]

Some receivers use new HQV Vida processor which is capable to upscale up to 4k

[alfredo]

No news I suppose...

[Ghostdivision]

Would love to see this as well, I was directed toward a ticket when I asked in the forum, one developer said this is a 1 percent feature, meaning he believes very few people want it.

If you want it might help to share your opinion.

[Ned Scott]

For my older movies I use original film versions of the movies and play them with a projector for maximum quality. For newer films I hire the actors to re-enact the movie live in my house.


















Sorry, I couldn't help it :D

[Memphiz]

That sounds like fun when watching some newer p0rn - right Ned? ^^

[adam.h.]

Sorry, I couldn't help it

well, I could: https://github.com/xbmc/xbmc/pull/1096

but either you guys do not like it or you are all this other not interested 99%, dunno, it seems to be in some limbo now

[Martijn]

Sorry, I couldn't help it

well, I could: https://github.com/xbmc/xbmc/pull/1096

but either you guys do not like it or you are all this other not interested 99%, dunno, it seems to be in some limbo now

since October 10 no new features will be added. We will only do bug fixes until after Frodo release

[Ned Scott]

but either you guys do not like it or you are all this other not interested 99%, dunno, it seems to be in some limbo now

Just having some fun. No one is actually opposed to the idea, but as Davilla noted, there's some code that needs to be refactored before we keep piling on new features, like this, on top of the old code.

While maybe only 1% might care about the quality increase, far more than that will likely be interested in how this could help out low power systems. The last comment in the PR caught my attention as it mentioned this would allow us to off-load deinterlacing to the display. That would be a very awesome feature for not just the Raspberry Pi, but other ARM/low power XBMC boxes.

[adam.h.]

ok, understand the code freeze. although it waits for review since 4 months, so anyone of xbmc gurus willing to help with code review and confirming that this patch still makes sense for Frodo codeline?