Deringing and upscaling help (Avatar), plus some quirks

[bilditup1]

Update: Untouched DVD samples can be found here. (http://forum.doom9.org/showthread.php?p=1706279#post1706279)

Hey all!


Background:

So I've decided to try my hand at enhancing my Avatar: The Last Airbender DVDs so they become watchable. Unfortunately, the DVD master suffers from awful edge enhancement, which as resulted in rings/halos everywhere. Worse, these rings and halos jump around during playback. Just bad all around. I have a very old 'TV Rip' of the show as well, which shows no trace of this (but is, ya know, otherwise awful).
I initially planned on simply upscaling the content. But that didn't account for deringing at all, which is not something I've ever had to deal with before (I'm not that adventurous). Thus began much trial and error to find out how to do my best to minimize these rings if not annihilate them entirely.

This is the script I ended up with, after more than fifty iterations:


#SetMT()
SetMemoryMax(4096)
## ...
## ...
## ...
##
## Load video
##
SetMTMode(5,2)
DGDecode_mpeg2source("D:\Ripping\TV\Avatar\Book1-Water\D1\E1\e1.d2v", info=3)
ColorMatrix(d2v="D:\Ripping\TV\Avatar\Book1-Water\D1\E1\e1.d2v",dest=0,interlaced=true,threads=0)
##
## IVTC
##
SetMTMode(2,8)
tfm(order=1).tdecimate(mode=1,hybrid=1)
##
## Deringing/dehaloing
##
DeHalo_alpha(rx=2.0, ry=2.0, darkstr=0.8, brightstr=2.0, lowsens=50, highsens=50, ss=2.0)
DeHalo_alpha(rx=1.0, ry=1.0, darkstr=0.2, brightstr=0.8, lowsens=50, highsens=50, ss=2.0)
warpdering()
warpdering()
HQDeringmod()
##
## Denoising
##
VagueDenoiser(threshold=2, method=3, nsteps=6, chromaT=2.0)
##
## Resizing
##
nnedi3_rpow2(rfactor=2,cshift="spline64resize",fwidth=1024,fheight=768,nsize=4,nns=4,qual=1)
##
## Sharpening
##
LSFmod(strength=255,ss_x=2,ss_y=2,Smode=3,Smethod=3)
#LSFmod(strength=255,ss_x=2,ss_y=2,Smode=3,Smethod=3)
##
## Anti-aliasing
##
maa2(mask=-15,chroma=true,aa=64,aac=56,threads=4,show=0)


I guess that looks like a bit of overkill. And I admit I wish I were more familiar with what the scripts I am calling are actually doing and how they work. But I tried to keep it clean, specify dependencies, and not load anything that isn't necessary. I also sorted my plugins folder by author, just to keep in mind that all of this is made possible by a team effort, and that we 'stand on the shoulders of giants'. (Pompous yes, but still true.)

Here's a comparison shot:

Original

http://files.nyu.edu/eb1167/html/screens/rips/avatar/01_katara_orig.jpg

Dehaloed and upscaled

http://files.nyu.edu/eb1167/html/screens/rips/avatar/04_katara_b7-709.jpg





Obviously I'm here because I want to refine this script as best I can. For clarity, I'm going to bullet-point for a bit. First, the basics:


I am not familiar with the comparative advantages of different enlargers (*eedis). But, this is what madVR uses for image doubling, so I thought it was a pretty safe choice, and mostly didn't change the settings.
For resizing, I have also been using Spline64 for years, but don't really know if it's appropriate here and haven't experimented with this recently or in this round.
Using a Spline64Resize alone, instead of in conjunction with image doubling - I did this because I was curious to see what the 640x480 image would look like - results in x264 crashing with code 3. I'm assuming that means I configured something wrong with respect to Avisynth MT. Any ideas? I simply replaced the nnedi3_rpow2() call with a Spline64Resize(640,480). My suspicion is that I left the colorspace conversion command in, and that might not play well at this low resolution; I'm going to double-check now...
Note that I chose 1024x768 because it is very likely these will be played back on iPads, and the simple scaling of 4x that resolution I thought could be marginally beneficial to quality. I'm not sure how true this is...? Otherwise I would maybe try for 960x720 for the space savings (approx 12% fewer pixels).
I am unsure whether or not to convert colorspaces and have read conflicting information about it. According to the Avisynth wiki on colorimetry (http://avisynth.nl/index.php/Colorimetry), playback devices will often assume bt.709 for content with a vertical resolution of 720p or higher, never mind whether or not the file is tagged as bt.601. As a result, I did both, on in 601 and one in 709. I've come across others who have been adamant never to do this. I have not yet calibrated my monitor and am having some trouble with levels, so I'm not really sure if the process is destructive or not. Any effect is pretty subtle - I think a sort of yellow-y shift like the pictures on the colorimetry wiki might be happening, but am not sure.
There is some minor aliasing, from what, I don't quite know. So I stuck an AA filter at the end there. But I have not done extensive trial and error of it yet. I suspect that I could dispense with it though. Thoughts?


Now, the real reason I'm here, the haloing...

Currently the images being produced are definitely sharp enough, but the haloing is not completely dealt with. I'm not sure if that's even possible, but I plan on trying my darndest. I added a denoise (Vague) in there to try to clean up what wasn't picked up, but I don't think that did anything but destroy detail. On that note, there is some pretty bad destruction of detail on the iceberg and the water. I don't really care so much about that, given that the iceberg is just a white background object that you're not really looking too closely at, and the water detail is easy to miss even when it's there. But obviously, that's not always going to be true. (For testing, I have stuck to the first three minutes of the pilot episode of the show, 'The Boy in the Iceberg'). So I'm looking for more effective dehaloing with less destruction. I think this may be asking for the moon, but if some marginal improvement can be made, I'd like to know. If screenshots of the source would help, I will happily provide them.
Note that most of my testing, after figuring out how to avoid making AviSynth MT crash, consisted of using different values for DeHalo_alpha in combination with other deringers. I think I have a pretty good feel of what's a 'good setting' for it, having used extreme numbers and tried out Masked_DHA (which turned out to be much less effective).
It is worth noting that this show is currently airing on the NickToons channel, and, as I said before, the non-DVD master does not appear to suffer from the haloing at all, but is much less sharp. Of course, it will also suffer from whatever logos Nickelodeon decides to plaster on it, unfortunately. But still. I've set up my Windows Media Center DVR to record it, and am thinking...maybe that source and the DVD ripped can be averaged to create the One Avatar Master To Rule Them All? In a manner similar to the cleanups and upscales of the Star Wars 'GOUT' DVDs? Some of those have had pretty phenomenal results given the awful, non-anamorphic, smeared 1993 LD master they came from. I don't really know much about this process, or how aggravating it could be to line them both up and such, and am not sure if the possible gains are worth it, if the logos can be 'masked' away, that sort of thing. I couldn't find decent info on this and would appreciate anything on it. (Though I haven't checked originaltrilogy.com yet, which is the logical place to start...)


Thanks a lot, if you've made it this far. I'm looking forward to learning!

[Asmodian]

I cannot offer much help except to mention a few points.

SetMemoryMax(4096) is not a good idea, try a more reasonable SetMemoryMax(1024) and only increase it further if you really run into memory issues.

Spline64 will ring (halo) more than Spline36 while being a bit sharper. Personally I think BicubicResize(b=1/3,c=1/3) or Spline36 is preferred for cshift. Ringing in chroma isn't great and chroma doesn't benefit much from sharpness (luma sharpness is much more significant to us humans). Also, maybe try nsize=0 instead of 4.

Note that I chose 1024x768 because it is very likely these will be played back on iPads, and the simple scaling of 4x that resolution I thought could be marginally beneficial to quality. I'm not sure how true this is...? Otherwise I would maybe try for 960x720 for the space savings (approx 12% fewer pixels).

While there is a small benefit to 2x scaling it will be swamped by the difference in encode quality if using the same size files. Ipads have decent quality resizing compared to Spline/Lanczos, only NNEDI3 will offer a noticeable improvement. Even NNEDI3 will not generate a lot of new detail so going down to 1.5x (720?) is reasonable. At the same size file I like the quality more if you do not upscale the source unless the upscaled encode is large enough to be transparent. So don't reduce the quality to allow the higher resolution and check the quality of a lower resolution but higher quality encode. You may find the bits are better spent on lower quantizers instead of more pixels.

I am unsure whether or not to convert colorspaces and have read conflicting information about it. According to the Avisynth wiki on colorimetry (http://avisynth.nl/index.php/Colorimetry), playback devices will often assume bt.709 for content with a vertical resolution of 720p or higher, never mind whether or not the file is tagged as bt.601. As a result, I did both, on in 601 and one in 709. I've come across others who have been adamant never to do this. I have not yet calibrated my monitor and am having some trouble with levels, so I'm not really sure if the process is destructive or not. Any effect is pretty subtle - I think a sort of yellow-y shift like the pictures on the colorimetry wiki might be happening, but am not sure.

Make very sure to get the colorimetry right! It is easy, your DVD is probably in BT.601 (http://forum.doom9.org/showthread.php?t=133982#post1090068) (and after the ColorMatrix is surely is) and you are scaling to or above the "HD" point so you need to go BT.709.

ColorMatrix(mode="Rec.601->Rec.709") is needed. You can leave the hint=true colormatrix in place, probably it will not do anything and if it does it would keeps the second from messing it up (but then you would have a pair of unneeded conversions). I have always found DVDs to be BT.601 so I only use a single ColorMatrix(mode="Rec.601->Rec.709") if upscaling.

It is worth noting that this show is currently airing on the NickToons channel, and, as I said before, the non-DVD master does not appear to suffer from the haloing at all, but is much less sharp.

That this is hardly surprising as the halos were created by a strong bad sharpen.

Personally I would not try to remove the halos completely. You cannot without destroying too much other detail and even then artifacts from them will remain. Go for a good balance of reducing haloing to watchable without doing too much other damage.

Mixing two sources is really hard and always requires a lot of manual work aligning frames both spatially and temporally, figuring out good masks, etc. Sometimes the frames will be misaligned in sub-pixels so it is hard to find good shift values. The edits may be slightly different so frame counts do not align. Unless you really really like the show I do not think it would be worth the effort involved.

Edit: If you post a short piece of the unprocessed video that you think represents your source well people may be able to offer you helpful suggestions. Screen shots tend to be of limited use but use png instead to avoid jpeg artifacts complicating matters. :)

[bilditup1]

I cannot offer much help except to mention a few points.

SetMemoryMax(4096) is not a good idea, try a more reasonable SetMemoryMax(1024) and only increase it further if you really run into memory issues.

Spline64 will ring (halo) more than Spline36 while being a bit sharper. Personally I think BicubicResize(b=1/3,c=1/3) or Spline36 is preferred for cshift. Ringing in chroma isn't great and chroma doesn't benefit much from sharpness (luma sharpness is much more significant to us humans). Also, maybe try nsize=0 instead of 4.



While there is a small benefit to 2x scaling it will be swamped by the difference in encode quality if using the same size files. Ipads have decent quality resizing compared to Spline/Lanczos, only NNEDI3 will offer a noticeable improvement. Even NNEDI3 will not generate a lot of new detail so going down to 1.5x (720?) is reasonable. At the same size file I like the quality more if you do not upscale the source unless the upscaled encode is large enough to be transparent. So don't reduce the quality to allow the higher resolution and check the quality of a lower resolution but higher quality encode. You may find the bits are better spent on lower quantizers instead of more pixels.



That this is hardly surprising as the halos were created by a strong bad sharpen.

Personally I would not try to remove the halos completely. You cannot without destroying too much other detail and even then artifacts from them will remain. Go for a good balance of reducing haloing to watchable without doing too much other damage.

Mixing two sources is really hard and always requires a lot of manual work aligning frames both spatially and temporally, figuring out good masks, etc. Sometimes the frames will be misaligned in sub-pixels so it is hard to find good shift values. The edits may be slightly different so frame counts do not align. Unless you really really like the show I do not think it would be worth the effort involved.

Edit: If you post a short piece of the unprocessed video that you think represents your source well people may be able to offer you helpful suggestions. Screen shots tend to be of limited use but use png instead to avoid jpeg artifacts complicating matters. :)

Thanks for all of that - very clear, common-sensical advice. I will try to prepare representative clips and post them here.
Unfortunately I am still having trouble with the script crashing Avisynth MT when just using a resize in that spot, but hopefully I'll work it out.
I have been using CRF-18 for these encodes...would you recommend I got for a specific bitrate or file-size instead?

[bilditup1]

Make very sure to get the colorimetry right! It is easy, your DVD is probably in BT.601 (http://forum.doom9.org/showthread.php?t=133982#post1090068) (and after the ColorMatrix is surely is) and you are scaling to or above the "HD" point so you need to go BT.709.

ColorMatrix(mode="Rec.601->Rec.709") is needed. You can leave the hint=true colormatrix in place, probably it will not do anything and if it does it would keeps the second from messing it up (but then you would have a pair of unneeded conversions). I have always found DVDs to be BT.601 so I only use a single ColorMatrix(mode="Rec.601->Rec.709") if upscaling.


Alright, so I think I got that right. I am pulling the colorimetry info directly from the d2v as per the ColorMatrix manual - it is, in fact, SMPTE170/BT.601 - and then using "dest=0" to convert bt.709. Which is just a longer way of doing the same thing, from what I can see, heh.

[bilditup1]

Does it matter if I set the color primaries, transfer, and color matrix flags in x264? Is it of any consequence?

[Asmodian]

Thanks for all of that - very clear, common-sensical advice. I will try to prepare representative clips and post them here.
Unfortunately I am still having trouble with the script crashing Avisynth MT when just using a resize in that spot, but hopefully I'll work it out.
I have been using CRF-18 for these encodes...would you recommend I got for a specific bitrate or file-size instead?

No, I like CRF for sure. I only meant to use a lower CRF with the smaller resolutions to get a similar file size and see if it looks better on the Ipad.

Alright, so I think I got that right. I am pulling the colorimetry info directly from the d2v as per the ColorMatrix manual - it is, in fact, SMPTE170/BT.601 - and then using "dest=0" to convert bt.709. Which is just a longer way of doing the same thing, from what I can see, heh.

Excellent, that is a better option and is correct. If something did report as BT.709 no double conversion takes place. :)

Does it matter if I set the color primaries, transfer, and color matrix flags in x264? Is it of any consequence?

Since you converted to what a player would usually default to the flags should not have any effect. Set them anyway so players that do read them know for sure what they should be. As far as I know only LAV+madVR respect the flags (LAV passes them and madVR uses them to do the correct YUV to RGB conversion) and they would default to the same values without the flags set so... :p

Still, set them anyway, you never know what the future might bring. :D

[bilditup1]

Just want to make clear - bits are not an issue. I could throw bits out there like there's no tomorrow. I use CRF 18 out of habit and a notion that the diminishing returns on higher bitrates come pretty quickly. Have I been misinformed?

[bilditup1]

Ringing in chroma isn't great and chroma doesn't benefit much from sharpness (luma sharpness is much more significant to us humans).


Sorry Asmodian, did you mention this because I turned on anti-aliasing for chroma? If it isn't perceived as sharp by humans (lol), I guess I could dispense with it, heh.

No, I like CRF for sure. I only meant to use a lower CRF with the smaller resolutions to get a similar file size and see if it looks better on the Ipad.
...


Thanks for all the clarifications there, and glad I'm getting some things right!

[bilditup1]

I have switched to a Spline36Resize(640,480), gotten rid of one of the deringing functions, the denoiser, the sharpener, and the AA, and set memory max to 1024 - so far, it hasn't crashed. I suspect the setmemmax is what allowed the resize to work again without crashing, so thanks for that! Also set CRF to 13. Previewing the file (by copying and pasting it) I'm pretty sure AA is necessary. Otherwise it looked surprisingly good, but much less sharp the than the 768p encode. I'll continue experimenting and report back.

[Asmodian]

Sorry Asmodian, did you mention this because I turned on anti-aliasing for chroma? If it isn't perceived as sharp by humans (lol), I guess I could dispense with it, heh.

No, that was because Spline64 is too sharp/ringing for chroma resizing/shifting in NNEDI3. Spline64 has a lot of ringing, even Spline36 does not have low ringing. However, this kernel is also used to downscale so maybe you want a really sharp high ringing kernel. This is not a critical issue in my mind, it all depends on what artifacts you notice v.s. the level of sharpness you want. Though less sharp kernels do compress better too. :)

Thanks for all the clarifications there, and glad I'm getting some things right!

Glad to help a bit, there are others who are better with filters here too so if you do post that sample you might get some better anti-haloing advice. :o

[Asmodian]

Just want to make clear - bits are not an issue. I could throw bits out there like there's no tomorrow. I use CRF 18 out of habit and a notion that the diminishing returns on higher bitrates come pretty quickly. Have I been misinformed?

Might as well not downscale after NNEDI3 at all. ;)

