Generating QT7 compatible encodes with x264: some notes

[trythil]

I'm using x264 r604, QuickTime Player 7.1.2 on OS X Tiger.

This works quite well (adjust for your input, obviously):

Code: Select all

nevrast:~/prj trythil$ x264 -I 300 -i 30 -r 10 -b 5 -t 2 --direct auto --me umh -m 7 --b-rdo --bime -p 1 --crf 16 
stream.dump -o qt1.264 640x352

nevrast:~/prj trythil$ MP4Box -add qt1.264 -add audiodump.m4a -fps 29.97 out.mp4

i.e.

- multiple reference frames are supported
- multiple B-frames are supported
- CABAC is supported

Things that don't yet work (in my experience, anyway):

- 8x8 DCT. QuickTime Player doesn't show the video if you use this.
- B-frame pyramid. The video plays, but very choppily. QuickTime Player also often became unresponsive.
- p4x4 partition -- same symptoms as with B-frame pyramid.
- Per-partition references (i.e. --mixed-refs) -- same symptoms.

Corroboration of these results would be greatly appreciated. I'll update these with other observations later.[/list][/list]

[trythil]

QT7 doesn't seem to perform aspect ratio correction, regardless of whether you specify it using x264's --sar switch or later in MP4Box. Not sure what the cause of that particular issue is.

[Zero1]

Good work, also I'm not sure about the level of support when it comes to slices.

[trythil]

Good work, also I'm not sure about the level of support when it comes to slices.

Got any testcases I might be able to run through?

[Zero1]

Nope, my normal encodes are beyond what Quicktime supports anyway, so if for instance I ran one single threaded and another multithreaded, it wouldn't make any difference since the file won't play anyway.

I've never looked into "Quicktime compatible" files because I believe as long as I'm doing things to spec, it should be up to the software writers (in this case Apple) to support all the relevant features if they want people to use their player.

I assumed you were running some tests for this purpose and so just gave you the heads up to experiment with threading/slices. It may have even been fixed in Quicktime since the last time I heard that it was an issue. It may not have been an issue either, I could be just getting something else mixed up.

[trythil]

I've never looked into "Quicktime compatible" files because I believe as long as I'm doing things to spec, it should be up to the software writers (in this case Apple) to support all the relevant features if they want people to use their player.

This is a good point, and I wish I could retitle this thread because of it.

"QuickTime compatible" gets the point across, but it also makes it sound as if x264 has some defect with generating spec-compliant video streams, which (as far as I know) it doesn't.

Perhaps "x264 encodes using the spec subset supported by QuickTime" is better :)

I assumed you were running some tests for this purpose and so just gave you the heads up to experiment with threading/slices. It may have even been fixed in Quicktime since the last time I heard that it was an issue. It may not have been an issue either, I could be just getting something else mixed up.

I'll give that a shot.

[Beefy_Suavo]

I can't get QuickTime 7 to like B-frames.

--bframes to anything other than zero will cause QT to not display the video info correctly


and will not let you mux the video to a .mp4 file.

The video will still play, but QT lags for a few seconds at the beginning before it catches up.

Setting --bframes 0 makes videos that you can play and export in QT7 without any problems.

Code: Select all

x264r618.exe --bitrate 2200 --bframes 0 --ref 5 --subme 6 --fps 23.976 --pass 1 --progress --threads 4 --output "U:\make\x264\x264testbf0p1.mp4" video.avs

[trythil]

I can't get QuickTime 7 to like B-frames.

--bframes to anything other than zero will cause QT to not display the video info correctly

What's the full version number? QT 7.1.2 does seem to handle B-frames, so that may have been a change.

[Beefy_Suavo]

I'm using 7.1.3