2013-08-22, 12:14
Been a while since I posted in this thread, so thought I'd give a status update (+ a possible bug report, below)
As you might remember I was using Intel HD4000 with the Xvba branch. After the latest Intel driver (Aug 7th), minor X-tweaking and updates, + a change to /etc/environment(!), I now have a nearly-100% smooth-running setup. The video is nearly flawless using VAAPI acceleration and rarely goes over 10% on any of the cores (4). So a major^2 improvement compared to last time! Also have subs and audio sync + remote working.
Big kudos to the team for an excellent movie-watching experience! It is _nearly_ identical to watching the discs on a dedicated player (Oppo + PS3). Also love the way forced subtitles are handled (and the way they are rendered). Certainly did not expect that aspect of it to be identical to a standalone player!
I did however run into two issues lately, one is the PCM 5.1 (+FLAC 5.1) resampling when using Video Clock (resample audio) as the sync option with S/pdif audio out. This issue should hopefully be fixed though (thanks for the info @fritsch!)
Another more important issue, however, is that XBMC has started showing a tendency to crash on certain MKVs (which are verified as working on other players (VLC; MplayerX), as well as after being scanned with mkvmerge for errors). This curious since XBMC basically never crashed before and I am hoping it is due to something I might have missed. Downgrading XBMC did not help.
So I'm really stumped as to why this happens, as I've not found any clear indications in the debug output –
http://pastebin.com/eDm8YbPH (EDIT: original log was removed for some reason)
XBMC then bails out with a segmentation fault. This was happening with two MKVs which I know are working, and I am wondering if it is due to some metadata-parsing problem(?). One of the videos which fail I already watched halfway through the day before, and the other crashes semi-randomly.
When this occurred I tested all other MKVs which I recently ripped (around 7-8), and they all work without issues.
Then, when switching back to one of the 'problematic' rips (still in the same XBMC instance) it crashes without fail. I will re-rip one of these to see if it is really caused by MKV corruption (which seems strange, as I can't detect problems with it elsewhere nor can mkvtoolnix)
It might also be caused by a xrandr issue. When XBMC crashes and is re-launched it is constantly running the GUI at 24Hz (vs. 60Hz) unless the system is rebooted. (btw., running the GUI at the same rate as (most) movies is a benefit IMO, since the movies instantly start without having the resolution switched beforehand.)
Sorry for the rather long post. I did 9-10 tests on this yesterday (w/ 3-4 reboots as well), and the issue persists. I went as far back as daily build from late June to rule out any recent changes causing this, but it behaves the same on all versions tested.
As you might remember I was using Intel HD4000 with the Xvba branch. After the latest Intel driver (Aug 7th), minor X-tweaking and updates, + a change to /etc/environment(!), I now have a nearly-100% smooth-running setup. The video is nearly flawless using VAAPI acceleration and rarely goes over 10% on any of the cores (4). So a major^2 improvement compared to last time! Also have subs and audio sync + remote working.
Big kudos to the team for an excellent movie-watching experience! It is _nearly_ identical to watching the discs on a dedicated player (Oppo + PS3). Also love the way forced subtitles are handled (and the way they are rendered). Certainly did not expect that aspect of it to be identical to a standalone player!
I did however run into two issues lately, one is the PCM 5.1 (+FLAC 5.1) resampling when using Video Clock (resample audio) as the sync option with S/pdif audio out. This issue should hopefully be fixed though (thanks for the info @fritsch!)
Another more important issue, however, is that XBMC has started showing a tendency to crash on certain MKVs (which are verified as working on other players (VLC; MplayerX), as well as after being scanned with mkvmerge for errors). This curious since XBMC basically never crashed before and I am hoping it is due to something I might have missed. Downgrading XBMC did not help.
So I'm really stumped as to why this happens, as I've not found any clear indications in the debug output –
http://pastebin.com/eDm8YbPH (EDIT: original log was removed for some reason)
XBMC then bails out with a segmentation fault. This was happening with two MKVs which I know are working, and I am wondering if it is due to some metadata-parsing problem(?). One of the videos which fail I already watched halfway through the day before, and the other crashes semi-randomly.
When this occurred I tested all other MKVs which I recently ripped (around 7-8), and they all work without issues.
Then, when switching back to one of the 'problematic' rips (still in the same XBMC instance) it crashes without fail. I will re-rip one of these to see if it is really caused by MKV corruption (which seems strange, as I can't detect problems with it elsewhere nor can mkvtoolnix)
It might also be caused by a xrandr issue. When XBMC crashes and is re-launched it is constantly running the GUI at 24Hz (vs. 60Hz) unless the system is rebooted. (btw., running the GUI at the same rate as (most) movies is a benefit IMO, since the movies instantly start without having the resolution switched beforehand.)
Sorry for the rather long post. I did 9-10 tests on this yesterday (w/ 3-4 reboots as well), and the issue persists. I went as far back as daily build from late June to rule out any recent changes causing this, but it behaves the same on all versions tested.
