2012-07-05, 04:48
Hmmm. What's your build environment?
2012-07-05, 05:27
OSX Lion and Xcode 4.3
Have also tried Mountain Lion DP4 and Xcode 4.4 DP5 to no avail
IOS SDK 5.1
Downloaded xbmc master via git and then followed the instructions..
cd tools/darwin/depends
./bootstrap
./configure --with-darwin=ios
Have also tried Mountain Lion DP4 and Xcode 4.4 DP5 to no avail
IOS SDK 5.1
Downloaded xbmc master via git and then followed the instructions..
cd tools/darwin/depends
./bootstrap
./configure --with-darwin=ios
2012-07-05, 05:59
And this has what to do with ffmpeg patch (thread topic) ? Please start a NEW thread for build issues.
2012-09-14, 02:58
Can someone try this patch out http://ffmpeg.org/pipermail/ffmpeg-devel...30738.html
It's for this subtitle issue https://ffmpeg.org/trac/ffmpeg/ticket/1722 pgs subs flash on screen very fast and are gone.
Here is a test m2ts file to see if the patch works http://dl.dropbox.com/u/103661855/Sample...ssue-.m2ts
It's for this subtitle issue https://ffmpeg.org/trac/ffmpeg/ticket/1722 pgs subs flash on screen very fast and are gone.
Here is a test m2ts file to see if the patch works http://dl.dropbox.com/u/103661855/Sample...ssue-.m2ts
2012-09-14, 13:34
Reread the patch description. It seems it should fix the opposite of your bug (e.x. subtitles which are shown for to long).
2012-09-14, 13:43
(2012-09-14, 13:34)Memphiz Wrote: Reread the patch description. It seems it should fix the opposite of your bug (e.x. subtitles which are shown for to long).
Dev of ffmpeg says we should try it and see if it helps too but Doombot cant do it and nor can i..
So we are looking for someone willing to test cause this problem really is a pain in the xxx and its present since xbmc 9
2012-09-14, 16:49
we are not talking about ios/atv2 here do we? (cause there was no XBMC 9 for this platform).
2012-09-14, 19:25
Nope this would be for windows and openelec using frodo builds.
Looks like someone has tried the patch and it works, so the next step is how does it get into xbmc?
https://ffmpeg.org/trac/ffmpeg/ticket/1722
Looks like someone has tried the patch and it works, so the next step is how does it get into xbmc?
https://ffmpeg.org/trac/ffmpeg/ticket/1722
2012-09-15, 12:49
Hard to be done. That patch doesn't apply on the ffmpeg version we are using (ffmpeg changed alot and the difference to the code we use is so huge that its hard to backport that patch into our version). I'll give it a shot - but don't count on it.
2012-09-15, 14:09
Ok - that patch doesn't help us at all. Its a patch for ffplay. We need it to be patched in libffmpeg itself. Since you have opened that issue on at least 3 forums here i just want to let you know that i won't write this on the other threads too. So its up to you to handle that messy information spread 
2012-09-15, 14:39
(2012-09-15, 14:09)Memphiz Wrote: Ok - that patch doesn't help us at all. Its a patch for ffplay. We need it to be patched in libffmpeg itself. Since you have opened that issue on at least 3 forums here i just want to let you know that i won't write this on the other threads too. So its up to you to handle that messy information spread
Thanks Memphiz for trying i didn't even realize it was just a patch for ffplay but then i don't understand most of this stuff.
I'm just someone trying to get a problem fixed so that i can fully enjoy XBMC.
So it's really up to ffmpeg to patch their code first right?
2012-09-15, 15:11
Not quiet sure. But if ffmpeg would deliver us the correct pts, dts and duration values for the subtitle packets - i would count on XBMC showing them at the right time. ATM it looks like duration is 0 or even lower zero. I'm not the right dev for making assumptions here (the player code in XBMC is quiet complex and i'm not used to it). The time calculations could be wrong in ffmpeg or in XBMC (but since other subtitle formats work i could guess its ok on XBMCs side).
2012-09-15, 17:48
Looks like the patches were applied to the official git repository. They will probably be part of the 0.12 release
"The problem was that the ffmpeg libraries were not providing the correct time at the logical place, therefore, applications based on ffmpeg would seek the value elsewhere, incorrectly. The ffmpeg libraries now provide the correct time at the logical place, but applications will probably still be using the incorrect one."
"The problem was that the ffmpeg libraries were not providing the correct time at the logical place, therefore, applications based on ffmpeg would seek the value elsewhere, incorrectly. The ffmpeg libraries now provide the correct time at the logical place, but applications will probably still be using the incorrect one."
2012-09-15, 18:12
K there are some more commits now (not only ffmpeg/ffplay). I tried them and it didn't fix the issue in xbmc :/
