MoComped deinterlace... don't know why i didn't think of this approach before. - Page 5

scharfis_brain · 8th February 2005, 18:19

where is your source from? (device)
which properties has it? (resolution, codec etc.)

how fast is this simple script:

Code:

avisource("all no grey.avi")

?

o-o...

import("C:\Program Files\AviSynth 2.5\plugins\mvbob.avs")

remove all files from the plugin-folder.

place the mvbob package somewhere else.

all dll placed in the plugin folder are getting loaded automatically by AVISynth. THis is not a good idea with those more advanced scripts.

Mug Funky · 10th February 2005, 14:45

scharfi: one question aboot reYV12 - is it useful if my decoder is delivering yv12 already? i use ffdshow to decode DV when i can (ie. when i'm not using premiere) and so far haven't had any problems with colour, but i'm not quite sure what i'd be looking for if i did have colour issues...

scharfis_brain · 11th February 2005, 19:01

reYV12 is only useful, if the DV-Decoder did upsample the YY12-PAL to YUY2 while decoding.

If your decoder already puts out the untouched YV12 (like ffdshow does, indeed) you do NOT need to use reYV12.

zilog jones · 12th February 2005, 20:13

Wow, this is amazing stuff!

I've had mostly great results, but I tried it with some game footage (with lots of fast movement and panning) and occasionally got some weird artefacts (in localised parts of the screen) like this:

(full frame example: http://www.skynet.ie/~zilog/pics/mvbob-weird.png)

It happens quite frequently with pans in this clip, and sometimes it's just a few dots here and there.

I tried changing blksize to the other two numbers but it didn't seem to make much difference. Anything else I should try changing? I take it the crappy quality (it was a composite source) isn't really helping either?

Besides this, it's a damn good de-interlacer, and it's been exactly what I've been looking for for ages. I still have to try out standards conversion with it too, which will probably also be amazing. Keep up the good work!

scharfis_brain · 12th February 2005, 20:31

yeah, those artifacts are caused by kerneldeint's motion map.

every! to repeat myself EEVVEERRYY

motion adaptive deinterlacer (tdeint, kerneldeint, etc.)

are not capable to decide between motion and static (bob and weave) IF
you are trying to feed it with a shorter shutter speed than 1/50 sec or 1/60 sec.

And computer games are currently always at zero shutter (no motionblur)

this yields to this effect:
patterned linear moving structures are alternating their luma from field to field at the same place.
this lets the motionmap of our motion adaptive deinterlacers mark this moving area static.

you may try to set bobth lower.
At the risl bobbing real static areas, of course.

Try a plain tdeint or kernelbob on that source. you'll see that it looks the same like mvbob.

btw.: could you send a unprocessed game sample video to me?
I am search for such clips for long, but noone I know has a game-console

zilog jones · 12th February 2005, 20:48

That makes sense - don't think I ever tried proper deinterlacing with game footage before, so I never came across that problem.

The framerate conversion works great! Though it's quite slow on my PIII 933MHz - half an hour for 60 frames (and that's without resizing and weaving)! It's worth it though

Oh, and I'll PM you about sending some game footage.

scharfis_brain · 12th February 2005, 21:00

The framerate conversion works great!
Do not thank me.
It is completely manao's stuff. I didn't alter anything. Thank him

And as you know - from the beginning of this thread - Mug Funky invented this mv-ed bobbing.

I just throwed in some things here and there, cooked it up to 100 degrees of celsius et viola

2Bdecided · 14th February 2005, 12:59

scharfis_brain,

Thanks for all your help in this thread. I managed 10fps with that simple script through AVS2AVI, or 18fps if the source and destination files were on separate HDDs. So, I realised something was very wrong!

When I used rawsource to access the original YUV files (rather than using the AVI files created by the yuv2avi.exe supplied with the YUV files) the speed of the full PAL>NTSC conversion picked up from the previous 0.02fps to about 1fps.

The results are very good, so I'm very happy!

Thanks again.

Cheers,
David.

Terka · 14th February 2005, 17:10

@scharfis_brain

to achive best results for fast moving scenes (sport) and deinterlace to 50fps: i have to use fast shutter speed. but to avoid deinterlacing artefacts you wrote it should be slower?

scharfis_brain · 14th February 2005, 17:19

to achive best results for fast moving scenes (sport) and deinterlace to 50fps: i have to use fast shutter speed.

why this?

1/50 sec shutter creates a motionblur that suggests natural motion to our eyes, while shorter shutters are creating a strob-effect (one can see moving contoures/ghosts even on TV).

Terka · 15th February 2005, 12:56

its because i film sport to see the mistakes

scharfis_brain · 15th February 2005, 19:01

generally high speed shutter video is much better for the motion compensation/estimation.
So the quality should be really godd with mvbob()

but the problems with motion adaptive deinterlacers will remain.

to quote myself:
patterned linear moving structures are alternating their luma from field to field at the same place.
this lets the motionmap of our motion adaptive deinterlacers mark this moving area static.

I think, that this is rarely the case with sports.

But it could often occur with game footage, like zilog jones experienced.

DeathTheSheep · 21st February 2005, 17:17

Questions from the bob-newbie:
1. Deinterlace=good, but can this thing double the framerate of non-interlaced material?
2. When I tried to stick the code in, it said "kernelbob not found". Where on earth do you get kernelbob?

Thanks for bearing with me, y'all!

scharfis_brain · 21st February 2005, 17:24

1) no!
try mvfps() for that purpose

