Quicktime and x264 [Archive]

Razorholt

8th July 2009, 18:57

Hello,

I was asked last week to encode a trailer using x264 but to be decoded with QuickTime player - Yes, I know...

Problem is, QT can't handle 720p or even 1024x resolution on a 2Ghz/1GB ram with standard video card. It's choppy.

What can I do at the encoding level for the video to play smoothly? I'm aware of the --no-deblock option but the quality suffers too much. Anything else I should try?

x264 cmd
--pass 2 --bitrate 1190 --stats ".stats" --level 3.1 --keyint 240 --min-keyint 24 --ref 2
--no-fast-pskip --subme 9 --trellis 2 --psy-rd 1.02:0.4 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct
--pbratio 1.25 --qcomp 0.69 --me umh --threads auto --thread-input --aq-strength 0.95 --progress
--no-dct-decimate

Thanks,
- Dan

LoRd_MuldeR

8th July 2009, 19:01

--no-cabac

Razorholt

8th July 2009, 19:03

--no-cabac

Oh ok. Let's see :D

Thanks,
- Dan

Razorholt

8th July 2009, 22:30

main profile with --no-cabac helped a lot. Thanks, LM.

LoRd_MuldeR

8th July 2009, 22:45

main profile with --no-cabac helped a lot. Thanks, LM.

