Doom10 Forum: Digital Video Discussion

Encoded in Lagarith, muxed with timecode
http://38.108.124.213/x264/Sample-Source.mkv

Otherwise, timecode also available here:
http://38.108.124.213/x264/Sample.tmc

Sorry for the delay.

Actually I found the problem. Somehow the "corrupted" frames were given a frame mean quantizer of 48 which obviously looks terrible.

So giving x264 a timecode file doesn't change the vbv behaviour?

I prepared a sample but don't think it is needed?

I meant x264 settings so that I could make that sample encode as fast as possible without affecting the selection of refs. Thanks for the script anyway, I was thinking about using something on the lines of that

Wouldn't the faster setting make x264 not able to use reference frame because it didn't try hard enough?

AQ and psy-rd still make a huge difference in grain and dithering retention even in the CRF 12-15 range. For such sources, bumping those up some from the --tune animation settings is usually a lot more efficient than lowering CRF.

I usually remove all the grains very carefully so grain retention rarely matters. My x264 setting is quite close to placebo so tuning it to animation won't make a difference.

You add the dither prior to feeding the source into x264, so you should just compare how good is the dither in avisynth, with something like interleave(clip1,clip2).

Then the SSIM in x264 will then tell you how much of those dither is lost in compression.

Quite a late reply but I finally managed to do a proper comparative test.

The following setting is used:

"C:\x264-1649.exe" --crf 13 --fullrange "on" --colorprim "smpte170m" --transfer "smpte170m" --colormatrix "smpte170m" --keyint 240 --min-keyint24 --ref 16 --no-fast-pskip --bframes 6 --b-adapt 2 --b-pyramid normal --deblock -2:-2 --subme 10 --trellis 2 --psy-rd 0.6:0.0 --partitions all --me umh --merange 32 --threads 1 --thread-input --qcomp 0.84 --aq-strength 0.3 --no-dct-decimate --psnr --ssim --vbv-maxrate 15000 --vbv-bufsize 15000

