X●, a new x264 GUI for Mac

[RadicalEd]

Hi all,

As us Mac users know, there are no insanely great x264 GUIs available to us. Handbrake comes the closest, but even that doesn't expose nearly as many x264 configuration options as, say, MeGUI, or the x264 commandline app.

Enter X●. X● will be the first fully-featured x264 GUI for Mac. We're aiming to expose every possible x264 configuration, while still keeping a dead-simple Mac-like UI. We intend to follow development right alongside x264, so as to never be out of date.

The app is currently in early alpha - libavcodec input and x264 encoding work, but MP4 muxing does not, and there are many GUI fixes needed before beta or even alpha status is reached.

Check out the website at http://xdot.command-q.org, follow development on the ⌘-Q Blog (http://blog.command-q.org/?cat=18), read more at the Qiki (http://wiki.command-q.org/index.php?title=Xdot), or discuss X● on our forums (http://forums.command-q.org/viewforum.php?f=26).

I'll definitely keep you guys posted on development updates. Hopefully we'll be on our way to beta by the new year!

[Guest]

http://xdot.command-q.org Dead link.

[Atak_Snajpera]

http://xdot.command-q.org
it works here.

BTW. You have chosen very wEiRd name (X●). It's like showing "apple" instead of just writing -> apple.

[Guest]

The link was dead when I posted.

It appears RadicalEd is at it again. The application cannot be downloaded but he's already touting it as "The premier MPEG-4 AVC encoder for Mac".

[RadicalEd]

It appears RadicalEd is at it again. The application cannot be downloaded but he's already touting it as "The premier MPEG-4 AVC encoder for Mac".

Please keep this thread positive. Unlike the project you're referencing, there is actual working code here.

[Guest]

How do you justify touting vaporware as "the premiere encoder"? And why announce something that no-one can obtain?

[Dark Shikari]

How do you justify touting vaporware as "the premiere encoder"? And why announce something that no-one can obtain?The site does seem to be rather heavy on the style vs substance ratio...

[Atak_Snajpera]

We're aiming to expose every possible x264 configuration
Who is 'We'? How many people is involved in this project? I didn't know that simple GUI requires more than one programmer. Look at me , buzzqw or morphinapg (forgive me if I didn't mention all people :)

BTW. Link is dead now.

[RadicalEd]

Who is 'We'?

BTW. Link is dead now.

Command-Q.org, which is mostly just me ;)

The link should work fine. Try http://xdot.command-q.org/index.html if just the subdomain doesn't work or if nothing else, http://www.command-q.org/apps/xdot/index.html

[Atak_Snajpera]

Command-Q.org, which is mostly just me
So what's the point of writing 'We' ???? I'm getting very suspicious when I hear magic 'We (the company)'

Try http://xdot.command-q.org/Xdot.html
This link is useless if we can not download your GUI.

[RadicalEd]

This link is useless if we can not download your GUI.
I'm sorry, I really am. I know a lot of people are interested in this project, and I thought I'd give the Doom9 community some advance-notice on its existence. I'll refrain from posting about products which aren't in at least testing phase in the future.

[Adub]

The link works fine here (the first one). It does look promising though. However, I don't even own a mac. But I do know someone who might be interested. Please release a proper build soon, instead of just teasing us.

[RunningSkittle]

sloppy html, by the way

[RadicalEd]

sloppy html, by the way

Not even going to lie, it's iWeb.

[Atak_Snajpera]

I know a lot of people are interested in this project, and I thought I'd give the Doom9 community some advance-notice on its existence. I'll refrain from posting about products which aren't in at least testing phase in the future.
We are big boys here at Doom9 and we like facts not phantoms. At least your site will be indexed by Google :)

[RunningSkittle]

are your screenshots from a working gui? or conceptual renders?

[RadicalEd]

are your screenshots from a working gui? or conceptual renders?

It's all real except for the preview window, which should be a synch to implement.

[MaXiMuS]

BTW. You have chosen very wEiRd name (X●). It's like showing "apple" instead of just writing -> apple.

