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 6th July 2008, 07:55   #41  |  Link
henryho_hk
Registered User
 
Join Date: Mar 2004
Posts: 889
Quote:
Originally Posted by IanB View Post
Your last image looks like you had the 2 red statements reversed.
Exactly.... I am so silly. Thanks IanB.
henryho_hk is offline   Reply With Quote
Old 8th July 2008, 07:02   #42  |  Link
florinandrei
Registered User
 
Join Date: Jul 2006
Posts: 118
Quote:
Originally Posted by 2Bdecided View Post
No, not when the user doesn't know what they want! Seriously though, I think florinandrei wants to learn - that sometimes includes learning that what you originally thought you wanted to do isn't really what you want to do at all!
True.

I was thinking I should just do 1080i -> 480p at 30fps, since 480p/30fps, while not a DVD standard, is apparently supported by some (many?) DVD players. You know, just deinterlace and be done with it.
But then, these DVDs will be played on interlaced CRT displays, so it's probably better (?) to keep it interlaced.

One day I'll be able to shoot hi-def progressive and then a lot of problems will disappear. Interlacing is a really bad annoyance.
I was actually thinking to get a "prosumer" (semi-pro) camera, but then for the same price ($3k) next year one could shoot 3k progressive at 120fps in raw format

http://www.red.com/nab/scarlet

If it's not vaporware, then it beats the hell out of an XH A1 at the same price.

Offtopic, sorry.

Quote:
If you do a bicubic resize and leave it at that, it'll all look a bit soft.
If you do a lanczos resize and run limitedsharpenfaster, it'll all look very sharp (too sharp?).
Neither will always "keep the perceived sharpness of the original, but on a smaller scale" - resizing doesn't work like that. You have to use the appropriate tools to get the sharpness you want, which is partly independent of the source. If you want it to look like the source, you'll have to throw in the processes that "recreate" that look at the new resolution, because it won't happen by magic.
I see your point.
Yes, that is the goal - the perceived sharpness should remain the same (adjusted for resolution changes), preserving the original look. I guess I'll just have to try different things and see what works.

How about lanczos without limitedsharpenfaster?
florinandrei is offline   Reply With Quote
Old 8th July 2008, 08:33   #43  |  Link
Alex_ander
Registered User
 
Alex_ander's Avatar
 
Join Date: Apr 2008
Location: St. Petersburg, Russia
Posts: 334
Quote:
Originally Posted by florinandrei View Post
I was thinking I should just do 1080i -> 480p at 30fps, since 480p/30fps, while not a DVD standard, is apparently supported by some (many?) DVD players. You know, just deinterlace and be done with it.
But then, these DVDs will be played on interlaced CRT displays, so it's probably better (?) to keep it interlaced.
There's no incompatibility of progressive footage on DVD with interlaced display: the video is outputted by fields (fake interlaced if progressive) from any standard DVD player. The main reason for keeping video interlaced is preserving better motion reproduction. When you deinterlace without doubling frame rate (you can only double it for PC or for 720p TV playback) you lose half of motion phases and get some artifacts.
Alex_ander is offline   Reply With Quote
Old 8th July 2008, 22:10   #44  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,802
Right, but the whole reason interlacing was standardized in the first place was its ability to maintain motion fluidity while reducing bandwidth requirements. It still does this today, but with all the headaches etc that we all know and love

On that note, I'm impressed with the quality of a simple separatefields + spline resize, with offset correction. There's less aliasing on the power line than with MVBob!

I did some fun stuff last night - converting a 1080i VC1 adult title to 720p60 with a simple bob (with spline) and was very impressed! Of course, it wasn't as good as MCBob, but there were no motion artifacts, like there were with Tdeint (without using TMM anyway, which slows the whole process down a bit)

~MiSfit

Last edited by Blue_MiSfit; 8th July 2008 at 22:31.
Blue_MiSfit is offline   Reply With Quote
Old 9th July 2008, 01:44   #45  |  Link
henryho_hk
Registered User
 
