Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

native resolution ( disable upscaling ) option #1096

Closed
wants to merge 1 commit into from

23 participants

adam-aph Memphiz Matt Filetto jmarshallnz Joakim Plate Voyager1 Karlson2k GhostM121 davilla sebjacob jpsdr DOCaCola Martijn Kaijser Edgewalker GeertAki opperpanter deh2k7 voip-ninja jeanpijon Ramkumar Trent Nelson harry1236 bobo1on1
adam-aph

http://forum.xbmc.org/showthread.php?tid=64139&pid=1131505#pid1131505

I spent few hours to dig into it and the results are promising. I'm pretty fresh to xbmc though, so maybe there is better way to deal with it. Anyway, what you need to run native resolution:

  • apply the provided patch
  • set in your advancedsettings.xml following variable in < video > section:
    <video>
        <upscalemode>1</upscalemode>      <!-- upscalemode: 0-default, 1-native scaling -->
    </video>
  • set your receiver to upscaling mode - upscale source to maximum display resolution (1080p in my case)

How it works:

  • the GUI works with maximum resolution
  • when the player is spawned it reads the source dimension and sets the renderer to the lowest supported resolution which is the best match for the source resolution
  • the movie is played with lowest acceptable resolution and is upscaled by the receiver to 1080p
  • when the playback stops, the xbmc GUI is back to default resolution (1080p for me)

Here are few examples, where
USER = default screen resolution
NATIVE = movie resolution
ADJUST2 = final xbmc resolution for playback


    NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
    NOTICE: Searching for NATIVE resolution: 1920x1080
    NOTICE: Display resolution ADJUST2 : default: 1920x1080 @ 24.00Hz (17)
    .
    NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
    NOTICE: Searching for NATIVE resolution: 1280x720
    NOTICE: Display resolution ADJUST2 : default: 1280x720 @ 50.00Hz (29)
    .
    NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
    NOTICE: Searching for NATIVE resolution: 720x304
    NOTICE: Display resolution ADJUST2 : default: 720x576 @ 50.00Hz (37)
    .
    NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
    NOTICE: Searching for NATIVE resolution: 608x336
    NOTICE: Display resolution ADJUST2 : default: 640x480 @ 60.00Hz (41)
    .
    NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
    NOTICE: Searching for NATIVE resolution: 640x256
    NOTICE: Display resolution ADJUST2 : default: 640x480 @ 60.00Hz (41)
    .
    NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
    NOTICE: Searching for NATIVE resolution: 640x272
    NOTICE: Display resolution ADJUST2 : default: 640x480 @ 60.00Hz (41)
    .
    NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
    NOTICE: Searching for NATIVE resolution: 720x392
    NOTICE: Display resolution ADJUST2 : default: 720x576 @ 50.00Hz (37)
    .
    NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
    NOTICE: Searching for NATIVE resolution: 608x256
    NOTICE: Display resolution ADJUST2 : default: 640x480 @ 60.00Hz (41)
    .
    NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
    NOTICE: Searching for NATIVE resolution: 640x352
    NOTICE: Display resolution ADJUST2 : default: 640x480 @ 60.00Hz (41)
    .
    NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
    NOTICE: Searching for NATIVE resolution: 624x224
    NOTICE: Display resolution ADJUST2 : default: 640x480 @ 60.00Hz (41)
    .
    NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
    NOTICE: Searching for NATIVE resolution: 1280x544
    NOTICE: Display resolution ADJUST2 : default: 1280x720 @ 50.00Hz (29)
    .
    NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
    NOTICE: Searching for NATIVE resolution: 624x352
    NOTICE: Display resolution ADJUST2 : default: 640x480 @ 60.00Hz (41)

I have to say that results are surprisingly good. I'm using receiver with Marvell Qdeo chip and it is doing great job, the picture is visible better than when xbmc is upscaling directly to 1080p. Well, you need to try yourself to judge.

The function used to find the closest resolution match is very simple, perhaps it might be improved. For now it tries to find the lowest resolution which is equal or higher than source resolution and tries to keep as close as possible to original refresh rate for the display.

Memphiz
Owner

Just before even reviewing this. We can't merge stuff without proper commit messages. "Update master" is a bit to general in that case ;).

You can change your commit message by doing the following on your branch:

git rebase HEAD~3 -i

then before each line put a "r" for reword. After that you can change the commit messages. Then you can update this PR by issueing:

git push -f origin master

(assuming origin is your remote - not ours ;) ).

Memphiz
Owner

Overall looks good to me (after adressing the mentioned things).

And you should consider to prepare the needed documentation in the wiki for the new advancedsetting.

I'm not sure if this approach will disturb the refreshrate adaption. From a quick look it could be that it will prefer the best fitting resolution and therefore skip a fitting refreshrate couldn't it?

adam-aph

ok, added a lot of cosmetics ;)

adam-aph

And you should consider to prepare the needed documentation in the wiki for the new advancedsetting.

no problem - let me know in what form do you need it (email or comment here, or... )

I'm not sure if this approach will disturb the refreshrate adaption.

it searches for the best resolution and then it looks for refreshrate closest to the original one. if the original screen is 1920x1080@24.00Hz and say source is 624x352, then it is finding first 640x480@70.00Hz, then 640x480@60.00Hz and stays with 60Hz as there is no more good dimensions.

Anyway, this automatic search is first approach to this feature. It can be heavilly parametrized, I can imagine for example that instead of finding the best match, we can define several dimension windows, or create rule that all SD contents always falls into 800x600@60Hz etc.
Here actually it will be good to have advise from more experienced users. Maybe this should just wait for feedback from others, for now this automatic setup seems to be good starting point.

Matt Filetto

This won't work when GUI is 60 htz and u play a 24hrtz:its going to set 60 according to above p9st

Memphiz
Owner

Ok some more thoughts. If a user has turned on refresh rate adaption - i bet he is doing this because of micro stuttering when refreshrate is not matched to the framerate. So in that case we have to ask us the question:

What is worse - having XBMCs upscaling or having microstutter. Imho microstutter is worse. In that case we should do the following:

  1. If refreshrate adaption is turned on - only match resolutions which have the exact same refreshrate (refreshrate calculation is above your code as you might already have seen). If the user wants resolution matching without caring refreshrate - he just has to turn of refresh rate adaption.

Another question is:

  1. Is it really a good thing to try to find a "close to" - native resolution? Or should we really try to match to the EXACT native resolution? When we only take a resolution close to the native one - we have 2 upscalers running (XBMC scales it up to the "near by" resolution and the TV/AVR scales up to the output resolution e.x. 1080p). I'm not into video quality enough for doing a judgement here. Maybe elupus could jump in here? ^^ (i bet most native resolutions in movies aren't even possible with most TVs right?)

And the last thing. Once we have consensus here. Since you changed your commit message for all 3 commits to the same - you can just squash all your commits down to 1 when everything is in place at the very end of this (no need to have 3 or 4 commits for this one feature).

Well lets hope for other comments because this isn't really my sector ;)

adam-aph

If you use it as bool

well I rather think it will have more values in near future (see my previous comment). but before this will be extended with other options I would rather wait for feedback from users, to see where is the immediate need to enhance it

If refreshrate adaption is turned on - only match resolutions which have the exact same refreshrate

yeap, makes sense, I will update the code

Is it really a good thing to try to find a "close to" - native resolution? Or should we really try to match to the EXACT native resolution?

I do not think there is other option here - see examples in the initial post, most of SD resolutions are something like:
608x336, 608x256, 624x352 etc. These resolutions are not what the receiver/video card can support.
as the reference, here are modes supported by my receiver:
1920x1080 @ 60.00 - Full Screen (12)
1920x1080 @ 60.00Hz (13)
1920x1080 @ 50.00Hz (14)
1920x1080 @ 30.00Hz (15)
1920x1080 @ 25.00Hz (16)
1920x1080 @ 24.00Hz (17)
1680x1050 @ 60.00Hz (18)
1440x900 @ 75.00Hz (19)
1440x900 @ 60.00Hz (20)
1440x576 @ 50.00Hz (21)
1440x480 @ 60.00Hz (22)
1360x768 @ 60.00Hz (23)
1280x1024 @ 75.00Hz (24)
1280x1024 @ 60.00Hz (25)
1280x960 @ 60.00Hz (26)
1280x800 @ 60.00Hz (27)
1280x720 @ 60.00Hz (28)
1280x720 @ 50.00Hz (29)
1152x864 @ 75.00Hz (30)
1024x768 @ 75.00Hz (31)
1024x768 @ 70.00Hz (32)
1024x768 @ 60.00Hz (33)
800x600 @ 75.00Hz (34)
800x600 @ 72.00Hz (35)
800x600 @ 60.00Hz (36)
720x576 @ 50.00Hz (37)
720x480 @ 60.00Hz (38)
640x480 @ 75.00Hz (39)
640x480 @ 73.00Hz (40)
640x480 @ 60.00Hz (41)
576x576 @ 50.00Hz (42)
576x480 @ 60.00Hz (43)
411x576 @ 50.00Hz (44)
411x480 @ 60.00Hz (45)
360x576 @ 50.00Hz (46)
360x480 @ 60.00Hz (47)
288x576 @ 50.00Hz (48)
288x480 @ 60.00Hz (49)