2) When I tried to stick the code in

what does that mean?!?

did you Dled the mvbob-package?

DeathTheSheep · 22nd February 2005, 22:17

Quote:

2) When I tried to stick the code in

Yeah, I ended up sticking it in by hand and typing in the basic kernelbob thing too. Yeah, I didn't hear the part about mvbob or whatever...

Oh, and this mvfps...I've heard about this thing before, I just have no clue where to find it. Excuse me for my ignorance pertaining to AVISynth... ;-()

scharfis_brain · 22nd February 2005, 22:34

Yeah, I ended up sticking it in by hand and typing in the basic kernelbob thing too. Yeah, I didn't hear the part about mvbob or whatever...

Oh, and this mvfps...I've heard about this thing before, I just have no clue where to find it. Excuse me for my ignorance pertaining to AVISynth... ;-()

You like masochism, don't you?

go back one page and take a look for 'package'
it should make everything clear.

or go here for lazy persons

http://forum.doom9.org/showthread.ph...487#post606487

DeathTheSheep · 22nd February 2005, 22:43

Quote:

You like masochism, don't you?

Yes, I'm just a pathetic excuse for an idiot who'd do anything for pain. There i go again... ;-)

opoman · 23rd February 2005, 16:09

Scharfis_brain:

I have been trying (unsuccessfully until a few nights ago) to find an acceptable PAL to NTSC conversion for UK PAL TV broadcast games of rugby, perhaps the stiffest test of a converter as far as motion-fidelity is concerned, with fast panning, zooming and subject movement (my 3.25 minute test clip (125MB) was left with groyal and is presumably still available to those who contact him.http://www.videohelp.com/forum/viewt...r=asc&start=90 )

I have tried your mvbob conversion with this rugby clip and the result was a terrific improvement on all that had gone before - the motion is entirely smooth and convincing and the very few imaging artefacts do not, in any way, spoil the viewing.

Congratulations to you and the sources that you used.

The golden priority in viewing rugby games is the motion - mostly horizontal. Any stuttering or flickering drives the viewer nuts after a few minutes - motion smoothness and truth are the key.

As it stood, your script is too good for me - my three minute clip of rugby took six hours to process with my system (tmpgenc or CCE, with a 1Gig PIII and .5 gig RAM). However, one of the contributors to the dvdhelp thread, groyal, has made some modifications to your approach which, while maintaining a watchable standard, have reduced processing time by about a factor of six.

Inevitably, like Oliver Twist, I want more. Is there anything further that you might suggest as a possible way to further adjust the image-quality vs processing time balance in favour of shorter processing time whilst maintaining 'motion-fidelity'.

Though not strictly a cross-post I am aware that by linking the fora I may cause objections. I hope *not* as some cross-fertilisation has already brought considerable benefit.

scharfis_brain · 23rd February 2005, 17:13

However, one of the contributors to the dvdhelp thread, groyal, has made some modifications to your approach which, while maintaining a watchable standard, have reduced processing time by about a factor of six.

I would like to see those modifications

Richard Berg · 23rd February 2005, 17:43

Here's the fast version:

Code:

crop(12,6,696,568)
i=bob(height=240)

fwd=mvtools0962_mvanalyse(i,isb=false,lambda=400)
bwd=mvtools0962_mvanalyse(i,isb=true, lambda=400)
i.mvtools0962_mvconvertfps(bwd,fwd,fps=59.94)

AddBorders(12,0,12,0)
AssumeFieldBased()
Weave()

I'm surprised this works well -- vertical resampling usually screws up deinterlacers. Also, the technique of only analyzing an interior block of an image won't work for all sources obviously. The poster does make a great point that mocomp is geometric in the # of pixels; anything you can do to reduce the mocomp'd area will help a lot more than you think.

8th February 2005, 18:19	#81 \| Link
scharfis_brain brainless Join Date: Mar 2003 Location: Germany Posts: 3,653	where is your source from? (device) which properties has it? (resolution, codec etc.) how fast is this simple script: Code: avisource("all no grey.avi") ? o-o... import("C:\Program Files\AviSynth 2.5\plugins\mvbob.avs") remove all files from the plugin-folder. place the mvbob package somewhere else. all dll placed in the plugin folder are getting loaded automatically by AVISynth. THis is not a good idea with those more advanced scripts. __________________ Don't forget the 'c'! Don't PM me for technical support, please.

10th February 2005, 14:45	#82 \| Link
Mug Funky interlace this! Join Date: Jun 2003 Location: i'm in ur transfers, addin noise Posts: 4,555	scharfi: one question aboot reYV12 - is it useful if my decoder is delivering yv12 already? i use ffdshow to decode DV when i can (ie. when i'm not using premiere) and so far haven't had any problems with colour, but i'm not quite sure what i'd be looking for if i did have colour issues... __________________ sucking the life out of your videos since 2004

