Why is decoding this such a slideshow??

[Blue_MiSfit]

Hey all,

So A friend of mine is lucky enough to have bought a Canon XL-H1 Camera. This badass mackdaddy records 1080i/p 720p / 480i/p at all kinds of frame rates. It's a fantastic camera. I got about 4 gigs of test clips from him, and have set about x264ing the lot of them.

I did one today, a relatively high motion 2.5 minute clip (roughly) depicting birds in a fountain. It's 1080, and a MeGUI analysis determined it is a hybrid progressive / interlaced, with the vast majority being progressive. I wanted to kill the interlaced bits, so I used the MeGUI suggestion for deinterlacing. Script:

LoadPlugin("D:\Archives\Video Software\AviSynth Plugins\Common\RemoveGrainSSE3.dll")
DGDecode_mpeg2source("C:\Documents and Settings\misfit\Desktop\XL-H1 Tests\Birds-1.d2v",info=3)
trim(0,2000)

ColorMatrix(hints=true)
edeintted = last.SeparateFields().SelectEven().EEDI2(field=-1)
TDeint(full=false,edeint=edeintted)

removegrain(mode=5)
crop(0,4,0,-4)


There is moving vegetation in the background and the birds are splashing water everywhere. I tried to encode at CRF 18, which produced spectacular results, but unfortunately is unwatchable due to (I think) bitrate spikes. I can watch properly encoded 1080p AVC just fine (at least the Apple trailers).

I am using CoreAVC (the old free version) to decode.

What do you guys think? Is this related to just too much bitrate? I am assuming that the VBV buffer is not taken into consideration when doing 1 pass CRF? And also that I would have to use 2 pass to make VBV work? What do you think I should set VBV to?

I will try to get some samples posted up.

Suggestions !


samples up. the clip is so short that you barely see the issue im talking about, but you get the idea.

http://rapidshare.de/files/26590317/XL-H1_Tests.rar.html


~MiSfit

[GodofaGap]

Due to CABAC decoding high-bitrate content is more CPU intensive than low-bitrate content. You could try --crf 22, 24 or 26 and see how that works out for you.

[CruNcher]

and try to disable inloop

[check]

QT uses a version of h264 which is only baseline profile, ie none of the fancy features of h264 are actually in use. x264 can use main and high profile features - this is where the slowdown is coming from.

btw, there is no free version of coreavc - you are not allowed to use/distribute the 0.0.0.4 alpha (or any other version :P)

[Manao]

QT uses a version of h264 which is only baseline profileNo. It's main profile, without mbaff/paff/interlaced, and without more than 1 bframe. Apples trailers, iirc, are using cavlc instead of cabac, and are made easy to decode ( hell, seeing how slow QT is for decoding, if they weren't easy, nobody would be able to use QT to play them ).

[check]

I thought the only setting from main profile that was used was 1 b-frame?

[Blue_MiSfit]

Damn. I dont even know where I came across that version. I will buy CoreAVC as soon as my paycheck comes in next month. I use it so often I feel bad about not having it :)

Anyway, I will encode a couple more tonight with 2 pass to see if I can get the VBV buffer to fix things...

[GodofaGap]

I can't imagine what VBV will fix for you. The bitrate of a video at crf 18 should be well below the read rate of your harddisk.

[foxyshadis]

But not CPU. Most of the seriously intensive settings are fairly constant over the length of a stream, except bitrate. When bitrate doubles, cpu utilization to decode CABAC also doubles, which is already a significant fraction of the decode time, and can put serious strain on a CPU normally near its limits. VBV can keep it to a maximum that can't overwhelm the CPU. High bitrate areas also typically have more motion vectors and less skips, but VBV will only slightly reduce that, if at all.

[*.mp4 guy]

Swithching to CAVLC is probably the easiest way to get smooth decoding, the only other significant speed up options are lowering the bitrate and turning off deblocking

[check]

has anyone done tests comparing the CPU % of a --crf # with and without CABAC? It would be interesting to see which is more efficient in terms of CPU decoding power.

