not much to say, I'm using stable libav-0.8.4 and trying to compile latest stable xbmc and it fails. Reproducible: Always
Created attachment 329484 [details] build log
cvs/gentoo-x86/media-tv/xbmc $ ebuildvar DEPEND|grep libav xbmc-11.0.ebuild : || ( media-libs/libpostproc <media-video/libav-0.8.2-r1 media-video/ffmpeg ) xbmc-9999.ebuild : || ( media-libs/libpostproc <media-video/libav-0.8.2-r1 media-video/ffmpeg ) Invalid?
(In reply to comment #2) > cvs/gentoo-x86/media-tv/xbmc $ ebuildvar DEPEND|grep libav > xbmc-11.0.ebuild : || ( media-libs/libpostproc > <media-video/libav-0.8.2-r1 media-video/ffmpeg ) > xbmc-9999.ebuild : || ( media-libs/libpostproc > <media-video/libav-0.8.2-r1 media-video/ffmpeg ) > > Invalid? I don't follow, can you explain please?
@Jer: nope the dep is correct, headers are found just right: checking libpostproc/postprocess.h usability... yes checking libpostproc/postprocess.h presence... yes checking for libpostproc/postprocess.h... yes It is broken up by the patchset that makes it work with ffmpeg 1.0. @aballier: Let me get this straight, you changed stable package to include 30+ patches. Put it straight to stable without any revision and you didn't even bother to compile it with the libav? Note I don't have problem with it being broken, I have huge problem that you did it on stable ebuild, so I was not even aware of the issue as I didn't need to recompile my xbmc. I revision bumped the xbmc to contain your patchset yet I keep the stable version with the old one until this one is bugless and arch tested. Also about the libav patchset, it was not merged upstream because they told me you (and some others) are working on it in some branch and will make sure libav will work so my patch is actually going to be useless. I will look to the issue more during the weekend more, because currently I don't have the time to do so.
(In reply to comment #4) > @aballier: > Let me get this straight, you changed stable package to include 30+ patches. > Put it straight to stable without any revision and you didn't even bother to > compile it with the libav? > > Note I don't have problem with it being broken, I have huge problem that you > did it on stable ebuild, so I was not even aware of the issue as I didn't > need to recompile my xbmc. > > I revision bumped the xbmc to contain your patchset yet I keep the stable > version with the old one until this one is bugless and arch tested. Yes it should have been rev bumped to be on the safe side, which I usually dont do for build fixes. On the other hand, I thank you for valuing the work this has been and hope you can join the fun next time :)
Created attachment 329592 [details, diff] xbmc-11.0-libav-r2.patch More in progress patchset. Problem that remains is it uses headers that are not available in 0.8 libav, 9 libav will have them so for further testing the dep will need to be raised and i will have to update to test it more.
a question, I saw that there are two version, 11.0 and 11.0-r1, 11.0 compiles well for me, but when I try to run a movie, I get black screen instead of the movie, I've only tried one movie (it was late) which was FHD movie, I know I need to test another movie or check if it is an issue of my hw but just to make sure, 11.0 do plays movies when compiled again libav?
(In reply to comment #7) > a question, I saw that there are two version, 11.0 and 11.0-r1, 11.0 > compiles well for me, but when I try to run a movie, I get black screen > instead of the movie, I've only tried one movie (it was late) which was FHD > movie, I know I need to test another movie or check if it is an issue of my > hw but just to make sure, 11.0 do plays movies when compiled again libav? Yes it does play movies when built with libav, yesterday i was watching clockwork orange :-) Possible is that your xbmc tries to use vdpau interface and it is broken, or something in that manner.
(In reply to comment #8) > (In reply to comment #7) > > a question, I saw that there are two version, 11.0 and 11.0-r1, 11.0 > > compiles well for me, but when I try to run a movie, I get black screen > > instead of the movie, I've only tried one movie (it was late) which was FHD > > movie, I know I need to test another movie or check if it is an issue of my > > hw but just to make sure, 11.0 do plays movies when compiled again libav? > > Yes it does play movies when built with libav, yesterday i was watching > clockwork orange :-) > > Possible is that your xbmc tries to use vdpau interface and it is broken, or > something in that manner. I use vaapi because as my hw is intel, more strangly it froze, I think it is a driver issue as I'm currently using the git version (had issues to boot it with 1080p so I thought that driver upgrade might solve it)
I don't think it is a driver issue. I had xbmc 10 for a long time without issue and once, today, revdep-rebuild updated it to 11.0, the same freezing experience occured as you mentioned in http://forums.gentoo.org/viewtopic-t-943282-start-0.html. I am using vaapi intel hd too. I don't have git versiones but I've installed latest ~amd64 keyworded ebuilds for intel driver and libva (I think so). Xbmc 10 was completely fine with these keyworded packages.
Fixed in 12.1-r1 which requires libav-9.
(In reply to comment #11) > Fixed in 12.1-r1 which requires libav-9. hu, seriously ? I had a look at your patchset and can see serious problems. Please fix before I revert: - 0001-* and 0002-* infringe my copyright as you can see from xbmc git log. - 0003-* introduces a memcpy for each frame which is unacceptable; current xbmc git master should have a much better solution - 0004-* and 0005-* use functions not present in ffmpeg 0.10; which is current stable. Part of these commits are also completely wrong as they apply to the bundled ffmpeg in xbmc which is ffmpeg 0.10.2... - Can't see anything bad in 0006, 7 and 8 but, at least for 8, this should be submitted upstream.
(In reply to comment #12) > (In reply to comment #11) > > Fixed in 12.1-r1 which requires libav-9. > > hu, seriously ? I had a look at your patchset and can see serious problems. > Please fix before I revert: > > - 0001-* and 0002-* infringe my copyright as you can see from xbmc git log. Uh what do you mean by this? From what I think Anton just worked on 12 and never checked master. So he just wrote the same shit you do, which is no copyright infringement. Also for removing 6 lines it is no supprising the diff seems the same. > - 0003-* introduces a memcpy for each frame which is unacceptable; current > xbmc git master should have a much better solution Sure point me to the commits and I will gladly look on them. > - 0004-* and 0005-* use functions not present in ffmpeg 0.10; which is > current stable. Part of these commits are also completely wrong as they > apply to the bundled ffmpeg in xbmc which is ffmpeg 0.10.2... That is no problem for us as I raised the dep for the new libav/ffmpeg so simply we can forget about building it with older ffmpeg. > - Can't see anything bad in 0006, 7 and 8 but, at least for 8, this should > be submitted upstream. Since I still have 2 months opened merge requests with no activity feel free to merge whatever you see fit to master.
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > Fixed in 12.1-r1 which requires libav-9. > > > > hu, seriously ? I had a look at your patchset and can see serious problems. > > Please fix before I revert: > > > > - 0001-* and 0002-* infringe my copyright as you can see from xbmc git log. > > Uh what do you mean by this? > From what I think Anton just worked on 12 and never checked master. So he > just wrote the same shit you do, which is no copyright infringement. > > Also for removing 6 lines it is no supprising the diff seems the same. I must confess that the tone was maybe too provocative. From the rest of the patches it is quite clear nobody dared to check master, that it was rewritten from scratch and not a bare grab of the commits with changed author. However, not even looking at upstream master doesn't speak well about the methods; let alone pushing patches to gentoo users without even having a review from upstream. > > - 0003-* introduces a memcpy for each frame which is unacceptable; current > > xbmc git master should have a much better solution > > Sure point me to the commits and I will gladly look on them. https://github.com/xbmc/xbmc/pull/2597 (btw, please explain me how you want to fix something if you're not able to look for upstream fixes yourself) > > - 0004-* and 0005-* use functions not present in ffmpeg 0.10; which is > > current stable. Part of these commits are also completely wrong as they > > apply to the bundled ffmpeg in xbmc which is ffmpeg 0.10.2... > > That is no problem for us as I raised the dep for the new libav/ffmpeg so > simply we can forget about building it with older ffmpeg. It is if you want the patches to be useful. AFAIK libav-9 is far from being able to be unmasked. I had pending bugfixes for xbmc. What should I do now? A -r2 dropping your patches? > > - Can't see anything bad in 0006, 7 and 8 but, at least for 8, this should > > be submitted upstream. > > Since I still have 2 months opened merge requests with no activity feel free > to merge whatever you see fit to master. Me too. Usually a ping on the PR gives it some attention.
(In reply to comment #14) > I must confess that the tone was maybe too provocative. From the rest of the > patches it is quite clear nobody dared to check master, that it was > rewritten from scratch and not a bare grab of the commits with changed > author. However, not even looking at upstream master doesn't speak well > about the methods; let alone pushing patches to gentoo users without even > having a review from upstream. You are again 2 notches too high in the provocative scale, please tone it down. > (btw, please explain me how you want to fix something if you're not able to > look for upstream fixes yourself) Usually backporting fixes might be a good idea, sometimes when the code at hand evolved a lot is quicker to do otherwise. Sometimes while you are fixing problems upstream moved further. Is not always clearly cut which is the best approach, help is always welcome. > It is if you want the patches to be useful. AFAIK libav-9 is far from being > able to be unmasked. I had pending bugfixes for xbmc. What should I do now? > A -r2 dropping your patches? libav-9 is hardmasked because software such as xbmc, we try our best to help downstreams but takes time and I do not have that much of it =\
Please, let's stop the non-technical discussion there (In reply to comment #15) > Is not always clearly cut which is the best approach, help is always welcome. You should have a look at my comments on bug #464552 for this specific case. > > It is if you want the patches to be useful. AFAIK libav-9 is far from being > > able to be unmasked. I had pending bugfixes for xbmc. What should I do now? > > A -r2 dropping your patches? > > libav-9 is hardmasked because software such as xbmc, we try our best to help > downstreams but takes time and I do not have that much of it =\ xbmc is more on the side that "needs" libav-9 rather than prevents it from being unmasked actually answering my own question: I guess the only sane thing to do is to move current -r1 to -r100 and do the backports in -r2.
latest versions have reworked libav support