Since you changed your commit message for all 3 commits to the same - you can just squash all your commits down to 1 when everything is in place at the very end of this (no need to have 3 or 4 commits for this one feature).

sure, will do

adam-aph

ok, I merged it and changed also the setup. now the advancedsettings.xml setup looks like this:

<video>
...
    <nativeupscale>
        <keepfps>false</keepfps>
        <forcewidezoom>true</forcewidezoom>
        <minwidth>0</minwidth>
        <minheight>0</minheight>
    </nativeupscale>
...
</video>

where:
  <keepfps>        - controls if the fps can be overridden or not (default is 'false')
  <forcewidezoom>  - controls if the output should be zoomed when upscaled (default is 'true')
  <minwidth>       - controls the minimum width when searching for closest resolution (default is '0')
  <minheight>      - controls the minimum height when searching for closest resolution (default is '0')

the < forcewidezoom > option requires some explanation. when < nativeupscale > is enabled, the assumption is that finally the output will be upscaled by external device to some high resolution (like 1920x1080). therefore we want XBMC to generate output filled with the video contents as much as possible (minimize black bars), as it will be stretched by the receiver anyway. the WideZoom option works perfect for this, so zooming can be forced here for SD contents, before receiver will finalize the picture. After all this looks pretty ok.

I tested these changes on the Linux version of xbmc.

jmarshallnz
Owner

When you have 624x352 and choose 640x480, what's the point - you're scaling it twice at that point. I don't have a problem necessarily if there is no scaling at all done by XBMC, but if XBMC is scaling as well as the TV that seems counterproductive?

adam-aph

I think the point is here: http://www.marvell.com/digital-entertainment/qdeo/
You would need to see the difference on the screen, otherwise the discussion is pointless ;)

jmarshallnz
Owner

The processing doesn't run when not resizing? This is the point of the patch after all, to have better resizing done by your TV/receiver or whatever. If XBMC is resizing (poorly apparently) then you want to eliminate that completely, else you're introducing a source of error. In the case of a 624 wide image, for example, you could center it in a 640 wide resolution to save any resizing at all by XBMC. Again, I have no problem for 1280 wide sources and the like - just not sure I see the point of resizing at 2 separate levels if the entire point was to remove the resizing to begin with. Perhaps as this problem will likely only be seen on SD sources, it doesn't really matter too much?

adam-aph

well, not really. the xbmc is always resizing the image, so the error is here already. resizing to smaller dimension is however creating smaller image errors, and then the processing chip enhances it even more. so at the end the image looks much better than original image fully processed by xbmc.
without initial resizing you will see on the screen big black bars on the half of the screen from all four edges.

jmarshallnz
Owner

It'll only be 8 pixels either side in the 624 width case, and nothing at all if the source was 640 wide or 1280 wide etc. The latter is where the real benefit comes as XBMC does no resizing.

adam-aph

I think the height is bigger problem than width, as usually SD contents fits very well either to 640 or 720 wide. Anyway all these examples which I tested above were looking much better with initial WideZoom scalling. Source 720x304 on resolution 720x576 gets almost 50% of horizontal black bars, and when upscaled by receiver to 1920 wide it looks like 70% of the screen is black. really ugly.
with initial WideZoom upscaling it looks much better, the picture dimensions are similar to the original xbmc dimensions.

well, yes, all this makes sense only for SD enhancements, the HD contents does not really need all this. the proposed patch will not affect the HD contents though.

Memphiz
Owner

Imho the keepfps option is a dupe of the refreshrate adaption in the gui. Get rid of it and use the gui option instead.

adam-aph

yeah, I was considering it initially. but at the end I think it makes more sense to keep it separately. The refresh rate adaption works for all your contents (HD, SD, whatever) - it is system wide parameter. When enabling < nativeresolution > adoption it is more convenient to keep all its options in the same place (override fps or not, force wide zoom or not etc). at least that was my thinking.

adam-aph

actually the intention was to apply this check only if both values are set. I'm not sure if enabling it when only one size is set (width or height) is practical?

Memphiz
Owner

Just tested it and stumbled over it. Up to you what this should do - i don't have an opinion on that. Well so far i compile tested this on osx, ios, linux and Windows. And runtime tested it on osx (testing the other platforms shortly).

Memphiz
Owner

On windows i get 2 compile warnings. To fix use double instead of float for your variables (else it complains to stick a double in a float in line 105 because calculation is done in double)

adam-aph

updated

Memphiz
Owner

Ok - i did runtime checks for all platforms now (osx,ios,atv2,linux,windows). It does what it should on all of them including ios with tvout (though i wouldn't do it there because switching resolutions is pain slow and we are loosing audio due to hdmi handshake audio b0rk).

So jm - at least from the technically POV i would sign this off for at least osx/ios (and if nobody else tests i sign it off for linux and windows too ;) ).

jmarshallnz
Owner

I think it's best to leave it to those that know the renderer.

@bobo1on1, @elupus?

bobo1on1 bobo1on1 was assigned
Joakim Plate elupus was assigned
Joakim Plate
Collaborator
adam-aph

If xbmc does any other scaling its quite pointless.

well, I do not have any good argument for upscaling, except what I saw on the screen: http://forum.xbmc.org/showthread.php?tid=64139&pid=1136328#pid1136328

adam-aph

ok, I corrected it according to suggestion made by jmarshallnz, now the image is streteched to aspect ratio of the final screen (most probably 16x9). The setup changed a little:

</video>
...
    <nativeupscale>
      <overridefps>true</overridefps>
      <correctpixelratio>true</correctpixelratio>
      <destwidth>1920</destwidth>
      <destheight>1080</destheight>
      <minwidth>0</minwidth>
      <minheight>0</minheight>
    </nativeupscale>
...
  </video>

where:
  <overridefps>        - controls if the fps can be overridden or not (default is 'true')
  <correctpixelratio>  - controls if the output should be stretched to final screen dimensions (default is 'true')
  <destwidth>          - controls the destination width to which the source will be scaled by AVR (default is '1920')
  <destheight>         - controls the destination height to which the source will be scaled by AVR (default is '1080')
  <minwidth>           - controls the minimum width when searching for closest resolution (default is '0')
  <minheight>          - controls the minimum height when searching for closest resolution (default is '0')

I tested briefly these changes on the Linux version of xbmc. I would need to test it a little more though.

adam-aph

ok, I'm done. It works great for me.
The setup changed a little again:

</video>
...
    <nativeupscale>
      <overridefps>true</overridefps>
      <correctpixelratio>true</correctpixelratio>
      <destres>1920x1080</destres>
      <minoutres>0x0</minoutres>
      <maxsrcres>0x0</maxsrcres>
    </nativeupscale>
...
  </video>

where:
  <overridefps>        - controls if the fps can be overridden or not (default is 'true')
  <correctpixelratio>  - controls if the output should be stretched to final screen dimensions (default is 'true')
  <destres>            - controls the destination resolution (width x height), to which the source will be scaled by AVR (default is '1920x1080')
  <minoutres>          - controls the minimum acceptable output resolution (width x height), which will be generated by xbmc (default is '0x0' - not active)
  <maxsrcres>          - controls the maximum source resolution (width x height), which will be handled by native scaling (default is '1024x768', '0x0' disables this check)

I tested these changes on the Linux version of xbmc.

Voyager1
Collaborator

sorry to enter the discussion so late.
I think it would also be nice if you choose an "interlaced" resolution (25.00i for PAL or 30.00i for NTSC) for SD material, so that the TV/Receiver will also turn on the native deinterlacer. Of course, XBMC deinterlacing should be turned off then too...

adam-aph

Do you mean it should disable it (VS_DEINTERLACEMODE_OFF) each time when nativeupscale is activated? Or only do this for specific resolutions or fps?

Voyager1
Collaborator

I would think so. The only thing that needs be done is set the right resolution to either 25i (720x576x25i for PAL) or 30i (640x480x30i) depending on the source material. I think that even "progressive" DVDs should play well with this.

adam-aph