Join Date: Mar 2004
Posts: 889
The aliasing on the power line also exists in the original 1080i material. Therefore, I wonder if separatefields + spline resize will look okay on interlaced TV.
henryho_hk is offline   Reply With Quote
Old 11th July 2008, 06:22   #46  |  Link
florinandrei
Registered User
 
Join Date: Jul 2006
Posts: 118
Quote:
Originally Posted by Blue_MiSfit View Post
Code:
ConvertToYV12()

#And finally we convert the colorspace from something else to YV12 
#(odd, because AVCHD should be YV12 - must be a decoder error).

#Actually, ConvertToYV12(interlaced=true) would be better
Correct. I removed all references to ConvertToYV12() and the MPEG2 encoder (the AviSynth host running the script) keeps working just fine.
I know for a fact that HC Encoder complains if the input is not YV12 so that must be it, AVCHD is already YV12.
florinandrei is offline   Reply With Quote
Old 11th July 2008, 18:34   #47  |  Link
florinandrei
Registered User
 
Join Date: Jul 2006
Posts: 118
I did something like this:

Code:
SetMTMode(2,2)
AVCSource("00000.dga")
MCBob()
LanczosResize(720,480)
AssumeTFF()
SeparateFields()
SelectEvery(4,0,3)
Weave()
It worked fine and the result looks crisp. But it's WAAAY to slow!
The first clip, 358 frames, took 2443 seconds to encode (0.15 fps). At this rate, a 1 hour video will take 200 hours to encode, or more than 8 days. I also tried MCBob-NNEDI but after some superficial testing that one appears to be even slower.
My system is a Core 2 Duo 5200 (one CPU, two cores).

Obviously, MCBob() is too slow for HD, unless it's used on very short clips.

I am willing to sacrifice time for quality, but the logistical issues with running a task for more than 8 days are pretty daunting since I can't dedicate a system to video processing (it's a machine I share with other people in the household). So it looks like I need to find a faster solution.

I noticed there are quite a few Bob functions, but I have zero experience with them. What I am looking for is something that is better that the most trivial Bobs, but not quite as slow as MCBob(). I am willing to wait up to 1 day for a 60 min video to encode, but that's I guess where I have to draw the line. So I have to speed up the process 8x. (*)
Motion compensated processing is a great idea, I understand the advantages, but it looks like MC on HD material with the current hardware is like encoding MPEG2 in 1997 - it just takes forever.

Can somebody point out some Bob functions that might fit the bill? (better quality than the most trivial ones, but faster than MCBob). As always, the goal is bobbing real 1080i footage (not computer generated, but filmed with a real camera) to shrink it to 480i.

Perhaps there are faster resize filters too, but my uneducated guess is that much more time is spent in MCBob() than in LanczosResize().
Also, I could speed up the MPEG2 encoder, which is currently running at max quality, but with these same settings, it produces 80 fps when encoding pure 480i footage, so I don't think it will make a measurable difference to tweak it in this context.
And a trivial Bob runs at 8 fps or so - I guess that's proof positive that MCBob() is the CPU hog.

(*) - I guess I could always buy faster CPUs, but even so I'm not sure whether MT.dll scales well enough with the number of cores, especially given the kind of filters I'm using. And a system that's 8x faster than my current one is going to be very expensive. I can't afford that.
OK, so I just realized that late next year, waiting for Moore's law, I might actually start using MCBob() on HD. But by that time I'm hoping to shoot all footage in 60 fps progressive for a not much bigger investment - bye bye interlaced video, you miserable evil thing.

P.S.: By the way, I am planning to keep doing experiments until I'm satisfied I have a procedure that converts 1080i to 480i at the best quality in a reasonable time with current hardware. When that happens, I will summarize my findings in a short HOWTO, either on this forum or on the AviSynth Wiki (if I can get permission to create content there). This looks like a topic that will become more important in the future, as the HD cameras become more popular while co-existing with legacy SD displays - so people will need ways to bridge the two kinds of formats while preserving a good image quality.
I will take a couple more weeks I guess. This is fun.
florinandrei is offline   Reply With Quote
Old 11th July 2008, 19:02   #48  |  Link
Didée
Registered User
 
