MediaFork 0.8.0BETA Public Release Date

[dynaflash]

Okee Dokee,
A couple of us on the irc channel have been discussing a *gasp* MediaFork 0.8.0beta Mac (Linux if ready) Public Release. After looking at where we are, and rhesters schedule for the next week. I think we should seriously entertain Sunday (today) as "GO TIME".

- At least on Mac, we should be able to fulfill expectations as a "beta" candidate

- Given the unknown traffic wise and server stress wise after we release, it is definitely best to do it when rhester is available. There is alot we can do ourselves, but server wise, only rhester can bail us out of certain scenarios. So, if we go before rhester is on hiatus, it should be quickly, to give us a day or two with him around. Otherwise, we should postpone until after he gets back.

- Frankly, at least mac wise, I feel there is some real benefit to getting some feedback from beta users to work out any bugs, etc.

So, with that in mind, if we can reach a consensus (or at least a healthy majority) on doing this, here is what I have for what would need to be done today:

1. Get update check working (not necessarily a show stopper, but very nice to get new versions out right from the get go).

2. At least one mod (other than rhester) assigned to each forum. Even if its temporary until rhesters return (as far as I know, he is the only one that can assign mods).

3. Upload the binary to our ftp site in the "release" directory.

4. Wait the prescribed 10 minutes for it to cache to offsite server.

5. Post a very fine piece of creative writing on the front page of our website announcing the release of MediaFork 0.8.0 beta (may also make sense to introduce the idea of logo submissions if that is the route we want to go here. Gives non coders a chance to contribute, but just an idea).

6. Put a helmet on and hide under something sturdy

Thats the way I see it (but, I have been wrong before), so please chime in and lets either go today or put it off until rhester gets back.

Thought/Ideas/Criticisms ?

[rhester]

I concur. Let's get it on.

sr55 - is a Windows beta by 9PM ET today (Sunday 2/11) feasible, with or without the GUI, just to get something out there for the public to play with?

Everyone - For any forum without at least three listed moderators, send me nominations by PM ASAP. You guys know where the talent lies (especially from m0k) better than I do.

Everyone - Does the CLI have an anamorphic switch? This is key.

Everyone - Have we fully eviscerated all references to HandBrake in terms of variables, code references, library/binary/source filenames, etc., etc.?

dynaflash - Sorry about the difficulties upping large PNGs. Any clue where the limit is? I'm sure it's a PHP limit, unfortunately, it could be in one of about a bazillion different places. I'll fix it for you - I want PNG screenies.

jbrjake - Care to nominate yourself to write the blog entry for the first public beta? I love what you're doing documenting PAR in the wiki, and the more I think about it, the more I think we ought to use the wiki for docs, because of the way it structures information and brings things together for you. Once we have a shell in place, I'll update our Docs page on the blog to point to respective sections...we'll basically use the blog as an "index page" to the real docs on the wiki. (Hint to all: This means use the wiki for all documentation fit for public consumption, unless someone would like to overrule me on this.)

Everyone - We need a file naming convention for the beta releases since they are sharing real-estate with the actual release folder. Ideally, it would be the same name as a public "real" release with -betaX tacked onto the end (e.g. foobar-macosx-0.8-beta1.zip). Before I offer up a suggestion on this, we need to understand whether the LATEST file puts any restrictions on filename. Anyone dug in and figured out how that works?

I just want to be clear, folks - to do this, today, is going to require an inhuman amount of effort on everyone's part and result in a slam on our blog, forum, and caching download server the likes of which we haven't seen since we were Dugg. We can handle it from an infrastructure standpoint, I've made sure of that, but expect a LOT of questions from confused users without documentation. sr55, you're going to get a [Censored] of activity...if your infrastructure falls over, you're welcome to put your Windows binary on our FTP in the release folder and link to it directly (see previous post on how) from your site to ease the pain.

Anything I missed? (I'm sure there is - I just got back from my daughter's first birthday party and I'm incredibly tired and brain-dead, but sufficiently motivated to write it up anyway. To put it simply, I'm stoked. Hell, I'm excited about playing around with PAR myself...so my question about its activation in the GUI was not a little self-serving as well.

If anyone wants off the train, speak now...

Rodney

[jbrjake]

As dynaflash well knows, I'm in full support of a public beta ASAP.

Everyone - Does the CLI have an anamorphic switch? This is key.

Yes, it's -p

Everyone - Have we fully eviscerated all references to HandBrake in terms of variables, code references, library/binary/source filenames, etc., etc.?

That is a qualified no. Variables, code references? No. We still have all the hb_ functions. Library/binary/source filenames? Yes. What's important, imo, is that it's all finished from the user point of view. It's only inside the source files that some names need to be changed.

I guess that brings another thing up though...do we have to do anything about the legal section, AUTHOR file, copyright, etc? That stuff all makes me uncomfortable.

From section 2 of the GPL included in the source directory:

a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.

jbrjake - Care to nominate yourself to write the blog entry for the first public beta?

Wow, sure. Thanks. =-)