ok, I do not know xbmc good enough, but after quick check in the code it looks like the information if the display is interlaced or not is taken from the display itself.
so I'm not sure if this is applicable here - I do not know if it makes sense for the AVR to provide interlaced input mode (between xbmc and AVR). At least on my AVR I can see following modes (see above):

720x576 @ 50.00Hz (37)
640x480 @ 60.00Hz (41)

and if you do not use AVR it seems that xbmc upscalling is better than average TV Set upscalling (at least if you do not use Kuro), so this might be useless feature...

Voyager1
Collaborator

if your display is in a progressive resolution (like the ones you called out, 37 and 41) and you feed it interlaced material then it has to be deinterlaced at the source (ie xbmc). My point was that if the material is interlaced (and the player knows this), and you set the resolution to interlaced as well, the display's deinterlacer will do its magic.

I noticed too that not all GPUs have the SD interlaced resolutions listed. Have no idea why that is.

Karlson2k
Collaborator

Native resolution should be used only if no up-/downscaling is made by XBMC.
Any LCD/Plasma TV would resize to it's screen resolution internally.
So for example in case of 1280x650 material, output chain can be 1280x650 -> (by XBMC - no scaling, black bars) 1280x720 -> (HDMI) 1280x720 -> (resize by TV) 1920x1080. This is OK as TV upscaler could be better than XBMC.

But in case of 1024x550 material, output chain can be 1024x550 -> (1st resize by XBMC) 1280x688 -> (by XBMC, black bars) 1280x720 -> (HDMI) 1280x720 -> (2nd resize by TV) 1920x1080. This definitely be worse than 1 upscale (no matter where - in XBMC or in TV). Picture lose more sharpness and becomes more blurry.

GhostM121

I started a thread on this on the xbmc website and would really like to see it added. Madvr does this perfectly, and imo it would be a waste not to allow interlaced content. I have a 1080i,30 profile in madvr, as well as a 480i,30 profile.

MADVR simply allows you to add resolutions supported by your video card and tv, and then switches to those resolutions when playing media with that resolution. It basically accomplishes what is discussed here...

Karlson made a good point and its something i think madvr does wrong, instead of just upscaling if that resolution is specified and input, it selects the closest resolution specified if that resolution is not specified in settings. So an obscure resolution you dont have specified i believe madvr pics the next closest resolution and scales to that. It would be ideal if it did not do this, and if the input resolution does not match an output resolution you specified, it simply lets xbmc upscale.

davilla
Collaborator

Another less than 1 percent feature :)

Display switching is already a hack and does not fully take into account that basically the display/audio is yanked out from under XBMC without so much as an excuse me :) On most platforms, that means the display device goes away which means GL contexts are in question as well as audio sinks if running audio over HDMI.

Before any more stuff gets added to display switching, I'd really like to see a thought out process of how xbmc should react to such a yank and the hacks we have replaced with a solid structure.

Sorry to be the naysayer but we really have to stop piling on such features without proper handling and just praying they work right.

GhostM121

I have no idea what you mean, xbmc already does refresh rate switching is similar. The desktop flashes and refresh rate is changed.

It works fine using madvr, the resolution simply changes, xbmc has it working already for refresh rates, adding the ability to alter the resolution wont be any different, as mentioned madvr has it working fine.

Nothing may work perfect but thats why were discussing implementing it, nothing xbmc adds just works.... Actually oppo bluray players output source direct, and basically output what video resolution is input and it removes audio sync issues since video scaling is not being introduced prior to sending the signal.

Less then 1 percent, i think this is part of the reason many video enthusiasts dismiss xbmc, many users more then 1 percent care about altering our video, their are alot of users outside this xbmc bubble some live in who use madvr and such for improved quality and handling of video.

Alot of even general users would also like to use their avr or high end tv's to handle deinterlacing and scaling.

Deleted user

then go use madvr. but please don't pester us with nagging on our development pages. kthx.

GhostM121

I am simply contributing to an idea that was posted, their was alot of discussion about madvr some wanted it implemented and an xbmc developer was trying to add it but was shut down.
Its not the point though, i simply wanted to show support for automatic resolution changes as a feature i would like to see.

Anyway this will be my last comment, I will stop posting...A mod in the forum linked me to this page when i asked the question, thats how i ended up here.

davilla
Collaborator

@GhostM121, right now with display switching, dvdplayer starts playing, audio/video demux queues fill, and decode started. Decode might involve a hardware video decoder that is tied into the display driver (vdpau, vda, vtb, etc). At the same time, a display switch is slammed in, all the while dvdplayer is trying to render video and audio. Since display (and audio if doing audio over hdmi) is now 'disconnected', this tosses dvdplayer into thrashing as it thinks it has fallen behind in rendering. This goes on until the display comes back which might be quick or might take up to 10 seconds or more.

Then the pause was added to try and fix this mess, but the pause really happens too late. Get the pause duration wrong and dvdplayer thrashes. You can see dvdplayer thrashing in xbmc.log.

What really needs to happen is;

a) dvdplayer starts demux, decode. Only then does it know the real size of the playing stream.
b) once dvdplayer knows the real size, then it switches display. note that nothing is rendered yet.
c) detect that the display has vanished, and wait for it to return.
d) once display returns, dvdplayer sets up rendering to match display
e) dvdplayer starts to render and life is good.

Joakim Plate
Collaborator
adam-aph

btw. what is going on with this request? are you going to close it as n/a, merge it, waiting for anything? just curious...

sebjacob

Stumbled onto trying to find a solution for the cpu challenged raspberry pi.

There's a couple reasons this would be cool on the pi for example :

1-The pi could switch to 1080i and let the receiver take care of the deinterlacing.
2-The Pi can't seem to upscale 720p@59.94 to 1080@59.94, but has no trouble playing the file at native res.

jpsdr

