Scripting Doctor Who

[ndjamena]

I'm thinking of processing my Doctor Who DVD to playback better on my WDTV.

I've been thinking what kind of filtering would work best for it. I've got some ideas but I don't really know how to get them to work.

Until The Trial of a Time Lord Classic Doctor Who is a mixture of progressive filmed scenes and interlaced video scenes.

What I'm thinking is that if I run the fields through a filter to detect scene detection, I can then run each scene through another filter to detect combing, if a scene seems to contain obvious combing it can be run through QTGMC, otherwise it can simply have it's frames duplicated to 50p.

I'll have to figure out how to crop scene by scene then upscale what's left to a standard size.

I've managed to run the first episode of Genesis of the Daleks through MSCDetection but got lost at that point.

What has everyone else done with the series?

[hello_hello]

I mightn't be of much help as my enthusiasm didn't extend that far. I only own a few classic Doctor Who DVDs from the Tom Baker era (PAL), but I duplicated the frames for the film parts and de-interlaced the video parts. Thanks to the BBC pretty much always using film for the outdoor scenes and video tape for everything else it's pretty easy to go through it manually.

I kind of did the opposite to what you're thinking. I also used QTGMC on the progressive parts for a bit of denoising (in progressive mode).
Because QTGMC doesn't tend to blur when de-interlacing, I've not tried working out how to only de-interlace the frames/scenes with combing, but because it naturally tends to denoise as it de-interlaces, I'd wonder if it's necessarily a good idea. You might end up with video sections where some scenes are obviously denoised and some not. Just a thought....

This was my script for episode 1 of Genesis Of The Daleks. Nothing particularly clever. If the cropping changed dramatically from scene to scene I'd normally adjust it as required, but for that DVD it seems I used "one size fits all" cropping.

