Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 29th November 2008, 01:59   #1  |  Link
jase99
*nix
 
jase99's Avatar
 
Join Date: Feb 2008
Posts: 34
Encoding Cartoons

How to decimate Looney Tunes NTSC DVD correctly? Here is a 17 MB 30 second sample: http://dump.no/files/3f6bbbed6f05/VTS01_PGC02_cut.m2v

First of all I believe the correct decimation approach needs to be selected and progressive frames recovered.

DGIndex reports (on the demuxed episode from which the sample was cut):
Stream Type: Elementary
Profile: main@main
Frame Size: 720x480
Display Size:
Aspect Ratio: 4:3 [2]
Frame Rate: 29.970030 fps
Video Type: Film
Frame Type: Progressive
Coding Type: B
Colorimetry: BT.470-2 B,G*
Frame Structure: Frame
Field Order:
Coded Number: 10285
Playback Number: 2
Frame Repeats: 0
Field Repeats: 0

This is what I've tried (but do not know if it is correct) :

I see frames which are almost duplicates and interlacing. By stepping through field by field I believe there are 12 unique frames per second and made this script:

MPEG2Source("VTS01_PGC02_cut.d2v")
SeparateFields()
SelectEvery(5,0,1)
Weave()
Crop(2,2,-2,-2)

Progressive frames appear to be recovered correctly, 11.988fps is returned.

I'm worried about patten lock so tried to use tdecimate:

MPEG2Source("VTS01_PGC02_cut.d2v")
TFM()
TDecimate(mode=1,cycleR=3,cycle=5)
Crop(2,2,-2,-2)

This recovers progressive frames almost ok and I don't have to worry about pattern lock anymore, but the 2nd frame is missing and (ignoring the 1 frame offset) all subsequent frames are slightly different to the first scripts output (something to do field field order perhaps?). The first script produces clearer images, I think TFM is bluring the output of the 2nd script, but without it interlacing remains. Since the first script appears to recover progressive frames correctly I assume this source does not need a de-interlacing filter.

I have zero experience encoding cartoons/anime so this is all guess work. Please guide me in the right direction.

Last edited by jase99; 29th November 2008 at 02:31.
jase99 is offline   Reply With Quote
Old 29th November 2008, 03:57   #2  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,901
It's soft telecined, so just set Force Film in DGIndex. Then if you want that strange frame rate, you can put SelectEven() or Decimate(2) in your script. What is your desired output format?

Last edited by Guest; 30th November 2008 at 04:07.
Guest is offline   Reply With Quote
Old 30th November 2008, 03:38   #3  |  Link
jase99
*nix
 
jase99's Avatar
 
Join Date: Feb 2008
Posts: 34
Thanks neuron2. I used force film and get progressive frames. I don't necessarily want that strange frame rate, I was thinking I should use a framerate that matched the artwork. For example, frames 0 and 1 are the same apart from dirt/noise/grain, likewise frames 2 and 3 are the same, 4 & 5, etc. Therefore I thought I should only pass every other frame to the encoder, after all, what's the point of encoding redundant information? There is a lot of grain in this source but I do not believe it is intentional. The output format is H.264/MKV.

On closer inspection I see small runs every now and then where every consecutive frame is unique. On occassion I see more than 2 duplicate frames of animation, for example frames 408 thru 419 are all the same frame of animation, only grain is different. Should I keep all frames or only unique frames of animation using VFR/timecodes and if so, how could that be done?
jase99 is offline   Reply With Quote
Old 30th November 2008, 04:11   #4  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,901
Quote:
Originally Posted by jase99 View Post
I was thinking I should use a framerate that matched the artwork. For example, frames 0 and 1 are the same apart from dirt/noise/grain, likewise frames 2 and 3 are the same, 4 & 5, etc. Therefore I thought I should only pass every other frame to the encoder, after all, what's the point of encoding redundant information?
Sure, that's fine as long as your target format is compatible with the decimated rate. You couldn't put 11 fps on a DVD for example.

Quote:
On closer inspection I see small runs every now and then where every consecutive frame is unique. On occassion I see more than 2 duplicate frames of animation, for example frames 408 thru 419 are all the same frame of animation, only grain is different.
That appears to be an intentional static scene. You can't just remove all duplicates because you will destroy static scenes.
Guest is offline   Reply With Quote
Old 30th November 2008, 04:25   #5  |  Link
jase99
*nix
 
jase99's Avatar
 
Join Date: Feb 2008
Posts: 34
Yep, the target format is compatible with the decimated rate. Why would static scenes be destroyed by dropping all duplicate frames? The scene would be displayed for the same amount of time if I could figure out how to detect static scenes and generate a timecode file for a variable frame rate encode (which matroska supports). Should I even be considering this?
jase99 is offline   Reply With Quote
Old 30th November 2008, 08:19   #6  |  Link
Comatose
Registered User
 