weird it is :) maybe u could change name to XDOT264 . please post alpha/beta version so we can test it. can not wait...

[RadicalEd]

weird it is :) maybe u could change name to XDOT264 . please post alpha/beta version so we can test it. can not wait...

I'd totally give an alpha because as far as I can tell, MP4 writing is now complete, but...

x264_encoder_encode is now giving me a segfault :/

Edit: Just kidding, I forgot a malloc. It looks like it's encoding now. Let me test it out a bit and then maybe I'll post a binary later tonight :D

[Emess]

I'd totally give an alpha because as far as I can tell, MP4 writing is now complete, but...
So that GPAC docu I gave you (or someone else on your project) helped? Excellent. I can't help but notice the daily builds page is about 2 months out of date though... And contains no actual pre-alpha source for people to look at either.

E~

[RadicalEd]

So that GPAC docu I gave you (or someone else on your project) helped? Excellent.

Nah, using libmp4v2.

I can't help but notice the daily builds page is about 2 months out of date though...
That's actually not accurate. I recently rebuilt the page, and it has old dates. They are slightly more recent. I really do need to run the script again... I'll probably do that overnight tonight.

And contains no actual pre-alpha source for people to look at either.

I'll try to get some up tonight. Like I said, it's encoding now, so that's a step in the right direction.

[RadicalEd]

Alright, since you guys have been clamoring for it, here it is: some pre-pre-pre alpha code. It reads from libavformat and libavcodec and encodes to x264, and... not much else. An MP4 file is generated by libmp4v2, but the data doesn't get written to it for some reason. The GUI configuration is currently completely broken, though I have an idea of how to fix that. Oh, and there's no audio. And the presets don't set anything yet. And the profile/level doesn't impose any restrictions yet. And there's no live preview.

But you wanted it, so here it is: http://xdot.command-q.org/xdot_pre_alpha.zip
Source only, since there's really no point in distributing a binary at this early stage.

You can watch the encoding progress from within the GDB console in XCode just to see that it works. It's currently hardcoded to 640x480 and 1000 kbps.

[RadicalEd]

Just so you guys know, I'm currently fixing all the GUI parts so they should work as expected, unlike the code above, where none of the GUI worked. I've also enabled selecting of output format, including: libmp4v2 MP4, GPAC MP4, LAVF MP4, and Matroska. Currently libmp4v2 is the only one that doesn't segfault (lavf may work, I haven't gotten to implement it yet). mp4v2 still writes a 4kb file and nothing else. Hopefully this will be solved shortly.

I'll post some more code when I'm done mapping all the UI stuff to the x264 preferences.

[Atak_Snajpera]

I'll post some more code when I'm done mapping all the UI stuff to the x264 preferences.
It will be better if upload finished product.

[RadicalEd]

It will be better if upload finished product.

Well, everyone wanted some alpha code for whatever reason, so I'm complying with that request.

[Ajax_Undone]

The reason for the requests was your original post. If it had not existed there would have been no reason for you to even post what code you have.

That is why its always a good idea to fallow the ((Programmers profile)). :eek:

1. Make a project map include all of what you want to accomplish with your program.
2. Make a proof of concept ie a working alpha.
3. keep going till you feal its ready for beta testing.
4. Then post said project in the appropriate forum.
5. Continue development until time when either its no longer needed or until you get tired of making it.:p

P.S. Just the way I see it anyway... There is no programmers profile. BTW:)

[RadicalEd]

Tonight I'm releasing an official pre-alpha of Xdot, and calling out in desperation for any developers familiar with GPAC, LAVF, or MP4v2 to help with the MP4 muxing code. MP4v2 is the most mature of the three and *almost* works, but writes a borked file. The error report from mplayer is as follows:
[h264 @ 0x791ed0]AVC: nal size -1707372823
[h264 @ 0x791ed0]no frame!


If anyone out there can help with getting MP4 muxing in any of these muxers working correctly, please contact me here or at tab@command-q.org (mailto:tab@command-q.org).