LoadPlugin("C:\Program Files\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("D:\Genesis Of The Daleks, Part 1.d2v")
AssumeTFF()
Trim(0,704).TFM().ChangeFPS(50,1)\
++Trim(705,12924).TFM().QTGMC(InputType=1, preset="medium", EzDenoise=1).ChangeFPS(50,1)\
++Trim(12925,26374).QTGMC(sharpness=0.5)\
++Trim(26375,29003).TFM().QTGMC(InputType=1, preset="medium", EzDenoise=1).ChangeFPS(50,1)\
++Trim(29004,33032).QTGMC(sharpness=0.5)\
++Trim(33033,33788).TFM().QTGMC(InputType=1, preset="medium", EzDenoise=1).ChangeFPS(50,1)\
++Trim(33789,35459).QTGMC(sharpness=0.5)\
++Trim(35460,0).TFM().ChangeFPS(50,1)
crop(18, 8, -20, -10)
Spline36Resize(640,480)
gradfun3()

I tried higher resolutions but didn't seem to gain anything from doing so, or so little it wasn't worth it. I didn't try "upscaling" as such.

[ndjamena]

I've done this before back in the beginning when I was making mp4s for my iPhone. I may be mixing thing up a bit with other shows but I'm pretty sure at least some of the earlier episodes had badly inconsistent borders that needed to be cleaned up on a scene by scene basis. I also remember that quite a lot of episodes did quite well using a single cropping setting. I was using LanzosPlus to resize back then though, so I can't pretend that I knew what I was doing.

I'm thinking of writing this into a powershell script to make it easier to do such things in the future. I know how to get scene detection now (although it seems to like splitting the opening sequence into several "scenes"), but I'm not sure how to get a measure of the likeliness of a particular frame being combed or not to make the decision as to whether it's a film segment or video. If I separate each scene into lossless avi format, it should make it easier to work with, or possibly I could just create a temporary AVS script for each scene so I can look at it...

[geometer]

As a newbie here, but kinda tech guy for decades, l'd like to add some remarks from a different view.

* I would like to see goals specified quite precisely, which is a process of its own.
So, what actually is "better playback", which ones are the disturbing flaws, the removal of which would reward such an effort of experimenting and processing?
Of course, experimenting is legit by itself, but for the readers it might be interesting to understand which attempt is goal-oriented, and which is open to any result, just to explore.

* There is this function that compares frames n, n-1 for changes.
When we throw a bobbing deinterlacer like speedy yadif at the whole material, this function will hopefully detect little difference between every two frames, when the source was not interlaced.
So, we can program a discriminator (=hysteresis with thresholds in electronics), that triggers to output the frame number *on change* of this behavior, and the type of change (->P; ->I).
Then also we can have that message written to a file.
Then, we can manually check success of that method, and inspect the scenes based on these start-scene frame numbers.
When ok, we can use that file either by a simple program generator that writes down statements like in posting #2, to process each scene accordingly. I would call the result a scene sequence program.
(I'd do such in the WSH "visual basic" dialect (*.vbs format), as we can drag-and-drop the result file on that program file and harvest the desired code in a second.)
Or some of the runtime functions are used, in that way it becomes a parameter file.
In a second pass, we use the deinterlacer of our choice, as coded in the scene sequence program (the particular deinterlacer syntax could be another parameter or declared constant to the generator, same tactics for all steps/syntax templates of processing, for each scene of either type I or P).

* About video sizes, I made the experience that at higher resolution that is only filled with reasonable video information (that is given), and not with noise or garbage, the encoders do optimize very well, and the same video, e.g. with my preferred 4/3 upsampling, becomes only slightly bigger in file size. But of course, the benefit would be in additional sharpening, edge processing, dithering, etc., so this is calculated invest in file size savings vs. quality.

* To my taste, convolution contributes tremendously to the pleasure of watching, when it is tuned properly. My examples harmonize with yadif, in that the result looks TV-ish on a high level of quality.
The bobbing and moiree in the soft form we get by this chain of processing (yadif, convolution, upsampling and low-radius sharpening, downsampling, and the specified lanzsos functions), gives quite a nice stimulation to the eye, as in good old TV, vs. the "movie feeling" with its artifacts like flickering and grainy film.
If someone really dislikes yadif, it won't help, but besides that, the artifacts are treated quite nicely, especially with the latest kernel here:
http://forum.doom9.org/showthread.php?p=1753146#post1753146 (example and various kernels to check out.)

Facit,
it might be interesting to combine the approaches, the scene change processing in respect to film scenes, then the upsampling, and usage of specialized distinct convo impulses each for film and video.
- scene based deinterlacing, cropping, and convolution
- upsampling, further sharpening and corrections (like sub-px chroma shifts that may be also scene based)
- resize to target format
- final crop

[hello_hello]

....I'm pretty sure at least some of the earlier episodes had badly inconsistent borders that needed to be cleaned up on a scene by scene basis. I also remember that quite a lot of episodes did quite well using a single cropping setting. I was using LanzosPlus to resize back then though, so I can't pretend that I knew what I was doing.

It probably depends how fussy you are and what your definition of "inconsistent" might be.
At a rough guess, the right hand side might have needed an average of 16 pixels cropped, but only 8 or 10 in quite a few places, and there was a few places where it needed 20. Chances are the left side was much the same, as scene by scene the actual picture is rarely in the centre.
Me.... unless the cropping varies by more than about 8 pixels I usually just crop whatever is needed to always remove the black, and as a result sacrifice a few pixels of picture in places..... due to life being relatively short.... and because if you were viewing the DVD on a TV that overscans you'd be losing at least that much anyway, possibly more.

There's been plenty of times I've adjusted the cropping from one scene to another, but I guess that particular DVD didn't exceed my own tolerance for using a "one size fits all" cropping.

Except..... now I think about it..... I did re-encode a section near the beginning of that episode a second time to crop a bit more due to some noticeable crud down the left side I missed initially. Somewhere close to the scene where we first see The Doctor on Skaro. The things you remember....

[ndjamena]

My WDTV has a crappy deinterlacer, I can see it working even on shows like House (M.D.) which (on the PAL version at least) are already more or less progressive. It also does nothing about ITU transfers, so the images are too narrow and take up less screen space then they should. Then of course there's the fact that Doctor Who has terrible overscan borders that the WDTV also does nothing about. I have to sit there and watch them and they're distracting and ugly. It's not just extra black on the edges either, or those annoying half lines on the top and bottom, some of the edges are just plain tacky and would really be better of being cropped off. The problems I'm referring to are relics of the times the program was produced, the scenes were pieced together using archaic methods into interlaced format and time has only made it worse.

By "upscaling" I mean that after cropping the images are smaller than they were and of varying sizes, returning them back to 768x576 therefore represents upscaling, although I wouldn't mind resizing them to 720p to see how it looks.

The Doctor Who Restoration Team did a rather good job overall, but some of the stories have their own problems (Terror of the Autons has large black bars on the top and bottom) that ought to be fixed up, and for my own tastes some of it could do with a little more denoising.

There is a IsCombed function in Decomb, but it only outputs boolean and I'm not sure how suitable it's method of detection will be.

[Motenai Yoda]

Tdeint deinterlaces only if is detected as combed, also it has many parameters to adjust comb detection, other than the possibility to use a custom clip as deinterlaced and combmask.

[ndjamena]

I need it output to a text file or something, the decision needs to be made after a whole scene has been analysed and I've had time to verify the results. The filmed parts shouldn't be touched by a deinterlacer at all, yet I don't want any traces of interlacing artefact showing in the videoed scenes at all.

IsCombed looks like it can do something like what I want, but I don't know how it works and it looks like it only has a single parameter.

I'll have to test it out once I've finished adding all the chapter and track names.

I know from experience with Handbrake's deinterlacer and the IVTC deinterlacer that it's impossible to deinterlace some interlaced frames properly without bumping the sensitivity up high enough that enumerable progressive frames wind up getting the deinterlacing treatment too. That's another reason I'm sceptical of whatever IsCombed does. I'm looking for OBVIOUS combing. I'm pretty sure it only looks at a single frame (ie no motion detection) and I'm not sure what the threshold parameter is held against.

I'll use IsCombed if I have to but I was hoping there was a better method of detecting combing somewhere by now.

[wonkey_monkey]

Then of course there's the fact that Doctor Who has terrible overscan borders that the WDTV also does nothing about.

Point of information - that's not an overscan border, it's nominal analogue blanking (https://en.wikipedia.org/wiki/Nominal_analogue_blanking).

An annoyingly non-even 9 pixels on the left and right of a properly transferred PAL DVD should never, ever be seen - even at zero overscan. They should be cropped before displaying a pillarboxed image on a 16:9 screen, for example.

[StainlessS]

If de-interlaced to double rate, could then pass through DBSC to locate scenes and remove variable sized borders.

http://forum.doom9.org/showthread.php?t=171624&highlight=DBSC

VDM_EdKey could also be useful if you needed to Override SC detections.
http://forum.doom9.org/showthread.php?t=172837

EDIT: If double rate deinterlacing produces Blended frames at scene change then DBSC will have problems detecting Scene Change,
ie if scene changes are done mid frame so one field belongs to 1st scene, and next field belongs to next scene.

[hello_hello]

Then of course there's the fact that Doctor Who has terrible overscan borders that the WDTV also does nothing about. I have to sit there and watch them and they're distracting and ugly. It's not just extra black on the edges either, or those annoying half lines on the top and bottom, some of the edges are just plain tacky and would really be better of being cropped off. The problems I'm referring to are relics of the times the program was produced, the scenes were pieced together using archaic methods into interlaced format and time has only made it worse.

Does your TV have a 4:3 mode?
Mine does, and I'm very sure it overscans. Well most of the time, or at least when the TV is connected to a device in PAL or NTSC mode (ie 720x576 at 50Hz).
The TV adds pillarboixing to make the picture 4:3 and that includes what would normally be overscanning for a 4:3 TV, but it probably needs to connect at 720x576 at 50Hz and for the player to output 720x576 without any resizing (Edit: I tested it. See my next post). If the player outputs 4:3 and the TV's in 4:3 mode you'll probably end up with quite a squished picture.

Unfortunately I think a TV's 4:3 mode is likely to be 1.33333 and not 1.364(ish) but it's a start.

I'm still not sure trying to de-interlace only combed frames is a good idea. It'd be great if you could just separate the film and video, but I still wonder what'll happen in video sections with no movement/combing. They wouldn't be de-interlaced either, which might be a bad thing if QTGMC's de-interlacing also denoises a bit. Is QTGMC de-interlacing a video frame without combing necessarily a bad thing?

Of the DVDs I encoded, most only switched between film and video once or twice. Some, not at all. The worst was "City Of Death, Part 1" which switched between the two about 27 times, but that's the series shot in Paris and quite the exception. For the rest, going through it manually wasn't hard. I didn't see any film sections in Episodes 4, 5 and 6 of Genesis Of The Daleks. In Part 2, I found three film sections and in Part 3 I found one.

[geometer]

ndjamena, I see that your personal preferences are the relevant criteria, as the purpose is mainly to watch on your device.
- combing must vanish, but any further impact of deinterlacer is unwanted
- minimizing of black bars by detailed cropping, aspect ratio is to preserve, so that default playback mode looks correct
- 50fps target
- optional denoising

can you test a number of deinterlacers beforehand? how are results with both formats?
I have the following concerns:
the more complex deinterlacers should not be switched on and off while a scene is going, as this would probably create visible changes in the style and quality of the picture. also, these have multilevel impact on various video properties, with side effects, so eventually the tuning per scene may not find a well-defined setting and a clear end.

did you try yadif on P and I scenes? with P it creates a neutral average (as the frames are broken into fields and then stored in interlaced form), and with I it works quite nicely and transparent i.e. a change in sharpness is practically invisible if the interlacing is sound, just that the algorithm creates artifacts for certain slanted lines, and also with sharp structures that are about as wide as 1-2 px. would you tolerate these, do they happen at all, at the given resolution of these shows? many other simple deinterlacers just would ruin sharpness in place of creating these artifacts.
the idea is that yadif could be switched on and off at need, because it doesn't do anything complex to the look of the frame except edge correction, and perhaps can be fully on all the time, as mode=1 will deliver double frame rate of 50fps of everything and this is it.
resizing and convolution filtering can further soften these artifacts. ok to me but YMMV..



I'm not yet familiar with avisynth syntax for the more complex per-frame functions. but I'm very sure you can create a good scene detection that will write down frame numbers (candidates of changes) to a file.
use luminance, complexity, and frame difference, with thresholds tuned to the source.
Subtract(clip.Trim(1, 0), clip) might already yield enough, together with the intrinsic statistics functions.

the project should use writefileif() as in http://avisynth.nl/index.php/WriteFile
note that the parameter is specified in quotes, as this is a runtime evaluation of a string.

something like:
filename = "scenechanges.txt"
Subtract(clip.Trim(1, 0), clip).WriteFileIf(filename, "current_frame", "isSceneChange(current_frame,<list of runtime variables>)", "myResultfunction(current_frame,<list of runtime variables>)", myCropAnalyzer(...) )

syntax-wise it's a wild guess by me, but those who need, will figure out how the correct coding should go.

isSceneChange and myResultfunction would be functions to write.
we use currrent_frame to detect odd/even frame position, as we expect every other frame to show a combing-delta, or scene change, or progressive frame change.
the suggested functions need static or global variables that survive between calls. e.g. we only can judge what happened after observing 3-4 frames, checking the numeric values of average luminance, noise, etc., whether they are sitting in a typical value interval for the events we observe. discrimination also has to know if it is based on odd or even frames, per scene.
isSceneChange - tells in boolean, whether it thinks the frame difference counts for a scene change.
myResultfunction - the latter has collected data since the previous scene change, and results in a string that mentions the ocurrence of combing, and perhaps also an estimate about black areas it found at the borders, so to harvest cropping coordinates.

or, myCropAnalyzer might take over all viewport and cropping/border analysis, and should output some average and minimum coordinates for each scene (left, top, width, height).

Note that after a scene change, the data of the past scene will be written down. so we have only the ending frame #. for easier processing, it might insert also the start frame # of that scene, from a static or global (side effect-) variable that was saved at previous change.

from the result file, a script can be generated, that controls the correct processing for each of the scenes.

I hope the concept is comprehensible. good luck!

[hello_hello]

An annoyingly non-even 9 pixels on the left and right of a properly transferred PAL DVD should never, ever be seen - even at zero overscan. They should be cropped before displaying a pillarboxed image on a 16:9 screen, for example.

You made me look....

When connected at 1080p (HDMI), my Bluray player seems to leave it up to the TV. I can still see the half scan lines top and bottom when overscanning is disabled (and the nasty black edges down the sides of a 4:3 DVD).

Edit: I re-wrote the post so it'd make sense.....

If the Bluray player is connected to the TV at 1080p and it's resizing to 4:3, the crud down the sides is not hidden, even with the TV's overscanning enabled.

If the Bluray player is in "original" aspect mode and connecting at 1080p (a counter-intuitive name but it means the output aspect ratio always matches the TV aspect ratio.... ie 16:9), the TV needs to be in 4:3 mode for a 4:3 DVD to display correctly, in which case it adds the pillarboxing and effectively overscans. In 16:9 mode overscanning is optional.

If I let the Bluray Player connect at a PAL (or NTSC) resolution (ie 720x576 at 50Hz) instead of forcing 1080p, overscanning can't be disabled and once again, the TV's 4:3 mode is required to display a 4:3 DVD correctly.

In PC mode, the TV doesn't overscan, even in 4:3 mode.

So if you're using a HDMI player, unless you use your TV's 4:3 mode, chances are you can see the annoyingly non-even 9 pixels on the left and right.

[ndjamena]

Well, I just played Spearhead from Space for a minute on the WDTV and measured the picture width with my tape measure. It's the special edition SfS that was rescanned from the original film stock (the people who handled the video recording at the time were on strike, that's why SfS is the only classic Doctor Who that's been released on Blu Ray) and so it takes up pretty much the entire 720x576 picture. Anyway, according to the tape measure it's 66cm wide.

Then I played the first episode of The Ambassadors of Death it has rather serious "blanking" and according to the tape measure the picture on the TV is 64cm wide.

Mind of Evil is somewhere in between, it measure at a little over 65cm.

How exactly is this supposed to work anyway? According to the Wikipedia article the whole point is that analogue picture sizes change, and the real picture is whatever isn't blanked stretched to 4:3. Considering how often the blanking changes in Doctor Who, the fact that it's not unknown for blackness on the sides to be actual picture AND pictures that take up the whole width of encoded pixels aren't exactly rare, I should think decreeing that all devices should arbitrarily crop 8 pixels from each side when it encounters interlaced SD material is just as bad as saying it shouldn't. I have DVDs that don't have blanking, if it comes to a choice between cutting off their actual picture or catering to the vagaries of some old TV shows I'm not sure there is a best answer.

Even if ITU was obeyed, a lot of these old shows would still look like crap around the edges. Iron Man: Armoured Adventures Season 2 on DVD looks absolutely pristine and it doesn't have the ITU sides, if I upscale that properly it's actually kind of difficult to tell the difference between it and the Blu Ray of Season 1, why would I want to handicap that for the sake of Doctor Who and Blackadder?

[hello_hello]

The problem is, 4:3 DVDs are supposed to be ITU (704x576 = 4:3) and the mpeg4 pixel aspect ratios used for secondary Bluray streams are virtually the same, but the HDMI spec says that 4:3 is exactly 4:3 and 16:9 is exactly 16:9, so that's what players seem to do when connected via HDMI, and that's what TVs seem to do when they're resizing.
http://lurkertech.com/lg/video-systems/#pixelaspect_hdmi
Even if a TV overscans in 4:3 mode (see my previous post, which I edited so it'd make sense) it'll probably still resize to exactly 4:3, so those 4:3 DVDs will look a little squished.

Overscanning isn't quite the same as blanking though. At a minimum it'd be something like 5%, possibly more, so even if the amount of black down each side varies from scene to scene, you're never likely to see it, because the overscanning usually means the black is off the edge of the screen along with some of the picture. That's why I don't get too excited about scene by scene cropping unless it changes dramatically.

My rule of thumb.... I'm pretty sure all 4:3 DVDs are ITU, so regardless of the cropping required I'd always use an ITU pixel aspect ratio for resizing.
I'm pretty sure most 16:9 DVDs use generic 16:9 resizing unless they're old and have a lot of black down the sides, then they're probably ITU.
That's the rule of thumb I go by, although I suspect all BBC 16:9 DVDs are ITU regardless of age or the amount of black down the sides. I suspect....

On a different note...... to add to the fun..... I'm starting to suspect the mpeg4 aspect ratios that are supposed to be used for 720x576 and 720x480 Bluray streams are being ignored in preference to exact 16:9 and 4:3 resizing, which is probably a good thing, given most players are HDMI these days, but I compared some 720x480 Bluray video to the same scenes in the 1080p Bluray movie recently and it was closer to exact 16:9 resizing than when using the mpeg4 aspect ratios. I haven't compared much of it, but I found that interesting.

[ndjamena]

This is the script I'm using for scene detection at the moment. I stole it from a thread somewhere here:


film = "D:\Ins\Title 01\Video 1.d2v"
source = MPEG2Source(film, cpu=6).nnedi3(field=-2)
min_scene_size = 5
trim_front = 0
trim_end = 0
scene_num = 1
scene_begin = 0
scene_end = -1
scheme = 2

vectors = source.MSuper(pel=2, hpad=12, vpad=12, rfilter=2, isse=true).MAnalyse(isb=false, search=3, searchparam=3, isse=true, lambda=440, dct=4)
source.MSCDetection(vectors, thscd1=248, thscd2=50)

file_out = "D:\Ins\Title 01\Video 2.txt"

WriteFileStart(file_out, "### scene change list ###" + chr(10))
FrameEvaluate(last, """
global newscene = (current_frame < scene_end + min_scene_size) ? false \
: (scheme == 1) ? (YDifferenceFromPrevious>40) \
: (AverageLuma>250)
scene_begin = newscene ? scene_end+1 : scene_begin
scene_end = newscene ? current_frame-1 : scene_end
scene_num = (newscene && (current_frame > 0)) ? scene_num+1 : scene_num
""")


WriteFileif(last, file_out, "newscene", "scene_begin + trim_front")

# log scene changes at end of film

WriteFileif(file_out, "current_frame==framecount-1", "scene_end + 1 + trim_front", """"
"""", "framecount-1-trim_end", """"
"""", """"end"""")

ShowFrameNumber(size=12, x=10, y=40)

ScriptClip(last, """subtitle("scene #"+string(scene_num))""")


I'll try DBSC if I can concentrate long enough to figure out how it works (which is a big IF).

That doesn't help with combing though.

I should think better detection of combing would be pretty much the next holy grail on a DVD restoration forum, but it doesn't look like anyone has done much about it that I can see.

Everyone seems more interested in endless resizing filters.

[hello_hello]

Personally I'm still not sure about the benefit of combing detection when using QTGMC, but I've asked about it twice, so I'll give up.

[ndjamena]

I was planning on running the film sequences through QTGMC in progressive mode, if that's what you mean.

[geometer]

ndjamena,
is it ok to interpret your wish to detect the combing, as per whole scene?
as, when there are e.g. two seconds in the scene with visible combing, this tells the whole scene is "video" and should be deinterlaced from start to end.
this is, because I guess that switching in the deinterlacer only for those two seconds, would create a visible jump in picture "style" (like sharpness, noise, bobbing), and further the remainder of the scene still needs to become frame-doubled.

for purpose of interlace detection, I would suggest to loop through a yadif'd copy of the video. note that it has the double number of frames.
in pseudo language,
we can evaluate the following condition in the loop:
if subtract(frame(n*2), frame(n*2+1)).avgY > threshold and subtract(frame(n*2), frame(n*2-1)).avgY > threshold then interlacedcount = interlacedcount+1
(pseudocode for create a difference frame and compare its luma average to a threshold)

given that this is a scene interval, the comparisons with the previous and next frames both should exceed the threshold, if the deinterlaced frames stem from actual interlacing. at least for the number of frames that would show combing - something must have moved.
else, every two consecuting frames should be almost identical. thus, for a progressive source, one side of the AND the condition must be false, with rare exception, and the final interlacedcount should be zero or much lower than the number of frames in the scene.

practically, YDifferenceToNext() and YDifferenceFromPrevious() could be used.
here are the details : http://avisynth.nl/index.php/Runtime_environment

(actual deinterlacing can be any method, yadif here is suggested as a fast testing tool for the analytic pass)

[StainlessS]

Perhaps of use, from RT_Stats


The compiletime/runtime clip functions share some common characteristics.
The 'n' and (where used) 'n2' args are the optional frame numbers and default to 'current_frame' if not specified.
The x,y,w,h, coords specify the source rectangle under scrutiny and are specified as for Crop(), the default 0,0,0,0 is full frame.
If 'interlaced' is true, then every other line is ommited from the scan, so if eg x=0,y=1, then scanlines 1,3,5,7 etc are scanned,
if eg x=0,y=4 then scanlines 4,6,8,10 etc are scanned. The 'h' coord specifies the full height scan ie same whether interlaced is true
or false, although it will not matter if the 'h' coord is specified as eg odd or even, internally the height 'h' is reduced by 1 when
interlaced=true and 'h' is even.
Some of the functions have 'x2' and 'y2' args for a second frame (which could be the same frame).
Note, 'x2' and 'y2' default to 'x' and 'y' respectively.



RT_YDifference(clip,int "n"=current_frame,int "delta"=1,int "x"=0,int "y"=0,int "w"=0,int "h"=0,int "x2"=x,int "y2"=y,
bool "interlaced"=false,int "Matrix"=(Width>1100||Height>600?3:2))
Returns FLOAT value luma difference (0.0 -> 255.0) between frame n area x,y,w,h, and frame (n+delta) area x2,y2,w,h.
Note, by default it will be equivalent to YDifferenceToNext as delta defaults to 1 and x,y,w,h defaults full frame.
Note, 'x2' and 'y2' default to 'x' and 'y' respectively.

Eg, RT_YDifference(clip,delta=0,y2=1,interlaced=true)
Would difference the even and odd lines of the same frame,

***
***
***

RT_LumaDifference(clip,clip2,int "n"=current_frame,int "delta"=0,int "x"=0,int "y"=0,int "w"=0,int "h"=0,
int "n2"=current_frame,int "delta2"=0,int "x2"=x,int "y2"=y,bool "interlaced"=false,int "Matrix"=(Width>1100||Height>600?3:2))
Returns FLOAT value luma difference (0.0 -> 255.0) between clip frame (n+delta) area x,y,w,h, and clip2 frame (n2+delta2) area x2,y2,w,h.
Note, 'x2' and 'y2' default to 'x' and 'y' respectively.


EDIT: Removed text referring to not yet available v2.0.

[ndjamena]

Well, I still have a way to go but:

This does scene detection:


film = "D:\Ins\Title 01\Video 1.d2v"
file_out = "D:\Ins\Title 01\Video 2.txt"

source = MPEG2Source(film, cpu=6).nnedi3(field=-2)
min_scene_size = 5
scene_num = 1
scene_begin = 0
scene_end = -1
scheme = 2

vectors = source.MSuper(pel=2, hpad=12, vpad=12, rfilter=2, isse=true).MAnalyse(isb=false, search=3, searchparam=3, isse=true, lambda=440, dct=4)
source.MSCDetection(vectors, thscd1=248, thscd2=50)

FrameEvaluate(last, """
global newscene = (current_frame < scene_end + min_scene_size) ? false \
: (scheme == 1) ? (YDifferenceFromPrevious>40) \
: (AverageLuma>250)
scene_begin = newscene ? scene_end+1 : scene_begin
scene_end = newscene ? current_frame-1 : scene_end
scene_num = (newscene && (current_frame > 0)) ? scene_num+1 : scene_num
""")

WriteFileif(last, file_out, "newscene", "scene_begin")

WriteFileif(file_out, "current_frame==framecount-1", "scene_end + 1")
WriteFileif(file_out, "current_frame==framecount-1", "framecount-1")

ShowFrameNumber(size=12, x=10, y=40)
ScriptClip(last, """subtitle("scene #"+string(scene_num))""")


It's not very good. It keeps breaking up the opening and closing credits every time the names change and sometimes in really weird places.


This detects combing:

film = "D:\Ins\Title 01\Video 1.d2v"
file_out = "D:\Ins\Title 01\Video 2.log"
MPEG2Source(film, cpu=6)
WriteFileif(file_out, "IsCombed()", "current_frame")


That does an OK job actually. I've run through the first episode of Genesis and so far none of the film scenes have been detected as video. Some of the shorter video scenes have been detected as film though. I'm pretty sure actual motion detection would help pick up these things, but since the only parameter for this function is "threshold" which is apparently "the amount of combing" I'm guessing whatever is going on in the trunk isn't that intelligent.

The files they make are just a list of numbers, one for each line. The very, very preliminary script for processing them is:


$Combing = Get-Content "D:\Ins\Title 01\Video 2.log"
$Scenes = Get-Content "D:\Ins\Title 01\Video 2.txt"

$d=0

for ($a = 0; $a -lt $Scenes.Count; $a++)
{
if (-not $Scenes[$a]) { continue }
$OutText = @()
$Start = [int] $Scenes[$a]
if($Start % 2 -ne 0 )
{
$Start = [math]::Floor($Start/2)
$OutText+="mpeg2source(""D:\Ins\Title 01\Video 1.d2v"", cpu=6)"
if (Get-Item -Path ("Z:\Work\Genesis\Video\Segment " + ($a-1) + "-" + $a + ".avs") -ErrorAction SilentlyContinue)
{
$OutText+=("trim(" + ($Start-1) + ",$Start)")
Remove-Item -Path ("Z:\Work\Genesis\Video\Segment " + ($a-1) + "-" + $a + ".avs")
Add-Content -Path ("Z:\Work\Genesis\Video\Segment " + ($a-1) + "-" + $a + ".avs") -Value $OutText
}
else
{
$OutText+=("trim($Start,-1)")
Add-Content -Path ("Z:\Work\Genesis\Video\Segment " + ($a-1) + "-" + $a + ".avs") -Value $OutText
}
$OutText = @()
$Start++
$StartOdd=$True
}
else
{
$Start = [math]::Floor($Start/2)
$StartOdd=$False
}
try
{
if ($Scenes[$a + 1])
{
$End = [int] $Scenes[$a + 1]
$End = [math]::Floor($End/2)
if ($Scenes[$a + 2])
{
$End-=1
}
$Video=$false
for ($b = 0; $b -lt $Combing.Count; $b++)
{
if (([int]$Combing[$b]) -le $End -and $Combing[$b] -and ([int]$Combing[$b]) -ge $Start)
{
$Video=$true
}
}
if ($Video)
{
$OutText+="mpeg2source(""D:\Ins\Title 01\Video 1.d2v"", cpu=6)"
$OutText+="trim($Start,$End)"
Add-Content -Path "Z:\Work\Genesis\Video\Segment $a.avs" -Value $OutText
}
else
{
$OutText+="mpeg2source(""D:\Ins\Title 01\Video 1.d2v"", cpu=6)"
$OutText+="trim($Start,$End)"
Add-Content -Path "Z:\Work\Genesis\Film\Segment $a.avs" -Value $OutText
}
"$Start-$End"
}
}
catch
{
"""" + $Scenes[$a + 1] + """"
}
$d++
}


It creates an avs file for each scene in either a "film" or "video" directory. That way I can have a look at each scene, look at the numbers to see if there's anything odd there, and if one shows up where it shouldn't all I have to do is move the avs file from one directory to the other. The next script should read all the avs files and create new ones in a single directory, adding the words #film or #video to the beginning of each avs file so that from then on it knows what to do with them.

Cropping is next. I'll have to figure out how to interact with the script so that it can prepare all the avs files for easy perusing and let me tell it what cropping to use for each scene.

In the meantime I've written this script for the end credits of the first episode


mpeg2source("D:\Ins\Title 01\Video 1.d2v", cpu=6)
trim(35460,0).QTGMC(preset="Placebo").Trim(1,-1).NNEDI3_Resize16(960,720,6,4,-4,-4).assumefps(25.0) ++ trim(35461,36824).ConvertToYV12(interlaced=false).vinverse.QTGMC(inputtype=1, preset="placebo", Sharpness=0.2).edgecleaner.NNEDI3_Resize16(960,720,6,4,-4,-4)

original = last
denoised = maa2(ss=3.00)
denoised.LSFmod(source=original, ss_x=1.0, ss_y=1.0, strength=100, overshoot=0, undershoot=0, soft=0, edgemode=0)
changefps(50.0)


I encoded it at crf 18 and watched it on my TV but I saw artefacts I'm pretty sure weren't in the virtualdub output. So at the moment my pc is working on re-encoding it at crf 13, placebo, tesa film and I need to go to bed because it's 6am.

[geometer]

>>It's not very good. It keeps breaking up the opening and closing credits every time the names change and sometimes in really weird places.

but why can't you just ignore the false scene breaks? normally they would have the same P/I attribute and get the same treatment, and finally concatenated, and viewed in order.
other than that, most credits have a black screen which can be detected (but don't know this show you work on)

[wonkey_monkey]

It's not very good. It keeps breaking up the opening and closing credits every time the names change

Well, the credits are video overload on film, so...

I can't help wondering if you wouldn't just be better off finding a playback device that handles deinterlacing better (what is it that the WDTV does wrong?), or can pass it through unaltered for the TV to do so.

[StainlessS]

You could try this (v2.6 only, something I was playing with some months ago):- http://www.mediafire.com/download/9qyqmcd4c2rkar8/SCSC-v0.0-20160116.zip

Very Brief instructions.


/*
SCSC(clip dclip,clip Motion,clip StartC,clip EndC,
\ Float "dPd"=45.0,Float "dCor"=0.55,Float "dFact"=1.5,Float "dMin"=2.0,Float "dMinLen"=6,Int "dCW"=0.333333,float "dCorHi"=0.75,
\ int "x"=0, int "y"=0,int "w"=0,int "h"=0,
\ Bool "AltScan"=false,Int "CDf"=-1,int "CTh"=15,Bool "ChromaI"=false,Int "Matrix"=(Width>1100 || Height>600)?3:2,
\ String "Override"="",String "Project"="",
\ int "oFla"=9,Bool "Show"=true,Bool "Verbose"=true,Bool "Ver"=true,Bool "ForceProcess"=False
\ )

dClip, Detection clip.
Motion, Clip used where Motion.
StartC, Clip used where Start-Of-Scene.
EndC, Clip used where End-Of-Scene.
dPd, Percent of Pixels different by at least 4, must be greater than this else SC detection overridden to no scene change.
dCor, Correlation smaller than this Otherwise SC detection ignored (overridden), EDITED:
dFact, dMin, Control how much bigger difference between Curr->Next has to be compared to Prev->Curr to detect scene change.
Curr->Next has to be greater than (dFact * 'Prev->Curr' + dMin).
dMinLen, Minimum frame length of current scene that qualifies for scene change detection.
dCW, Detection ChromaWeight, 0.0 = Luma Only.
dCorHi, No explanation.
x,y,w,h, Coords.
AltScan, scan only alternate lines.
CDf, No explanation.
CTh, No explanation.
ChromaI, YV12 Chroma Is Interlaced.
Matrix, RGB -> Luma-Y conversion (if RGB && dCW==0.0). 3=PC709, 2=PC601.
Override, If 1st character is '*' then Overrides supplied in remainder of string, otherwise it is a filename for Overrides txt file.
Override Format (One override per line of text):-
42 # +ve number forces Start-Of Scene, in this case at frame 42.
-42 # -ve number sets frame to NOT Scene Change, in this case at frame 42.
-42,100 # -ve with comma separated Range, forces frames 42 to 100 to be NOT Scene-Changes.
Project, Set to eg "Test" to create files "Test_EndFrames.txt", "Test_MidFrames.txt", "Test_StartFrames.txt", "Test_RangeFrames.txt".
Project files only saved if movie totally scanned.
oFla, Maximum Number of Flash Frames to detect.
Show, Show Metrics on frame.
Verbose, Verbose metrics.
Ver, Show Version.
ForceProcess, Scans entire file, producing Project files without display.

*/

Avisource("D:\V\Cabaret.avi")

#RoboCrop() # Dont let borders 'water down' metrics.

SCSC(Last,Last,Last,Last,Project="Project")


EDIT: If getting too many detection try raising dMin to about 6 or 8.
Changed dCor from 55.0 to 0.55, got my point mixed up :(

[ndjamena]

DBSC_Scan_Client cuts the title sequence into more pieces than MVTools, and SCSC is missing some of the filmed scene changes.

I think I'll write a PS script to join scenes together if I happen to drop them into a certain folder. That's how iTunes works and it should make this a little more manageable.

[ndjamena]

Well, the credits are video overload on film, so...

I can't help wondering if you wouldn't just be better off finding a playback device that handles deinterlacing better (what is it that the WDTV does wrong?), or can pass it through unaltered for the TV to do so.

That implies I have money to spend. It also doesn't help with the cropping issues, and believe me, as bad as Doctor Who is, if I remember correctly at least the first season of Blackadder is worse. I'll also have to look through Monty Pythons Flying Circus, The Goodies and a bunch of other old British sitcoms and sort them out too.

Once I have this script finished I'll be able to reuse if for a bunch of things (not that 610 episodes of Doctor Who isn't significant in its own right).

[wonkey_monkey]

if I remember correctly at least the first season of Blackadder is worse.

I'm pretty sure there's only one film sequence from season 2 onwards (not counting the titles) - in the episode Bells. And it has scrolling interlaced text!

Doesn't QTGMC leave well enough alone on progressive material? (I would check myself but have no working main laptop right now)

[ndjamena]

I'm talking about the cropping. This isn't about interlacing, it's about scene by scene filtering. It's about controlling when and where the filters are being applied to get the best possible outcome.

I remember at least one scene in Blackadder where they were running down some stairs, the black border was so huge and so off compared to the scenes around it that it was pretty much mantatory to process it separately. Of course I've bought the remastered set since so I have no idea if the same problems are still there, I'll find out when I come to it.

The human mind has advantages computers can never match. We can recognise objects from vague outlines and tell when something doesn't look right. To computers the images are just numbers and they'll never be able to match human perception and judgement when dealing with image artefacts (or at least not within a reasonable timespan.) If I scrutinise each scene personally I should be able to do a better job then any set filters, but I need the filter to help me streamline the process because this is a pain in the arse.

If you've ever run QTGMC on progressive footage and compared the two halves born from the same original frame you can see that they're different. It depends on what you mean by "well enough". The way I'm doing it now will duplicate the film frames at the very last stage, just before encoding so they'll be perfect copies of each other rather than just close enough. If I can tell the difference between two sibling frames after being processed by QTGMC then, even if they look OK, neither one of them can be all that close to the original and by definition that means detail must have been lost or warped.

I'm in the process of sorting through the scenes now, combining the ones that have been incorrectly spit. It's just one episode at the moment, so for now I'm just figuring out what I need, ultimately by the end I'm hoping to streamline the process, run the powershell scripts on entire directories and automate as much of it as possible.

I don't see why I'm getting such resistance to this from this forum.

[geometer]

>> The way I'm doing it now will duplicate the film frames at the very last stage,

they had been broken into fields each with only half the information, as if they were interlaced. at playback time they merge, but I can see a difference only in single step mode.
you will need to weave the fields together, and declare them as a frames, and duplicate after.

the point is therefor a reliable discriminator to know if it is a progressive scene.
a deinterlacer in an analytic run would show a a' b b' c c' ... so we can use the frame-subtract tool to check for the low difference of every two frames, plus a varying higher difference when we compare the other two frames, and when a scene has mainly frame pairs with such a pattern, it is declared progressive in the log file.

I found avidemux extremely simple to sift through a video for scene changes, especially when I had written down the time stamps of interesting parts.
also the crop filter is wysiwyg enough and to put a resizer after it, and tweak it also, gives me all the data to define the required processing of the scene.