I generally like a bit under 18 but this really is person/screen dependent. Ipads are pretty small but high resolution and you are close to the screen. I think of ~16 as where it usually starts to go transparent to the source. Size does go up fast though and there is some point that is too large for everyone. Also encode settings matter too, if being picky.

I have switched to a Spline36Resize(640,480), gotten rid of one of the deringing functions, the denoiser, the sharpener, and the AA, and set memory max to 1024 - so far, it hasn't crashed. I suspect the setmemmax is what allowed the resize to work again without crashing, so thanks for that! Also set CRF to 13. Previewing the file (by copying and pasting it) I'm pretty sure AA is necessary. Otherwise it looked surprisingly good, but much less sharp the than the 768p encode. I'll continue experimenting and report back.

AA on the luma does look to be needed based on the screen shot.

See what a no resize after NNEDI3 CRF 18 encode looks like, that might be very nice on the ipad, or even try 16 if 18 wasn't too big. I think the ipad does respect the aspect ratio flags and the fewer resizes the better. :)

[bilditup1]

Might as well not downscale after NNEDI3 at all. ;) ...I think the ipad does respect the aspect ratio flags and the fewer resizes the better. :)

HMM...why not? I'd only have to resize to get the aspect ratio right, like you said. But see, I have to clarify - the iPad is just one of the devices this will be viewed on. We could just as soon view it on a 64" Plasma via Plex on a Roku or something, and somehow I doubt that they get aspect ratio flags right. Anyway, I have not tested on the playback devices just yet.