11th February 2005, 19:01	#83 \| Link
scharfis_brain brainless Join Date: Mar 2003 Location: Germany Posts: 3,653	reYV12 is only useful, if the DV-Decoder did upsample the YY12-PAL to YUY2 while decoding. If your decoder already puts out the untouched YV12 (like ffdshow does, indeed) you do NOT need to use reYV12. __________________ Don't forget the 'c'! Don't PM me for technical support, please.

12th February 2005, 20:31	#85 \| Link
scharfis_brain brainless Join Date: Mar 2003 Location: Germany Posts: 3,653	yeah, those artifacts are caused by kerneldeint's motion map. every! to repeat myself EEVVEERRYY motion adaptive deinterlacer (tdeint, kerneldeint, etc.) are not capable to decide between motion and static (bob and weave) IF you are trying to feed it with a shorter shutter speed than 1/50 sec or 1/60 sec. And computer games are currently always at zero shutter (no motionblur) this yields to this effect: patterned linear moving structures are alternating their luma from field to field at the same place. this lets the motionmap of our motion adaptive deinterlacers mark this moving area static. you may try to set bobth lower. At the risl bobbing real static areas, of course. Try a plain tdeint or kernelbob on that source. you'll see that it looks the same like mvbob. btw.: could you send a unprocessed game sample video to me? I am search for such clips for long, but noone I know has a game-console __________________ Don't forget the 'c'! Don't PM me for technical support, please.

12th February 2005, 21:00	#87 \| Link
scharfis_brain brainless Join Date: Mar 2003 Location: Germany Posts: 3,653	The framerate conversion works great! Do not thank me. It is completely manao's stuff. I didn't alter anything. Thank him And as you know - from the beginning of this thread - Mug Funky invented this mv-ed bobbing. I just throwed in some things here and there, cooked it up to 100 degrees of celsius et viola __________________ Don't forget the 'c'! Don't PM me for technical support, please.

