Smart render/remux H.264 .mp4 to Quicktime .mov?

NickHope wrote on 7/2/2011, 2:49 AM
Trying to send a downscaled, compressed screener/sample video to people in Apple-land.

First try was to render an H.264/.mp4 file with x264 in MeGUI with default settings (i.e. not deliberately dumbed down for Quicktime). I told them to rename it to .mov if they had trouble (as advised quite often on this forum) and they've said: "While changing the extension to .mov may assist in viewing, we need to convert the files to a quicktime format for delivery to the client".

I opened the file in Quicktime Pro and rendered to H.264 .mov. It took about 20 seconds to render a solid green file.

Has anyone found a way to smart-render (i.e. simple remux from .mp4 to .mov without re-compressing) any of the following, and did the file play OK on the recipient's computer?

Sony AVC .mp4
MainConcept AVC .mp4
x264 H.264 (e.g. done with Handbrake or MeGUI)

Or am I basically stuck with exporting an uncompressed or lossless intermediate and using Quicktime Pro's H.264 encoder?

Comments

musicvid10 wrote on 7/2/2011, 8:23 AM
"(i.e. not deliberately dumbed down for Quicktime)"

Nick,
Try another render in MeGui with the following (don't know the exact syntax):

No 8x8 dct
No weight p
No b-pyramid
Constant frame rate

then try again in QT Pro.
That is usually dumb enough for Quicktime.
NickHope wrote on 7/2/2011, 9:41 AM
Thanks musicvid. The Quicktime H.264 compatibility horror story is all coming back to me now.

As this is only a screener, and I really don't want to do it a 3rd time, I've decided to encode it in Quicktime Pro. As a note to self, and to help anyone who wants to render a downscaled .mov screener for Apple-world, here's what I'm doing.

1. Debugmode Frameserver. Frameserve in RGB24 at HDV 1080-60i project settings.

2. AviSynth script (help here):

AviSource("d:\fs.avi")

ConvertToYV12(interlaced=true, matrix="Rec709") # Quicktime Pro is using Rec709

AssumeTFF()

Spline36Resize(1280,height)

QTGMC( Preset="faster", FPSDivisor=2 )

Spline36Resize(width,720)


3. Open that .avs script in VirtualDub and render an uncompressed .avi file (note that levels of this file in Vegas will not match the original).

4. Quicktime Player (7.6.2) > Export (need Quicktime Pro) > Export Options:



Levels of the output file match those in Vegas. For a 13-sec segment of video, "low" gave me 2.48Mb, "medium" gave me 5.63Mb, and "high" gave me a whopping 17Mb (Edit: These values might have been inflated by including uncompressed audio. Not sure). I'm using "medium". At lower res I would probably use higher. It's not giving the bitrate/quality ratio of x264 but it's OK.
NickHope wrote on 7/3/2011, 7:58 AM
Took another look at it today and realised that the H.264 file exported by Quicktime Pro is actually garbage. Haloing, banding, gamma shift, clipping, you name it. But the footage is of whales in blue water so it's particularly challenging.

I found out that "Export" in Quicktime Pro, appears to always re-compress the file, whereas "File" > "Save As" will do a simple remux from .mp4 to .move as long as the streams are acceptable. If they are not acceptable it says is will save a tiny file of about 10k, and then it just doesn't do it. I discovered that a SonyAVC .mp4 file is acceptable for direct saving (remuxing), so that is good.

I went back to rendering with my normal process to try and get more quality and went about the task of seeing how much I would have to dumb the default x264 settings in order get Quicktime Pro to save (remux) as a .mov.

I chose the "Main" profile, which automatically disables I8x8, and I found I also had to disable B frames completely, as well as weighted P frames, so ended up with settings giving me the following string in the x264 advanced options:

program --profile main --crf 21.0 --bframes 0 --weightp 0 --output "output" "input"


For the audio I used Nero AAC-LC cbr 128k

I will report back if they have any trouble with these .mov files when they are received.
Laurence wrote on 7/3/2011, 8:12 AM
Streamclip could probably also do this rewrap, and unlike Quicktime Pro, it would be fast and you could do a batch conversion (I think):

http://www.squared5.com/svideo/mpeg-streamclip-win.html
NickHope wrote on 7/3/2011, 8:23 AM
Quicktime Pro is very fast doing a "Save As", once you feed it a compliant file. Basically as fast as it can write the file.

MPEG_Streamclip requires you purchase the Apple MPEG2 component. But yes, it should also do this correctly. I had some stability problems in the past with it (needed to disable DirectDraw acceleration in the Quicktime preferences).
NickHope wrote on 7/6/2011, 11:01 PM
Ultimately the recipients were happy with the "dumbed down" x264 files.
musicvid10 wrote on 7/6/2011, 11:22 PM
program --profile main --crf 21.0 --bframes 0 --weightp 0 --output "output" "input"

Wouldn't even take b-frames? Then just as well take out CABAC too and deliver Baseline Profile. That's about as dumb and as fat as mp4 can get.
NickHope wrote on 7/6/2011, 11:40 PM
Correct. Quicktime Pro wouldn't save the file as .mov with any B frames. I'm not sure what CABAC actually does. Is it related to B frames?

Even with the dumbest profiles, x264 always seems to make a really nice job.
musicvid10 wrote on 7/6/2011, 11:47 PM
All that higher profiles do is improve compression efficiency. They come with their own price tag (longer renders, playability on consumer devices). They were invented to enable broadcasters to send more streams at the same quality through the same pipe. The notion that high profile settings improve quality is a myth.

CABAC is another one of those compression tools. But it is practically useless without b-frames (which in turn require CABAC compression).

Going to CAVLC compression (Baseline profile) has the advantage that it will play on anything, even the oldest iPhones, and decodes much faster. But the file size relative to quality is fatter.