[capfuturo]

Good Afternoon XBMC Developers,

Often there is no-reciprocity between the Aspect Ratio a movie is presented in (the real aspect ratio of the movie if it were in a letterbox frame) and the Display Aspect Ratio. The latter seems to be the one XBMC consistently shows the user as AR media flag, which misrepresents the real aspect ratio besides misleading the user with regards to the real proportions of what they are watching.

If one defines the aspect ratio manually in a local NFO file, some improvement takes place in the 'AR flag department', although still not what it should be. Why? For Ben-Hur, for instance, a film presented in a 2.76 Aspect Ratio, XBMC will show a 16:9 flag (Display Aspect Ratio that can be read from the media info); manually changing the NFO to an aspect of 2.76 (or indeed anything over 2.35) results in XBMC showing a persistent 21:9 flag, which is 2.33 AR and therefore as wrong and useless as having a 16:9 flag. In any case, all editing efforts are lost since XBMC will reinstate the 16:9 flag as soon as the movie is played again.

It is utterly important to be able to see a flag that tells the real aspect ratio intended for the movies we watch; it is a useful information that tells about the real proportions of what I am watching, and precious when it comes to differentiate multiple versions of the same movie, such as restored versions, or re-releases, that usually present variations in the AR amongst them. If that information is not available in the media file, then one should be able to set it manually and expect it to STAY like that, otherwise it is useless and misleads the user into believing something it is not simply because there is conflicting information being display on the screen at the same time: aspect ratio flag versus the image I am watching simply do not match (please see image below).

There has been a bit of noise about this issue in some threads such as here (1), here (2) and here(3) but no attempts to fix this has been manifested, that I am aware of. I'd like to raise attention on this matter amongst developers and hopefully get an adequate response.

Thanks in advance,

CF

Ben-Hur Blu-Ray release 2.76 Real Aspect Ratio presented by XBMC with an Aspect Ratio Flag (display) 16:9 :

[Ned Scott]

>including the black bars

I can't believe this made it into the bluray spec. It's not the users' fault, though.

I do not know of a solution, but since this is an issue with any non-encoded content, which is very common in XBMC, then hopefully a developer will want to take up the task. Right now it would be viewed as a feature request to allow the user-defined over-ride to stay, since XBMC always rechecks certain stream details upon every playback of a video.

[capfuturo]

Good night Ned Scott,

I appreciate your response. Is there any further action I should take such as submitting this as a request? I found a thread here in which ad-anda, a team-XBMC member, is having a useful exchange pointing towards a possible solution. However I have limited access to whatever has happened to those efforts in the last 5 months, and whether they have reached a working point amongst certain developers.

All best,

CF

[Ned Scott]

That thread sounds like the best lead for this.

[nickr]

So can I get this right? This is a 2.76 film presented as a 16:9 frame with black borders? Get a properly encoded file!

[Ned Scott]

It's a bluray 1:1 rip/ISO. That's how the bluray spec did it. Any encoding will mean degrading the file, which a lot of users don't want to do. Normally I would say the same thing, just properly encode the file, but using BR ISOs is very common for XBMC users.

Heck, now that I think about it, I wonder how 3D SBS files are reported in XBMC for aspect ratio. That's another situation where the normal aspect radio detection won't work out.

[capfuturo]

Ned Scott, thanks for your accurate understanding of the scenario here and the needs of many users, with whom I share same concerns regarding aspect ratios. We are at a point in history in which regular consumers can finally afford massive amounts of storage in order to preserve the highest quality available in the market for their film collections; this trend will only get stronger in time. It is a very basic principle: many of us DO NOT encode.

Just as a reminder to nickr, this is happening not just on Ben-Hur but on every single 1:1 ripped film presented in letterbox OAR (original aspect ratio), which is the tendency of remarkable Studios such as Eureka! here in Europe or Criterion, in the USA, RUSCICO in Russia, Shochiku or Toho from Japan. It is not about getting a proper encoding; it is about implementing a way to display the real aspect ratio by means of, among several possibilities, using (not applying) the crop black bar feature to calculate the RAR (real aspect ratio) or, as Ned Scott mentioned earlier, having a user-defined override to STAY, or both.

Now that you brought up the subject, I am wondering same thing about 3D files...

Best, CF

[mm_half3]

Hello CapFuturo,

Sorry for not responding earlier to the pm's you sent, was in the process of replying a few weeks back but got interrupted, and then forgot to finish the response. Will try to summarize where I left things with my attempts to mod xbmc to allow the user to disable the overwrites of AR's contained in nfo files.

Things are pretty much at the same point as described in the thread from the developers forum you refer to in your post. I was able to successfully compile MacOsX 10.7/10.8 binaries using modified source from one of the official frodo release builds, that when used in conjunction with a very simple python add-on , keeps the valid AR's in place during and after media playback....but could not replicate the same behavior in the newer source code trees (are the official xbmc git-hub source trees being used for the gotham development, or are they just newer frodo source?). Got stuck trying to pull the value of the active video's folder/directory path while in the function used to write the AR. Wanted to track this down, but since I had working frodo code, kind of let it slip.

I did setup a github repository with my code mods, but never requested a formal pull request into any master source trees because

a) the mods/patches are in the original release source for frodo, and the source has since undergone pretty significant changes. Was not sure if developers to this older tree are even accepting change requests

b) After reviewing the suggested process of getting mods/patches included into the official source trees, my take was the best way was to post the feature and code mods in the development forum, and see if it received any interest from users. Even though the issue was important to my setup, the thread in the development forum did not really get much attention, so figured it was not something that would be considered as a valid patch candidate.

[ironcross]

I am interested in this as well. I need to have the aspect ratio for my CIH projection system.

[capfuturo]

Hi ironcross,

This is the best way to gain momentum: showing your interest here on the thread. In the meantime we are waiting for the Universe to tip on our favour. Those who understand how important is this we have presented and explained the need for this feature to some developers and hopefully we'll get to hear some positive echo.

Best,
CF

[Ned Scott]

Remember, don't be discouraged if something like this isn't commented on for a while, even months. Often times there are devs who see something like this and agree and want to add it, but have lots of other things to finish up too. Sometimes the change comes as a surprise, because devs want to make sure their solution works before making a big deal out of it, etc.

[adrian ballard]

Just so you know, I'm all in for this much needed improvement.
As more and more people move to projectors, the AR is critical as many of those users use scope screens with either an anamorphic lens or memory feature to properly fill their screens.

Also, we need this to apply to the number of audio channels [greater than 5.1] as well.
As an example, 7.1 DTS-HD will be reported as 5.1.
I can change it in the NFO file, but as soon as I play the movie, it's overwritten.

My hack way still works but:
1. is a very messy solution
2. shouldn't be required
3. is skin specific

-a

[Kib]

are the official xbmc git-hub source trees being used for the gotham development, or are they just newer frodo source?

https://github.com/xbmc/xbmc -> the master branch is gotham development. The latest Frodo development is i the Frodo branch.

I suggest to create a patch based on master in a seperate branch of your own, then rebase it before making a pull request.
Pull requests based on Frodo will probably not even be looked at anymore.

[adrian ballard]

nudge

[mm_half3]

Just an update, finally was able to port code used to enable this feature in xbmc-12.0 code to the xbmc-13.0 source. More details are in this development thread