Question : In all of this, how are the size screen adjustment settings used ???
(For exemple, in my case where i've adjusted screen size to compensate overscan of TV).
I've not been able to figure out within all the explanations...

jpsdr

@adam-aph
The fact is that information of interlaced CAN be taken from the display !
Here result from my log file :
12:58:07 T:2592 NOTICE: Additional mode: 1920x1080 @ 50.00 - Full Screen
12:58:07 T:2592 NOTICE: Additional mode: 1920x1080 @ 60.00 - Full Screen
12:58:07 T:2592 NOTICE: Additional mode: 1920x1080 @ 59.94 - Full Screen
12:58:07 T:2592 NOTICE: Additional mode: 1920x1080 @ 25.00i - Full Screen
12:58:07 T:2592 NOTICE: Additional mode: 1920x1080 @ 30.00i - Full Screen
12:58:07 T:2592 NOTICE: Additional mode: 1920x1080 @ 29.97i - Full Screen
12:58:07 T:2592 NOTICE: Additional mode: 1920x1080 @ 24.00 - Full Screen
12:58:07 T:2592 NOTICE: Additional mode: 1920x1080 @ 23.98 - Full Screen

adam-aph

@jpsdr
I think you are missing the point - using this patch without AVR in between is kind of pointless.
Please also try to read my previous comment here: #1096 (comment)

jpsdr

Sorry, i haven't mentionned it, but I have AVR... My PC is connected by HDMI to an AVR (Pioneer VSX-921K).
Having things like "30.00i" => Interlaced is possible to detect.... That what i thought, but i may be mistaken.
Considering your log, with things like 75Hz, i thought it was from a PC monitor, so maybe with no interlace mode, i just wanted to show you that there is information like "30.00i", and maybe, you may never had seen this kind of information.
I just wanted to give you a little piece of information, just in case you may not have it...

I wanted to try your patch on one of my custom build, but unfortunately noticed one thing in my XBMC log of supported resolutions of my device : No 23.976 (neither 24.00) for 720p...!!! As 99.99% of all i'm watching is either 1080p or 720p 23.976fps, and i'm watching with "Adjust display to match frame rate" activated, and "Windows full screen instead of true full screen" not activated.... i'm afraid it will not match my expectations in my case... :(
So, considering my partial log :
.....
13:27:41 T:976 NOTICE: Additional mode: 1176x664 @ 59.94 - Full Screen
13:27:41 T:976 NOTICE: Previous line repeats 2 times.
13:27:41 T:976 NOTICE: Additional mode: 1280x720 @ 50.00 - Full Screen
13:27:41 T:976 NOTICE: Additional mode: 1280x720 @ 60.00 - Full Screen
13:27:41 T:976 NOTICE: Additional mode: 1280x720 @ 59.94 - Full Screen
13:27:41 T:976 NOTICE: Additional mode: 1280x768 @ 60.00 - Full Screen
13:27:41 T:976 NOTICE: Previous line repeats 2 times.
13:27:41 T:976 NOTICE: Additional mode: 1280x800 @ 60.00 - Full Screen
....
13:27:41 T:976 NOTICE: Additional mode: 1360x768 @ 29.97i - Full Screen
13:27:41 T:976 NOTICE: Previous line repeats 2 times.
13:27:41 T:976 NOTICE: Additional mode: 1360x768 @ 24.00 - Full Screen
13:27:41 T:976 NOTICE: Previous line repeats 2 times.
13:27:41 T:976 NOTICE: Additional mode: 1360x768 @ 23.98 - Full Screen
13:27:41 T:976 NOTICE: Previous line repeats 2 times.
13:27:41 T:976 NOTICE: Additional mode: 1366x768 @ 50.00 - Full Screen
......

How a 720p (so 1280x720) 23.976fps file will be played ?

adam-aph

ok, not sure if I follow, but this patch is not altering the screen modes available on your display. Try to use following setup changes:

= to make sure that native scalling will never change your preferred fps:

      <overridefps>false</overridefps>

= to make sure that native scalling will be deactivated for sources with higher resolution than 800x600:

      <maxsrcres>800x600</maxsrcres>
jpsdr

Apparently i'm not clear enough, because indeed you don't follow...
Of course i know this patch doesn't alter my avaible screen modes.
My prefered fps is the fps of the source file ("Adjust display to match frame rate" activated). Value which can btw change on the fly if xbmc detect a vfr file, or realise the fps the file was started with was incorrect (see my PR #1387).
I was hoping that 720p would be directly out to 720p, and my AVR will do the upscale to 1080p.
Unfortunately, on my gig, 720p is supported but not at 23.976fps, and the closet higher resolution avaible which support 23.976fps is 1360x768... So, my question was : My 720p 23.976fps file, with your patch, and considering the possibility my AVR has (with the partial log i've provided), how will it be out by xbmc ?

adam-aph

ok, got it

I think that if you will allow for fps overriding, then for 1280x720@23.976 the code will find 1280x720@50.00 as the best fit from the list of available resolutions

If you disallow fps overriding and will insist to have 23.976fps then it will not find anything suitable and will stay with whatever xbmc set initially for this source

see also my first post in this thread - the patch shows in the log what was the initial resolution, what is the source resolution and what was finally decided - so the best what you can do is apply the patch and post here snippet from the log ;)

jpsdr

I thought it may has choosen 1360x768...
EDIT : No, maybe 1366x768@23.98... which is not in my partial log.
About fps, i think it should be improved, by prioritizing multiple of original fps. If source is at 25fps, 50fps should be prioritized before 30fps for exemple, and allowing 50fps if source is 25fps even if fps overriding is disabled, because it will not cause the display issue users want to avoid if fps display is an integer multiple of fps source file. Wich mean, if fps overriding is off, for 29.97 allowing 59.94, but not 30. I'll try to see if i figure out something, not maybe immediately, but it's something i'll try to see. Your patch is very interesting.

EDIT : 23.976 =24000/1001 29.97=30000/1001 => 1e-3 relative value, so i think of something like :
nfRD = g_settings.m_ResInfo[i].fRefreshRate/fOrgRefreshRate;
if (abs(nfRD-floor(nfRD+0.5))<1e-5) fRD=0.0;

adam-aph

ok, I did not realize that multiple fps is better than closer fps, but I think you are right, these two lines of code should do better.

jpsdr

I think it should be a little more "intelligent". For an original 25fps, if you have 50, 75 and 100 avaible, i think, the best is to chose the lowest, so 50. Actualy, it will chose the last in the order checked...
I'll try to figure out something...

jpsdr

I've got this :

double nfRD,fRD, fD, fODist = 100000000.0;
int iWD, iHD, piW = g_settings.m_ResInfo[m_resolution].iWidth, piH = g_settings.m_ResInfo[m_resolution].iHeight;
int pnfRD=1;

  fRD = g_settings.m_ResInfo[i].fRefreshRate - fOrgRefreshRate;  // refreshrate delta
  nfRD = g_settings.m_ResInfo[i].fRefreshRate/fOrgRefreshRate;
  if (abs(nfRD-floor(nfRD+0.5))<1e-6) fRD=0.0;

  if( fRD >= 0.0 && iWD >= 0 && iHD >= 0 && fD <= fODist &&
     g_settings.m_ResInfo[i].iScreen == iOrgScreen ) 
  {
    if ((piW==g_settings.m_ResInfo[i].iWidth) && (piH==g_settings.m_ResInfo[i].iHeight) && (fRD==0.0))
    {
        if (pnfRD>floor(nfRD+0.5))              // Allow change only if fps < previous
        {
            m_resolution = (RESOLUTION)i;         // if we are here, then this resolution is closer to 
            fODist = fD;                          // the source parameters than previous one
            pnfRD=floor(nfRD+0.5);
        }
    }
    else
    {
        m_resolution = (RESOLUTION)i;         // if we are here, then this resolution is closer to 
        fODist = fD;                          // the source parameters than previous one
        pnfRD=floor(nfRD+0.5);
        piW=g_settings.m_ResInfo[i].iWidth;
        piH==g_settings.m_ResInfo[i].iHeight;
    }
  }
adam-aph

this should do the same, but seems to be simpler:

   for (size_t i = (int)RES_DESKTOP; i < g_settings.m_ResInfo.size(); i++)  
   {
   ***
     nfRD = g_settings.m_ResInfo[i].fRefreshRate / fOrgRefreshRate; // refreshrate fit
   ***

     fD = (iWD * 1.0) + (iHD * 1.0);                            // default weights for width and height resolution

     if (!bOverrideFPS)
     {                                                          // if original fps should be preserved, accept only these 
       fRD = (fRD == 0.0) ? (0.0) : (-1.0);                     // resolutions where refreshrate is the same
     }
     else
     {                                                          // preferred multiple fps     
       fD += fRD * ( (abs(nfRD-floor(nfRD+0.5)) < 1e-6) ? 10.0 : 100.0 );
     }

     if( fRD >= 0.0 && iWD >= 0 && iHD >= 0 && fD <= fODist &&
         g_settings.m_ResInfo[i].iScreen == iOrgScreen ) 
     {
       m_resolution = (RESOLUTION)i;         // if we are here, then this resolution is closer to 
       fODist = fD;                          // the source parameters than previous one
     }
   }

it searches through all fps and prefers these which are lowest multiply, but if will not find anything, it will stay with the closest fps.
makes sense?

jpsdr

Make sense.
Nevertheless, my point of view is the following, but you can, of course, have another.

The true thing to understand is "What is the true meaning of preserving fps ?".
Someone who want that, the real purpose is a "smooth" play, without stuttering. Wich means, he's not absolutely not bothered by a 25fps played at 50Hz, but he will if played at 30Hz, because video will stutter.
On the other hand, if he activate native scalling, he also want it to be effective.
If he plays a 720p 30fps file, and on his system, fps avaible for 720p are only 50 or 60, even if he's not allowing fps overriding, 720p@60 should be selected. This is why i think, fps of multiply should be allowed in all the cases.

I just want my point of view to be clear for you and you've understood what i want to say with my poor english. After, you may not agree and don't want to make it that way, not hard feelings, it's your work. I just want to be sure that even if you don't want to make it this way, you've clearly understood "what you don't want".

adam-aph

I completely agree, and I think that the code agrees either ;)

assuming that we have poor SD of 680x256@30 and following available resolutions:
800x600 @ 60.00Hz (36)
720x576 @ 50.00Hz (37)
720x480 @ 60.00Hz (38)
640x480 @ 75.00Hz (39)

then the code after last fix should chose 720x480@60 and with the original design it will take the lower fps (50).

If you made this patch already, is this feasible for you to add that fix and see how it behaves on some other sources?

jpsdr

... You said you agree... but i still don't see how you can have 720x480@60 selected if you have deactivated fps override...

adam-aph

if you deactivate fps override then the code will search for setup with exact fps as source (30 in this example) and probably will find nothing, so the original xbmc setup will remain.
I think this is what is expected in that case?

Here are some examples in case when the fps override is allowed and source is 680x256@30:
EDIT: corrected calculations (again)

1) 720x576@50
fD = 720-680+576-256=360
fRD = 20
nfRD = 1.66666
abs(nfRD-floor(nfRD+0.5)) = 0.4444

so fD = 360 + 20*100 = 2360

2) 720x480@50
fD = 720-680+480-256=264
fRD = 20
nfRD = 1.66666
abs(nfRD-floor(nfRD+0.5)) = 0.4444

so fD = 264+ 20*100 = 2264

3) 720x480@60
fD = 720-680+480-256=264
fRD = 30
nfRD = 2
abs(nfRD-floor(nfRD+0.5)) = 0

