x264 HQ-Slow beautiful: Suggestions to speed up with higher bitrates...

[sjchmura]

So I have been doing alot of encoding of HD transport streams to MP4 (megui/x264). HQ-slow is stunning.

So most encodes are 1080i->720p (or 720p) to smaller. At bitrates between about 4000 for 720p.

On my AMD4400x2+ HQ-slow is quite slow.

I have gone through the multithreaded AVISynth and there is some speed improvement (I think) with complex scripts. Also switching from undot() to denoise() helped alot.

However, if I were to experiment with options to speed up HQ-Slow at this higher bitrates what do people suggest are the first few settings I play with and what impact does that have on the codec?

Thanks for any suggestions...

[nm]

If you don't need to have the result fit within a specific filesize, use 'constant quality' (CRF) instead of two pass encoding. Otherwise, check what people are doing here: http://forum.doom9.org/showthread.php?t=116773

With CRF, you'll save the (fast) first pass encoding time and the first filtering pass, which may be significant depending on your AVISynth script.

[shon3i]

maybe me range 8 can help, try to disable cabac, use main profile, aslo RemoveGrain (mode=1) have same effect like UnDot, but much faster, and there is SSE2 i SSE3, so you can use it for max speedup

[sjchmura]

Thanks for the tips - I will read them:

Yes, REMOVEGRAIN (mode=1) is MUCH faster than undot().

The CRF idea is great - that will save the whole first pass which is usually 1/2 that of realtime!

Thanks again. Will experiment

[IgorC]

If the source is clean deblocking filter is more than enough.
Just adjust the level of deblock.
Simply speaking deblock is most smart denoiser to preserve details and remove unwanted noise. It's codec feature. It is smart cause of it's not only some prefiltering but also brings some info to decoder

H.264 is not ASP. There is no need for preprocessing for high quality sources.

[Sharktooth]

main vs high profile = no speedup.

[shon3i]

main vs high profile = no speedup.
Yes it have, but in my case, on my computer. Oh his AMD4400x2+ that is probably transparent

[sjchmura]

But many MPEG2 OTA HDTV transport streams are low enough bitrate to where adding the MPEG2 deblocking (from DGINDEX cpu=3) can help. In addition, the "undot()" will increase compression ratio since there are still alot of film artifacts etc.

It is my understanding that the deblocking for the MPEG4 is stickt;ly to prevent playback blocking - it will nto "fix" the OTA HDTV source that is broadcast at to low of a bitrate to prevent the fast moving action "blocks".

[Blue_MiSfit]

That's correct. AVC deblocking will not fix existing blocks in the source, it will only help reduce blocks introduced by AVC compression.

DGDecode's deblocker is very good - I haven't had much experience with others.

RemoveGrain(mode=1) or mode=5 will give you basically a 'free' compressibility boost, while not visibly affecting the image aside from maybe killing a bit of noise. mode=2 is a bit stronger. All of these (provided that you use the SSE / SSE2 / SSE3 DLLs) will be very very fast.

~MiSfit

[IgorC]

It is my understanding that the deblocking for the MPEG4 is stickt;ly to prevent playback blocking
What you mean by MPEG-4? ASP or AVC? or Both?
AVC's Deblock and ASP postprocessing aren't the same thing.

Something like deblock 0:0 won't left neither one filmgrain pixel.
Deblock can be strong as heavy filters like fft.

[rack04]

That's correct. AVC deblocking will not fix existing blocks in the source, it will only help reduce blocks introduced by AVC compression.

DGDecode's deblocker is very good - I haven't had much experience with others.

RemoveGrain(mode=1) or mode=5 will give you basically a 'free' compressibility boost, while not visibly affecting the image aside from maybe killing a bit of noise. mode=2 is a bit stronger. All of these (provided that you use the SSE / SSE2 / SSE3 DLLs) will be very very fast.

~MiSfit

Is the SSE RemoveGrain called RemoveGrainS?

[Chainmax]

I read many posts saying that MPEG2Dec3's deblocker was somehow broken and smoother too much, if DGDecode's cpu=3 hasn't improved on it then using it is probably not a good idea. I always use DeBlock_QED for light deblocking as it does a great job and is designed to keep as much detail as possible. If stronger deblocking and/or more speed are needed I switch to DGDecode's DeBlock which is inspired by H.264's deblocking and was originally a part of Manao's MVTools.

[Audionut]

Is the SSE RemoveGrain called RemoveGrainS?

No. It's removegrain.dll. You then have removegrainsse2.dll and removegrainsse3.dll.

I can't remember what the removegrains.dll does. Look at the readme.

[sjchmura]

RemoveGrainSSE2.dll - I could NEVER that to work on my AMD X2 4800+ - but the regular one works great.

I need to read about DeBlock_QED

Would this be good for the MPEG2 OTA HDTV streams that have some block noise in fast moving scenes??

[Chainmax]

No. It's removegrain.dll. You then have removegrainsse2.dll and removegrainsse3.dll.

I can't remember what the removegrains.dll does. Look at the readme.

RemoveGrainS is a static version that doesn't need to have the helper DLLs installed.


RemoveGrainSSE2.dll - I could NEVER that to work on my AMD X2 4800+ - but the regular one works great.

I need to read about DeBlock_QED

Would this be good for the MPEG2 OTA HDTV streams that have some block noise in fast moving scenes??

DeBlock_QED is not as fast as DeBlock (and the cpu=3 switch, I assume), but is supposed to keep more detail than either, so I'd definitely recommend it for detailed sources like the one you mention.

[bkman]

If blocking in the source is not too severe I definitely recommend that you use the "deblock()" (H.264 deblocking) feature of DGDecode instead of the built-in Mpeg-2 deblocker and smoother activated by "cpu=n". It doesn't drop detail like the latter.

[CruNcher]

bkman sorry i cant agree all my tests showed that @ high bitrate mpeg-2 sources with marginal blocking visualy (HVS) manaos H.264 deblock() can't help alot and is suboptimal in a Encoding Speed/Visual Quality (HVS) balance kind of way for me personaly.
At least i like to prefere not useing it in such situations because of the big speed drop it causes for the result i get, but it also has todo with the source and how long the blocks are visible (scene) and the viewer himself and his visual prediction ofcourse, i would never recommend anything for such stuff, it's how your eyes and brain feel about it, everyone has to decide this for himself.

[sjchmura]

DeBlock_QED

So do we need to recompile this for HD ... >720x568 rez??? I saw some threads but was not sure how they were "tricking" the current dll to work....

So is CPU=4 really broken in DGIndex???