Log in

View Full Version : X●, a new x264 GUI for Mac


Pages : [1] 2

RadicalEd
26th December 2008, 18:56
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
26th December 2008, 19:22
http://xdot.command-q.org Dead link.

Atak_Snajpera
26th December 2008, 19:43
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
26th December 2008, 20:49
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
26th December 2008, 20:51
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
26th December 2008, 20:58
How do you justify touting vaporware as "the premiere encoder"? And why announce something that no-one can obtain?

Dark Shikari
26th December 2008, 21:03
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
26th December 2008, 22:25
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
26th December 2008, 22:37
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
26th December 2008, 22:45
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
26th December 2008, 22:55
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
26th December 2008, 23:05
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
26th December 2008, 23:06
sloppy html, by the way

RadicalEd
26th December 2008, 23:10
sloppy html, by the way

Not even going to lie, it's iWeb.

Atak_Snajpera
26th December 2008, 23:13
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
26th December 2008, 23:23
are your screenshots from a working gui? or conceptual renders?

RadicalEd
26th December 2008, 23:32
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
30th December 2008, 19:34
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
31st December 2008, 02:53
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
31st December 2008, 03:28
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
31st December 2008, 08:44
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
31st December 2008, 10:17
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
2nd January 2009, 08:08
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
2nd January 2009, 08:13
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
2nd January 2009, 08:40
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
2nd January 2009, 09:27
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
11th January 2009, 08:52
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
17th January 2009, 18:08
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
18th January 2009, 10:37
OK so our new vaporware comes to fruition... Congrats :):thanks:

RadicalEd
18th January 2009, 13:51
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
18th January 2009, 18:02
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
19th January 2009, 19:34
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
19th January 2009, 23:04
Do you intend to provide a binary for PPC-based systems and/or older versions of OS X?

RadicalEd
19th January 2009, 23:31
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
20th January 2009, 01:00
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
20th January 2009, 01:02
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
21st January 2009, 06:09
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
23rd January 2009, 12:06
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
25th January 2009, 02:34
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
28th January 2009, 08:36
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
28th January 2009, 11:48
Nice you make my Mac happy this is an awesome app.. Keep up the good work.:D:thanks:

RadicalEd
28th January 2009, 21:59
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
20th March 2009, 13:18
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
21st March 2009, 19:55
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
25th March 2009, 10:05
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
26th March 2009, 21:09
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
27th March 2009, 19:53
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
28th March 2009, 00:40
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
28th March 2009, 02:54
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
28th March 2009, 03:12
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?