so fD = 264+ 30*10 = 564

the lowest fD wins, so it will be case 3) in this example.

jpsdr

I think there is a mistake in your fD, no ?
1 should be 720-680+576-256=360
2 & 3 should be 720-680+480-256=264
"if you deactivate fps override then the code will search for setup with exact fps as source (30 in this example) and probably will find nothing, so the original xbmc setup will remain.
I think this is what is expected in that case?"
This is what i've try to explain, and said we may had different point of view : For me, the real purpose of deactivating fps is not to absolutely keep the same fps, but to absolutely keep the same visual result in play. Playing at 59.94fps a 29.97fps produce the exact same visual result, and you'll absolutely not see the difference (each frame will be send twice to the screen) and should be allowed in all cases, but playing it at 30fps will create stuttering in the video, and is not to be allowed if fps override is deactivated. So, this is why, in my own custom build, i'll make it work this way.

Now, theorical situation...
File, almost the same 680x256@29.97
Possible resolutions :
case a)
720x480@30
720x480@59.94
1280x720@29.97

case b)
720x480@30
1280x720@59.94
1920x1080@29.97

case a), best choice should be 720x480@59.94.
Computation results are
264+0.03100=267
264+29.97
10=563.7
824+0*10=824
The worst case is choosen... The code i've proposed chose the best if i've made no mistake.

case b, best choice should be... well, here it may depend from point of view... Personnaly, i think 1280x720@59.94.
Computation results are
264+0.03100=267
824+29.97
10=1123.7
2744+0*10=2744
The best case is not choosen here too... The code i've proposed also chose the best if i've made no mistake.

adam-aph

sorry for calculation mistakes, corrected now

regards fps override - I think I would disagree here, this option allows user to stay with preferred fps no matter what the code thinks would be better

regards other calculations - my point is that the original code works simple - it is just the matter what weights are assigned for particular screen parameters - currently it considers the lowest screen dimensions as the most important factor, then fps which should be lowest from multiply of available fps
so I think it makes more sense to work on proper weights for these parameters to achieve desired result, than embed more logic into it - but of course this is just my opinion

see here for all modes supported by my AVR: #1096 (comment)
I'm not sure if this is common, maybe you can post here modes supported by your AVR? I'm trying to understand if we are trying to fight with ghosts, or there are AVR's which supports fps like 59.94 or 29.97?
anyway with these modes which my AVR supports, for the example source 680x256@29.97 the code would chose 720x480@60 which I would consider as not so bad choice.

jpsdr

Of course there are AVR which support 59.94 and 29.97... Didn't you see my partial xbmc log a few post ago ????
This one #1096 (comment)
I'll implement my own custom version of you patch this WE, and will make some try.

adam-aph

ups, missed it

ok, looking again on your examples I can see that the code should prefer multiply of fps regardless of the distance to the source fps, although take the lowest one.
also "punish" more the case when fps is not multiply of source fps

so changing that line: fD += fRD + ( (abs(nfRD-floor(nfRD+0.5)) < 1e-6) ? 10.0 : 1000.0 );
would change these calculations to:

a)
264+0.03+1000=1264,03
264+29.97+10=303,97
824+0+10=834
which is 720x480@59.94

b)
264+0.03+1000=1264,03
824+29.97+10=863,97
2744+0+10=2744
which is 1280x720@59.94

and for my original examples:

1) 720x576@50
360+20+1000 = 1380

2) 720x480@50
264+20+1000 = 1284

3) 720x480@60
264+30+10 = 304

so it is still good

DOCaCola

Are there any devices that natively output @30 resolutions?

Karlson2k

This is wrong 'distance' calculation.
If you have several coordinates (x, y, z, f) than distance between two point is sqrt( (x1-x2)^2 + (y1-y2)^2 + (z1-z2)^2 + (f1 - f2)^2). It's not depend on positive/negative deltas.

sure - make it better and let us know how it works for you in real width/height/fps domain. this one above, although I agree is kind of "simplified" works perfect for my SD movies :D

Karlson2k
Collaborator

Besides my comment about wrong fit calculation, supposed patch still allow double scaling.
You should rescale image only one time: in XBMC or in TV.
In other words: if TV accept exact image resolution, than XBMC could use it as output and allow TV to rescale image. In all other cases XBMC should rescale image to configured resolution (which should be TV native resolution) to allow pixel-to-pixel exact TV output.

adam-aph

Sorry dude, I suggest that you start reading comments from at least this one: #1096 (comment)

Karlson2k
Collaborator

@adam-aph Did you suggest it to me?
I can only repeat: #1096 (comment)
You should not try any resolutions, except native image resolution and native display resolution. In any other case you'll get double upscaling: one in XBMC and one in display. Any double upscale will be worse than single scaling in XBMC.
Regarding FPS. All displays support widest choice of FPSs at native resolution, so there are no reason to try other resolution if you are fps-addicted.
About interlaced videos. If you want to deinterlace video by TV, the only way to get it is to output video at exact video's resolution and FPS. In all other cases TV will be unable to deinterlace. So again there are no reason to look for any "close" resolution.
Other problem for interlaced video is how to sync even/odd frames output from video decoder with even/odd frames in video out.

Joakim Plate
Collaborator
Karlson2k
Collaborator

@elupus Try it. Result will be terrible. :)
If you resize even frame, having only half of horizontal lines, you'll get inter-/extrapolated new lines (some will be placed in original locations of odd frame lines). Than those lines will be unpredictably shifted (new number of lines = new relative places of lines) and mixed with other shifted and inter-/extrapolated lines. Just try to imagine how resulting frame will be deinterlaced. :)

Karlson2k
Collaborator

@elupus Of course if you resize only horizontally, result will be fine.

Joakim Plate
Collaborator
Karlson2k
Collaborator

@elupus Yes, theoretically possible, but practically unusable. :)

And idea in general is good. It's nice to have a choice where to resize video. At least to compare result.

DOCaCola

as reference/inspiration on how others have implemented it. Here are the options for resolution switching my Dreambox DM800 DVR offers:
https://lh.rs/yPD9ArzT0g9E
https://lh.rs/oQpcVQrjV9Uh

Karlson2k
Collaborator

@DOCaCola Seems that in Dreambox terminology SD = 576

adam-aph

ok, no offense ;) I think it would be good to include it into the main xbmc codeline, so people can actually use it and have better understanding if/what needs to be changed.

or improve it and then include into xbmc

endless debates what is better or worse are pointless for me if you cannot see it on your home screen ;)

Karlson2k
Collaborator

@adam-aph I'd suggest to start from less controversial way and most simple way at the same time: native image resolution or native TV/display resolution.
It's relative simple patch, think can be easily integrated into mainline. Just put all settings to GUI.
In case of demand for more features you can improve it in later PRs.

adam-aph

ok, what do you mean by "native image resolution"? see examples from the beginning of this thread, say for SD 720x304 what would be native resolution for you?

Joakim Plate
Collaborator

I tend to agree.. we must start simple if we want this in. SD 720x304 would be 720x480 if aspect matches close enough (already an allowed aspect error setting that can be used)

Joakim Plate
Collaborator

Ie. Adjust for aspect. Iterate all resolutions available, select any mode where the aspect error and scaling error is minimal if no scaling is performed (or only one direction).

Karlson2k
Collaborator

Any resolution without resize (just adding black bars).
So yes, output 720x304 as 720x480 is OK

adam-aph

the iteration is there already

you can disable any scaling by setting < correctpixelratio > to false

you can disable any fps overriding by setting < overridefps > to false

but if you can make it simpler - go for it, anything available in the mainline is better than nothing, controversial or not ;)

Karlson2k
Collaborator

@elupus We should think more about aspect error with native resolution. In one hand - looks like nice idea, but in other hand we'll get definitely lower image quality (double resize).
Problem will be doubled in very low resolution - even small aspect ratio change will be unacceptable, while changing ration with resize to final resolution is fine (as implemented now in mainline).

jmarshallnz
Owner

SD resolutions are complicated by the fact that the 720x304 will no doubt be assuming square pixels, whilst 720x480 or 720x576 are not square. The TV will most likely get it wrong in other words. Whether this is enough to bother folk I dunno. I also suspect that a small amount of vertical-only scaling to fix aspect for SD content such as this is probably overwhelmed by the low resolution anyway so the double vertical scaling is probably meaningless.

Karlson2k
Collaborator

@adam-aph You can save this branch locally and replace it with simpler one or open separate PR with simpler patch.
Don't pollute advancedsettings.xml, use GUI settings.

Karlson2k
Collaborator

@jmarshallnz You right. Patch should handle non-square pixels properly.
For videos XBMC has real aspect ration information from file, for output pixel aspect is defined by standard.

