I found the solution for our problem, but need a bit help from .:B:. ^_^
we have to use the eden branch from FernetMenta instead of master or xvba.
After getting in contact with FernetMenta, Opdenkamp (FernetMenta uses his repositories for xbmc) and looking at the official XBMC repository I found out that:
1. The master branches of them do not include all available patches
2. Master branches should be used only for developing purposes
3. FernetMenta and Opdenkamp don't use gcc4.7, but now they are informed ^_^
4. Actually the aur package uses the "xvba" branch, FernetMenta told me that this branch is merged in "master" and shouldn't be used anymore by us
5. XBMC's EDEN , Opdenkamps Eden-pvr and FernetMenta's Eden branches are the right one for us, the early adopters of gcc4.7
Could you please build a package which uses the Eden branch from FernetMenta?
Trying that by myself I had some problems with the libpng patch in combination with the eden branch.
Corpswalker, patches are identical. The usleep patch is included in both the stable and the git build. What OpenELEC is using is actually 'my' patch (fixing an include really isn't that difficult, but I did give it to the main dev).
Please use this topic for support:
I talked to some of the XvBA guys. Since they rebased on Eden recenly, the libpng patch should already be included, so you should leave it out. For now, it's as easy as replacing xvba with eden in the PKGBUILD.
As you might guess git is a moving target. I have included the hash of the working commit in the PKGBUILD so you might want to try using that to build.
Edit: sorry, misread - was supposed to be eden instead of master, corrected.
Last edited by .:B:. (2012-04-12 17:13:59)
.:B:., if you compare teh ffmpeg/patches folder of master and Eden branch you will see that master has 27 patches, while the second one has 78.
I will try to edit your PKGBUILD. Will post the result.
*Edit* I see you updated the PKGBUILD just when I was posting the solution ^_^.
Last edited by Corpswalker (2012-04-12 16:05:08)
In the other thread please .
Edit: you should use the eden branch, not the master, it seems. Master has indeed a new ffmpeg, eden is what you want.
Last edited by .:B:. (2012-04-12 14:54:53)
I am wondering if anyone is experiencing the same issue after building this package.
After installation I open xbmc and add media movies and/or TV shows. xbmc does it's thing and recognises them and places them in the library.
The problem occurs when I clock on either movies or tv shows; xbmc spontaneously closes
I've tried it under a few DE's and by itself as an xbmc session, the problem still exits. I attempted a build about a month ago just after the HD release but I didnt have the time to work on it. I'd like to resolve it now and any help would be appreciated.
After a few weeks of being lax I rebuilt xbmc-git last night and installed it this morning only to find that a problem I've never had before with my setup is occurring. Tearing. I'm running it on a low power atom based HP thin client and crystalhd and Arch x86.
I thought at first maybe the upgrades to intel-dri,mesa et al. that occurred at the same time doing package upgrades may have been the cause but downgrading all of them didn't change anything. Also booted into the last kernel version since a kernel upgrade also took place but no change. This leaves only last night's pull of xbmc-git.
I was able to fix the tearing by disabling the option to match display refresh to video. Normally this has always worked fine, switching my TV to 24p during movie playback... it still does change the mode to 24p but I get all sorts of tearing. When I leave the option off and let it play videos in 60hz the tearing is gone.
Can anybody else with access to regular intel video hardware (or even other, just using the aforementioned playback option) confirm that there is a regression in xbmc gotham here?
I highly doubt crystalhd is at fault since I don't think they have updated the codebase upstream for many moons now.
Edit; I was able to get the tearing to go away only by enabling the intel TearFree option in xorg.conf which I never had to use before now... strange... not sure what exactly changed that caused this.
Last edited by binaryjay (2014-01-14 21:38:01)