But takes away much of the power of x264 :(

nurbs

8th July 2009, 22:46

If quicktime can handle it High Profile shoudn't be harder to decode than Main profile and it would give a little extra compression.

Razorholt

8th July 2009, 22:58

If quicktime can handle it High Profile shoudn't be harder to decode than Main profile and it would give a little extra compression.

Well, I thought so too, until I tried the encoded files on a 2.1GHz/512ram machine with an internal graphic card.

OT: And I'm having the same issue with Silverlight 3 (beta). On the latter I hope their final release will fix the issue. I've been told that silverlight and quicktime are very close in terms of behaviour and if a file doesn't play smoothly on QT it won't play well on Silverlight either.

- Dan

nurbs

8th July 2009, 23:52

Well, crappy implementation I guess. Maybe they want to disencourage people from using high profile since AppleTV can't handle it and the files they sell are main profile as well. Would be interesting to know if the performence is better in OS-X than in Windows. I think a new version of Quicktime is coming out with the next MacOS so maybe they'll improve a little.

Your CPU is an AthlonXP or Pentium IV right? If it's something newer that would be really abysmal performance.

Blue_MiSfit

9th July 2009, 01:09

I think Apple's decoder doesn't implement frame-level parallelism - but does implement slice based parallelism. I might be totally wrong though!

Also, it's hideously slow at doing CABAC... I usually just turn off CABAC (and hence trellis) when targeting QuickTime. Doing so makes playback of 720p (and even 1080p content at moderate bitrates) doable on lower speed Athlon64 or high clocked Pentium 4 systems, which basically means anything from the past 3-5 years.

It's true that disabling CABAC is a big bummer, but x264 is so much better than any other H.264 codec that it's not really a huge deal when you're going for QuickTime compatibility.

Also, I hear Silverlight 3 should have much improved H.264 decoding and presentation. I'm expecting a lot from Ben Waggoner :)

I'm actually running some tests right now to see how much PSNR / SSIM disabling CABAC actually costs. I'm testing with a BluRay source scaled down to DVD-style 480p, psy opts disabled, and everything else pretty much maxed, and 2 pass encoding... I'll post more

~MiSfit

Razorholt

9th July 2009, 01:19

Blue_MiSfit

9th July 2009, 01:38

Here's the results of my little test:

Encode 1 Settings (CABAC on):

--bitrate 1250 --ref 5 --mixed-refs --bframes 3 --b-adapt 2 --weightb --subme 9 --trellis 2 --psy-rd 0:0 --partitions all --8x8dct --threads auto --thread-input --aq-mode 0

Encode 1 Stats:
---[NoImage] avis [info]: 720x480 @ 23.98 fps (2000 frames)
---[NoImage] x264 [info]: using SAR=1/1
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
---[NoImage] x264 [info]: profile High, level 3.0
---[NoImage]
---[NoImage] x264 [info]: slice I:23 Avg QP:17.09 size: 31862 PSNR Mean Y:48.20 U:51.11 V:51.47 Avg:49.00 Global:48.93
---[NoImage] x264 [info]: slice P:788 Avg QP:19.09 size: 10721 PSNR Mean Y:46.38 U:49.91 V:49.97 Avg:47.27 Global:47.12
---[NoImage] x264 [info]: slice B:1189 Avg QP:20.92 size: 3221 PSNR Mean Y:45.98 U:49.91 V:49.96 Avg:46.94 Global:46.77
---[NoImage] x264 [info]: consecutive B-frames: 2.5% 35.3% 49.6% 12.5%
---[NoImage] x264 [info]: mb I I16..4: 31.6% 42.5% 25.9%
---[NoImage] x264 [info]: mb P I16..4: 2.8% 7.1% 2.1% P16..4: 30.0% 13.1% 8.9% 1.4% 0.5% skip:34.1%
---[NoImage] x264 [info]: mb B I16..4: 0.3% 0.7% 0.2% B16..8: 25.9% 3.2% 3.0% direct: 3.3% skip:63.3% L0:30.4% L1:42.5% BI:27.1%
---[NoImage] x264 [info]: 8x8 transform intra:56.1% inter:59.3%
---[NoImage] x264 [info]: coded y,uvDC,uvAC intra:59.6% 64.1% 34.5% inter:17.2% 13.1% 1.2%
---[NoImage] x264 [info]: ref P L0 77.8% 11.3% 6.0% 2.7% 2.1%
---[NoImage] x264 [info]: ref B L0 90.3% 6.0% 2.4% 1.2%
---[NoImage] x264 [info]: SSIM Mean Y:0.9884366
---[NoImage] x264 [info]: PSNR Mean Y:46.163 U:49.924 V:49.982 Avg:47.093 Global:46.928 kb/s:1247.77
---[NoImage] encoded 2000 frames, 17.16 fps, 1247.92 kb/s

Test 2 (CABAC disabled) settings:

--bitrate 1250 --ref 5 --mixed-refs --bframes 3 --b-adapt 2 --weightb --no-cabac --subme 9 --psy-rd 0:0 --partitions all --8x8dct --threads auto --thread-input --aq-mode 0

Test 2 results:
---[NoImage] avis [info]: 720x480 @ 23.98 fps (2000 frames)
---[NoImage] x264 [info]: using SAR=1/1
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
---[NoImage] x264 [info]: profile High, level 3.0
---[NoImage]
---[NoImage] x264 [info]: slice I:23 Avg QP:17.61 size: 32978 PSNR Mean Y:47.85 U:50.88 V:51.21 Avg:48.67 Global:48.56
---[NoImage] x264 [info]: slice P:788 Avg QP:19.74 size: 10728 PSNR Mean Y:45.87 U:49.53 V:49.56 Avg:46.78 Global:46.60
---[NoImage] x264 [info]: slice B:1189 Avg QP:21.53 size: 3190 PSNR Mean Y:45.52 U:49.54 V:49.56 Avg:46.49 Global:46.30
---[NoImage] x264 [info]: consecutive B-frames: 2.5% 35.3% 49.6% 12.5%
---[NoImage] x264 [info]: mb I I16..4: 35.2% 28.7% 36.2%
---[NoImage] x264 [info]: mb P I16..4: 3.9% 4.4% 3.9% P16..4: 28.7% 14.9% 5.8% 1.5% 0.6% skip:36.3%
---[NoImage] x264 [info]: mb B I16..4: 0.6% 0.6% 0.5% B16..8: 25.7% 3.2% 2.2% direct: 3.2% skip:64.0% L0:28.3% L1:47.1% BI:24.6%
---[NoImage] x264 [info]: 8x8 transform intra:35.0% inter:39.1%
---[NoImage] x264 [info]: coded y,uvDC,uvAC intra:59.7% 62.4% 34.1% inter:13.1% 7.4% 0.9%
---[NoImage] x264 [info]: ref P L0 77.0% 11.3% 6.5% 2.8% 2.4%
---[NoImage] x264 [info]: ref B L0 89.1% 6.6% 3.0% 1.4%
---[NoImage] x264 [info]: SSIM Mean Y:0.9876351
---[NoImage] x264 [info]: PSNR Mean Y:45.684 U:49.553 V:49.582 Avg:46.630 Global:46.438 kb/s:1247.21
---[NoImage] encoded 2000 frames, 30.66 fps, 1247.35 kb/s

So in the end, we see that enabling CABAC and trellis 2 gives an SSIM mean of .988436, and disabling these gives an SSIM mean of .9876351

Not a huge difference, but granted this was a relatively high bitrate for this source.

Just my two cents - feel free to yell and scream if you want, and maybe I'll do some more testing :)

~MiSfit

Razorholt

9th July 2009, 01:58

Interesting test. Can you please report the CPU usages while playing both files?

Thanks,
- Dan

LoRd_MuldeR

9th July 2009, 01:59

About CABAC:
http://akuvian.org/src/x264/entropy.png

So with CABAC enabled you get 10-20% extra compression for free at "medium" quantizers. At "high" quantizers you get even more (up to 90%).

Blue_MiSfit

9th July 2009, 05:38

@ Razorholt,

Which decoder did you have in mind? If you're thinking QuickTime, don't because these are all high profile streams.

If you want QuickTime specific results I can formulate some different tests that are a bit more real-world.

~MiSfit

Razorholt

9th July 2009, 05:50

Blue_MiSfit

9th July 2009, 06:55

Okay. I'm running a new test right now that should be a bit more representative of a real-world scenario.

This time the clip will be 1280x720 (2.35 image with mattes) at 2mbps. This should stress the codec quite a bit more, as we were near saturation with the previous test.

I've devised a profile based on MeGUI's "Unrestricted 2pass QuickTime for Windows". The settings (in brief) are:

2pass encoding at 2000kbps
main profile
subme 9
5 refs
all psy opts disabled
1 b-frame, b-adapt 2

The version with CABAC enabled will have trellis 2

For reference, my system is a Q6600 CPU with 8GB of RAM and a Radeon 4830 running Windows 7 RC1 x64

~MiSfit

Blue_MiSfit

9th July 2009, 07:01

Interesting...

The CABAC version played with between 9-10% CPU Utilization on my system, which means less than half of one core.

The NoCABAC version played with between 5-6% CPU Utilization.

Then again, we're talking a Q6600 versus a P4 :P I _guess_ one could say disabling CABAC makes decoding ~twice as fast... It's hard to measure accurately on QuickTime anyway.

~MiSfit

Dethis

9th July 2009, 09:16

I think that you should compare CABAC vs no-CABAC playback not at the same bitrate but at the same quality (metrics). I suppose(??) that encoding @ same CRF's should do the job. You could start with the (now default) CRF23 and time permited go on with ... crf17, crf20, crf26 ...

Blue_MiSfit

9th July 2009, 20:30

I don't think so. CRF and PSNR aren't related AFAIK.

I think CABAC decoding complexity is directly proportional to bitrate in any case.

~MiSfit

Gokumon

9th July 2009, 20:51

So in the end, we see that enabling CABAC and trellis 2 gives an SSIM mean of .988436, and disabling these gives an SSIM mean of .9876351

Not a huge difference, but granted this was a relatively high bitrate for this source.

Just my two cents - feel free to yell and scream if you want, and maybe I'll do some more testing :)

~MiSfit

The problem with that test is that it's virtually meaningless and doesn't really say anything. CABAC isn't meant to give higher SSIM or PSNR (as both it and CAVLC are lossless entropy coders). The point of CABAC is to get higher compression efficiency over CAVLC.

Dark Shikari

9th July 2009, 20:52

The problem with that test is that it's virtually meaningless. CABAC isn't meant to give higher SSIM or PSNR. The point of CABAC is to get higher compression efficiency over CAVLC.Higher compression is equivalent to higher PSNR, because it means better quality at the same bitrate.

Gokumon

9th July 2009, 20:58

Higher compression is equivalent to higher PSNR, because it means better quality at the same bitrate.

Yes, but comparing 2 lossless encoding schemes at the same bitrate and then doing a PSNR/SSIM diff between them is a meaningless comparison. A meaningful test would have been enabling CABAC and then enabling CAVLC when encoding at the same CRF value and showing the decreased file size you get with CABAC.

Dark Shikari

9th July 2009, 21:09

Yes, but comparing 2 lossless encoding schemes at the same bitrate and then doing a PSNR/SSIM diff between them is a meaningless comparison.Why? If you're encoding for a specific bitrate, and you want to know how much better quality you get from turning on CABAC at that bitrate, that's exactly how to measure it.

Gokumon

9th July 2009, 23:54

Why? If you're encoding for a specific bitrate, and you want to know how much better quality you get from turning on CABAC at that bitrate, that's exactly how to measure it.

Because in any test I've done, like in the one posted prior in this thread, the difference in SSIM difference has been negligible. At most I've seen a .1% difference (it was .08% in the test above for a .04% increased bitrate). If you're going by that alone one doesn't see any real meaningful difference and I'd say considering the almost halving of the encoding framerate turning CABAC for a .08% increase in SSIM would show it in a negative light as that is an imperceptible difference. Now if you do them both at a constant CRF you can see the sometimes dramatic file size decrease due to CABAC which is an actual meaningful thing to see. But then again, this is just my view.

Dark Shikari

10th July 2009, 00:20

Because in any test I've done, like in the one posted prior in this thread, the difference in SSIM difference has been negligible. At most I've seen a .1% difference (it was .08% in the test above for a .04% increased bitrate).You really have no idea how SSIM works do you?

nurbs

10th July 2009, 00:23

If I didn't make a mistake the encode with CABAC has about 7% higher quality (SSIM) than the one without.

Razorholt

10th July 2009, 00:47

Dethis

10th July 2009, 01:05

I don't think so. CRF and PSNR aren't related AFAIK.

I think CABAC decoding complexity is directly proportional to bitrate in any case.

~MiSfit

If you have neither bitrate not vbv-maxrate limits, with the same source and same all the other parameters the two encodings - CABAC vs NO-CABAC - should have the same metrics. . Ofcource there is a problem here because you really need vbv-maxrate defined (especially if CABAC = ON) to ensure proper playback of difficult scenes.
I dont know how trellis 2 vs trellis 1 can trigger the equivalence.

Then you have two encodings with same quality and about 10% different bitrates to compare for playability

LoRd_MuldeR

10th July 2009, 01:20

Playing my x264-encoded 1080p H.264 stream (CRF=21, CABAC enabled) in QuickTime I get ~42% CPU usage. MPlayer plays the very same stream with ~20% CPU usage :sly:

Dark Shikari

10th July 2009, 02:00

If you have neither bitrate not vbv-maxrate limits, with the same source and same all the other parameters the two encodings - CABAC vs NO-CABAC - should have the same metrics. . Ofcource there is a problem here because you really need vbv-maxrate defined (especially if CABAC = ON) to ensure proper playback of difficult scenes.
I dont know how trellis 2 vs trellis 1 can trigger the equivalence.

Then you have two encodings with same quality and about 10% different bitrates to compare for playabilityRDO will give different results with CABAC vs CAVLC.

Razorholt

10th July 2009, 04:21

Playing my x264-encoded 1080p H.264 stream (CRF=21, CABAC enabled) in QuickTime I get ~42% CPU usage. MPlayer plays the very same stream with ~20% CPU usage :sly:

But mplayer can't be embbed in a web page, can it? :o

Dark Shikari

10th July 2009, 04:28

But mplayer can't be embbed in a web page, can it? :oSure it can, using mplayerplugin. But any smart person would use Flash, not a media player plugin, for web video, right?

right?

Razorholt

10th July 2009, 04:47

Sure it can, using mplayerplugin. But any smart person would use Flash, not a media player plugin, for web video, right?

right?

I guess I'm stupid then because I never liked Flash player - and probably never will - until it provides a constant frame rates without eating too much CPU. Flash is good for checking videos, not watching movies - that's my opinion. Seriously, are you going to sell me solutions such as Brighcove's? Well, I'll stop right there because I don't want to go OT :)

So, mplayerplugin huh? Thanks, I'll check it :D

- Dan

Dark Shikari

10th July 2009, 05:22

I guess I'm stupid then because I never liked Flash player - and probably never will - until it provides a constant frame rates without eating too much CPU.Wait, this thread is a joke then, right?

Flash eats too much CPU, so you look around and find the only player slower than Flash and use it instead?

And then you proceed to make a thread complaining about CPU usage in that player?

Razorholt

10th July 2009, 05:35

Dark Shikari

10th July 2009, 05:40

Wait wait. I didn't make the decision to use quicktime, as I said in the first post. My client didn't want (his choice, remember) to use Flash. You disagree, fine. Now, on a personal note I don't like Flash to watch full-length movies in DVD or HD quality because it's crap.No, you're just contradicting yourself repeatedly. Again, you claimed Flash is bad because it was slow, yet you believe Quicktime (even slower than Flash) is a valid alternative. What color is the sky in your world?Am I ruining your evening? :)No, I'm actually getting a pretty good laugh out of you.

Razorholt

10th July 2009, 06:05

No, you're just contradicting yourself repeatedly. Again, you claimed Flash is bad because it was slow, yet you believe Quicktime (even slower than Flash) is a valid alternative. What color is the sky in your world?
Ok, young man. I do respect your work a lot and I think you're doing an amazing job on the x264 development but here, you're not good. First, I didn't say that I picked QuickTime as an alternative to Flash because in fact I DO NOT like QuickTime. Yes? Second, Flash is not slow... It just that it can't play a video at a constant bitrate (above 1mb) on an average PC. Oh and the sky in my world is blue, so what?

No, I'm actually getting a pretty good laugh out of you.
mean

plonk420

10th July 2009, 07:54

not sure what's being said, but i just tested near-DVD quality high profile (with CABAC) @ 1.6mbit ~700x572@25 via flash 10 with no issues... on probably an "average pc" .. E4400 (2ghz). even took it down to 1.2ghz, too. was NEARLY maxing a core, but still 10-15% headroom.

LoRd_MuldeR

10th July 2009, 12:39

But mplayer can't be embbed in a web page, can it? :o

VLC Player ships with a browser plugin. And its H.264 decoder is the same as used by MPlayer, ffdshow and friends ;)