adam-aph

well, guys, to be honest I'm not following your hesitations

  • it needs to be enabled by advanced settings (on the purpose), so it will not create massive headache in any way, until somebody will start playing with it

  • no doubt it is not perfect and for sure can be improved - but in my opinion than can be done when people will start testing it with different sources / hardware and will fall eventually into some real issues

  • the current code is for me as simple as it was possible - if you see any specific thing which should be added/changed then name it, because requirements called "simpler" or "non-controversial" are hard to implement ;)

  • so if I'm the only one seeing value in this patch maybe just forget about it

Joakim Plate
Collaborator
DOCaCola

No, this feature is a good thing.
TVs are designed to work with low resolution content.
The rescaler chips in (more expensive) TVs are selected/optimized to give best possible picture quality for a particular resolution on this particular hardware (LCD panel).
While XBMC uses the 'generic' techniques to rescale content, which of course works well in most scenarios, native resolution/refresh rate output might give us (perceived) better picture quality on some TVs.

Joakim Plate
Collaborator

I never said it wasn't. I said an advanced setting is a massive headache and that it shouldn't need so much config.

adam-aph

@elupus:

Just looks overly complex. I don't get why we need so much configuration.

overridefps - you may want to stay with your preferred fps (24fps?) so disable ovverriding

correctpixelratio - you may hate any kind of stretching, so disable it

destres - there is no way to find out what is the final resolution (not between xbmc and AVR, but between AVR and TV) - so it needs to be provided here

minoutres - you may want to skip some low resolutions available at AVR for some reasons, so specify here the minimum one which can be assigned during the iteration

maxsrcres - you may want to disable NR when resolution is good enough, so specify here the maximum resolution on which NR is still active

DOCaCola

hmm, some thoughts on the usefulness of these commands

overridefps - why would someone like to not have the fps adjusted as defined by the content? Are there technical limitations that would produce issues when fps are not adjusted?

correctpixelratio - it might be required for some configurations, but usually the monitor/TV handles the correct aspect ratio. If the aspect ratio is wrong, then the monitor/TV should be configured accordingly.

destres - not really understanding what the commands purpose is. would it be enough to let the code not select resolutions higher than the one set globally?

minoutres - this command might be useful in some scenarios. With very low resolution content the overlay GUI might become very pixelated and hard to use.

maxsrcres - don't see a need for this command. what do you mean, 'good enough'? That defeats the purpose of NR. Why would we now want to rescale 720p content to 1080p?

adam-aph

yes, I would also have one question - why people are always reading only the last 3 posts and think that their point of view is unique and the most important? :D

re overridefps - pls check Memphiz above

re correctpixelratio - do you mean adjusting your AVR/TV before playing each source? :p

re destres - perhaps it may be replaced by some other existing global variable or perhaps you may want NR to assume some fixed output resolution - not sure at this point

re minoutres - correct

re maxsrcres - say you don't want NR to be enabled on any SD which is width 720 or more

DOCaCola

no, i am just trying to understand from a user point of view and help finding a compromise on this thing. If you are pissed for some reason, then that is none of my business. :p
correctpixelratio: yea, maybe i just don't understand the purpose of this option. If you have set your TV to output content with correct aspect ratio (versus streched) then this should be not necessary? Is this intended for when a TV doesn't offer an option to scale content with correct aspect ratio? If a TV is that bad, then probably it would be better to let XBMC handle the rescaling, right? :) But maybe i missed the point.
maxsrcres: What would be the advantage or purpose of not having such content at native resolution?

adam-aph

ok :D

re correctpixelratio - I saw it in my tests that stretching at xbmc and then processing by good AVR creates better experience at the end - but if you will read Karlson2k and others - this is not so obvious before you see it on your screen, so why not to make it easy for others and allow to disable it?

re maxsrcres - well, it is like somebody may feel more comfortable to make sure that 1080 or something will never go trough the NR code.. just an option you may want to ignore if you do not care

Karlson2k
Collaborator

Everything merged to master should be needed for endusers. But endusers will not play with advancedsettings.
So put all settings into GUI. And even for developers - it's easier to play with settings when settings in GUI. You can share your custom build until it's merged.
The only setting for advancedsettings is "disable native resolution support".
Advancedsettings should not be treated as temporal place for GUI setting.

adam-aph

may I suggest incremental approach? release it as it is, as kind of "experimental" feature, so those who are interested will start playing with it. when the code will stabilize enough (also some options may go, some new may be required) then add nice GUI options for it.

Joakim Plate
Collaborator
jmarshallnz
Owner

I suggest moving the settings to a local struct, put sensible defaults (these can be what is sensible for you for example), then add what you need (a toggle?) to turn it on to a gui setting.

After that we can see how well it works under different scenarios and move to perfect it - you have the settings local to play with during this process, and you can then expose what is absolutely needed to work in a way that makes sense to users.

adam-aph

so would this work for you:

  • add a toggle option in System/Video-Settings screen, say "Native Resolution Enabled"

  • hardcode sensible default values for NR

  • keep option to ovverride these default values via advanced settings if somebody is not happy with these defaults

jmarshallnz
Owner

Everything except number 3 works for me.

adam-aph

so where these overridefps/correctpixelratio/destres/minoutres/maxsrcres attributes can be read from, if advanced settings is bad place, but you still want end user to tweak with them?

jmarshallnz
Owner

That's the thing, we don't want them to tweak them yet. i.e. store them in some struct locally, and we can expose exactly what is needed later.

adam-aph

ok, this is really not my problem, it is for me just like you would build a car without the steering-wheel and say - let's people try it, we will see what useful they can do about it :D

Anyway I think I'm done with it. The code is here, you may copy it, change it, add all possible bells and whistles on GUI side - or just simply ignore it. Good luck ;)

Martijn Kaijser

So that means you lost interest then?
This is exactly what was meant we had to maintain it when the dev looses interest.

Karlson2k
Collaborator

@adam-aph No offence, but using advancedsettings instead of GUI settings sounds for me like putting steering wheel under the hood. :)

Voyager1
Collaborator

@adam-aph - I agree with the others here. Please be a little more patient and get your work into the basecode in a stepwise approach. Initially this will also allow you to get feedback from a wider community using a simple set of settings. As jmarshall says, this will then teach us what else we need to expose...

adam-aph

well, if you see above then you will realize how patient I was during 6 months (!) of this discussion. I really surprised myself :D during that time I never rejected any request which was technically justified.
now you wanted to have GUI toggle to make sure people will be aware of this feature - ok, I can understand this. however with all my patience I cannot understand why are you bitching on advance settings option? Just do not use it, ignore it, deny that it ever existed! :D
so now I say: take it or leave it. I never play games which I do not understand. that's it ;)

Edgewalker

I just found this by accident after asking about this feature in Windows Support on the forum; please keep working on this adam-aph... it's more valuable than you know. And for those who would be naysayers or who don't think "endusers" use advancedsettings.xml, I am an "enduser" and I most definitely use it, to make stuff work that should work already.

In point of fact, this method is how the XBox version of XBMC handles output of video, perhaps not via the same code but in a similar way; I am looking for my HTPC's XBMC to do the same thing, because frankly SD content looks like crap the way it is being handled now.

1% is still greater than zero... so please quit sandbagging this and implement it for anyone who wants to try it (without them having to have a programming degree).

I can run a compiler if I have to, so can someone PM me on the forum (same username) and explain how would I go about adding this to Eden source so I can have XBMC work the way I want? Thank you, and thank you adam-aph for a USEFUL FEATURE.

Karlson2k
Collaborator

@adam-aph There are some (unofficial) rules. Every settings that needed for correct configurations and use of XBMC must be placed in GUI (like output sound device, directories with media files, language, output video resolution). Those settings should be configured as easily as possible.
Complicated settings, that require deep technical knowledge (like MySQL), or troubleshoot settings (like dirty regions, flip buffer) must be placed in advancedsettings.xml.

During last 6 months at least 3 of my PRs wasn't get it because of use of advancedsettings. And several others was rejects by reason that I don't follow unofficial rules. And that is right, because when code grows, rules must be stricter otherwise it'll be impossible to maintain and support resulting monster.
Moreover you can just write a good patch and forget about it, while XBMC team must maintain your code, support users for you code, write documentation, wiki, FAQ and so on... For me it's not very logical to explain that video output should be configured in GUI, but after that native video output should be configured in AS.

And note, that some nice feature can be implemented in 200 lines of code, but configuration and GUI can take 2000 lines of code. And if original developer don't implement GUI for it, who must do it?
PS I'm not in XBMC team

adam-aph