Source is Anime DVD with 32232 Frames. 19385 Frames remaining after dedup. (Typically the drop rate % is around 15-25%, although I've seen as high as 67% on Ichizon) 
Both versions are TTempsmoothed in the last stage of processing at (maxr=7,strength=8,fp=true)
A masked merge with a motion mask is used to "restore" artifacts created by fp=true.

A couple of soft tricks were used to "tune" dedup and TTempsmooth to work better on anime content with low noise using very low thresholds. The filtered source is very clean in static sections. Motion parts won't be dedupped so the source will be the same for those parts.

Deduped Result:

avs [info]: 720x480p 0:0 @ 24000/1001 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.0
x264 [info]: frame I:184   Avg QP:11.27  size: 57289  PSNR Mean Y:54.48 U:57.76 V:57.31 Avg:55.23 Global:54.86
x264 [info]: frame P:5103  Avg QP:14.09  size: 16076  PSNR Mean Y:52.03 U:55.38 V:55.08 Avg:52.83 Global:52.25
x264 [info]: frame B:14098 Avg QP:15.79  size:  8948  PSNR Mean Y:51.28 U:54.79 V:54.57 Avg:52.13 Global:51.52
x264 [info]: consecutive B-frames:  4.6%  4.5% 10.5% 27.9% 22.4% 19.7% 10.3%
x264 [info]: mb I  I16..4: 18.7% 33.3% 48.1%
x264 [info]: mb P  I16..4:  3.0%  3.3%  2.9%  P16..4: 30.0% 12.7%  5.3%  1.1%  0.6%    skip:41.1%
x264 [info]: mb B  I16..4:  0.4%  0.3%  0.4%  B16..8: 19.9%  8.9%  4.0%  direct: 6.3%  skip:59.8%  L0:44.6% L1:40.7% BI:14.7%
x264 [info]: 8x8 transform intra:33.3% inter:29.8%
x264 [info]: coded y,uvDC,uvAC intra: 45.2% 55.5% 43.1% inter: 18.5% 19.8% 9.1%
x264 [info]: i16 v,h,dc,p: 60% 24%  7%  9%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 23% 14% 32%  5%  5%  5%  5%  5%  6%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 31% 12% 13%  7%  8%  9%  6%  7%  6%
x264 [info]: i8c dc,h,v,p: 49% 20% 24%  7%
x264 [info]: Weighted P-Frames: Y:3.6%
x264 [info]: ref P L0: 50.8%  3.3% 11.9%  6.6%  4.4%  4.4%  3.1%  2.5%  2.0%  2.1%  1.8%  2.3%  1.4%  1.4%  1.1%  1.1%
x264 [info]: ref B L0: 58.9% 12.8%  6.3%  4.3%  2.9%  2.7%  2.2%  1.7%  1.4%  1.5%  1.4%  1.9%  1.2%  0.6%  0.3%
x264 [info]: ref B L1: 91.0%  9.0%
x264 [info]: SSIM Mean Y:0.9972241 (25.566db)
x264 [info]: PSNR Mean Y:51.511 U:54.975 V:54.729 Avg:52.347 Global:51.720 kb/s:2164.20

encoded 19385 frames, 3.58 fps, 2164.21 kb/s

Without Dedup:

avs [info]: 720x480p 0:0 @ 24000/1001 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.0
x264 [info]: frame I:222   Avg QP:11.13  size: 57396  PSNR Mean Y:54.77 U:58.10 V:57.72 Avg:55.52 Global:55.07
x264 [info]: frame P:11702 Avg QP:14.07  size:  9181  PSNR Mean Y:52.49 U:56.03 V:55.77 Avg:53.31 Global:52.55
x264 [info]: frame B:20308 Avg QP:15.69  size:  5762  PSNR Mean Y:51.33 U:54.83 V:54.67 Avg:52.18 Global:51.66
x264 [info]: consecutive B-frames: 15.9%  5.9%  7.9% 35.5% 16.5% 12.8%  5.4%
x264 [info]: mb I  I16..4: 20.4% 32.3% 47.3%
x264 [info]: mb P  I16..4:  1.5%  1.6%  1.3%  P16..4: 21.4%  7.2%  3.5%  0.7%  0.4%    skip:62.4%
x264 [info]: mb B  I16..4:  0.2%  0.2%  0.2%  B16..8: 17.7%  5.6%  2.3%  direct: 4.7%  skip:69.2%  L0:42.7% L1:44.7% BI:12.6%
x264 [info]: 8x8 transform intra:34.3% inter:29.8%
x264 [info]: coded y,uvDC,uvAC intra: 44.1% 54.5% 43.0% inter: 12.5% 13.6% 6.9%
x264 [info]: i16 v,h,dc,p: 61% 23%  7%  9%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 13% 34%  5%  5%  5%  5%  5%  6%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 31% 12% 14%  7%  8%  9%  6%  7%  6%
x264 [info]: i8c dc,h,v,p: 50% 20% 24%  6%
x264 [info]: Weighted P-Frames: Y:1.6%
x264 [info]: ref P L0: 56.6%  2.8% 10.0%  5.3%  3.4%  3.5%  2.5%  2.1%  2.0%  2.5%  2.0%  2.3%  1.5%  1.3%  1.1%  1.0%
x264 [info]: ref B L0: 62.1% 11.8%  5.5%  3.7%  2.2%  2.0%  1.7%  1.7%  1.3%  1.7%  1.6%  2.3%  1.1%  0.7%  0.5%
x264 [info]: ref B L1: 93.9%  6.1%
x264 [info]: SSIM Mean Y:0.9973853 (25.826db)
x264 [info]: PSNR Mean Y:51.774 U:55.290 V:55.089 Avg:52.616 Global:51.983 kb/s:1411.58

encoded 32232 frames, 3.95 fps, 1411.58 kb/s

Final file size:
VFR 218,870,440 bytes
CFR 237,442,955 bytes (+8.5%)

Saving of about 18MB. Scale it up to 1080P it would be 106M, bang on what I said before. However loosing 0.25~0.3db of SSIM/PSNR is probably where some of the saving is coming from.

I think the valid way of testing the effect of deduping is probably encode with constant quantizer mode. (Which btw is what I used until joining Doom10!). Although I have to say the compression saving (or not) is highly influenced by the filters used after dedup and obviously the source.

Download TDeint and put it in your avisynth plugin folder, then stick the following in a notepad
MPEG2Source("yourd2vpath.d2v",cpu=4)
TDeint
and save it to an .avs file somewhere, use that avs as the input file for x264

Use the 32bit x264. The 64bit x264 require some extra programs and modification to the cli command to run.

This is really no significant different from what handbrake is already doing. If you are intended to start more professional in encoding then do the Avisynth way. Otherwise you are just wasting your own time doing what all the GUI does in a long-winded way. Avisynth filters need hours if not hundreds of hours to master.

Since x264 doesn't handle audio at all, you will need to remux after encoding. The vob also need some processing, like deinterlacing.

Try something like this http://www.digital-digest.com/articles/MeGUI_H.264_Conversion_Guide_page1.html

TTempsmooth works on a pixel level so strong mosquito noise are usually not filtered by ttempsmooth unless you have a high threshold. The temporal range is also limited, which means the result you get from averaging (N-7 to N+7) current frame, is NOT the same as (N-6 to N+8) next frame. That small difference wastes bits. I guess that also depends on your x264 setting, as a wild guess perhaps dct decimation?

On the other hand Dedup detection is on a block level so it can deal with some strong noise, particular with trigger2, threshold2 and range2. If you temporal denoise after Dedup you effectively get a larger temporal radius.

Dedup is helping the denoiser, as well as helping the x264 encoder to make better use of reference frames.

Duplicate frames are compressed to zero (after CABAC, they use ~1byte/frame). VFR is a hack; it is not a compression tool.

Unless you have the original source before any artificial noise/grains are added, the "duplicate" frames are never compressed to zero. Even with quite heavy temporal smoothing I still get somewhere in the range of 200 bytes to 7kb per "duplicate" frame.

There are two types of VFR, one is mixing clips with different base rate, the other one is to have all sort of different rates as low as 1.2FPS (1Pass Dedup). I personally find that Deduping (probably a better word than VFR which confuses with the other type) saves between 2000-16000 frames per episode of anime. Most samples I've tried the bitrate saving is as high as 3 CRF. The preset is not so much the issue, the key part really is --ref 16 unless you want your encoding to be DXVA compatible which you're stuck with whatever the resolution allows.

The saving comes from the reduced number of i-frames, better use of reference frames and from temporal smoothing.

The main problem with Dedup is unless you come up with some really good hack (assisting dedup to identify what is detail and what is noise), you're going to drop a lot of details from your clip. Noise could be as high as 0.9% but a small mouth movement or a moving cloud will only register 0.3%. Set the dedup threshold too low you don't drop enough duplicates to benefit from it and setting it too high your encoding will be jerky.

Depends on how resource-intensive is your Dedup hack if you have one and your x264 setting, you might actually see your encoding time increases. I also frequently see dedup skipping so much frames that dgavc is giving decoding error on h264 sources, essentially requiring lossless pass prior to dedup().

Seekability is NOT affected because any given frame is still only as far away to the keyframe as the interval. I couldn't see the point of using Dedup on live action because there is hardly anything that is 100% still.

What settings are you using when you say "encoding it normally"?

--crf 13 --ref 16 --no-fast-pskip --bframes 6 --b-adapt 2 --b-pyramid normal --deblock -2:-2 --subme 10 --trellis 2 --psy-rd 0.6:0.0 --partitions all --me umh --merange 32 --threads 1 --thread-input --qcomp 0.84 --aq-strength 0.3 --no-dct-decimate --psnr --ssim --qpmin 10

The above profile is the one I use for anime normally.

Hi!

I usually encode with the default profile at CRF 15 and was wondering: If blocking primarily occurs in frames not receiving enough bits, does that mean it would be best to disable deblocking at something like CRF 15?

Other modifications you would suggest to the default settings at CRF 15? I just want one good general setting to use, hard drive space obviously is not the biggest concern.

The actual quantizer used for each given block is depending on qcomp, aq and mbtree. While you set CRF 15 there could be a lot of blocks could have a quantizer of over 22, which you definitely need some deblocking.

If space is not the biggest concern then just use the standard profile. If not then use something like --preset "veryslow" or even "placebo". I usually use -2:-2 for all contents. For animation I use CRF 12 for SD, CRF 13 for 720P, CRF 14 for 1080P, add 3 for non-animation footage, in conjunction with settings somewhere between veryslow and placebo.

Hm, ok, but why doesn't the problem appear to VirtualDubMod ? If the whole thing would be so memory consuming, VDM should also quit working and complaining about the lack of free mem ...

Another thing:
basically it's 5 single scripts that produce me the clips and one that "merges" them. So I assume the moment I open the main script, all other get loaded into memory which eventually might cause the hassle ... Is it possible to drop the instance after it's been processed to free som mem for the next part ?

If you are planning to use mkv as the final container, you can just encode the 5 parts separately and merge them later with mkvmerge.

Personally I find that manually setting SetMemoryMax does not work very well. If I set something too low the script stalls to like 0.02FPS. If I set it too high it just waste ram.

Encoding to a lossless pass then encode allow you to use the 64bit x264 (unless you use 64bit avisynth plugins only, which is highly unlikely). Don't know if Huffyuv has 64bit version, but Lagarith certainly does

Depends on your DVD, you may need to deinterlace instead of IVTC.

The safe bet is usually do

srcclip = MPEG2Source(whatever)
deintclip = srcclip.TDeint()
ivtcclip = srcclip.TFM(pp=7,clip2=deintclip).TDecimate()

Could replace the pp=7 to pp=4 if there is still a problem, or adjust the cthresh value higher or lower.
There is not much point doing VFR encoding here, if you make the section 30P the scene will be jerky, if you make it 24P the moving text will be jerky and there is no easy way of fixing it.