Anyway, it seems Flashplayer currently is the most convenient option to embed H.264 video in a web-site...

benwaggoner

14th July 2009, 01:10

Flash eats too much CPU, so you look around and find the only player slower than Flash and use it instead?

Is it really slower?

I can get 1080p to play back with QuickTime at least some of the time, but never with Flash.

I don't know if that's the decoder or the pipeline, though. QuickTime at least will use hardware YUV to RGB conversion and hardware stretch. While Flash in theory does GPU scaling, I've never actually seen it work on a 1920x1200 or larger display.

Dark Shikari

14th July 2009, 01:14

Is it really slower?

I can get 1080p to play back with QuickTime at least some of the time, but never with Flash.Last time I heard CABAC made Quicktime decoding something like twice as slow...

benwaggoner

14th July 2009, 01:17

Last time I heard CABC made Quicktime decoding something like twice as slow...
That wouldn't be surprising. Apple's never had CABAC encoding so I doubt they've optimized much for it.

I wonder how thier 8x8 block and multiple reference frame performance is...

St Devious

14th July 2009, 18:17

VLC Player ships with a browser plugin. And its H.264 decoder is the same as used by MPlayer, ffdshow and friends ;)

so can you use this plugin to play Flash content on the web ? or how is this plugin used ?

LoRd_MuldeR