Join Date: Apr 2002
Location: Germany
Posts: 5,394
Try Yadif. It's not a "trivial" bob, and fast like hell.

Since you're shrinking vertically by more than 50%, the benefits of the more sophisticated bob filters are in the area of "dimishing returns", anyway.

Other bobbing alternatives there are plenty - Kernelbob, TDeint, YadifMod, MVBobMod, MVBob, TempGaussMC, whatnotelse ... TempGaussMC could be a choice for a "not-too-slow" mo-comp'ed bobbing filter, when used with fast settings ( (1,1,0,"Yadif"), essentially).
__________________
- We´re at the beginning of the end of mankind´s childhood -

My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!)
Didée is offline   Reply With Quote
Old 11th July 2008, 19:41   #49  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,802
^ Listen to this guy, he knows what he's talking about

Yadif is amazing, given its fantastic speed! I find its quality to be just below TDeint(mode=1), but with better stability, and a lower chance of artifacting. Another choice would be TDeint with TMM providing the motion mask, to reduce the chance of artifacts.

But yes, I think YADIF would be your optimal choice

~MiSfit

Last edited by Blue_MiSfit; 11th July 2008 at 19:49.
Blue_MiSfit is offline   Reply With Quote
Old 11th July 2008, 21:49   #50  |  Link
florinandrei
Registered User
 
Join Date: Jul 2006
Posts: 118
Thanks everyone, I will try the suggestions y'all offered.

Quote:
Originally Posted by Blue_MiSfit View Post
Another choice would be TDeint with TMM providing the motion mask, to reduce the chance of artifacts.
Can you provide a script example please? Thanks.

__________________
Florin Andrei

http://florin.myip.org/
florinandrei is offline   Reply With Quote
Old 11th July 2008, 22:20   #51  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,802
A very simple example:

Code:
mm=tmm()
TDeint(mode=1, emtn=mm)
~MiSfit
Blue_MiSfit is offline   Reply With Quote
Old 13th July 2008, 10:20   #52  |  Link
PatchWorKs
Registered User
 
PatchWorKs's Avatar
 
Join Date: Aug 2002
Location: Italy
Posts: 228
For those who don't know, MediaCoder build 4130 now has the
Quote:
ability to correctly decode AVCHD (the format used by many HD camcorder)
Enjoy !
PatchWorKs is offline   Reply With Quote
Old 13th July 2008, 12:53   #53  |  Link
czerro
Registered User
 
Join Date: Feb 2008
Posts: 31
I'm curious, what is the incentive to Bob vs IVTC? I understand it makes it easier to convert back to 29.97fps with weave() thus making it easier to author, but there are tricks to get around that restriction (ie fake the framerate).

I have never authored DVD's but dealt with SVCD encoding back in the early days of portable image backup when DVD authoring at 2x for a 200 dollar drive (20 dollar 1-time DVD) was not really an efficient or cost-effective option... And many intelligent people, knowing how much 23.976 vs 29.97 fps can effect image quality on an 800 meg disc mpeg-2 *Hardware Player Compatible* stream, created programs to fake 29.97 flags on 23.976 sources. DVD hardware WILL play 23.976 source with 23.976 flags, but with a noticeable intermittent stutter. Also audio would often get out of sync on FastForward/Rewind/Pause/etc. DGPulldown was a genius program that worked by magic and dark voodoo (I'm pretty sure anyway) and would somehow by simply changing the flags in your 23.976 source (30 seconds of work) convince any hardware or software player that it was rendering a 29.97 fps stream. Intermittent stutter gone, and looked better than a "true" 29.97 fps "fake" (progressive as opposed to interlaced) stream.

I assume Avisynth's ChangeFPS(), AssumeFPS(), options perform some sort of similar function, although I've never had any reason to deal with them. Why is IVTC flag tampering not a superior way to maintain bits per frame (quality) over Bob/SelectEvery/Weave? I'd rather get away with compressing/rendering an HD source at 23.976 fps than 29.976 fps considering the framesize (1080i!)
czerro is offline   Reply With Quote
Old 13th July 2008, 22:40   #54  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,802
Quote:
I'm curious, what is the incentive to Bob vs IVTC?
The two are to be used for completely different sources.

