x264-MP4 that is playable in Quicktime 7, completely via CLI!

[Randall]

Hi there,

In many threads of this forum I've read about creating mp4-files with x264 that are playable in Quicktime 7. Some guys seem to have found a solution already, but I've never seen a complete "workflow". So, I'd like to publish mine. It works entirely via Windows command-line. Basic video is a dv-avi.

What is needed:

-x264.exe (I've used the latest build 270)
-faac.exe for the sound (version 1.24.1)
-avi2wavcmd.exe (to create an intermediate wav-file)
-mp4creator.exe (to mux, version 1.2.8)
-avisynth (for x264 input)

What to do:

1. Prepare an avs-file as our input with the following code:

avisource("c:\INPUTFILE.avi")
ConvertToYV12()


2. Create a batch file with these parameters:


avi2wavcmd c:\INPUTFILE.avi c:\sound_temp.wav

faac -q 75 -c 32000 --mpeg-vers 4 -o c:\sound_done.aac c:\sound_temp.wav

x264.exe -q 30 --bitrate 650 -I 250 -i 25 --bframes 0 --no-b-adapt -r 5 -w --analyse all --subme 6 --no-psnr --progress --fps 25 -o "c:\raw.264" "c:\INPUTSCRIPT.avs" 720x576

mp4creator -c c:\raw.264 -rate=25 c:\h264.mp4
mp4creator -c c:\sound_done.aac -aac-profile=4 -hint -interleave c:\h264.mp4
mp4creator -optimize c:\h264.mp4
mp4creator -list c:\h264.mp4


That's it. Unfortunately due to the lack of money I couldn't test it on a Mac - maybe you can?

Bugs:

- Hinting doesn't work yet (If I do so, mp4creator produces a huge and worthless file)
- I can't mux with mp4box, if I try it always says "h264-file is truncated"

I hope you have some suggestions for me!


OK i give up. why are you switching colorspaces to YV12? Is is just because the filters you use require it? Unless QT only supports YV12, I don't see the point. :confused:

[stephanV]

x264 only supports yv12 input and uses yv12 internally anyway.

[Randall]

damit is that the reason my quicktime vids are fux0red? they play fine in mplayer (although I get some kind of warning about can't find the colorspace) I wonder what that could be? ;)

[stephanV]

No, thats not the reason why quicktime is fux0red. I doubt there is any encoder right now that supports anything else than YV12. So it wouldn't be unfair to say that at least 99.99% of all h264 files use YV12.

[Randall]

I think the days of avi are numbered. Once we start moving into AVC, everything will be contained in either .mp4 or .mpg like you said above.

Cheers!
I disagree with your opinion of the days of avi being numbered. While H.264 is probably the superior format for quality vs compression, the hardware support for DivX playback is quite extensive, and continues to grow. Meanwhile the only hardware support for AVC that I know of currently is iPod video and PSP handheld devices only. Granted, I'm sure that the popularity of AVC will cause a massive hardware backing (eventually), the fact is that DivX, who just released version 6 as a competitor to H.264 baseline, isn't going away any time soon and neither is the .avi format IMO.

The .avi (Audio Video Interleave) format has been around since 1992, it has a lot of overhead compaired to .mp4, and it was also introduced by the often despised Microsoft. Despite all of this, it has managed to hang around for 13 years thanks to companies and open source projects that have made compression codecs supporting the AVI format. This is including but not limited to Full Frames (Uncompressed AVI), Intel Real Time Video, Indeo, Cinepak, Motion JPEG, Editable MPEG, VDOWave, ClearVideo / RealVideo, QPEG, MPEG-4, XviD, DivX and others. While all but a few of these codecs are a dieing breed, as long as DivX continues to support the .avi format, it will continue to exist for the forseeable future. And if future video players what to maintain legacy support, AVI will always be with us. ;)

[Randall]

as you know he-aac is backwards compatible, so you can play an he-aac stream with every aac decoder, still with crappy quality
so a normal 64kbps aac stream will sound better than a he-aac stream at 64kbps decoded with a normal aac decoder

therefore it makes no sense to encode with he-aac when you want to play the stream in qt (or with any other aac decoder not handling sbr)

I think it makes sense in a futureproof mentality to just go ahead and encode HE-AAC when encoding audio for QuickTime, mainly because like you said, it will play in any LC-AAC decoder because it is backwards complatable. I recommend doing this because I assume that QuickTime will eventually have a decoder that can handle SBR, meanwhile Nero and the libavc open source players all support it. If QuickTime wants to be a decent playback solution, then they will support SBR down the road. That's just my opinion

[Sharktooth]

I disagree with your opinion of the days of avi being numbered. While H.264 is probably the superior format for quality vs compression, the hardware support for DivX playback is quite extensive, and continues to grow. Meanwhile the only hardware support for AVC that I know of currently is iPod video and PSP handheld devices only. Granted, I'm sure that the popularity of AVC will cause a massive hardware backing (eventually), the fact is that DivX, who just released version 6 as a competitor to H.264 baseline, isn't going away any time soon and neither is the .avi format IMO.

The .avi (Audio Video Interleave) format has been around since 1992, it has a lot of overhead compaired to .mp4, and it was also introduced by the often despised Microsoft. Despite all of this, it has managed to hang around for 13 years thanks to companies and open source projects that have made compression codecs supporting the AVI format. This is including but not limited to Full Frames (Uncompressed AVI), Intel Real Time Video, Indeo, Cinepak, Motion JPEG, Editable MPEG, VDOWave, ClearVideo / RealVideo, QPEG, MPEG-4, XviD, DivX and others. While all but a few of these codecs are a dieing breed, as long as DivX continues to support the .avi format, it will continue to exist for the forseeable future. And if future video players what to maintain legacy support, AVI will always be with us. ;)
im not convinced AVI will survive. DXN is moving to their proprietary container (.divx - yes it's a hacked .avi, but still no longer .avi) to integrate chapters, subs and other stuff (including xvid streams).
AVI is still there coz virtualdub and few other "big" softwares support it.

[Randall]

I have been having success without using b-frames in QT7. (I was using 2 b-frames (adaptive). This is my successful encoding command line

"x264.exe" --pass 2 --bitrate 839 --stats ".stats" --bframes 0 --subme 1 --analyse none --me dia --progress --no-psnr --output "foo.mp4" "foo.avs"

I am currently trying 3-pass encoding and 1 b-frame. I hope b-frames will work, as it really helps the quality a lot. This is my current command line
"x264.exe" --pass 3 --bitrate 839 --stats ".stats" --bframes 1 --subme 1 --analyse none --me dia --progress --no-psnr --output "foo.mp4" "foo.avs"

I think that QT was borking on 2 b-frames, because when I switched to zero it worked (with a big quality hit though, I had artifacts, whereas before I had none at the same bitrate). I am hoping that 1 b-frame will work, as I believe apple's internal QT encoder has support for 1 b-frame. We'll find out tomorrow I guess. :rolleyes:

hmmm I just noticed that the version of MeGUI that I'm using (bundled with Sharktooth's rev.365A build) always has the --analyse stuck to "none". I really wanted --analyse p8x8,b8x8,i4x4,p4x4. d'oh! I knew my encodings were going way way too fast. (probably explains my sucky quality at reasonably high bitrates) I might just write a batch script if I can't figure this out. Is this a bug that anybody else had?

UPDATE
Ok I just tested my second encoding attempt using 3-pass and 1 B-frame. It worked in QT, and the 3-pass looks nice and smooth with no artifacts! So know I'm gonna try it again with the whole smash (--analyse p8x8,b8x8,i4x4,p4x4)

[Sharktooth]

randall do not use turbo if you want to do 3 passes. It's a megui bug.

[Randall]

sux0r! thanks for the info Sharktooth. Looks like I'll be re-encoding tonight. BTW, what happens when I choose turbo on 3 passes? The encodes don't crash or anything, but I'm assuming that you're talking about the .stats file not being written correctly, or one of the three passes not being useful.

[Sharktooth]

turbo is made to remove or set different values in x264 parameters for the 1st pass to make it faster. in auto 3 pass with turbo, all those "turbo parameters" are applied to all passes... and the encode is screwed...

[smok3]

Randall: iam working on a little win bat file as well, see if it is of any use:
http://somestuff.org/x264_qt/x264_bat.zip

from x264_bat_readme.txt:
required:
------------------
x264.exe
faac.exe
change.exe (should be included)
mplayer.exe
mp4box.exe
(put those somewhere on the system path)
avisynth
&
template.avs (should be included)


usage example:
------------------
x264_.bat d:\avis\input.avi c:\somepath\template.avs
(you need to use full paths.)

- template.avs is included, edit as you wish.


notes:
------------------
if input is input.avi, output will be named input.avi.mp4,
everything else are temporary files, delete those manualy,

del *.aac
del *.wav
del *.264

(p.s. pretty unstable and badly tested at the moment, will need more work, use at your own risk.)

[Randall]

Thanks guys. I'll take a look at that batch file smok3 thanks.