Join Date: Dec 2007
Posts: 639
In that case they'll be fine and you can do that with DeDup, but I don't recommend it - if you don't use a low enough threshold then it will make very slow pans choppy, and you might have to use a threshold so low that the noise would flag the frame as unique.
The default threshold will also consider frames where characters trembling (the outlines change slightly every frame) to be dupes.

Just doing blind SelectEvery() might be bad for the same frame. Most animation is 12 fps, but then you have pans which need the whole 24 fps to be smooth... so then you can use DeDup for VFR, but that brings up the issue I just mentioned.

You could still do it, but then you'd have to check all the pans are OK which is a hassle. If they aren't, you'll need to manually fix them and then it becomes a lot of work that isn't worth the benefit.

Last edited by Comatose; 30th November 2008 at 08:25.
Comatose is offline   Reply With Quote
Old 30th November 2008, 08:41   #7  |  Link
thetoof
Sleepy overworked fellow
 
Join Date: Feb 2008
Location: Maple syrup's homeland
Posts: 933
You could run Dedup after some good denoising to minimize the impact of the issue Comatose talked about. A few denoisers you can look at : frequency (dfttest, fft3dfilter/gpu....), motion compensated (MVDegrain, MC_Spuds, TemporalDegrain, MCTemporalDenoise), TNLmeans, at_denoise (from anisotools).... and many others.

