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. |
8th July 2008, 07:02 | #42 | Link | ||
Registered User
Join Date: Jul 2006
Posts: 120
|
Quote:
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:
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? |
||
8th July 2008, 08:33 | #43 | Link | |
Registered User
Join Date: Apr 2008
Location: St. Petersburg, Russia
Posts: 334
|
Quote:
|
|
8th July 2008, 22:10 | #44 | Link |
Derek Prestegard IRL
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
|
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
__________________
These are all my personal statements, not those of my employer :) Last edited by Blue_MiSfit; 8th July 2008 at 22:31. |
11th July 2008, 06:22 | #46 | Link | |
Registered User
Join Date: Jul 2006
Posts: 120
|
Quote:
I know for a fact that HC Encoder complains if the input is not YV12 so that must be it, AVCHD is already YV12. |
|
11th July 2008, 18:34 | #47 | Link |
Registered User
Join Date: Jul 2006
Posts: 120
|
I did something like this:
Code:
SetMTMode(2,2) AVCSource("00000.dga") MCBob() LanczosResize(720,480) AssumeTFF() SeparateFields() SelectEvery(4,0,3) Weave() 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. |
11th July 2008, 19:02 | #48 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
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!) |
11th July 2008, 19:41 | #49 | Link |
Derek Prestegard IRL
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
|
^ 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
__________________
These are all my personal statements, not those of my employer :) Last edited by Blue_MiSfit; 11th July 2008 at 19:49. |
13th July 2008, 10:20 | #52 | Link | |
Registered User
Join Date: Aug 2002
Location: Italy
Posts: 303
|
For those who don't know, MediaCoder build 4130 now has the
Quote:
__________________
HYbrid Multimedia Production Suite project @ GitHub |
|
13th July 2008, 12:53 | #53 | Link |
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!) |
13th July 2008, 22:40 | #54 | Link | |
Derek Prestegard IRL
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
|
Quote:
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
__________________
These are all my personal statements, not those of my employer :) |
|
14th July 2008, 01:37 | #55 | Link | |
Registered User
Join Date: Jul 2006
Posts: 120
|
Quote:
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? |
|
14th July 2008, 12:16 | #56 | Link | |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
Quote:
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!) |
|
14th July 2008, 15:09 | #57 | Link |
Registered User
Join Date: Dec 2002
Location: 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. |
15th July 2008, 07:16 | #58 | Link |
Registered User
Join Date: Jul 2006
Posts: 120
|
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() 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 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. |
15th July 2008, 07:22 | #59 | Link |
Derek Prestegard IRL
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
|
What does this look like:
Code:
MPEG2Source(...) AssumeTFF() SeparateFields Don't sprinkle randomly Determine the field order, set it, and forget it ~MiSfit
__________________
These are all my personal statements, not those of my employer :) |
15th July 2008, 08:05 | #60 | Link | |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
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) Code:
DirectShowSource("00000.m2ts", audio=false) AssumeTFF() Yadif(mode=1) Quote:
__________________
- 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!) |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|