Kodi Community Forum

Hi all,

First, I would like to thank all those that contributed to the development of XBMC.

I installed openelec 3.95.6 on my Raspberry Pi (model B).
In general it works well (including PVR), nevertheless I experience problems when displaying mp4 videos shot in portrait mode (e.g. vertically) with my android smartphone (same issue with Nexus S and Moto G).
Unfortunatelly, I did not find any thread concerning the issue i am experiencing.

Description of the issue: The video is displayed with the right orientation (portrait), but is streched horizontally so as to fill the whole 16:9 screen (note: vertically, no streching is applied to the video)

My video settings in XBMC are the following:
- Allow error in aspect ratio to minimize black bars: None
- Display 4:3 videosas: Normal

Note: The video is displayed correctly in several other viewers (e.g. online on Dropbox)

The tags of an mp4 for which I experience the above mentionned issue are:

I would be very thankfull for any hint in order to solve this issue.

Regards

poivre

Can you upload a sample (e.g. to dropbox) and give me a link?

Thank you for your quick reply
I uploaded it in dropbox

The video itself:

https://dl.dropboxusercontent.com/u/1013...535679.zip

Screenshot of the video while being displayed on my pi:

EDIT: I 1st uploaded the wrong screenshot... Now corrected...

https://dl.dropboxusercontent.com/u/1013...hot001.png

(Btw, thank you for your openelec raspberry performance video. It convinced me to use the pi as a media center)

I've pushed a fix to newclock3 branch.
This should appear in the next milhouse (openelec) or miappa (raspbmc) test build, so keep an eye out for them.

If testing is positive it will move to gotham_rbp_backports branch, and will appear in official openelec/raspbmc builds.

Thank you popcornmix.
I will test the build once it is available

Can you test with this build:
http://forum.xbmc.org/showthread.php?tid...pid1690291

Hi,

Thank you for the build.

The aspect ratio is fine now.

Unfortunately, a substantial part of the the top and the bottom is now cut (see screenshot: https://dl.dropboxusercontent.com/u/1013...hot002.png )
It seems that in the current build, the video is not shrinked in order to fit to the screen height, but still tries to occupy the same surface as a landscape video.

Regards

poivre

(2014-04-24, 20:27)poivre Wrote: [ -> ]Unfortunately, a substantial part of the the top and the bottom is now cut (see screenshot: https://dl.dropboxusercontent.com/u/1013...hot002.png )
It seems that in the current build, the video is not shrinked in order to fit to the screen height, but still tries to occupy the same surface as a landscape video.

Can you try this on xbmc on another platform (e.g. Windows).
I believe I've followed the same logic as dvdplayer.
Playing with dvdplayer on Pi gives correct aspect ratio, and cuts the top/bottom, and I believe omxplayer behaves the same.

Quote:Can you try this on xbmc on another platform (e.g. Windows).

On windows 8.1, XBMC 12.3 Frodo shows the video in a wrong orientation (but with a correct aspect ratio):
https://dl.dropboxusercontent.com/u/1013...o_12_3.jpg

On windows 8.1, XBMC 13.0 beta 4 shows a streched video with the right orientation
https://dl.dropboxusercontent.com/u/1013..._beta4.jpg

-----------------

Quote:I believe I've followed the same logic as dvdplayer.
Playing with dvdplayer on Pi gives correct aspect ratio, and cuts the top/bottom, and I believe omxplayer behaves the same.

Indeed the video is cut with both DVDPlayer and OMXplayer. (e.g. they seem to have now the same erroneous behaviour)

-----------------

I had a look at your commit ( https://github.com/popcornmix/xbmc/commi...d12c9b563f )

Quote:+ // fix up transposed video
+ if (m_hints.orientation == 90 || m_hints.orientation == 270)
+ {
+ float diff = (DestRect.Height() - DestRect.Width()) * 0.5f;
+ DestRect.x1 -= diff;
+ DestRect.x2 += diff;
+ DestRect.y1 += diff;
+ DestRect.y2 -= diff;
+ }

I am not a programmer, but looking at the code, I am not surprized that the video is cut.
If my understanding of the definition x1, x2, y1 and y2 is right (see drawing here: https://dl.dropboxusercontent.com/u/1013...222049.jpg )

Then:
because the video is centered:
x1old+x2old=x1new+x2new
y1old+y2old=y1new+y2new
because the aspect ratio should be kept:
(x2new-x1new)/(y2new-y1new)=(y2old-y1old)/(x2old-x1old)
because the portrait video should use the full height
y1new=0 (here I make the assumption that the origin (0,0) is the bottom left corner and that the screen is wider than high, if not this might not be true)

Resolving this system of equations, we get (if I did not make any mistake...):
y1new=0
y2new=y1old+y2old (This equals the screen height if the rectangle was already centered before)
x1new=(1/2)*(x1old+x2old-(y1old+y2old)*(y2old-y1old)/(x2old-x1old))
x2new=(1/2)*(x1old+x2old+(y1old+y2old)*(y2old-y1old)/(x2old-x1old))

I hope that this helps.

Regards
poivre

Have a look here:
https://github.com/xbmc/xbmc/blob/master...r.cpp#L357

That is how dvdplayer does it, and it's what I've based my code on.
Might be worth opening a trac ticket (or a forum post in a general forum) if you believe dvdplayer's behaviour is wrong and see what the devs say.

Do you mean that the fact that DVDPlayer cuts the video might be an expected feature? (This is surprizing to me)
I am not sure to understand completely your answer. Is there a reason not to correct it in the OMXplayer independently of the DVDPlayer?
(What do you think about validating the above mentionned x1,x2,y1,y2 computation in one of the next test builds, so that it could be provided to the dvdplayer developpers too?)
OK. I will open a ticket in the general forum.

Thank you

Note: I know that it is not a good habit to shoot video in portrait mode, but unfortunately, many smartphone videos are taken like that these days. Therefore supporting portrait video is quite important to me and probably to many other users)

I expect dvdplayer's behaviour is a bug.
It is possible that scaling to the full height is not the ideal solution. I'm guessing that won't do the expected thing in all the zoom modes, like fill.

It feels to me that orientation should be considered in earlier code, where the x1,x2,y1,y2 coordinates are calculated, rather than trying to fix it at the rendering stage.
That's why I'd like an xbmc dev who knows this code well to weigh in. It might result in a better fix.

In general I try to match the behaviour of dvdplayer with omxplayer. Having different behaviour is always going to be the wrong choice.
If dvdplayer is doing the wrong thing, it should be fixed there.

Now I understand your point. In fact I also wondered why the coordinates are not calculated correctly earlier, so that DVDPlayer and OMXPlayer do not have to modify them according to the orientation.

I opened a thread here: http://forum.xbmc.org/showthread.php?tid=193215

---

By the way, your fix in the test build seems to have corrected the preview image of the video too.