That said, what's in this pre-alpha? Here's what works:
-Reading from LAVF/LAVC
-Encoding to x264
-All GUI configuration (save for minor glitches)
-Presets (saving and loading might be wonky still)
-Image scaling using swscale might work, haven't tested yet, but it should
-Added lots of Mac-specific things like badging, Growl, Sparkle updating, etc

What doesn't:
-MP4 writing is borked as described above
-Multipass
-Dragging multiple videos at once
-Progress reporting needs to be threaded, right now the UI only updates after the encode is completed. Progress can be watched through Console.app, however.
-Preview/review. There is preliminary code to support this, but it's commented out in this release

Left out:
-Audio, I'm worried about getting video fully working before delving into this

The full changelog is here (http://xdot.command-q.org/changelog.txt).

That said, hopefully this will catch the eye of some developer more familiar with MP4 muxing than I am, and have fun testing!

Xdot (http://xdot.command-q.org/Xdot.dmg.zip) - Source (http://xdot.command-q.org/Xdot_src.zip).

Edit: Note, this build requires an existing copy of libmp4v2 and libgpac, because for some reason I can't build against these libs statically. If you don't have them on your system, I put up some installer packages inside the Xdot DMG under "External Libs". Just run this before you launch X●, and you should be good to go!

Edit 2: Big shout out to Yuvi! He's helping with the muxing AND just donated some code that will take care of a lot of the audio stuff!

[RadicalEd]

At long last, X● is now capable of encoding a fully-functioning video file in the MP4 or MKV format! This is made possible by a recent change to the project: there is now the option to do encoding via libx264, as was the case before, or, now, to use x264’s binary directly. This option can be set via the main menu->Preferences. There are a few drawbacks to using x264 directly, among them being:
- Raw YUV/YUV4MPEG input only
- No encoding preview
There are, of course, a few things that don’t work yet, those being:
- Progress reporting
- Multipass
But these just deal with more in-depth use of NSTask, so eventually they should be supported with the x264 binary. Of course, the benefits are that it now encodes and writes a file, which is still broken with the libraries. I’ve included an updated version of x264.pkg from ⌘-Q Builds if you don’t already have an x264 binary on your machine.
So, without further ado, here it is: http://xdot.command-q.org/Xdot.dmg.zip
Of course, source is always at http://xdot.command-q.org/Xdot_src.zip
And the full changelog is here (http://xdot.command-q.org/changelog.txt)

[Ajax_Undone]

OK so our new vaporware comes to fruition... Congrats :):thanks:

[RadicalEd]

OK so our new vaporware comes to fruition... Congrats

Thanks :p
It's still pre-alpha until I fix MP4 muxing using the libraries.

[RadicalEd]

Some updates today (too late to be considered part of pre-alpha 3 IMO):
Added framerate support for binary encoding
Added encoding range support
Added zones when encoding binary, library needs some fixes. They don't show up in the table yet, but they're there.
Size calculation

Updates from yesterday that I snuck into pre-alpha 3:
Added BWToolKit preference tabs
[FIXME] Don't write pass log file in current directory
Add error reporting for binary x264
Make menus sensible
Enable opening via menu instead of DnD
Enable SAR for binary
Fixed dragging multiple videos
Fixed badge displaying 0 instead of 1

Yuvi, where'd you go? :<

[RadicalEd]

Two new things: Xdot now has a brand new website that's more representative of its growing featureset: http://xdot.command-q.org.

Also, MP4 metadata is now supported with libmp4v2! All fields supported by mp4v2 are supported by Xdot. They don't display in the table view yet, but they are muxed in. Of course, this only works when using libmp4v2, which still doesn't write a proper file, so it's somewhat useless at the moment :(

[[P]ako]

Do you intend to provide a binary for PPC-based systems and/or older versions of OS X?

[RadicalEd]

ako;1239522']Do you intend to provide a binary for PPC-based systems and/or older versions of OS X?

Unfortunately I haven't been able to compile the libraries I'm using for PPC systems, so as it stands now I can't provide a universal binary. As for pre-10.5 systems, parts of Xdot use features unique to 10.5, so again, probably not.

[[P]ako]

Unfortunately I haven't been able to compile the libraries I'm using for PPC systems, so as it stands now I can't provide a universal binary. As for pre-10.5 systems, parts of Xdot use features unique to 10.5, so again, probably not.

Fair enough.

[Atak_Snajpera]

It would be better if focused on programming instead of new website which promotes unfinished product! It's like car seller showing unfinished prototype of new car! GET TO WORK MAN!

[RadicalEd]

It would be better if focused on programming instead of new website which promotes unfinished product! It's like car seller showing unfinished prototype of new car! GET TO WORK MAN!
Since yesterday, I've done just that ;) Xdot pre-alpha 4 is now out and live on the website! Big changes since pre-alpha 3:
- Various fixes to binary encoding
- Encoding range support
- Zone support
- Size calculation (finally!)
- Preset saving/loading/editing
- All tables now work as expected, and most are editable directly.
- Ranges and floats should now work in text boxes, our range control was majorly borked (though for now there is no range checking, so don’t enter bogus values!)
- Full MP4v2 metadata support. X● now supports every meta tag that libmp4v2 can mux, and they are all correctly written!

Get it at the new website at xdot.command-q.org (http://xdot.command-q.org)!

[RadicalEd]

I've worked all night to bring you all a surprise beta of X●! But first, I should explain some things.

This isn't the beta I was planning – that is, the libraries are still as broken as they were before. However, X● is now perfectly functional using the binaries, and as such, I've repurposed our 1.0 release to require feature-completion for binary encoding, relegating the library encoding to a future version.

That said, what's included in our biggest update yet? The full changelog is, as always, available url=http://xdot.command-q.org/changelog.txt]here[/url], but how about a summary?

First, audio encoding using Core Audio. X● can now encode your audio to AAC. Second, universal input for binary mode using MPlayer. And a bunch more, including:
- Multipass
- MP4 tags for binary encoding
- Subtitle muxing
- Image scaling using FFMPEG with SWScaler
- Rudimentary progress reporting

Furthermore, the support packages have been consolidated into one package with everything you need to run X●, so you won't have to go through three different installations.

There are tons of other minor tweaks and fixes, but those are the big ones.

So please, be sure to hit up the website (http://xdot.command-q.org) and check it out!

-Mike

Now to get an hour of sleep before class...

[RadicalEd]

Beta 2 is up.

Features over beta 1:
- Binary meta tag support
- Enable/disable audio or video (audio only does not work currently)
- New open panel with external audio and subtitle support
- Autodetection of subtitle files in the same directory as the video
- We now link statically as much as possible, so there shouldn't be any more problems with missing dylibs.
- Several segfault, overflow, range, GUI, and other tweaks and fixes

FIFO support is planned for beta 3, so no more huge intermediate files.

[RadicalEd]

Beta 3.1 is out, and it makes all the other betas look like alphas. From the blog announcement (http://blog.command-q.org/?p=194):
Here are some of the big changes:
- FIFO support for video - no more huge intermediate files! (Audio is still dumped, FFMPEG doesn’t like FIFO)
- Multiple audio and subtitle detection
- Closed panels are no longer autoreleased - this should fix 90% of crashes
- Panels are now hidden when inactive, only the progress window is shown during encoding, which brings me to:
- Real, live progress reporting! (Finally!)
- Enhanced “Open File” panel that allows adding and removing of external and internal streams
- No more library dependencies, unfortunately we haven’t yet been able to build the support binaries completely statically, so we still have to install some libs, but…
- Binaries are now installed to /opt/local/bin/xdot, so as not to conflict with MacPorts or your own custom builds
And some of the more minor tweaks:
- Fixed the responder chain - tabbing now works in all settings textfields
- Add a button to configure presets rather than having to choose “custom” every time
- Bigger drop zone
- Update meta tags to current MP4v2 tags
- Preference to select the volume used to dump temporary audio
- Make sure there is enough disk space to dump audio
There are a few caveats, as always:
- Scaling is broken for now, as FFMPEG doesn’t like FIFO

http://xdot.command-q.org

[Ajax_Undone]

Nice you make my Mac happy this is an awesome app.. Keep up the good work.:D:thanks:

[RadicalEd]

3.2 is out with the following fixes:
- Re-enable MKV outformat
- Sanitize total frame calculation - fixes MKV progress reporting among other things
Edit: 3.3 is also now out with the following fixes:
- Fix selection of alternate temp volumes
- Correctly detect main volume so we don't crash if there is no Macintosh HD

[MacLover]

I am currently downloading it, and from what I have read this should be a lot better than HandBrake which although great lacks quality wise sometimes :(

Edit: It keeps giving me the beach ball, IDK how to convert AC3/AAC to WAV so when I click yes to it saying it will encode to PCM first it just freezes :(

[refulgentis]

I am currently downloading it, and from what I have read this should be a lot better than HandBrake which although great lacks quality wise sometimes :(

Edit: It keeps giving me the beach ball, IDK how to convert AC3/AAC to WAV so when I click yes to it saying it will encode to PCM first it just freezes :(
Why would you use software that was barely out of alpha that seemingly was abandoned 8 weeks ago?

Where in the hell have you read that this should be better than HandBrake?

HandBrake has much more development time into it, and *uses the exact same* encoder/decoder libraries for your purposes (mkv -> mp4). In fact, HandBrake uses newer ones if you're willing to compile development code, which is near brain dead easy. Also, HandBrake doesn't have to rely on binaries, it directly addresses the libraries.

You're *much* better off figuring out how to change HandBrake/x264's options to get better quality than hoping that software that has every indication of being not even close to ready, that has probably not 1% of the code-hours invested in it, that uses _the *EXACT* same decoders and encoders_ as HandBrake, will magically give you increased quality.

[RadicalEd]

I am currently downloading it, and from what I have read this should be a lot better than HandBrake which although great lacks quality wise sometimes :(

Edit: It keeps giving me the beach ball, IDK how to convert AC3/AAC to WAV so when I click yes to it saying it will encode to PCM first it just freezes :(

Oh wow, new posts. I stopped checking this thread because it sort of died off.
refulgentis is correct, there shouldn't be a quality difference between X• and Handbrake, unless you are setting options that Handbrake does not expose. As for the bugginess, I'd suggest holding off until the next beta, which is vastly, vastly better than the current one in speed and features, and it's pretty much complete save for a few things.

that seemingly was abandoned 8 weeks ago?
Anyone following the development blog would know that's not the case.
http://blog.command-q.org/?cat=18

[Ankle Bond]

Why would you use software that was barely out of alpha that seemingly was abandoned 8 weeks ago?

I am thinking this app will never materialize. Granted, terms such as 'alpha' quality are subjective but still it is hard to grant an alpha-badge to x-dot's last release, let alone a beta-badge :eek:

Anyone following the development blog would know that's not the case.

The development blog is unconvincing. X-dot is pre-alpha software (in my opinion of course). Looks like it will go nowhere just like Celluloid.

[RadicalEd]

it is hard to grant an alpha-badge to x-dot's last release, let alone a beta-badge :eek:
What makes you say that, exactly?

Looks like it will go nowhere just like Celluloid.
Pardon me, but Celluloid went nowhere because AviSynth 3 stagnated and died, which was hardly my fault.

[Ankle Bond]

What makes you say that, exactly?
Experience :cool:

Pardon me, but Celluloid went nowhere because AviSynth 3 stagnated and died, which was hardly my fault.
I found this in Celluloid announcement:
Within the next few days, I'm going to begin development on an OS X-native, Cocoa-based NLE written on top of and using AVISynth as a backend. It'll be no momentous task, as all the hard work in getting an editing and rendering engine has already been done by the AVS team.
It's interesting you're so quick to blame another project as the reason why Celluloid failed. After reading the relevant thread it's pretty clear what happened; after announcing the project you ran into obstacles and instead of engineering around them, you chose to wait for a long-shot, for another project/developer to develop AviSynth3 . When you announced Celluloid it seems pretty clear it was going to be built it on top of the already existing AviSynth. So what happened to that? My conclusion is you bit off more than you could chew; your product was not well planned; and blaming other projects for that is in really, really bad taste. This might be a hard pill for you to swallow, but a necessary one I think.

Cheers :)

[RadicalEd]

When you announced Celluloid it seems pretty clear it was going to be built it on top of the already existing AviSynth. So what happened to that? My conclusion is you bit off more than you could chew; your product was not well planned; and blaming other projects for that is in really, really bad taste. This might be a hard pill for you to swallow, but a necessary one I think.
What in the blazes are you talking about? When Celluloid was announced AviSynth 3 was still being actively developed, though it didn't really work. Then the sole developer stopped working on it, which left Celluloid dead in the water since it was a _GUI_ for AviSynth.
This stuff isn't hard to understand.

Experience
Until you file an actual bug report your anecdotal bashing is meaningless.

[Ankle Bond]

When Celluloid was announced AviSynth 3 was still being actively developed, though it didn't really work. Then the sole developer stopped working on it, which left Celluloid dead in the water since it was a _GUI_ for AviSynth.
Your words:

It'll be no momentous task, as all the hard work in getting an editing and rendering engine has already been done by the AVS team.
This suggests to any sane reader your project has what it needs from the engine. Or maybe you exaggerate?

[Guest]

@Ankle Bond

Your posts are uninformed and inflammatory. I followed the Celluloid thread from the beginning. It was always relying on Avisynth 3.

You've made your point. Why don't you let it go?

[RadicalEd]

This suggests to any sane reader your project has what it needs from the engine. Or maybe you exaggerate?
At the time it appeared that AviSynth 3 was going to materialize, as Caro and Bidoche were still active on it, so, yes, I considered the engine to be a sure thing. I couldn't have foreseen that Bidoche would get the melancholy, nobody could. It's unfortunate, but that's how things panned out. What can you do. Anyway, this is a silly argument and we ought to drop it as neuron2 suggests.

[RadicalEd]

Small update inspired by some unrelated code I had been working on: X•'s UI is now threaded, meaning it no longer locks up during encode. This opens up the possibility of canceling/pausing encodes, adding to the queue while an encode is running, and editing the settings of queued encodes, which is pretty cool and something I've wanted to implement for awhile now.

A few other things about the next release: It should have a full progress table that shows all jobs rather than just the current encode, and the code will be much, much cleaner, abstracting away the x264 functions from the interface such that swapping the libraries for the binaries in a future version will be trivial. I may put off the code reworking until beta++ just due to the amount of work, but it will be in there soon.

[Edit]Pause implemented, cancel et al probably when I stop being asleep.

[vzmr82]

I was looking after this project since it was first announced. I downloaded several of the beta versions, but I didn't do anything useful with it. Some of the encodings never finished...

And just looking at the blog, and the news update about the project, I too was assuming it was dead... it seams not, lets see. I hope it doesn't deserve the same kind of daily updates as http://builds.command-q.org/...

[RadicalEd]

I hope it doesn't deserve the same kind of daily updates as http://builds.command-q.org/...

Haha, yeah, the thing with builds is that I never worked out all the kinks in the script, so I never got to add it to cron, plus I wasn't sure anyone was actually using it. I have some ideas to bring it back to life including Sparkle integration and universal binaries, so it won't stay dead forever.

So many projects, so little time. Good thing it's almost Summer break.

[RadicalEd]

For those of you left wanting in the recent dry-spell of news at Command-Q, I've just made a post on the blog that will catch your attention. It contains the roadmap for app development for the rest of the year and offers some insight into how much is really going on behind the scenes, and how busy we've* really been. It also debuts some previously-unmentioned features of X•'s coming 1.0 release. The most relevant part to you guys would be:
The next thing on the list is something terribly overdue, and that is the final release version of X•. But your wait has not been in vain. Some of the features of X• 1.0 include live capture and editing, YouTube upload, DVD input, filtering support, true job control with pause/resume/cancel and a full job list, and many other improvements here and there including massive speed improvements. The other big change is that in order to facilitate cleaner code and easy swapping of encoding backends (for when X• eventually migrates from binary encoding to library encoding), X•’s encoding engine is being abstracted out into a versatile and backend-independent framework which will handle all of the encoder controls, called EnCore. This will be functionally similar to – but not excluding – libhandbrake, as libhandbrake could very easily be implemented as yet another encoding backend in EnCore. Moving the encode handling out of the main X• code tree will allow us to develop the interface agnostic of the actual encoding method used. But wait: EnCore is not just for H.264 - we’ll be introducing X•’s brand new cousin, !DVD, shortly after X•’s release.
So sorry again for the lack of updates, just know that the project is far from dead, and in fact becoming better by the day.

Full post here (http://blog.command-q.org/?p=238)

Edit: Oh, and for the skeptics: I'm not blowing smoke with this feature list. All of the mentioned enhancements for 1.0 are implemented at various levels of completion, and those that aren't already fully implemented are mostly just some busywork away from being finished. Later in the post I mention a demo video coming up; I just want to implement the job table view before making this. Most of those features will be present in the demo.

Edit 2:*And I do mean "we" this time (see: earlier in this thread). Command-Q has expanded since December. We have a few new developers working with us and a growing group of people working together on a top-secret project that is briefly mentioned in the blog post.

[Ankle Bond]

status update from http://command-q.org . bold added for emphasis.

Early this morning (5/17/09), command-q.org was hacked. While the attack was a relatively white-hat attempt to expose the insecurities of the previous pub.command-q.org system, and no specific data was lost, multiple user accounts on the forum and so on were also compromised. For everyone's own good, the .org is going to be down for a bit while we sort all this out and discover what data was and was not compromised. To the affected users, you'll be hearing from us shortly. Hopefully the site will be back soon, but I really just don't even know right now. This whole thing was pretty ***** lame.

Update (8:07 AM): The good news is that unless the whitehat in question is lying (and I don't believe he is), no user accounts were compromised except for my own throwaway site passwords. This means there shouldn't be any concern about stolen passwords from any of the site databases (apparently these are all properly hashed and salted anyway, thumbs up for safe software). Apparently the only one with anything to worry about is me. So don't sweat it too much.

Still determining how to respond to this whole situation, updates will be posted to this page.

Update (10:37 AM): Things are pretty much back to normal. The parts of the site that are database driven (blog, chan, forums that nobody uses) will be offline for a bit, but it's not a big deal.

Should clarify slightly, what occurred was not technically a hack or really even an exploit, it was simply an abuse of privileges given to pub users; namely the ability to upload and execute PHP files. This is mostly a failing of my host and it exemplifies a problem that has existed since pub's inception: the very weak controls offered over other FTP users in the system. With the recent site overhaul I had planned to address this, but I suppose I was a bit too slow. That said, all that occurred was that one ambitious pub user decided to abuse his PHP execution rights in order to gain access to the main site directory, snooping a few relatively useless database passwords and inserting a worthless comment into the old index.html. That's nice of him to not try to wreck havoc, but nothing dangerous really could have been done even if he had gone on a table-dropping and file-rm'ing spree. So yeah, that's what happened.

Update (12:15 PM): Site's going to be down in a big way for at least the next 24 hours or so.

5/19: Due to multiple extenuating circumstances, including, but not limited to, the above, command-q.org and all projects therein are suspended indefinitely.
- Michael

[MaXiMuS]

command-q.org and all projects therein are suspended indefinitely.

that is upseting ... damn ... :mad: :scared: :(

[Ajax_Undone]

@RadicalEd

So ed does this mean that your project is dead as well. Being as it is hosted at said website with said issues...

[MaXiMuS]

http://command-q.org/

is UP :)

with text "Don`t quit us just yet..."

[Ajax_Undone]

Yeah but it still seems ominous.

Besides no word from Ed on this new development here in the forums...

[RadicalEd]

'Oi all.

Noticed referrers coming from this thread in my access logs on the site. Since my email notifications on Doom9 have been broken for over a year, I tend to just check in occasionally, and normally this thread is dead when I do. So my apologies for not staying present. If some admin cares to look into the problem, I'd really appreciate it.

Now, as for what is going on with the site...

It's a pretty complicated situation, as you might've gleaned from the previous placeholder text. At the time when the site got 'sploited, multiple Bad Things™ were happening in the general vicinity of my Internets and I decided it would be best to pull the plug for awhile. Admittedly, the text "suspended indefinitely" is slightly melodramatic, because I didn't mean to imply "shut down forever", but rather "not going to be worked on until things get straightened out with the site and otherwise".

The current placeholder image, markedly less dramatic and depressing than the prior placeholder text (Macbot you are such a cute firework :3), is something I've been wanting to do for a few days now. It will likely stay while the site undergoes reconstruction. If anyone had accessed the front page of the site in the weeks prior to the exploit, they will have noticed that multiple areas of the site were going down for renovations. I'll probably leave the site the way it is while I rebuild each aspect.

I imagine the blog will be back up relatively soon, and I can go into greater depth about the situation there. Though for now this is really all there is to know. The reason there hasn't really been any news on the project front is merely that I've been involved in some freelance projects unrelated to command-q and those have been consuming most of my time (mainly because I'm getting paid for them :p ), and also because I have been taking a step back and learning the ins and outs of Cocoa and Objective-C development much more thoroughly (iTunes U++). So really, the next steps for the projects that you guys would be interested in mostly consist of rewriting and refining, which isn't so interesting on the face of things. Everything that was said in the roadmap blog post still pretty much holds true, however.

To make a long story short, the .org is not dead. The projects are quite healthy (four of the seven things in the placeholder image exist in working form, O naysayers). News will continue to come in. What's been happening the past two weeks has just been a necessary break in order to regroup. My apologies for it.

Thanks, guys, for being understanding. Moreso than certain (http://handbrake.fr/irclogs/handbrake/handbrake20090520_pg7.html) unnamed others (http://handbrake.fr/irclogs/handbrake/handbrake20090426_pg2.html). After reading things like that, I wasn't sure anyone really cared if command-q vanished from the face of the Earth. Good to know that's not true. I'll be in the IRC (irc://irc.efnet.net/#doom9) and refreshing the thread occasionally if you guys have any questions.

[RadicalEd]

Oh, I nearly forgot! I spoke to some GStreamer developers recently, who had some very exciting news! It turns out that GStreamer is working on an AviSynth plugin, and a means to parse AviSynth script! So while AviSynth 3 has stagnated, leaving us *nix users out in the cold, we will be getting a means to use AviSynth natively. This means very good things for a certain other project. The other good news about that is that the PiTiVi developers, who do most of the work on GNonLin, will be assisting with said project as well.

[RadicalEd]

Well, I suppose this is what I get for inquiring about maliciously-intended visits to my domain noticed earlier in my site's access logs. The Handbrake developers (dynaflash, jbrjake, and KonaB1end) have sunk to [link removed -- rule 4] stalking me on social networking sites and [link removed -- rule 4] threatening my life over relay chat. I'm going to have to avoid posting publicly for awhile until they get their heads on straight.

Hard to believe this was all caused by [link removed -- rule 4] a tagline on a website that vaguely implied that Handbrake wasn't the best GUI out there for encoding H.264 months ago.

I wish I could provide you guys with some contact info to keep in touch, but I'm afraid that would just lead to more harassment and threats.

[Guest]

Since the OP has now gone way OT on his own thread, and is posting links to rule 4 violations, not to mention the fact that it has all become vaporware, it's time to close it.