I like the idea of doing all the user docs in the Wiki, btw. It seems to work well for Adium.

Everyone - We need a file naming convention for the beta releases since they are sharing real-estate with the actual release folder. <snip> Before I offer up a suggestion on this, we need to understand whether the LATEST file puts any restrictions on filename. Anyone dug in and figured out how that works?

I looked at the update code the other night...I believe they run off dates, like 20060211, not file names. I think that's the only content for the LATEST file: two lines, with two dates: the HB_BUILD dates of the latest stable and unstable releases.

But quite frankly, the more I think about it, I don't know if the update code should really be a priority for this first beta, if we don't know how it works entirely. I'd just like to get something out there. Show we're actually alive.

[jbrjake]

Here's what I've got so far for the blog entry announcing the beta. Anything in-between asterisks will be a link. I know I must be missing a bunch of stuff for features, bugs, fixes, etc, so help me out people...

Code: Select all

 
Old open source projects never die, they just get new names.

We're proud to announce the first public beta of MediaFork!

*Download MediaFork 0.8.0 Beta 1 for Mac OS X*

We're all very excited to get an application out there for the community to stress-test. It is a beta, and we can't guarantee any particular level of functionality or stability, but we think you'll enjoy it. Highlights include full 640*480 iPod video, *anamorphic encoding*, and newer, faster copies of x264 and ffmpeg.

Please *visit our forums* to report *bugs*, suggest *features*, ask *questions*, or join *development*. We are also available on *IRC*.

MediaFork is a GPL'd, multiplatform, multithreaded DVD to MPEG-4 ripper/converter, available for Mac OS X, Linux, and Windows. It is based on the source code to *HandBrake*, written by Eric Petit and Laurent Aimar.

New in this release:
• Updated libraries (meaning better quality, hopefully fewer bugs, and increased speeds)
• iPod 5.5G support
• Revamped graphical interface
• *Anamorphic encoding* with pixel aspect ratio
• Brighter color reproduction in QuickTime
• Lists disks by DVD name instead of by drive name
• Titles output movies based on the DVD name.
• 32Khz audio output
• Constant rate factor encoding with x264
• New preference item to turn deinterlacing on by default
• New preference item to select the default audio language

Fixed:
• Reading straight from a DVD (broken in our earlier alpha)

Broken:
• Encoding multiple audio tracks

For a complete list of changes, *visit our Trac timeline*.

Please stay tuned to this blog, especially graphic designers. We will soon be holding a contest to choose a new icon for MediaFork. Prizes will include: a sense of pride in a job well-done, artistic immortality, and a warm feeling of self-satisfaction.

[thanar]

Regarding the forthcoming bandwidth peak, I believe torrents could be a solution. You could also add a torrent engine inside the updater in order to automatically download a newer version (well, maybe sometime)!

[jbrjake]

Regarding the forthcoming bandwidth peak, I believe torrents could be a solution.

Yeah, um... I don't think we're going to fold a torrent library into MediaFork before 9PM eastern time tonight.

Benlake and I have talked about integrating Sparkle, though, at some point down the line. That's the system many Mac apps use to automate update checking and downloading.

[thanar]

I too believe incorporating a torrent library wouldn't be an easily feasible task. It was just an idea for the future, as is Sparkle I guess. However, if bandwidth issues are indeed serious, you could still share a single torrent file (which would require the user to manually add to a torrent client, of course) and the bandwidth would be easily split on the community. You know how it is... The MediaFork server would be much more lightweight, bandwidthwise, that way!

[s55]

@rhester - Windows port is ready when the main build is. A Patch file has been commited so it compiles on windows just fine. All i need is for everyone else to commit any changes and let me know when done so i can compile the latest rev.

I currently have rev284 compiled and it seems to work nicely. (Make Building is working to.)