[GodofaGap]

check: CAVLC is less CPU hungry

foxyshadis: bitrate and CPU consumption on overall decoding are not 1:1 with CABAC.

[Manao]

decoding time ~= bitrate * alpha + resolution * beta. At quantizers 20-23, bitrate * alpha ~ resolution * beta. ( 20-23 is a wild guess ). Alpha and beta are constant depending on the decoder and the decoding computer ( for example, beta is quite low whenever a hardware accelerator is used ).

That means that at very high bitrates and fixed resolution, decoding time = bitrate * alpha + constant, with bitrate * alpha >> constant, so decoding time ~= bitrate * alpha.

At very low bitrates, however, it's the resolution that matters the most.

Finally, deblocking is roughly 30 to 50% of the resolution * beta factor ( depending - of course - of whether or not it's used, and of the percentage of skips, which depends on the bitrate, which complicates everything at low bitrates... ).

[Blue_MiSfit]

Well then I will try CAVLC, 2 pass with VBV, no deblocking, and a lower overall bitrate.

It will be nice when decoding AVC is as easy as decoding MPEG-2 is currently. These 1080i MPEG-2 clips bobbed to 60fps on playback are really quite impressive.

[foxyshadis]

I don't think you need to ratchet the bitrate down too far; in fact, if you're going to use CAVLC, you might want more of it instead. For instance, a quick test with a 10 sec 20Mbps CABAC vs 25Mbps CAVLC, the former required 19 seconds to play and the latter 14 seconds, via ffdshow.

(Core is realtime for both, thanks to dual-core and all that, but interestingly, uses nearly the same amount of CPU time on both - in other words, they've found a way to reduce the decoding overhead of CABAC significantly. This is a much newer version than yours, though it's still pre-1.0, so it may not hold entirely true.)

[foxyshadis]

Something really weird I just noticed: x264 isn't giving me any b-frames on 1080p video, whether the bitrate is high or low. Smaler movies with the same profile work fine. Is it a bug, or is there something about the resolution that precludes b-frames?

It could be that it's just my test sequences though, I only have a few and they're pretty short and complex stuff.

[Blue_MiSfit]

an update.

When I disable CABAC, and the inloop filter, things are perfect when decoding with CoreAVC pro (I bought it :) )

I think the original MPEG-2 when bobbed looked a little bit better, just in terms of crispness of motion etc.

[Awatef]

Hey Blue, just thought that it doesn't make sense that your clip is hybrid.
The only thing that I can think of to explain this is that some portions have shifted fields, which make things *look* interlaced but actually aren't. So you just have to use Telecide from the Decomb package to reassemble the fields correctly ;)

[smok3]

i have used:

--bitrate 8000 --nf --no-cabac --subme 1 --no-chroma-me --analyse none --me dia --threads 4 --thread-input --progress --no-psnr

for my latest 1280x720p stuff and it decodes smooth (at least with coreavc and with mplayer when run with higherpriority) on my athlon clocked at 1.8 giga.

(this cmd happened with a help from some users from this forums)

edit: encoding was done on dual xeon, so thats why i used all this threads...

[Blue_MiSfit]

@ Awatef:

I know it seems unlikely, especially considering the source is a Canon XL-H1 camera shooting in 1080i60. This is what the MeGUI analysis suggested I use, so I used it :)

[Awatef]

Well, don't trust those analysers too much.
There may be some combing, but definitely not an "interlacing-combing" but "shifting-combing". I get this type of combing when capturing: sometimes the capture software drops a frame after having stored only one field of the previous frame and then oops! the following frames get stored delayed, say the odd field in one frame, the even field in the next one, or vice-versa, etc
So Telecide should be more than enough, no need for sophisticated deinterlacing techniques.

[nm]

Am I missing something here? The camera can shoot at 1080i60 and that is interlaced, not telecined 24 fps.

[Awatef]

Yup, you're missing something :D
He said in his opening post, it can do 1080p too.