Win My BRRip Playback Branch of Eden
#46
I withdrew the last pull request I had made and submitted a new one. Over the holiday I took another look at all of the ffmpeg commits that impacted this and was able to bring it much closer to the current ffmpeg master. Hopefully now we don't need a patch because it's spot on with ffmpeg minus a couple things that will roll in as other ffmpeg commits are merged. I also split out the xbmc and ffmpeg commits, I couldn't tell if that's what they wanted with their note on the last request, but it seems fitting to split it.

I also referenced all of the ffmpeg commits that I could find in the commit description, so hopefully that gets them the information they need to verify with the ffmpeg master. Unfortunately this wasn't implemented in ffmpeg all at once so it was very spread out.

jjd-uk: A lot of the changes that are incorporated now appear to have been added to ffmpeg in the last month or two, so I know it's in the master, but it looks like it's in version 1.0 based on their branches.

They were quick to ask any questions on the last request, so I'm sure we'll see what they have to say soon. Honestly I just hope they don't take a baseball bat to me since this is all new to me =)
Reply
#47
Just curious I noticed this comment on your pull request

"davilla merged commit e6f195c into xbmc:master from GreenOnyx:FrodoPGSForced 6 hours ago"

Not sure what this means?

It might be your first time but you know more then me, I am sure you did it all like you were suppose to.

Reply
#48
It means that the code changes GreenOnyx supplied have been merged into the XBMC code, seems like the changes have been treated as fixes to the ffmeg libraries so haven't been delayed by the current feature freeze for Frodo.

What this means is that the fixes should show up in the next Nightly build and also be in the official Frodo release Smile

Just goes to show if people supply code changes via the official route things can move remarkably quickly if it's viewed as not having impact on other areas. Well done to GreenOnyx for doing the necessary work and on a successful pull request Smile
Reply
#49
You are all awake too early for me =) Yes, I was going to let everyone know that it was merged and it is in fact in last night's nightly build (XBMCSetup-20121227-d4d9b3e-master.exe 28-Dec-2012 10:38). I have installed this build this morning and it seems to work great for me still. Please let me know if anyone runs into any problems or odd scenarios with their subtitles.

That said, there has been a problem reported and I'm not sure how it'll work out. The one issue so far is that it breaks people using external ffmpeg because part of the ffmpeg code that xbmc uses is using ffmpeg's up to date objects and part is not. I'm not sure if they're wanting a patch so that it's not in line with the latest ffmpeg until the rest of xbmc upgrades, or if they want a patch that takes the up to date code and reverts it back to a point where an external ffmpeg will work.

It seems like they'd want the later, otherwise there's not much of a point in implementing larger ffmpeg updates/improvements unless it's done across the board. I'm not familiar with the patch side of things though. The comments can be found at this link if anyone wants to follow along: 1992 (PR)
Reply
#50
Seems to me that they are not asking anything further of you as XBMC with it's internal ffmeg is fine so offers benefits to the virtual the whole XBMC userbase, so as I read it the external ffmeg people (which will be a very small group of people) will have to supply a patch if they wish to fix any issue they see.
Reply
#51
Yeah, I agree. Are external ffmpeg users required to compile their own ffmpeg due to patches like that then? Otherwise I'm not sure how it would be useful since you obviously couldn't apply that patch for everyone as it would just eliminate the change.

Sorry, I've obviously never used an external ffmpeg, never had a reason to.
Reply
#52
I submitted a new pull request that hopefully will avoid utilizing the new objects if a user is using an external ffmpeg that's older than the needed version. Hopefully it does the trick so that we can keep this fix in place. I'll post back if it makes a nightly in case anyone wants to test more.
Reply
#53
Again it's been merged quickly into XBMC so still looking good for Frodo
Reply
#54
Sure was, and it looks like it made it into last night's nightly build (XBMCSetup-20121229-d446c0a-master.exe 29-Dec-2012 10:39). Crossing my fingers that it does the trick.

I'm extremely impressed at the maintainers speed and everyone's assistance/input. To have things merged and tested so quickly, comments cleaned up with fixes noted, etc. is amazing.
Reply
#55
Would have replied sooner to this but only got the one notification just now! This is great news, can't wait to try out the latest nightly, this community rocks Smile
Reply
#56
Just curious what is an external ffmpeg? I am assuming since I dont know what that means I likely wont be effected?
Reply
#57
Ghostdivision:
ffmpeg is a 3rd-party library XBMC uses to decode and render movies. By default, XBMC ships with an own copy of that library, but on linux the library could already be present/installed in the OS and thus the XBMC version for this OS/distribution can be changed to make use of the global/shared/external OS library instead and don't ship/use an own copy.
Reply
#58
Edit-will comment later with more testing
Reply
#59
So what i was going to say, and maybe this out of the scope of the conversation here, since I have know idea how to do it. But mpc, lav filer automatically selects forced subtitle pgs stream if it finds forced flags when the movie is launched, and based on the language argument you set up. SO if you set up "eng" argument, it seems to check the english subtitles for forced flags, and then selects it if it finds it automatically, no work required.

It takes the guess work out if your dealing with bluray rips with multiple english streams or whatever your language is. SO i was wondering now that we can detect forced pgs flags thanks to the work in this thread, how hard would it be to setup a check when you load a movie for forced subtitles for the preferred language, for forced flags, and then xbmc could auto set it to that?

This would help alot of casual end users who use simple things like makemkv programs which wont manually demux and flag a forced track, I just seen so many posts on here and makemkv about forced subtitle issue in xbmc over the years, and its still not quite perfect and hassle free yet.
Reply
#60
(2013-01-09, 04:33)Ghostdivision Wrote: It takes the guess work out if your dealing with bluray rips with multiple english streams or whatever your language is. SO i was wondering now that we can detect forced pgs flags thanks to the work in this thread, how hard would it be to setup a check when you load a movie for forced subtitles for the preferred language, for forced flags, and then xbmc could auto set it to that?
So does it not currently work like that? not 100% about subtitles but the audio language tracks are chosen based on XBMC language setting, so I would have thought something similar could be done for subtitles if it's not there already.

Reply

Logout Mark Read Team Forum Stats Members Help
My BRRip Playback Branch of Eden2