As for the GUI, i can bundle it with it but i cannot update the GUI to support the new features / loss of x264b13 (I've still got a lot of work to do to rebuild the GUI as is.) so i don't think its wise to do this. I'd rahter just let a user choose wither to upgrade or not.

[latchkey]

I guess that brings another thing up though...do we have to do anything about the legal section, AUTHOR file, copyright, etc? That stuff all makes me uncomfortable.

(/IANAL)
Well you're keeping the license intact so there's no need to change the COPYING file, but you should certainly be added to the AUTHORS one.

You guys have forked the project and made significant changes to the code. Leaving titer as the only author is just inaccurate and wouldn't be fair to him or to you.

In the same vein, the copyright date should be changed to the release date to accurately reflect date of publication.
(/IANAL)

[thanar]

You guys have forked the project and made significant changes to the code. Leaving titer as the only author is just inaccurate and wouldn't be fair to him or to you.

I couldn't agree more. What's more, since MediaFork is a completelly revamped Project (or will be eventually), what's the point of leaving the same AUTHOR file? Anyway, I believe you wouldn't have to dig too deep in the GPL licence procedures to determine what's the right thing to do...

[latchkey]

well, you want to leave titer in AUTHORS because he still has substantial (in this case a majority) of code in the project. The same is true for any files where he was the last one to make changes. The goal is simply to accurately reflect who the authors are.

As far as the GPL goes, I think jbrjake brought up the right section. Since you've modified the files and are now going to be distributing them to others, the requirement is simply to make clear who made the modifications and when.

I'm with jbrjake in that I'd feel weird replacing "titer" with my name at the top of a file, but imagine what titer would feel looking at a library file that's been reworked and had all the hb_ functions renamed to mf_, but that still has his name and "modified on" date at the top.

latchkey
IANAL
Ian

[jbrjake]

(If I knew better how to use my mod powers, I'd split this GPL conversation off to another thread...)

On preview: pretty much what latchkey said. It's about giving titer the largest share of the credit, without creating a scenario where he sees source code credited to him that he didn't write or that doesn't meet his quality standards.

What's more, since MediaFork is a completelly revamped Project (or will be eventually), what's the point of leaving the same AUTHOR file?

Don't overestimate what we've done. Titer laid out a building, raised its walls, gave it a roof, and wired in plumbing, electricity, and central air. What we've been doing is repainting the exterior (new name), rearranging some pictures hanging on the wall (revamped GUI), plugging in a few new kitchen appliances (iPod 5.5G, anamorphic), and caulking some cracks incurred in a recent renovation (reverting to libmp4 to avoid the memory leak). In many cases, these changes were inspired by blueprints the architect left behind (titer's Trac/svn, where we got the correct rate control code for x264 as well as some other goodies).

What I mean when I say the legal issues make me feel uncomfortable, is this: Our code definitely has changed, but as the over-arching structure remains the same, how do we honor and credit titer for that key task, while making clear to users that this fork is unauthorized and minor changes have been made? More importantly, how do we codify that in a GPL and machine-readable form?

I'd be happy to avoid all this for the beta, though, and just release something for people to use. Worry about legal niceties for the first non-beta version.

[latchkey]

What I mean when I say the legal issues make me feel uncomfortable, is this: Our code definitely has changed, but as the over-arching structure remains the same, how do we honor and credit titer for that key task, while making clear to users that this fork is unauthorized and minor changes have been made? More importantly, how do we codify that in a GPL and machine-readable form?

I'd be happy to avoid all this for the beta, though, and just release something for people to use. Worry about legal niceties for the first non-beta version.

Well, once you publish modified files you become distributers and the GPL requirements are supposed to kick in. As to whether that's going to matter much at this point, yeah, I don't imagine it's going to be a huge issue.

For what it's worth, I think the machine-readable and GPL form is that you keep the per-file notices accurate and append yourselves, plus a note listing the origins of mediafork and your gratitude to titer in the AUTHORS file.

IANAL
latchkey

[rhester]

Everyone - Have we fully eviscerated all references to HandBrake in terms of variables, code references, library/binary/source filenames, etc., etc.?

That is a qualified no. Variables, code references? No. We still have all the hb_ functions. Library/binary/source filenames? Yes. What's important, imo, is that it's all finished from the user point of view. It's only inside the source files that some names need to be changed.

I'm fine with that for a beta - but I'd really like to see the fork completed inside and out for the final public release.

I guess that brings another thing up though...do we have to do anything about the legal section, AUTHOR file, copyright, etc? That stuff all makes me uncomfortable.

I think this was fairly well covered in later posts - in short, I think the AUTHOR and copyright file should be updated to recognize titer and HandBrake as the originators and reflect the fork.

However, there's more - a readme, whatsnew, todo, etc. that needs to be updated.

Everyone - We need a file naming convention for the beta releases since they are sharing real-estate with the actual release folder. <snip> Before I offer up a suggestion on this, we need to understand whether the LATEST file puts any restrictions on filename. Anyone dug in and figured out how that works?

I looked at the update code the other night...I believe they run off dates, like 20060211, not file names. I think that's the only content for the LATEST file: two lines, with two dates: the HB_BUILD dates of the latest stable and unstable releases.

OK - so what should the file name standard be? I'd like to propose:

MediaFork-<version>-<platform>-<state>.ext

i.e. MediaFork-0.8.0-win32-beta1.zip or MediaFork-0.8.0-macosx_universal-final.dmg, etc.

But quite frankly, the more I think about it, I don't know if the update code should really be a priority for this first beta, if we don't know how it works entirely. I'd just like to get something out there. Show we're actually alive.

I concur. Let's forego the update code until at least beta 2.

Rodney

[rhester]

The only concern I have about the blog entry is that it is very Mac-targeted. I think somewhere in there we ought to sneak in a line mentioning off-handedly that we're also going to beta Windows and Linux. *laughs*

On a more serious note, assuming jbrjake will be absent from the launch, I'll update his work a bit for the blog and do the post myself. What time of day are we targeting? How close are we to ready? It seems most of the outstanding stuff is documentation inside the distribution (README, TODO, Copyright, AUTHORS, etc.)

Rodney

[rhester]

Regarding the forthcoming bandwidth peak, I believe torrents could be a solution. You could also add a torrent engine inside the updater in order to automatically download a newer version (well, maybe sometime)!

Our binary downloads are now cached offsite - it won't be an issue, and it certainly won't need such an exotic solution.

Rodney

[rhester]

@rhester - Windows port is ready when the main build is. A Patch file has been commited so it compiles on windows just fine. All i need is for everyone else to commit any changes and let me know when done so i can compile the latest rev.

I currently have rev284 compiled and it seems to work nicely. (Make Building is working to.)

As for the GUI, i can bundle it with it but i cannot update the GUI to support the new features / loss of x264b13 (I've still got a lot of work to do to rebuild the GUI as is.) so i don't think its wise to do this. I'd rahter just let a user choose wither to upgrade or not.

How do you want to handle the binary distribution, then - we'll host the CLI version and you host the GUI?

Rodney

[rhester]

What I mean when I say the legal issues make me feel uncomfortable, is this: Our code definitely has changed, but as the over-arching structure remains the same, how do we honor and credit titer for that key task, while making clear to users that this fork is unauthorized and minor changes have been made? More importantly, how do we codify that in a GPL and machine-readable form?

I'd be happy to avoid all this for the beta, though, and just release something for people to use. Worry about legal niceties for the first non-beta version.

Well, once you publish modified files you become distributers and the GPL requirements are supposed to kick in. As to whether that's going to matter much at this point, yeah, I don't imagine it's going to be a huge issue.

For what it's worth, I think the machine-readable and GPL form is that you keep the per-file notices accurate and append yourselves, plus a note listing the origins of mediafork and your gratitude to titer in the AUTHORS file.

We can't release a public beta without being in compliance with GPL. If that means we have to slip the launch, that's what it means, though it doesn't seem overwhelming to update the text files accordingly. They don't have to be perfect, they just have to be accurate.

Rodney

[latchkey]

It seems most of the outstanding stuff is documentation inside the distribution (README, TODO, Copyright, AUTHORS, etc.)

Are there plans to build any sort of user documentation, or is this on hold for the non-beta days?

[rhester]

It seems most of the outstanding stuff is documentation inside the distribution (README, TODO, Copyright, AUTHORS, etc.)

Are there plans to build any sort of user documentation, or is this on hold for the non-beta days?

It's WIP, but won't be ready for the first few betas. We're counting on previously-experienced users to provide the majority of our initial feedback, but there has been work to document some of the more esoteric but exciting new features.

To the best of my knowledge, titer did no actual documentation but relied on third-party user guides linked to from his site. I hope we do slightly better than that, though we will still welcome and encourage third-party guides.

Rodney

[dynaflash]

Guess this topic is no longer relevant

[ravnwolf]

If you're curious, since Feb 1, the server where the downloads are cached offsite has seen 177GB of traffic, 12,528 unique hits and 17,315 total hits. I hope everyone has seen pretty good download speeds. I've monitored the network and haven't seen any major hiccups along the way.

-ravnwolf

[jbrjake]

If you're curious, since Feb 1, the server where the downloads are cached offsite has seen 177GB of traffic, 12,528 unique hits and 17,315 total hits. I hope everyone has seen pretty good download speeds. I've monitored the network and haven't seen any major hiccups along the way.

Thank you so much, ravnwolf. If we were handling all this on rhester's server we never would have made it. Hell, for a few days the website was choking just sending out the redirects...

Anyway, as it has now been exactly a week since release, here's a download total:

31,250

That includes all 16,226 redirect to ravnwolf's download site for the beta (total hits, not unique, and including all three platforms but not the raw source code: 12,279 Mac, 3,366 Win, and 356 Linux), the 225 before the redirect counter started, and the 15,024 downloads the MacUpdate mirror handled.

=)