2010-06-28, 17:49
NB: This bug does not appear in release 9.11. It also didn't appear in the nightlies until relatively recently. Unfortunately I can't find exactly which revision it appears in as all the nightlies (for osx at least, where it's easy to try different versions consecutively) that are currently available exhibit this problem or have a bigger problem in that they crash on startup on my mac. :-)
But I think this bug was introduced within the last few weeks, as material I'd previously watched just a few weeks ago and had no problem with is now showing this problem.
And the problem is... :-)
It seems to be no longer honouring the pixel aspect ratio in mpeg4 files as produced by HandBrake (and thus actually encoded by x264).
Given a source recording from BBC HD - 1440x1080 with a stored pixel aspect ratio of 4/3 to give a display size of 1920x1080; with the viewing mode set to "Normal" XBMC now displays these scaled to 1920x810; ie: correctly expanded horizontally but vertically squashed. (Can clearly see that things that should be round, like planets, are oval. Plus, of course, it's letterboxed on the TV screen.)
I can correct at play-time by changing the viewing mode to Stretch 16:9, but clearly this isn't right, it should be doing that by itself, as it used to. :-)
This behaviour was first noticed on my Ubuntu-Lucid Revo a little while ago, and replicated with recent nightlies (including the exact revision currently on the Revo) on the Mac, so it's a cross-platform bug.
For a while I laboured under the apprehension that I'd encoded things wrong, which is why this bug report didn't appear when the bug did I'm afraid. I've now checked this isn't the case, as the same material plays at the correct aspect ratio in, eg: vlc, mplayer, quicktime and indeed XBMC 9.11. :-)
There doesn't appear to be anything particularly useful being logged; it's not reporting any errors, just doing it wrong. Would it help to provide a minute or so of video to replicate it with?
NB: the raw EyeTV recordings do not show this bug; they show at the correct aspect ratio. These are encapsulated in mpeg2 transport streams though. (And recent XBMC nightlies also seem a bit prone to crashing in playing them but this I blame on the BBC encoder.)
With this in mind I ran one of the files I was having a problem with through mkvmerge to produce an mkv version, and that plays back in the recent nightlies perfectly, with the correct aspect ratio.
So this looks like it may be an issue with understanding the aspect ratio data in MPEG4 files. A problem which all this other software (to whit: vlc, mplayer, quicktime, mkvmerge (which logs it's read a display size of 1920x1080 from the source), xbmc 9.11 and less recent nightlies since then) doesn't have. :-)
But I think this bug was introduced within the last few weeks, as material I'd previously watched just a few weeks ago and had no problem with is now showing this problem.
And the problem is... :-)
It seems to be no longer honouring the pixel aspect ratio in mpeg4 files as produced by HandBrake (and thus actually encoded by x264).
Given a source recording from BBC HD - 1440x1080 with a stored pixel aspect ratio of 4/3 to give a display size of 1920x1080; with the viewing mode set to "Normal" XBMC now displays these scaled to 1920x810; ie: correctly expanded horizontally but vertically squashed. (Can clearly see that things that should be round, like planets, are oval. Plus, of course, it's letterboxed on the TV screen.)
I can correct at play-time by changing the viewing mode to Stretch 16:9, but clearly this isn't right, it should be doing that by itself, as it used to. :-)
This behaviour was first noticed on my Ubuntu-Lucid Revo a little while ago, and replicated with recent nightlies (including the exact revision currently on the Revo) on the Mac, so it's a cross-platform bug.
For a while I laboured under the apprehension that I'd encoded things wrong, which is why this bug report didn't appear when the bug did I'm afraid. I've now checked this isn't the case, as the same material plays at the correct aspect ratio in, eg: vlc, mplayer, quicktime and indeed XBMC 9.11. :-)
There doesn't appear to be anything particularly useful being logged; it's not reporting any errors, just doing it wrong. Would it help to provide a minute or so of video to replicate it with?
NB: the raw EyeTV recordings do not show this bug; they show at the correct aspect ratio. These are encapsulated in mpeg2 transport streams though. (And recent XBMC nightlies also seem a bit prone to crashing in playing them but this I blame on the BBC encoder.)
With this in mind I ran one of the files I was having a problem with through mkvmerge to produce an mkv version, and that plays back in the recent nightlies perfectly, with the correct aspect ratio.
So this looks like it may be an issue with understanding the aspect ratio data in MPEG4 files. A problem which all this other software (to whit: vlc, mplayer, quicktime, mkvmerge (which logs it's read a display size of 1920x1080 from the source), xbmc 9.11 and less recent nightlies since then) doesn't have. :-)
