Xdot: A new x264 GUI for Mac

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 Xdot. Xdot 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.

Xdot is currently in pre-alpha.

What works:
-Reading from LAVF/LAVC
-Encoding to libx264 or x264 binary
- Generally all the GUI settings, including zones and MP4v2 metadata
-Presets (loading saved presets is still a bit wonky)
-Image scaling using swscale might work, haven’t tested yet, but it should
-Lots of Mac-specific things like badging, Growl, Sparkle updating, etc

What doesn’t:
- Progress reporting GUI: Progress can be observed from Console.app
- Preview/review: Converting the raw pixel data to NSImages is currently not working, though there is preliminary code for this.
- Audio encoding: We're focused on getting video flawless before we delve into the audio parts, although there is a large chunk of code to do just this donated by Yuvi (thanks Yuvi!)
- Multipass: This requires just a bit more tweaking with NSTask, and should be supported soon.
- Minor note: Bounds checking for configuration fields is currently broken and disabled.

Currently, MP4 writing using the libraries (MP4v2 and GPAC) is broken, so the only way to get a working encode is to use the binary encoding mode. This option can be set via the main menu->Preferences. I’ve included an updated version of x264.pkg from Command-Q Builds if you don’t already have an x264 binary on your machine. There are a few drawbacks to using x264 directly, among them being:
- Raw YUV/YUV4MPEG input only
- No encoding preview

Check out the website at http://xdot.command-q.org, follow development on the Command-Q Blog, read more at the Qiki, or discuss Xdot on our forums.

xdotpreview_1.png