In both cases, we want to take interlaced video, and deinterlace it without loosing info. However, the two types of sources (hard telecined video and pure interlaced videos) need to be handled differently.

Telecined video is essentially a progressive stream that has undergone a (sometimes nasty) process to make it "fit" inside a 29.97fps interlaced stream (assuming NTSC). So, to make 24p film content fit inside 60i ntsc, you cut the 24p into 48 fields per second, then duplicate some fields here and there, until you reach 60 fields per second. That's how telecine works.

If it's done properly, telecine is usually pretty simple to remove. If it's a common 3:2 pulldown, a simple TFM.TDecimate will remove the extra fields, and re-assemble the original 24p. There are more exotic methods for more exotic / broken sources, but this works most of the time.

Now, bob-deinterlacing should typically only be applied to TRULY interlaced video. i.e. when you do SeparateFields, and step through, each field represents a distinct temporal location. This is opposed to telecined material (where you have some duplicated fields that can just look a tiny bit spatially different).

Bobbing will take each temporally distinct field, and interpolate it to a full frame, using any number of special methods to use detail from other fields to assist in the interpolation process.

So, bobbing returns 60p. Same-rate deinterlacing can be as simple as bobbing followed by SelectEven, or there can be a dedicated same-rate algortihm. Same-rate deinterlacing returns 30p

(note, that 30p=29.97fps progressive, 60p=59.94fps progressive, 24p=23.976fps progressive, 60i=29.97fps interlaced).

The two are distinct procedures that should not be confused. One cannot simply apply IVTC to a pure interlaced stream, and expect meaningful results.

~MiSfit
Blue_MiSfit is offline   Reply With Quote
Old 14th July 2008, 01:37   #55  |  Link
florinandrei
Registered User
 
Join Date: Jul 2006
Posts: 118
Quote:
Originally Posted by Didée View Post
TempGaussMC could be a choice for a "not-too-slow" mo-comp'ed bobbing filter, when used with fast settings ( (1,1,0,"Yadif"), essentially).
I tried to call the filter like this: TempGaussMC(1,1,0,"Yadif") and it gave me an error.
I tried it like this: TempGaussMC(EdiMode="Yadif") and it's slower than MCBob().

What's the correct syntax for TempGaussMC() that makes it faster than MCBob() without losing too much quality?
__________________
Florin Andrei

http://florin.myip.org/
florinandrei is offline   Reply With Quote
Old 14th July 2008, 12:16   #56  |  Link
Didée
Registered User
 
Join Date: Apr 2002
Location: Germany
Posts: 5,394
Quote:
Originally Posted by florinandrei View Post
I tried to call the filter like this: TempGaussMC(1,1,0,"Yadif") and it gave me an error.
I tried it like this: TempGaussMC(EdiMode="Yadif") and it's slower than MCBob().
Since you managed to use named parameter syntax in your 2nd line (EdiMode="Yadif"), I think you'll be able to figure how to use the same named syntax for the 1st line.

Testing with SD content, everything with default settings (i.e. empty parantheses: MCBob() / TempGaussMC_beta1() ), I found that TempGaussMC is 40% faster than MCBob. With really fast settings, it's running 4 times the speed of MCBob (though the results are not all that brilliant, then). Moreover, TempGaussMC has a lower memory usage than MCBob. In short, with SD I cannot replicate your findings.

Figuring the special needs of HD-1080 is the job of you guys. If you want me to figure those needs, no problem: feel free to provide me with the according hardware ... a beefy quadcore with plenty of RAM and a mighty GPU will do for now.
(Since ingenuity doesn't automagically reflect in $$$ or €€€, it's beyond my possibilites, sorry. Please excuse that I am poor.)


NB, you're really shooting the butterfly on a wheel. Going 1080i -> 480i means your going from 100% image area down to 16.6% image area, or the other way round: you're loosing 83.3% image area in the process. Still, you want to use golden nails to hammer some planks together? The vast majority of the intermediate improvement (at the 1080p stage) will be lost again when you've reached 480i. A plain and fast bob() does pretty good for that task ...
__________________
- We´re at the beginning of the end of mankind´s childhood -