12th February 2005, 20:13	#84 \| Link
zilog jones Registered User Join Date: Mar 2004 Location: Ireland Posts: 481	Wow, this is amazing stuff! I've had mostly great results, but I tried it with some game footage (with lots of fast movement and panning) and occasionally got some weird artefacts (in localised parts of the screen) like this: (full frame example: http://www.skynet.ie/~zilog/pics/mvbob-weird.png) It happens quite frequently with pans in this clip, and sometimes it's just a few dots here and there. I tried changing blksize to the other two numbers but it didn't seem to make much difference. Anything else I should try changing? I take it the crappy quality (it was a composite source) isn't really helping either? Besides this, it's a damn good de-interlacer, and it's been exactly what I've been looking for for ages. I still have to try out standards conversion with it too, which will probably also be amazing. Keep up the good work!

12th February 2005, 20:48	#86 \| Link
zilog jones Registered User Join Date: Mar 2004 Location: Ireland Posts: 481	That makes sense - don't think I ever tried proper deinterlacing with game footage before, so I never came across that problem. The framerate conversion works great! Though it's quite slow on my PIII 933MHz - half an hour for 60 frames (and that's without resizing and weaving)! It's worth it though Oh, and I'll PM you about sending some game footage.

14th February 2005, 12:59	#88 \| Link
2Bdecided Registered User Join Date: Dec 2002 Location: UK Posts: 1,673	scharfis_brain, Thanks for all your help in this thread. I managed 10fps with that simple script through AVS2AVI, or 18fps if the source and destination files were on separate HDDs. So, I realised something was very wrong! When I used rawsource to access the original YUV files (rather than using the AVI files created by the yuv2avi.exe supplied with the YUV files) the speed of the full PAL>NTSC conversion picked up from the previous 0.02fps to about 1fps. The results are very good, so I'm very happy! Thanks again. Cheers, David.

14th February 2005, 17:10	#89 \| Link
Terka Registered User Join Date: Jan 2005 Location: cz Posts: 704	@scharfis_brain to achive best results for fast moving scenes (sport) and deinterlace to 50fps: i have to use fast shutter speed. but to avoid deinterlacing artefacts you wrote it should be slower?

14th February 2005, 17:19	#90 \| Link
scharfis_brain brainless Join Date: Mar 2003 Location: Germany Posts: 3,653	to achive best results for fast moving scenes (sport) and deinterlace to 50fps: i have to use fast shutter speed. why this? 1/50 sec shutter creates a motionblur that suggests natural motion to our eyes, while shorter shutters are creating a strob-effect (one can see moving contoures/ghosts even on TV). __________________ Don't forget the 'c'! Don't PM me for technical support, please.

15th February 2005, 12:56	#91 \| Link
Terka Registered User Join Date: Jan 2005 Location: cz Posts: 704	its because i film sport to see the mistakes

15th February 2005, 19:01	#92 \| Link
scharfis_brain brainless Join Date: Mar 2003 Location: Germany Posts: 3,653	generally high speed shutter video is much better for the motion compensation/estimation. So the quality should be really godd with mvbob() but the problems with motion adaptive deinterlacers will remain. to quote myself: patterned linear moving structures are alternating their luma from field to field at the same place. this lets the motionmap of our motion adaptive deinterlacers mark this moving area static. I think, that this is rarely the case with sports. But it could often occur with game footage, like zilog jones experienced. __________________ Don't forget the 'c'! Don't PM me for technical support, please.

21st February 2005, 17:17	#93 \| Link
DeathTheSheep <The VFW Sheep of Death> Join Date: Dec 2004 Location: Deathly pasture of VFW Posts: 1,149	Questions from the bob-newbie: 1. Deinterlace=good, but can this thing double the framerate of non-interlaced material? 2. When I tried to stick the code in, it said "kernelbob not found". Where on earth do you get kernelbob? Thanks for bearing with me, y'all! __________________ Recommended all-in-one stop for x264/GCC needs on Windows: Komisar x264 builds!

21st February 2005, 17:24	#94 \| Link
scharfis_brain brainless Join Date: Mar 2003 Location: Germany Posts: 3,653	1) no! try mvfps() for that purpose 2) When I tried to stick the code in what does that mean?!? did you Dled the mvbob-package? __________________ Don't forget the 'c'! Don't PM me for technical support, please.