It can acually work quite well to remove useless duplicates in anime if you stabilize your frame enough.
Something that you can also try is to run the analysis pass on an over-denoised clip (loss of detail is not very important) to minimize the effect of noise and then apply the results on your clip for VFR duplicate removal (run it after IVTC though).
__________________
AnimeIVTC() - v2.00
-http://boinc.berkeley.edu/-
Let all geeks use their incredibly powerful comps for the greater good (no, no, it won't slow your filtering/encoding :p)
thetoof is offline   Reply With Quote
Old 30th November 2008, 11:01   #8  |  Link
jase99
*nix
 
jase99's Avatar
 
Join Date: Feb 2008
Posts: 34
Thank you Comatose and thetoof for the great suggestions. I used dfftest with a high sigma for a pass 1 denoised clip:

test9a.avs:
MPEG2Source("VTS01_PGC02_cut.d2v")
dfttest(sigma=4)
DupMC(log="test9.dup.txt")

I've been playing with filters to try and get rid of the dirt/noise in the source without losing too much detail. Black lines have been a little troublesome. I noticed dedup didn't adjust the framerate after frames have been dropped to keep the duration the same. The correct fps is required when feeding input to x264 for correct bitrate distribution so I added AssumeFPS(). This is the script I used for pass 2:

test9b.avs:
MPEG2Source("VTS01_PGC02_cut.d2v")
oldcount = framecount
oldfps = framerate
DeDup(show=false,dec=true,threshold=4, maxcopies=10, maxdrops=4, decwhich=0, log="test9.dup.txt", times="test9.times.txt")
FastLineDarkenMOD(thinning=0)
temporaldegrain(degrain=3) #dfttest(sigma=2) loses too much detail
deen("a3d",3) #deen("a3d",4) too harsh
FastLineDarkenMOD(thinning=0)
NNEDIresize_yv12()
AddBorders(4, 0, 4, 0)
aWarpSharp(depth=8,blurlevel=4,thresh=0.5,cm=1)
FastLineDarkenMOD(thinning=0)
Crop(4,0,-4,0)
DeHalo_Alpha()
Spline36Resize(last.width/2,last.height/2)
Crop(2,2,-2,-2)
averagefps = (float(framecount)/float(oldcount))*oldfps
AssumeFPS(averagefps)

Don't be surprised if anyone recognises bits of this script, I've used ideas and script snippets from various posts and done lots of testing to arrive at this.

I checked the output of dedup using show=true, it appears to work great. I limited maxdrops to only 4 because I intend to add subtitles to the encode.

Ultimately I will do a 2 pass x264 encode. The script is extremely slow so pass 2 will be to lossless huffyuv and (in parallel using avs2yuv), to the first pass of x264. The third pass (x264's 2nd pass) will simply use the pre-generated lossless avi as input.

For now though, while I'm still experimenting, I ran a 1 pass crf encode of the sample:

x264 --threads auto --thread-input --sar 8:9 --deblock -1:-1 --crf 20 --b-pyramid --direct auto --ref 16 --merange 32 --partitions all --8x8dct --b-adapt 2 --bframes 6 --subme 9 --me tesa --mixed-refs --weightb --no-fast-pskip --no-dct-decimate --trellis 2 --psy-rd 0:0 --progress --output test9.h264 test9b.avs
avis [info]: 716x476 @ 12.05 fps (312 frames)
x264 [warning]: width or height not divisible by 16 (716x476), compression will suffer.
x264 [info]: using SAR=8/9
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 4.0
x264 [info]: slice I:6 Avg QP:17.06 size: 32618 PSNR Mean Y:46.32 U:48.27 V:48.00 Avg:46.81 Global:46.73
x264 [info]: slice P:117 Avg QP:18.87 size: 9084 PSNR Mean Y:44.44 U:47.47 V:46.54 Avg:45.11 Global:45.00
x264 [info]: slice B:189 Avg QP:22.96 size: 3516 PSNR Mean Y:43.57 U:46.87 V:45.66 Avg:44.27 Global:44.14
x264 [info]: consecutive B-frames: 4.6% 24.8% 46.1% 19.6% 4.9% 0.0% 0.0%
x264 [info]: mb I I16..4: 17.6% 38.6% 43.8%
x264 [info]: mb P I16..4: 6.1% 8.5% 3.1% P16..4: 52.2% 11.6% 8.3% 1.2% 0.6% skip: 8.4%
x264 [info]: mb B I16..4: 0.7% 0.3% 0.4% B16..8: 22.2% 2.9% 4.7% direct: 2.2% skip:66.6% L0:41.9% L1:52.2% BI: 5.8%
x264 [info]: 8x8 transform intra:43.9% inter:43.8%
x264 [info]: direct mvs spatial:98.9% temporal:1.1%
x264 [info]: ref P L0 66.8% 12.4% 5.7% 2.7% 2.4% 1.9% 1.8% 1.0% 1.0% 0.9% 0.7% 0.6% 0.6% 0.7% 0.5% 0.3%
x264 [info]: ref B L0 66.9% 13.8% 5.3% 2.8% 1.9% 1.6% 1.2% 0.7% 0.8% 0.7% 0.8% 0.9% 0.7% 1.0% 0.8%
x264 [info]: ref B L1 90.5% 9.5%
x264 [info]: SSIM Mean Y:0.9905828
x264 [info]: PSNR Mean Y:43.947 U:47.120 V:46.037 Avg:44.634 Global:44.482 kb/s:593.96
encoded 312 frames, 0.48 fps, 594.21 kb/s

The result is here: http://dump.no/files/c2b5bf8c5221/test9.mkv

Could this script be improved? I'm concerned that I might be altering the source too much or not removing (or removing too much) dirt/noise. I realise this is subjective but I would be grateful for some feedback from experienced cartoon/anime encoders.

I can post some comparison source/encode screenshots if it would help, but I think watching the source and encode in motion is better.
jase99 is offline   Reply With Quote
Old 30th November 2008, 20:46   #9  |  Link
Nightshiver
Quality Freak
 
Join Date: Jun 2007
Location: Area 52
Posts: 597
Video is extremely jerky to me. Why didn't you just use force film? I also see that your basically trying to get rid of all the grain, which, imo, you should never do. If you want to safely remove lots of grain, just use mvdegrain with a high thsad level. I'm also wondering why your using something as old as deen for this.
Nightshiver is offline   Reply With Quote
Old 30th November 2008, 23:22   #10  |  Link
jase99
*nix
 
jase99's Avatar
 
Join Date: Feb 2008
Posts: 34
I used force film as per neuron2's advice. Then I dropped all consecutive duplicate frames and used timecodes. Video playback is the same whether I drop frames and use timecodes or not. The encode plays as smooth as the orignal DVD, check the mpeg-2 sample. The advantage of dropping duplicates is there is less to encode, the result is a smaller file size with no loss of quality.

I'm not sure I should be getting rid of grain on this source either. It doesn't look like intentional grain to me (i.e., something that should be there), it looks like noise/dirt. If I encode the source with no filtering then the bitrate required is enormous to keep good quality. The source is pretty disgusting. I tried mvdegrain but it seemed to remove more detail than temporaldegrain. What should I use instead of deen?
jase99 is offline   Reply With Quote
Old 30th November 2008, 23:48   #11  |  Link
thetoof
Sleepy overworked fellow
 
Join Date: Feb 2008
Location: Maple syrup's homeland
Posts: 933
Look at the suggestions I made in my previous post. These are some of the most HQ denoisers available. You can test them, tweak the settings (more than only strenght/sigma) and you'll find which is the one you prefer. The default settings are not a good reference point when you're removing noise/grain.
btw, the full power of TemporalDegrain() can only be seen when you have an optimal pre-denoised reference clip (FFT3Dfilter is very useful for that since you can specify a different denoising strenght on 4 frequency ranges)
Here is one of the first post I made on this forum that talks about the issue/solution (and I guess the whole thread will be interesting for you).
__________________
AnimeIVTC() - v2.00
-http://boinc.berkeley.edu/-
Let all geeks use their incredibly powerful comps for the greater good (no, no, it won't slow your filtering/encoding :p)
thetoof is offline   Reply With Quote
Reply

Tags
cartoon, decimation, tdecimate

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 09:17.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.