My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!)
Didée is offline   Reply With Quote
Old 14th July 2008, 15:09   #57  |  Link
2Bdecided
Registered User
 
Join Date: Dec 2002
Location: Yorkshire, UK
Posts: 1,673
I think he's just a masochist. At least two of us have told him bob() is good enough!

btw, for typical camcorder footage shot without a tripod (i.e. the camera is never really still, so fields never really match) yadiff becomes the same as bob(), doesn't it?

Cheers,
David.
2Bdecided is offline   Reply With Quote
Old 15th July 2008, 07:16   #58  |  Link
florinandrei
Registered User
 
Join Date: Jul 2006
Posts: 118
OK, I get it.

I'm focused on Yadif() since it's fast enough - I get between 5 and 6 fps from it, which is good enough: this way it could make a DVD before I get back from work if I start it in the morning.
The better bobs are too slow.
Also, I can't distinguish visually between Yadif() and the slower bobs - not for this kind of processing anyway.

But now I have another issue. I just made a DVD-RW with 3 different algorithms - separatefields/shift/interleave, tdeint/mmc, and yadif - and tested it on the PS3 with an HD (progressive) screen.
Shift looks okay, more or less.
But the other two vibrate very badly when there's motion, as if the order of fields is mismatched, or something. The script is:

Code:
SetMTMode(2,2)
LoadCPlugin("C:\Program Files\AviSynth 2.5\plugins\yadif.dll")
DirectShowSource("00000.m2ts", audio=false)
Yadif(mode=1)
LanczosResize(720,480)
AssumeTFF()
SeparateFields()
SelectEvery(4,0,3)
Weave()
The HCenc ini is:

Code:
*MAXBITRATE       9500
*PROFILE          best
*AUTOGOP          15
*CQ_MAXBITRATE    5.000
*AQ               1
*DC_PREC          10
*INTERLACED
*TFF
*NOSCD
*MATRIX           mpeg
*LUMGAIN          1
*PRIORITY         normal
*WAIT             1
This is the file:

http://dl.getdropbox.com/u/29966/00000-yadif.m2v

I think I'll start by sprinkling AssumeTFF() in various places and watch the results. Maybe it's because I'm forcing TFF in HC.ini and it's not TFF? But AssumeTFF() in the .avs should take care of that.

It's kind of surprising to fail like this. IIRC, I tested it before and it was fine. But the scripts have changed quite a bit meanwhile.
__________________
Florin Andrei

http://florin.myip.org/
florinandrei is offline   Reply With Quote
Old 15th July 2008, 07:22   #59  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,802
What does this look like:

Code:
MPEG2Source(...)

AssumeTFF()
SeparateFields
Step through it frame by frame. Is the movement smooth or jittery? If it's jittery, try AssumeBFF.

Don't sprinkle randomly Determine the field order, set it, and forget it

~MiSfit
Blue_MiSfit is offline   Reply With Quote
Old 15th July 2008, 08:05   #60  |  Link
Didée
Registered User
 
Join Date: Apr 2002
Location: Germany
Posts: 5,394
DirectShowSource does not hand over the source's actual field order to Avisynth. If Avisynth doesn't have a discrete filed order info, it defaults to BFF. Yadif picks up the field order provided by Avisynth. Since your source is TFF, that's where things go wrong.

Possibility #1:
Code:
DirectShowSource("00000.m2ts", audio=false)
Yadif(order=1,mode=1)
Possibility #2: (mostly preferred)
Code:
DirectShowSource("00000.m2ts", audio=false)
AssumeTFF()
Yadif(mode=1)

Quote:
Originally Posted by Blue_MiSfit
Determine the field order, set it, and forget it
The "forget it" part can be dangerous, in case your filterchain contains a filter that always resets field order to BFF, such as Bob().
__________________
- We´re at the beginning of the end of mankind´s childhood -

My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!)
Didée is offline   Reply With Quote
Reply

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 01:47.


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