2013-02-05, 19:21
Apperently the bookmark function is gone, but there are (more or less bad) workarounds: http://stackoverflow.com/questions/54732...in-xcode-4
2013-02-07, 00:54
(2013-02-05, 19:21)dataolle Wrote: Apperently the bookmark function is gone, but there are (more or less bad) workarounds: http://stackoverflow.com/questions/54732...in-xcode-4
Yeah, I sadly noticed that too ;-( Thanks for the pointer but I'm looking for a "non intrusive" way (i.e no code changes) to add bookmarks with a short remark like "DVDDemuxFFmpeg::open" and so on. Unfortunately the "disabled-brake-point" is rather useless since you cannot add any descriptive text to break-points in xcode.
It's kind of odd there is no plug-in to xcode since so many people are asking for that functionality. For a second I had in mind to switch over to VS2012 instead but I couldn't stand the idea to set up a new working xbmc source environment from scratch again.
Anyhow, I'm still in the middle of debugging the ffmpeg-integration. I'm using two parallell sessions, one working and one stuttering video stream side by side on different screens to see if I can catch any differences. For the moment I'm focusing on ::open and ::read in "DVDDemuxFFmpeg.cpp". This is rather time-consuming, I only wish I had more time...
I've also sent a poll about the issue to the ffmpeg library user group ([email protected]) but no luck so far.
Hi folks, I think I've finally found the problem!
After some late night digging I fortunately managed to locate the problem to the ffmpeg libraries. It looks like the current libavcodec used by xbmc (v53.61.100) contain some bugs that sometimes results in stuttering video. The latest stable release of libavcodec is v54.91.102. After some "quick 'n dirty" porting I made it to work with xbmc and the stuttering was all gone! I used a 1280x720 (BANDWIDTH=2 793 000 mb/s) stream with the "SVT Play" add-on and it worked like a charm.
It accually took a few days (
) before I realized that I forgot to check which libavcodec version that was used in xbmc. When I back-ported mplayer2 with the older libavcodec I got the same problem as in xbmx.
There have been some changes to the new version of the ffmpeg libraries and there are some new issues that must be fixed and of course everything needs to be regression tested before it can be released. I'll will check with the XBMC-team if I can hand over the final porting to them.
--
After some late night digging I fortunately managed to locate the problem to the ffmpeg libraries. It looks like the current libavcodec used by xbmc (v53.61.100) contain some bugs that sometimes results in stuttering video. The latest stable release of libavcodec is v54.91.102. After some "quick 'n dirty" porting I made it to work with xbmc and the stuttering was all gone! I used a 1280x720 (BANDWIDTH=2 793 000 mb/s) stream with the "SVT Play" add-on and it worked like a charm.
It accually took a few days (
) before I realized that I forgot to check which libavcodec version that was used in xbmc. When I back-ported mplayer2 with the older libavcodec I got the same problem as in xbmx. There have been some changes to the new version of the ffmpeg libraries and there are some new issues that must be fixed and of course everything needs to be regression tested before it can be released. I'll will check with the XBMC-team if I can hand over the final porting to them.
--
2013-02-12, 20:47
(2013-02-12, 20:08)CosyCat Wrote: nice find! have you tried the fix on rpi?Sorry, not yet! But it would be very useful if you could locate someone with a working development environment for the RPi. Then I could hand over some instructions how to implement the new ffmpeg libraries. I would rather not set up yet another dev-env myself since I've already have three others to cope with (OSX, IOS and Win). But I'm quite sure it will work on RPi since the GPU fully supports up to level 4.1 (bluray) including the avc1.77.30. See "RPi and AT H.264 decoding levels" ...
2013-02-12, 21:48
So this lib is inside ffmpeg version being used?
I had buffering issues on windows version too, and it seemed ok with eden..
i thought that had to do with ffmpeg version also
Also, with gotham, i hope ffmpeg version 1.1 will be used (lots of bug fixes)
I had buffering issues on windows version too, and it seemed ok with eden..
i thought that had to do with ffmpeg version also
Also, with gotham, i hope ffmpeg version 1.1 will be used (lots of bug fixes)
2013-02-12, 22:35
(2013-02-12, 21:48)Skank Wrote: So this lib is inside ffmpeg version being used?Yes, including all other libraries in the 1.1 release: http://www.ffmpeg.org/download.html#release_1.1
2013-02-12, 22:37
Guess we just have to wait till 1.1 ffmpeg version is pulled in
2013-02-12, 22:40
(2013-02-12, 22:37)Skank Wrote: Guess we just have to wait till 1.1 ffmpeg version is pulled in
Yeah, that's the plan. Want to contribute with a RPi port?
2013-02-12, 22:43
2013-02-14, 10:10
flyingrat: youre a rockstar! way good work.
I can set up a dev environment on my rpi, I will look into this today...
I can set up a dev environment on my rpi, I will look into this today...
2013-02-14, 11:13
Has anyone yet requested for a pull for latest ffmpeg version on github? Cant find it
2013-02-14, 11:55
(2013-02-14, 10:10)dataolle Wrote: flyingrat: youre a rockstar! way good work. I can set up a dev environment on my rpi, I will look into this today...Great!
2013-02-14, 12:56
(2013-02-14, 11:13)Skank Wrote: Has anyone yet requested for a pull for latest ffmpeg version on github? Cant find itNo changes pushed to the xbcm repo yet since I'm still doing work on a local clone.
But I suspect future discussions will become more code oriented and they will probably fit better on github. Not sure which git model currently being used by xbmc but I guess a normal fork and pull would do. If you have the time and possibility, it would be nice if you could check way of working.
Then we can prepare a new fork (or whatever) and move on from there...