@Karlson2k you are talking about good coding practices. sure, each ecosystem builds its own, XBMC community its no different here. in my professional life I'm dealing with software systems way more complicated than XBMC. XBMC is my preferred entertainment tool, this is just a hobby. and I'm kind of ok with rules which the community worked out during the life of XBMC. if you will read this thread from the beginning then you can see that I did not complain when Memphiz grilled me to make the code XBMC-standards compliant. I can also understand that a toggle at GUI level is good thing, as it makes this functionality exposed to all users with some default settings.

but here is where my will for compromise ends. this patch needs more testing with different hardware setup. It needs to be simple exposed to wider audience. and I need tool like AS when I can quickly test different configuration options with these users. maybe some new switches will be required - I thought for example that the whole "distance" function should be probably refactored to be another AS parameter, like some kind of regular expression so it can be flexible changed. i made it pretty straight (I believe) - this patch is still kind of "experimental". asking me to hide all parameters is not reasonable - it will end up with the situation that it will not work properly for majority of the users and they would need to wait half of year for another XBMC release. on the other hand, asking me to implement all these "temporary" parameters at GUI level is not reasonable either - as you pointed out, this is significant effort, this is poisoning the GUI and some of these parameters for sure will go away with one of next iterations.

so the process which is for me kind of natural - that the working version of some functionality is then iteratively improved is somehow not accepted by the XBMC team. they expect to have this patch fully functional from day one. which is kind of naive expectation in my opinion. from my experience I can say that keeping some "techie" options at AS level and moving them gradually to GUI level as the code is stabilizing is the most reasonable approach. it seems that we cannot get agreement on this and this is like end of the story on my side ;)

GhostM121
Karlson2k
Collaborator

@GhostM121 Don't worry, I'm sure it'll be implemented.

GeertAki

I vote +1 for this feature and want to thank adam for all the effort he put already into this!
Many thanks!

opperpanter

+1, thanks Adam for all your hard work.

Maybe we could implement it with 1 parameter in the GUISettings.

This parameter would be a dropdown/combox to select a possible value:

Full = Equal to current behaviour of xbmc, do full upscaling (default).
Disabled = Disable all upscaling, no zooming, use exact resolution from input etc.
Minimal = Use closest resolution, do zooming (is this zooming different from the 'Z' key during playback?).
MinimalZoomed = Minimal with zooming.

Something like this would allow us to keep iot relatively simple, but still have some choices for advanced users?

@adam-aph I think getting the basics right is of great value, because it will be good enough for the majority of people. Once the feature gets used and there's feedback we can always add more settings/presets.

deh2k7

I agree - let's get a build with SOMETHING working, either with a simplified GUI setting or an advanced setting X<L template to work with and get users testing out the functionality. Once you have good feedback on how its working, we all can offer some suggestions on how to best implement it into the final version. I would guess starting with everything in advancedsettings would be simplest way to get things going, as long as we had at least a clear understanding of each of the possible settings and values.

voip-ninja

Just wanted to add my moral support to this settings option. I have a pretty damn expensive video processing chipset in my AVR that would probably do a much better job of upscaling 720P and SD source material than the HTPC can do currently.

jeanpijon

+1 I think this is great feature - I will try to compare results with my Samsung Smart TV (it seems that main problem on my HTPC is not decoding of HD content, but actually upscaling SDi)

Ramkumar

+1 for this feature. I am not sure if this is relevant at this point or may have been though of before, but just my 2 cents. About upscaling twice one by XBMC and then by the AVR, XBMC can just pad blacks instead of upscaling to the nearest resolution.

Trent Nelson
harry1236

This will be the great feature for the people who have avr with good video processing power. I would really love to see this on xbmc.

Deleted user

you were warned,.

Deleted user ghost closed this
sony2 sony2 referenced this pull request
Closed

native resolution #3054

Tobias Hieta tru referenced this pull request from a commit in RasPlex/plex-home-theatre
Tobias Hieta tru Don't load prefs for sections from SecondaryServers.
First half of  #1096
38c6c9b
Cedric Girard X-dark referenced this pull request from a commit in X-dark/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
5743ad6
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
b70241c
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
e9ce243
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
e463583
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
2a9dde0
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
5770b9d
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
8888070
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
c1dc6d7
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
693586b
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
26594a7
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
11e91e4
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
74158c7
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
a6483cb
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
00296ac
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
b07fc5a
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
972a159
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
9f29a61
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
dee1168
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
793e62f
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
aba99fb
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
1c7e8fe
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
67778ef
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
763e46e
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
6d334f6
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
a33e6e4
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
0df78bf
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
6edb50b
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
e3ab95c
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
0586064
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
949e46b
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
9cd168d
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
e5924e2
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
9e93cd1
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
35ddb73
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
aa0749e
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
3950a58
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
56a4a4d
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
b9554ae
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
9e1a9b7
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
f235a4b
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
7165848
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
ff5b47c
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
c332ea8
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
75b4d35
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
efd4c2c
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
835ca01
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
beac6dd
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
01ca58c
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
9f4170c
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
5a37430
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
ed2de18
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
c1607ac
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
ac0cc0d
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
b7659d6
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
ea712e3
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
0b0ad44
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
25d4f9f
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
028e914
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
7bba547
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
61a4499
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
d653635
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
f1e1931
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
246316c
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
baaf952
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
88c8895
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
8bc9797
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
5d39c6d
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
4760ee5
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
36a5a3a
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
1f27247
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
24a8520
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
f35f859
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
dd68330
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
2ef8197
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
5de9b56
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
49e1052
popcornmix popcornmix referenced this pull request from a commit in popcornmix/xbmc
Cedric Girard X-dark native resolution
From adam-aph pull #1096
Rebased to master with appropriate code change
Removed AdvancedSettings and move them to a struct with sensible
defaults
615486f
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Nov 2, 2012
  1. adam-aph
