CoreAVC's options when source filter for encode.

[mitsubishi]

Hi, I have started trying x264 out. I'm using staxrip and meGUI as well as using them to learn the command line.

I think I've finally figured out what DGIndex does, but it won't work with my BBC HD source. So what I'm doing is demuxing out ac3 with projectX, encoding video, then manually cutting the audio with besplit and muxing it in.

So far my AVS is:DirectShowSource("L:\Planet Earth E6 - Ice Worlds.ts")
Crop(2,2,-2,-2)
LanczosResize(960,544)
Trim(9568,10568)
ConvertToYV12()(for a section for testing)
and I've tried a few profiles, but am still getting blockiness in the skies, at 4k bitrate for 2 hours per DVD, but I've read some things to try for that.

Anyway I'm just mentioning my process in case there are any comments to it, particularly the resize (1440x1080 - 1964x1088?).

My actual question is about what should coreAVC's settings be when using an AVC source. If I leave de-interlacing on 'software' does that mean my deinterlacing is done and I don't have to worry about the mbaff in the source? What do the options mean? And then there is deblocking, we are all told to turn it off for playback unless our PCs are high-end, but should it be on for re-encoding.

Thanks, and sorry for ruining your day if I have asked a stupid question. :o

[Oxygen]

I don't know how you managed to make your AVS filter work with coreavc, i never could have a working avs file with coreavc, elecard takes over all the time :/

[DarkZell666]

@Oxygen : A couple of tools allow you to tweak directshow filter merits (DSFManager for example). So you can give CoreAVC a higher merit, or lower elecard's.

@mitsubishi: indeed, checking the deinterlacing in CoreAVC decoder means that the deinterlacing is done with and you don't need to worry about it.

I don't use CoreAVC personnally, but there is "Deblocking vs. Deblocking" (no joke, read on ;)).

Deblocking is either a post-processing option (which is what it means for DivX and XviD for example), or AVC's encoding feature.

In your case, you should have it turned on in CoreAVC (since it isn't the post-processing option you might have thought it was ;)). In fact, I'm surprised they made this an option, since AVC deblocking should always be turned on while decoding. Maybe it was indeed to help playback on low-end PC's.

[mitsubishi]

Thanks, yeah I had another read through the CoreAVC thread and discovered deblocking is part of the AVC specs and the off option was only added to Core to to aid decoding speed. On the original BBC streams the only difference I notice is that my E6300 gets choked in complex scenes, on my encodes it removes the blocking I was originally unhappy with with little CPU impact.

I sort of thought I understood interlacing, except for its relevance in digital until I read about mbaff. So I guess for now I'll just leave it on 'software' and hope that's best. I tried 'double framerate' expecting to get twice the frame count and at 50fps but didn't. Does it do that for standard interlacing?

I've been continuing to play around and am getting more comftable with all the 'stuff', trying 'CQ-ASP_Q2_eq(crf)' at 18 yields 5354 kbit/s and 'HQ-SLOW' is a bit quicker than '1p-Good quality'.

Well I tried this:

a=DirectShowSource("D:\test\test.ts").LanczosResize(944,528).Trim(436,1724).ConvertToYV12()
b=DirectShowSource("D:\test\1.mp4").FlipVertical()
# return ssim(a,b,"results.csv","averageSSIM.txt",lumimask=true)
StackVertical(a,b)
and it seems that the frames sometimes get out of sync, guess that's directshows fault, but it shouldn't matter when just just doing an encode from start to finish should it?


What I have been able to do now is after demuxing video with TSConverter, editing it in a Hex editor as per a post by Bond and renaming it .264 I can now open it in MPC and mp4box recognises it. However when I try to mux it, CLI or Yamb, it crashes.


Unhandled exception at 0x0046ee75 in MP4Box.exe: 0xC0000005: Access violation reading location 0x00000010.

[mitsubishi]

For what it's worth, these are my results so far1P-Intermediate 4500 - 3m22 - 4569 kbit/s
SSIM= 77.85
SSIM Mean Y:0.9712780

1p-Good quality 4500 - 5m46 - 4581 kbit/s
Average SSIM= 79.31
SSIM Mean Y:0.9734502

1p-Maxspeed 4500 - 1m46 - 4628 kbit/s
SSIM= 72.19
SSIM Mean Y:0.9623200

CQ-ASP_Q2_eq(crf) 18 - 6m46 - 5354 kbit/s
SSIM= 81.94
SSIM Mean Y:0.9768508

HQ-Insane 4500 - 32m58 - 16m51 - 16m07 - 4523 kbit/s
SSIM= 80.16
SSIM Mean Y:0.9742818

HQ-Slowest 4500 - 14m15 - 2m02- 12m13 - 4524 kbit/s
SSIM= 80.01
SSIM Mean Y:0.9741067

HQ-Slower 4500 - 9m19 - 2m05 - 7m14 - 4524 kbit/s
SSIM= 79.68
SSIM Mean Y:0.9738298

HQ-SLOW 4500 - 7m12 - 2m04 - 5m08 - 4525 kbit/s
SSIM= 79.45
SSIM Mean Y:0.9734839
Clearly I'm not entirely sure what I'm doing yet and plan to do a full test when I do. Hopefully these ssim's are where they should be.
It seems 'HQ-Slowest' is the best for me for now, with '1p-Good quality' resonable for speed.

[Daodan]

Hmm..is that ssim from x264 or you calculated it with external filters? Because that value is rather horrible. I remember an encode at crf 27 that gave me SSIM 94. I don't want to imagine how 80 would look like.

[mitsubishi]

Ah, you know I didn't know x264 outputted a value, I've extracted it from the logs and added in to my post above. The other value is from the avisynth plugin:
a=DirectShowSource("D:\test\test.ts", audio=false).LanczosResize(944,528).Trim(436,1724).ConvertToYV12()
b=DirectShowSource("D:\test\8.mp4", audio=false)
return ssim(a,b,"results.csv","averageSSIM.txt",lumimask=true)Of course now I'll have to graph the two results to see the curve.... (IIRC it is an 8th power)


EDIT: http://forum.doom9.org/showthread.php?t=61128 Yes it is 100(x^8) which more or less fits, just a slightly higher result with x264. 0.94 would only be 60.96 on this scale, probably 59ish taking into account the higher results from x264.