22nd February 2005, 22:34	#96 \| Link
scharfis_brain brainless Join Date: Mar 2003 Location: Germany Posts: 3,653	Yeah, I ended up sticking it in by hand and typing in the basic kernelbob thing too. Yeah, I didn't hear the part about mvbob or whatever... Oh, and this mvfps...I've heard about this thing before, I just have no clue where to find it. Excuse me for my ignorance pertaining to AVISynth... ;-() You like masochism, don't you? go back one page and take a look for 'package' it should make everything clear. or go here for lazy persons http://forum.doom9.org/showthread.ph...487#post606487 __________________ Don't forget the 'c'! Don't PM me for technical support, please.

23rd February 2005, 16:09	#98 \| Link
opoman Registered User Join Date: Feb 2005 Location: UK Posts: 5	Scharfis_brain: I have been trying (unsuccessfully until a few nights ago) to find an acceptable PAL to NTSC conversion for UK PAL TV broadcast games of rugby, perhaps the stiffest test of a converter as far as motion-fidelity is concerned, with fast panning, zooming and subject movement (my 3.25 minute test clip (125MB) was left with groyal and is presumably still available to those who contact him.http://www.videohelp.com/forum/viewt...r=asc&start=90 ) I have tried your mvbob conversion with this rugby clip and the result was a terrific improvement on all that had gone before - the motion is entirely smooth and convincing and the very few imaging artefacts do not, in any way, spoil the viewing. Congratulations to you and the sources that you used. The golden priority in viewing rugby games is the motion - mostly horizontal. Any stuttering or flickering drives the viewer nuts after a few minutes - motion smoothness and truth are the key. As it stood, your script is too good for me - my three minute clip of rugby took six hours to process with my system (tmpgenc or CCE, with a 1Gig PIII and .5 gig RAM). However, one of the contributors to the dvdhelp thread, groyal, has made some modifications to your approach which, while maintaining a watchable standard, have reduced processing time by about a factor of six. Inevitably, like Oliver Twist, I want more. Is there anything further that you might suggest as a possible way to further adjust the image-quality vs processing time balance in favour of shorter processing time whilst maintaining 'motion-fidelity'. Though not strictly a cross-post I am aware that by linking the fora I may cause objections. I hope not as some cross-fertilisation has already brought considerable benefit.

23rd February 2005, 17:13	#99 \| Link
scharfis_brain brainless Join Date: Mar 2003 Location: Germany Posts: 3,653	However, one of the contributors to the dvdhelp thread, groyal, has made some modifications to your approach which, while maintaining a watchable standard, have reduced processing time by about a factor of six. I would like to see those modifications __________________ Don't forget the 'c'! Don't PM me for technical support, please.

23rd February 2005, 17:43	#100 \| Link
Richard Berg developer wannabe Join Date: Nov 2001 Location: Brooklyn, NY Posts: 1,211	Here's the fast version: Code: crop(12,6,696,568) i=bob(height=240) fwd=mvtools0962_mvanalyse(i,isb=false,lambda=400) bwd=mvtools0962_mvanalyse(i,isb=true, lambda=400) i.mvtools0962_mvconvertfps(bwd,fwd,fps=59.94) AddBorders(12,0,12,0) AssumeFieldBased() Weave() I'm surprised this works well -- vertical resampling usually screws up deinterlacers. Also, the technique of only analyzing an interior block of an image won't work for all sources obviously. The poster does make a great point that mocomp is geometric in the # of pixels; anything you can do to reduce the mocomp'd area will help a lot more than you think.