I generally like a bit under 18 but this really is person/screen dependent...I think of ~16 as where it usually starts to go transparent to the source. Size does go up fast though and there is some point that is too large for everyone. Also encode settings matter too, if being picky.

AA on the luma does look to be needed based on the screen shot.


Gotcha, thanks for this bit of wisdom

See what a no resize after NNEDI3 CRF 18 encode looks like, that might be very nice on the ipad, or even try 16 if 18 wasn't too big.

Aye aye cap'n...

Also encode settings matter too, if being picky.

Being picky is what I'm all about! Given the amount of work that needs to be done to improve this thing, using slower x264 settings has only a marginal impact on speed, from what I can see.
The command line looks like this, for the current encode:

"C:\blu\MeGUI\tools\x264\avs4x264mod.exe" --level 4.1 --preset slow --tune animation --crf 13.0 --deblock -1:-1
--keyint 230 --ref 5 --vbv-bufsize 78125 --vbv-maxrate 62500 --merange 32 --subme 10 --partitions all --trellis 2 --no-fast-pskip
--colorprim smpte170m --transfer smpte170m --colormatrix smpte170m --sar 1:1

[bilditup1]

Oh, I'm not really familiar with how to do anamorphic encoding at all. Is it as simple as just changing the --sar flag to the proper ratio? So then I guess I need to learn how to calculate that.