very nice GUI (I didn't used it yet, but I DL it )
bye

Originally Posted by http://blog.command-q.org/?p=188

I've worked all night to bring you all a surprise beta of Xdot! 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, Xdot 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 here, but how about a summary?

First, audio encoding using Core Audio. Xdot 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 Xdot, 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 and check it out!

-Mike

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

just a notice to tab
please do not install your lib in /usr/local/lib
choose a perzonnalized place (like "Application Support" for example)

after installation, I could not compile anymore another tool (broken gpac)
and some X11softs does not work anymore too

PS: the other advantage is:
if another soft "needs" to install some librairies, it will not break your soft
bye

Herve: Was this problem caused by the beta or the old pre-alpha? The pre-alpha's GPAC package had a bug in it where it would install the GPAC headers to /usr/local/include instead of /usr/local/include/gpac. I don't know why installing anything to local/lib would break GPAC compilation or X11...

Herve: I install the libraries and binaries to /usr so as to not conflict with MacPorts. Would you prefer if I install them to /opt? I'm currently trying to find out what the convention is for external libraries, I might be able to put them in the app package.

Originally Posted by Tab

Herve: Was this problem caused by the beta or the old pre-alpha?

pre-alpha

The pre-alpha's GPAC package had a bug in it where it would install the GPAC headers to /usr/local/include instead of /usr/local/include/gpac. I don't know why installing anything to local/lib would break GPAC compilation or X11...

sorry I don't have more informations, last days I tried to compile mjpegtools and ffmepg, 2 failures because of maths.h / gpac (if my memories are OK). I didn't install something else since my last compile.

Originally Posted by Tab

Herve: I install the libraries and binaries to /usr so as to not conflict with MacPorts. Would you prefer if I install them to /opt?

/usr/local or /opt or /sw etc is not a great idea.
The easiest -for users and for your updates- is to have your own folder (macport use its own /opt, fink use its own /sw) it's safer to avoid /usr/local/bin

I'm currently trying to find out what the convention is for external libraries, I might be able to put them in the app package.

the "unix clean" solution is /usr/local/bin but you will have problems (or can cause pb) if a user or a software decides to install something.
Use your own folder (or inside the app) and you have no more concern (personnaly I use ~/Library/Application Support/ and app bundle, but you can use everything you want, and you even could modify -not adviced- ~/.bash_profile if you really need it )

So I don't have a real solution, my experience show that static librairies are easier to manage than dynamic ones, and avoid to use commun folder for a single use.

bye
(PS: contact me by mail if you want to continue this discussion)

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.

http://xdot.command-q.org

This version still doesn't work for me. It's still crashing at startup.
Here is the crash log :

Process: X• [520]
Path: /Applications/X•.app/Contents/MacOS/X•
Identifier: com.command-q.X_
Version: ??? (???)
Code Type: X86 (Native)
Parent Process: launchd [85]

Date/Time: 2009-01-26 16:23:01.281 +0100
OS Version: Mac OS X 10.5.6 (9G55)
Report Version: 6

Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Crashed Thread: 0

Dyld Error Message:
Library not loaded: /usr/local/lib/libmp4.0.dylib
Referenced from: /Applications/X•.app/Contents/MacOS/X•;
Reason: image not found

I'f I'm not mistaken, it's looking for some library (libMP4) in usr/local/lib.

Originally Posted by jpschuck

I'f I'm not mistaken, it's looking for some library (libMP4) in usr/local/lib.

That's odd... libmp4.0.dylib should have been installed with the support package. You installed that, right?

Originally Posted by Tab

Originally Posted by jpschuck

I'f I'm not mistaken, it's looking for some library (libMP4) in usr/local/lib.

That's odd... libmp4.0.dylib should have been installed with the support package. You installed that, right?

Me sooooo stupid ! I didn't notice this "support" folder inside the disk image...
So now it's working. X• is a nice app that looks promising. The panel of x264 settings seems pretty exhaustive, and each setting is clearly explained with a pop-up.
Yet, in my opinion it's a bit annoying that all windows in the program are floating windows. First, the transparency makes the settings window rather difficult to read. Second, it seems that it's impossible to get rid of them when an encoding task is in progress.

I was also wondering which disk was used by X• when doing the yu4mpeg conversion. Does it use the same disk as the destination or the system disk ?

In addition, if I open an output file in Quicktime, the Quicktime information window tells me that the file is 0 bytes in size.
. This also leads to a number of other problems
such as the impossibility to save as a Quicktime file.
It has probably something to do with mp4box as this problem also occured with ffmpegX (although it never occurs with Handbrake).

jpschuck,

If the file is zero bytes, you are probably encoding using the libraries, which is currently broken and unsupported for 1.0.

As far as the disk, it uses /tmp on your local disk. However, this won't be a problem in future releases as Xdot will be using FIFO pipes, so no huge intermediate files!

Finally, the floating panel issue has been addressed and will be fixed in the coming beta. All panes save for the progress (or main window if you're not encoding anything) will fade away. As far as readability... sorry :/ That's an issue with using HUD controls in general.

Long story short, the next beta should fix all the major problems.

On a related note, there is an embarrassing bug in the currently available version where closing a panel autoreleases it, and trying to open it again locks up the app. That's been fixed.

Originally Posted by Tab

jpschuck,

If the file is zero bytes, you are probably encoding using the libraries, which is currently broken and unsupported for 1.0.

I'm using the binary (x264 binary in the preferences window). The file is not actually 0 byte, it's the value displayed in Quicktime. In addition, such files have also a strange behaviour under MPEGStreamclip (blank first frame, inabilty to navigate between keyframes, inconsistent timer...), or Avidemux (impossible to do a passthrough export).

Beta 3.1 is out, and it makes all the other betas look like alphas. From the blog announcement:

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

Originally Posted by Tab

- Scaling is broken for now, as FFMPEG doesn’t like FIFO

read again the mail
1- you must specify format/size/fps before input
2- you must give a full path for input (the previous "cd " has no effect here)

ffmpeg -f rawvideo -s 720x480 -r 30000:1001 -i /tmp/my_fifo.yuv ...

bye

Originally Posted by Herve

Originally Posted by Tab

- Scaling is broken for now, as FFMPEG doesn’t like FIFO

read again the mail
1- you must specify format/size/fps before input
2- you must give a full path for input (the previous "cd " has no effect here)

ffmpeg -f rawvideo -s 720x480 -r 30000:1001 -i /tmp/my_fifo.yuv ...

bye

FFMPEG hangs forever when I try to pipe fifo output from it...

Originally Posted by Tab

FFMPEG hangs forever when I try to pipe fifo output from it...

I use fifo and ffmpeg to convert AVCHD files
mkfifo (full path of fifo.yuv)
cd (folder of the fifo) && mplayer (blabla) (output no path fifo.yuv) & ffmpeg -f rawvideo -r (fps of input stream) -s (size of the input stream) -i (full path o the fifo) (options and output)

If you don't succeed, your mplayer command should be wrong
bye

Herve: It's no problem, I've switched to just using MPlayer to scale, which is much easier since I'm already using MPlayer to pipe to x264. Actually, I have a little surprise related to that, but you'll have to wait until the next beta to find out about it

I'm guessing vaporware.