14th July 2009, 20:00

so can you use this plugin to play Flash content on the web ? or how is this plugin used ?

You can simply embed a MP4 file, containing H.264 video, in your web-site and the VLC plugin (if installed) will take care of this.

Flash (Player) won't be involved at all...

St Devious

14th July 2009, 21:13

You can simply embed a MP4 file, containing H.264 video, in your web-site and the VLC plugin (if installed) will take care of this.

Flash (Player) won't be involved at all...

can youtube videos and other flash videos using H.264 be played using this ?

SeeMoreDigital

14th July 2009, 21:50

Hi Razorholt,

These are the x264 encoding options I use for my QT7 compatible encodes: -
cabac=0 / ref=4 / deblock=1:0:0 / analyse=0x1:0x13 / me=umh / subme=6 / psy_rd=1.0:0.0 / mixed_ref=0 /
me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 /
threads=3 / nr=0 / decimate=1 / mbaff=0 / bframes=2 / b_pyramid=0 / b_adapt=1 / b_bias=0 / direct=3 /
wpredb=0 / keyint=250 / keyint_min=25 / scenecut=40(pre) / rc=2pass / bitrate=1000 / ratetol=1.0 /
qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30 /
aq=1:1.00 / cabac=0 / ref=4 / deblock=1:0:0 / analyse=0x1:0x131 / me=umh / subme=6 / psy_rd=1.0:0.0 /
mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 /
chroma_qp_offset=-2 / threads=3 / nr=0 / decimate=1 / mbaff=0 / bframes=2 / b_pyramid=0 / b_adapt=1 /
b_bias=0 / direct=3 / wpredb=0 / keyint=250 / keyint_min=25 / scenecut=40(pre) / rc=2pass /
bitrate=1000 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 /
ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00

Cheers

Razorholt

14th July 2009, 23:56

Thanks SeeMoreDigital, I'll give it a try tonight :)

-Dan