HandBrake

benlake wrote:Well I'll hang around on freenode in #handbrake-dev, until rhester tells me to screw off. Cya there

No guff from me. This isn't my project - I just thought it would be nice if people could collectively pull HandBrake out of the ashes. It appears the answer is a yes. =)

Rodney

benlake wrote:Anyhow, initial implementation, if the new camp will accept me I'm willing to help out.

Please see your private message on this board.

Rodney

Can the auto-update code be modified to only run if the build is marked as a release build? That way we can update the build info with each update but auto-update will only activate when needed. Manually, yes - the code has no way of knowing it's a release or not. :) Perhaps a debug flag passed at ...

If we really are OK without the ffmpeg MacIntel patch, let's remove it from the svn and modify the Jamfile appropriately.

Rodney

Agree re: versioning, but HB_BUILD is only of real significance to the auto-updater.

That opens Pandora's Box. How to handle this for release builds is trivial - but do we allow for auto-updating of betas? (Note: It can't be done with normal pathing for obvious reasons.)

Rodney

If it does, it's only on titer's hard drive. No such public documentation exists, but I agree it would be of major value.

Aren't there tools to at least get this started in an automated fashion a la JavaDoc?

Rodney

johnallen wrote:This also suggests that we may need someone in a build manager role. Possibly one person for each platform.

Thoughts?

I was thinking same, but originally from a standpoint of an automated nightly build process per platform. I see the value - what we're lacking is volunteers.

Rodney

I still think we may have an ethical issue releasing HB without a nod from titer. Is he still MIA? Yes, indeed. I agree about the confusion of ethics, but the reality is that the code is GPL - as far as I know, we are within rights to do so. Clearly, if titer resurfaces at some later point and obje...

I put it on the front page already, will do so here as well.

Rodney

I'll make the call.

To avoid (even more) confusion, whatever the default was in 0.7.1, so shall it be in 0.7.2. Done.

We'll revisit in 0.8.0.

Rodney

baggss wrote:I am working on 2 new tutorials in relation to the upcoming 0.72 release (is 0.72 or 0.7.2?).

It's 0.7.2.

Rodney

One last thing on gui then I will shut up. Whether Legacy or GenII, two things about the h.264 selections: Do we want to still offer baseline level 1.3 ? I see no reason to do so. It won't benefit iPod, it won't benefit standalone players, it won't benefit HandBrake. Anyone have any great ideas on ...

Just for clarity, GenII gui has no real additions over the legacy gui. Just a reorganization of where things are. UniGui however, would need a considerable test cycle as I still need to make some pretty decent mods to /macosx/Controller.mm As I said, it depends on what our timeframe is and what we ...

Well, as far as gui improvements for HB Mac. I see three possibilities: - Legacy Gui (m0k gui with the addition of the new ipod selection) - GenII Gui (the one in our binary test 0.7.1a5) - UniGui (the prototype I am working on) The names are just made up to help when referring to them internally. ...

I would think once the new site gets announced on the old site, we will be needing mods on those other forums. Maybe some of the power users from over at the m0k site would be willing. I know baggs over there is super active in the support area. He is especially helpful to new users and very patien...

we don't really need to worry about mingw since Cygwin seems to work fine, unless of course it can offer improved performance??? It's not about improved performance as much as it is lack of dependence on external 3rd party libraries. A mingw binary is "standalone" and doesn't require us t...

This may be premature (and if it is, feel free to tell me to be quiet ;), but should we consider automatic production of nightly builds from svn available to the beta testers? (For those who haven't been following along, we are slowly building a group of "real" beta testers, complete with ...

All forums are now postable. We are now "real". Let's hope there's no flood.

Rodney

Guys, It's become clear that the cat is now largely "out of the bag". From what I can tell, we have several different thrusts in flight: - GUI improvements - x264 stabilization - Windows port I'd like to have a roadmap to 0.7.2. Ideally, we should get a release out as soon as possible - we...

If they aren't needed anymore, and they are causing compliation problems, let's remove them from the trunk and Jamfile. I can't confirm or deny for certain, but I've seen at least two reports now that including them causes problems and leaving them out results in a clean compile (but we have no test...

Go easy on kenthorvath, guys. He's made his peace and is welcomed as a contributor here.

Rodney

Although I too agree that a name change isn't required, how about using a new icon? There has been some discussion about this - I believe general consensus was/is that we'll move to a new icon when we have a revamped/Cocoa (?) GUI in place. In fact, there has more recently been discussion about a &...

I knew better than to use those screenshots - but then, I didn't think anyone outside of development would actually find/look at the new site yet. =) They shall be replaced with the 'official' screenshots from titer's site immediately. I will also post a note on the blog letting the general public k...

On the bright side, now we know we can jump from r604 to r616 with a one-line diff to encx264.c... And brighter, you can package up the contrib gzip and FTP it up yourself for all developers to automatically take advantage of. Well, that, and change the web pointer to it in the contrib directory te...

If anything, I fear it would introduce more confusion, because it would give the impression that the fork is a totally different tool. I've given a good bit of thought to the matter, and never really been satisfied with either answer, but at this point, I see no reason to change the name. This isn't...