[creaothceann]

You can just process the encode with MKVMerge GUI and specify the aspect ratio there. I think it's then set in the resulting MKV file and MPCH respects that, afaik.

By the way, are you sure that the DVD can be IVTC'd? I got a English/Spanish/Portuguese one and it seems to be fully Video. (http://www.mediafire.com/download/031a60s329nzj0m/Avatar_tmp.7z)

EDIT: Or maybe I just misremembered and it's telecined but with an irregular duplicate frame pattern. Anyway, when I tried that there was some problem...

[bilditup1]

You can just process the encode with MKVMerge GUI and specify the aspect ratio there. I think it's then set in the resulting MKV file and MPCH respects that, afaik

Thanks for chiming in. While I will in fact watch this using MPC-HC on my laptop and maybe TV, for compatibility with iDevices, probably the final container will be mp4 (aka 'm4v'). From what I read in x264 settings, the SAR is just the original aspect ratio of the source, so I can safely enter 3:2 there, right? ED: or I guess 10:11, per this? (https://en.wikipedia.org/wiki/Aspect_ratio_(image)#Distinctions)

By the way, are you sure that the DVD can be IVTC'd? I got a English/Spanish/Portuguese one and it seems to be fully Video. (http://www.mediafire.com/download/031a60s329nzj0m/Avatar_tmp.7z)

EDIT: Or maybe I just misremembered and it's telecined but with an irregular duplicate frame pattern. Anyway, when I tried that there was some problem...

I am relying on the deinterlacing analysis of the AVS Script Creator of MeGUI, which recognized it as TFF telecined - "Hybrid film/interlaced. Mostly film". I am not familiar enough with 'hybrids' to understand where it isn't film. The credits? I am having some trouble with that, however that seems to be related to the deringing filters. However, I did find an interlacing artifact at one point in earlier encode, around Uncle Iroh when he's having his tea (such disrespect! lol). I guess something like AnimeIVTC could help with that? I don't want add giant scripts unless absolutely necessary though, heh :/

[bilditup1]

As an aside: I was flipping through Vudu last night and found that they had each season of Avatar on sale for $13 each (more or less the same price as the DVD). I checked the two minute preview, and it seemed to be a different transfer - no ringing at all! But aliasing and even interlace artifacts galore :( And it's not like I could buy it and break DRM - the only people who seem to have figured that out are white-hats.

[bilditup1]

Glad to help a bit, there are others who are better with filters here too so if you do post that sample you might get some better anti-haloing advice. :o

What would you recommend the settings be for such a sample? Or should I just try to post a chunk of the m2v somewhere?

[bxyhxyh]

It seems you have solved your problems.
But I should say that you should set thread only once in the first SetMTMode call.

SetMemoryMax(1024) # or your favourite number
SetMTMode(5,2) # or SetMTMode(5,4) etc
your_source()
SetMTMode(2)
# filtering etc...

That would help to run faster, would use less memory and would lower the chance to crash.

[bilditup1]

It seems you have solved your problems.


Not quite. I'm still trying to dering without destroying too much detail, and am not sure if I'm 'doing it right'. I'd like to leave a representative sample here...I guess I'll just pick parts and encode them at a high setting without applying any filters.


But I should say that you should set thread only once in the first SetMTMode call.

SetMemoryMax(1024) # or your favourite number
SetMTMode(5,2) # or SetMTMode(5,4) etc
your_source()
SetMTMode(2)
# filtering etc...

That would help to run faster, would use less memory and would lower the chance to crash.


Thanks for the advice.

[bilditup1]

Perhaps, because the source is already pretty aliased, I should run AA before the deringing?

[bilditup1]

No, I like CRF for sure. I only meant to use a lower CRF with the smaller resolutions to get a similar file size and see if it looks better on the Ipad.


I ended up doing that and I can't really tell the difference...it might be a little better, or a little worse. What I do know is the encode goes about three times faster with similar quality. You get a larger file at the end but not by much.

By chance I stumbled across two older threads that dealt with converting this exact set of DVDs. Using the settings from one of the posts in those threads, I think I did slightly better on the dehaloing end (moved up the anti-aliasing to right after the call to DeHalo Alpha, which is called with slightly different numbers). There were several other options there, but they don't seem to work with AviSynth 2.6 MT and I'm not interested in constantly playing games with which DLL is active. Given that those threads are 7+ years old, I'm curious about the possibility of a more modern solution.

Anyway, I've finally gotten around to cutting up some untouched samples of the DVD, and have uploaded them to Mega separately.

First ep:
1. Extended Intro. (https://mega.co.nz/#!6E4RyCgA!4WxBEwDBliOkdwmlRWZlCtW6jEJNDZelw-bXUU8S6BM) Intro with about thirty more seconds of material. Pay attention to faces, easy to see halos.
2. First scene. (https://mega.co.nz/#!WNhx1AJD!buempu-7kbhwJszhkN2Aa_It7eKPmwVmofLzMCoCmm8) Pay attention to faces, especially from afar - loss of detail.
3. End credits. (https://mega.co.nz/#!6QYAATgI!7ojmgdq3JN28O1n7G5j2JKsosGQvuRzQxoO5v47u9ys) Appears to be 30fps on 24 background or something? I think this is where most of the video frames are.

Second ep:
1. Regular Intro. (https://mega.co.nz/#!yAJSCBqK!pcqH9R5IuZvsKSn74r-LMcO-5YNnTMV7-iTzzXvmzTg) Every show from here on out has this intro. Doesn't seem to hard to deal with. There are some haloing artifacts around the text at the end that the dehaloing filters seem to exacerbate, or changing into a different kind of artifact (looks kind of like an inky smear).
2. First scene. (https://mega.co.nz/#!ORZlSBJC!wg6k2Wt6KYD9spTnTry-MReR88GK-siNZufGR3BM1SE) Pay attention to faces from afar - the sharpening messes with the details. Halos also easy to see here, overall. Lens flare at the beginning looks weird.
3. Second scene. (https://mega.co.nz/#!qMYTibAI!MnwPmeu-yub3omsUAuP6CxvKK00dYCQfL3XNX8uBoZE) Again the faces in the background, hard to make out.
4. End credits. (https://mega.co.nz/#!CJACFByD!6obrqWME7k6_RQQDf3jnOjwFQMLAXdshDLpamyPKCXw) Not much video in here, in contrast to the first episode. Not sure what to make of that. I guess I'll have to check each episode individually for this and decide whether to encode vfr or not based on that?

Thanks again ppls.