This page is out of date. Refresh to see the latest.
93 xbmc/cores/VideoRenderers/BaseRenderer.cpp
View
@@ -37,6 +37,7 @@ CBaseRenderer::CBaseRenderer()
m_sourceWidth = 720;
m_sourceHeight = 480;
m_resolution = RES_DESKTOP;
+ m_bestResolution = m_resolution;
m_fps = 0.0f;
}
@@ -66,6 +67,69 @@ void CBaseRenderer::ChooseBestResolution(float fps)
#endif
CLog::Log(LOGNOTICE, "Display resolution %s : %s (%d)",
m_resolution == RES_DESKTOP ? "DESKTOP" : "USER", g_settings.m_ResInfo[m_resolution].strMode.c_str(), m_resolution);
+
+ m_bestResolution = m_resolution; // save it
+ int iNatW = (int)m_sourceWidth;
+ int iNatH = (int)m_sourceHeight;
+
+ if( g_advancedSettings.m_nativeMaxWidth && iNatW > g_advancedSettings.m_nativeMaxWidth )
+ iNatW = 0;
+
+ if( g_advancedSettings.m_nativeMaxHeight && iNatH > g_advancedSettings.m_nativeMaxHeight )
+ iNatH = 0;
+
+ if( g_advancedSettings.m_nativeUpscaleMode && iNatW && iNatH ) // Native Upscale Mode
+ {
+ CLog::Log(LOGNOTICE, "Searching for NATIVE resolution: %dx%d", m_sourceWidth, m_sourceHeight);
+
+ bool bOverrideFPS = g_advancedSettings.m_nativeOverrideFPS;
+ double nfRD, fRD, fD, fODist = 100000000.0;
+ int iWD, iHD;
+ double fOrgRefreshRate = g_settings.m_ResInfo[m_resolution].fRefreshRate;
+ int iOrgScreen = g_settings.m_ResInfo[m_resolution].iScreen;
+
+ if(iNatW <= g_advancedSettings.m_nativeMinWidth &&
+ iNatH <= g_advancedSettings.m_nativeMinHeight)
+ {
+ iNatW = g_advancedSettings.m_nativeMinWidth;
+ iNatH = g_advancedSettings.m_nativeMinHeight;
+ }
+
+ // best fit
+ for (size_t i = (int)RES_DESKTOP; i < g_settings.m_ResInfo.size(); i++)
+ {
+ fRD = g_settings.m_ResInfo[i].fRefreshRate - fOrgRefreshRate; // refreshrate delta
+ nfRD = g_settings.m_ResInfo[i].fRefreshRate / fOrgRefreshRate; // refreshrate fit
+ iWD = g_settings.m_ResInfo[i].iWidth - iNatW; // width delta
+ iHD = g_settings.m_ResInfo[i].iHeight - iNatH; // height delta
+ // distance function:
+ // refreshrate, witdh and height deltas are multiplied by weight factors
+ // current weights values do not prefer any parameter (well, almost...)
+ // so we will search for lowest width, height and refresh rate which fit to the source parameters
+ // however if any of these parameters need to be preferred, bump up the weight value for it
+ fD = (iWD * 1.0) + (iHD * 1.0); // default weights for width and height resolution
+
+ if (!bOverrideFPS)
+ { // if original fps should be preserved, accept only these
+ fRD = (fRD == 0.0) ? (0.0) : (-1.0); // resolutions where refreshrate is the same
+ }
+ else
+ { // preferred multiple fps
+ fD += fRD + ( (abs(nfRD-floor(nfRD+0.5)) < 1e-6) ? 10.0 : 1000.0 );
+ }
+
+ if( fRD >= 0.0 && iWD >= 0 && iHD >= 0 && fD <= fODist &&
+ g_settings.m_ResInfo[i].iScreen == iOrgScreen )
+ {
+ m_resolution = (RESOLUTION)i; // if we are here, then this resolution is closer to
+ fODist = fD; // the source parameters than previous one
+ }
+ }
+
+ CLog::Log(LOGNOTICE, "Display resolution ADJUST2 : %s (%d)",
+ g_settings.m_ResInfo[m_resolution].strMode.c_str(), m_resolution);
+ }
+
}
bool CBaseRenderer::FindResolutionFromOverride(float fps, float& weight, bool fallback)
@@ -391,10 +455,12 @@ void CBaseRenderer::ManageDisplay()
void CBaseRenderer::SetViewMode(int viewMode)
{
+ int savedViewMode;
+
if (viewMode < VIEW_MODE_NORMAL || viewMode > VIEW_MODE_CUSTOM)
viewMode = VIEW_MODE_NORMAL;
- g_settings.m_currentVideoSettings.m_ViewMode = viewMode;
+ g_settings.m_currentVideoSettings.m_ViewMode = savedViewMode = viewMode;
// get our calibrated full screen resolution
RESOLUTION res = GetResolution();
@@ -403,6 +469,27 @@ void CBaseRenderer::SetViewMode(int viewMode)
// and the source frame ratio
float sourceFrameRatio = GetAspectRatio();
+ // if we upscale via external AVR device, correct the pixel ratio
+ if( g_advancedSettings.m_nativeUpscaleMode && m_bestResolution != m_resolution
+ && g_advancedSettings.m_nativeCorrectPixelRatio )
+ {
+ float destWidth = (float)(g_advancedSettings.m_nativeDestWidth);
+ float destHeight = (float)(g_advancedSettings.m_nativeDestHeight);
+ float destFrameRatio = (float)destWidth / destHeight;
+ bool destScreenIs43 = (destFrameRatio < 8.f/(3.f*sqrt(3.f))); // final output
+ float outWidth = (float)(g_settings.m_ResInfo[m_resolution].iWidth);
+ float outHeight = (float)(g_settings.m_ResInfo[m_resolution].iHeight);
+ float outFrameRatio = (float)outWidth / outHeight;
+ bool outScreenIs43 = (outFrameRatio < 8.f/(3.f*sqrt(3.f))); // xbmc output
+
+ if( outScreenIs43 && !destScreenIs43 ) // final output is 16x9
+ viewMode = VIEW_MODE_STRETCH_16x9;
+ else if( !outScreenIs43 && destScreenIs43 ) // final output is 4x3
+ viewMode = VIEW_MODE_STRETCH_4x3;
+
+ g_settings.m_currentVideoSettings.m_ViewMode = viewMode;
+ }
+
bool is43 = (sourceFrameRatio < 8.f/(3.f*sqrt(3.f)) &&
g_settings.m_currentVideoSettings.m_ViewMode == VIEW_MODE_NORMAL);
@@ -494,8 +581,12 @@ void CBaseRenderer::SetViewMode(int viewMode)
g_settings.m_fZoomAmount = 1.0;
}
+ // restore original view mode
+ g_settings.m_currentVideoSettings.m_ViewMode = savedViewMode;
+
g_settings.m_currentVideoSettings.m_CustomZoomAmount = g_settings.m_fZoomAmount;
g_settings.m_currentVideoSettings.m_CustomPixelRatio = g_settings.m_fPixelRatio;
g_settings.m_currentVideoSettings.m_CustomNonLinStretch = g_settings.m_bNonLinStretch;
g_settings.m_currentVideoSettings.m_CustomVerticalShift = g_settings.m_fVerticalShift;
+
}
3  xbmc/cores/VideoRenderers/BaseRenderer.h
View
@@ -90,7 +90,8 @@ class CBaseRenderer
void CalculateFrameAspectRatio(unsigned int desired_width, unsigned int desired_height);
void ManageDisplay();
- RESOLUTION m_resolution; // the resolution we're running in
+ RESOLUTION m_resolution; // the resolution we're running in
+ RESOLUTION m_bestResolution; // the preferred resolution
unsigned int m_sourceWidth;
unsigned int m_sourceHeight;
float m_sourceFrameRatio;
55 xbmc/settings/AdvancedSettings.cpp
View
@@ -110,6 +110,16 @@ void CAdvancedSettings::Initialize()
m_videoFpsDetect = 1;
m_videoDefaultLatency = 0.0;
+ m_nativeUpscaleMode = false;
+ m_nativeOverrideFPS = true;
+ m_nativeCorrectPixelRatio = true;
+ m_nativeDestWidth = 1920;
+ m_nativeDestHeight = 1080;
+ m_nativeMinWidth = 0;
+ m_nativeMinHeight = 0;
+ m_nativeMaxWidth = 1024;
+ m_nativeMaxHeight = 768;
+
m_musicUseTimeSeeking = true;
m_musicTimeSeekForward = 10;
m_musicTimeSeekBackward = -10;
@@ -471,6 +481,51 @@ void CAdvancedSettings::ParseSettingsFile(const CStdString &file)
XMLUtils::GetBoolean(pElement, "disablebackgrounddeinterlace", m_videoDisableBackgroundDeinterlace);
XMLUtils::GetInt(pElement, "useocclusionquery", m_videoCaptureUseOcclusionQuery, -1, 1);
+ TiXmlElement* pNativeUpscale = pElement->FirstChildElement("nativeupscale");
+ if (pNativeUpscale)
+ {
+ m_nativeUpscaleMode = true;
+
+ XMLUtils::GetBoolean(pNativeUpscale, "overridefps", m_nativeOverrideFPS);
+ XMLUtils::GetBoolean(pNativeUpscale, "correctpixelratio", m_nativeCorrectPixelRatio);
+
+ CStdString tmpStr;
+
+ if (XMLUtils::GetString(pNativeUpscale, "destres",tmpStr))
+ {
+ int destWidth, destHeight;
+
+ if( sscanf(tmpStr.c_str(), "%dx%d", &destWidth, &destHeight) == 2 )
+ {
+ m_nativeDestWidth = destWidth;
+ m_nativeDestHeight = destHeight;
+ }
+ }
+
+ if (XMLUtils::GetString(pNativeUpscale, "minoutres",tmpStr))
+ {
+ int minWidth, minHeight;
+
+ if( sscanf(tmpStr.c_str(), "%dx%d", &minWidth, &minHeight) == 2 )
+ {
+ m_nativeMinWidth = minWidth;
+ m_nativeMinHeight = minHeight;
+ }
+ }
+
+ if (XMLUtils::GetString(pNativeUpscale, "maxsrcres",tmpStr))
+ {
+ int maxWidth, maxHeight;
+
+ if( sscanf(tmpStr.c_str(), "%dx%d", &maxWidth, &maxHeight) == 2 )
+ {
+ m_nativeMaxWidth = maxWidth;
+ m_nativeMaxHeight = maxHeight;
+ }
+ }
+
+ }
+
TiXmlElement* pAdjustRefreshrate = pElement->FirstChildElement("adjustrefreshrate");
if (pAdjustRefreshrate)
{
10 xbmc/settings/AdvancedSettings.h
View
@@ -153,6 +153,16 @@ class CAdvancedSettings
bool m_DXVANoDeintProcForProgressive;
int m_videoFpsDetect;
+ bool m_nativeUpscaleMode;
+ bool m_nativeOverrideFPS;
+ bool m_nativeCorrectPixelRatio;
+ int m_nativeDestWidth;
+ int m_nativeDestHeight;
+ int m_nativeMinWidth;
+ int m_nativeMinHeight;
+ int m_nativeMaxWidth;
+ int m_nativeMaxHeight;
+
CStdString m_videoDefaultPlayer;
CStdString m_videoDefaultDVDPlayer;
float m_videoPlayCountMinimumPercent;
Something went wrong with that request. Please try again.