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. |
14th April 2011, 09:11 | #601 | Link | |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,391
|
Quote:
Here's a simple simulation of what has happened: Code:
BlankClip(width=576,height=480) interleave(BlankClip(width=576,height=480,color=$006000), \ BlankClip(width=576,height=480,color=$600000)) AssumeTFF().ShowFrameNumber() i1 = SeparateFields().SelectEvery(4,0,3).Weave() i2 = i1.bicubicresize(576,464,0,0.5) .addborders(0,8,0,8,color=$200000) stackhorizontal(i1.addborders(0,0,8,0,color=$002000),i2) bob(0,0.5) subtitle("bobbed interlaced source",x=160,y=32) subtitle("""interlaced source resized 'progressive', then bobbed""",x=576+88,y=32) return(last)
__________________
- 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 April 2011, 09:57 | #602 | Link |
partially-informed layman
Join Date: Jan 2002
Location: Bangkok, Thailand
Posts: 314
|
I'm an idiot. I had H264 decoding disabled in ffshow. I've enabled it now and DirectShowSource will open both .MTS fine. Incidentally the TM700 file had been giving exactly the same error as the HG21 file before I enabled the H264 decoding.
|
14th April 2011, 11:07 | #604 | Link |
partially-informed layman
Join Date: Jan 2002
Location: Bangkok, Thailand
Posts: 314
|
Didée, 3 questions about the script you used for the doll, which gave excellent results...
1. Have you tweaked that script specifically to cater for the horrific, moiré-inducing nature of the background, or is it a script that you might use generically for HD to 480i conversion? 2. Since QTGMC is a development of tempgaussmc, could tempgaussmc_beta2a(1,1,1,nsize=5,sharp=1,sharpness=0.0,svthin=0.0,sbb=0) be done in QTGMC, to minimise the number of scripts involved? 3. Where would the "missing" AR 16:9 aspect ratio flag go? |
14th April 2011, 12:34 | #605 | Link | |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,391
|
1. Yes / maybe
2. Sure, just need to use parameter names 3. x264: "--sar width:height" Generally, the usage of QTGMC (or even the 'double' usage) in this case here is ever-so-slightly over the edge. - With such a big downsize as in 1080 -> 480, a quite similar result probably could be achived with a much simpler bob (even yadif), or even with a direct fieldbased downsize. I just had to go the TGMC route, since johnmeyer concluded 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!) |
|
14th April 2011, 12:43 | #606 | Link |
Registered User
Join Date: Jul 2010
Posts: 448
|
Didée's script in QTGMC 3.31 form. Untested, just a settings conversion. I don't know what tempgaussmc_beta2a is, I only have beta2/mod (maybe a version that supports NNEDI3?).
Code:
# For more speed add Blocksize=32 and/or drop NNeurons and/or switch to "Faster" QTGMC( "Fast", TR0=1,TR1=1,TR2=1, NNeurons=1, SubPelInterp=1, Sharpness=0 ) -- >here< is a good point to save an intermediate Huffy or Laggy or FLV-y -- ;-) bicubicresize(1440,960) bicubicresize(720,960,-.8,.6) p1 = bicubicresize(720,480,-.8,.6) p2 = p1.QTGMC( "Slower", TR0=1,TR1=1,TR2=2, InputType=1 ) p2.blur(0,1).sharpen(0,.51).blur(0,1).sharpen(0,.85) i1 = assumetff().separatefields().selectevery(4,0,3).weave() # p1 # straight to 60p # p2 # plus more calmed i1 # re-interlaced p2 return(last) Code:
global MeGUI_darx = 16 global MeGUI_dary = 9 |
14th April 2011, 12:59 | #607 | Link |
Registered User
Join Date: Sep 2006
Posts: 55
|
@didee:
Nice analysis. I understood but half of it. The upshot I take it is that 'clip is broken' = 'clip cannot be reglued'. Again, I wonder if there is a strategy within qtgmc that might somehow minimize that goofy stretching yet still clean out the combing (SelectEven?). And of course I can always just keep it interlaced and live with the blur. It's only to be used at a low resolution anyway. Thanks for the help. |
14th April 2011, 17:01 | #608 | Link | |
Registered User
Join Date: Feb 2002
Location: California
Posts: 2,695
|
Quote:
I have been given many clips like this to clean up. First of all, the idiot(s) that screwed around with it before you got it managed to encode black bars into the video. Obviously you want to crop those out. Second, the way I have dealt with identical videos in the past is to separatefields() to end up with half-height double-fps video. I then carefully look at the odd and even fields. In the case of your video, it is quite clear that the odd fields were created from some sort of horrible estimation algorithm. You can see people's faces warp and distort. Yuchh! The approach then is to decimate (delete) the odd fields, crop out the black bars, resize the remaining fields to the original frame size (minus the crop), and then use MVTools2 to estimate the the missing frames/fields. Obviously you are losing the "resolution" from the decimated fields, but they contain nothing but garbage, so it really doesn't matter. The code below is extracted from a script I used when I restored all fifty-seven hour-long episodes of the Johnny Cash show for a collector several years ago. He got them from a collector in the UK who got them from Australia who got them from source here in the US. You get the idea. Too many hands. In my case, I was trying to get them to look like the original video broadcasts, and so I converted back to 60i. In your case, you might be happy just to convert them to 30p which is what I have done. Here's a low bitrate encode of the resulting video: KibSok_cut (fixed).avi If you encode at higher bitrate, it should look pretty clean. Code:
loadplugin("C:\Program Files\AviSynth 2.5\plugins\MVTools\mvtools2.dll") top_bottom_crop=40 AVISource("e:\frameserver.avi").ConvertToYV12.killaudio() crop(0,top_bottom_crop,-0,-top_bottom_crop) #Throw away bad fields. Video is now half size vertically. separatefields().selecteven() source=LanczosResize(640,464-top_bottom_crop) super2=MSuper(source,pel=2) backward_vec = MAnalyse(super2,blksize=16, overlap=4, isb = true, search=3 ) forward_vec = MAnalyse(super2,blksize=16, overlap=4, isb = false, search=3 ) MFlowFps(source,super2,backward_vec, forward_vec, num=30, den=1, ml=100) Last edited by johnmeyer; 14th April 2011 at 17:05. Reason: added additional note about bitrate |
|
14th April 2011, 17:57 | #609 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,391
|
Sorry John, but the technical part of your analysis of the problem is completely wrong.
At 'mastering' stage, nobody did try to deinterlace this video. The odd fields are not made by some horrible estimation algorithm, and the even fields share the very same issue like the odd fields. What happened was that interlaced 720x480 was resized to 640x464 with a resizer in progressive mode. Exactly that, nothing more, nothing less. Edit: proof: Your solution is good - since it's close to impossible to (sufficiently) revert the interlace-damage, keeping just one field & discarding the other is the next best thing you can only do. But the problem analysis definetly needed to be corrected. Edit: <*deleted*> (issue purged)
__________________
- 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!) Last edited by Didée; 14th April 2011 at 20:56. |
14th April 2011, 20:44 | #610 | Link | ||
Registered User
Join Date: Feb 2002
Location: California
Posts: 2,695
|
Quote:
You ask me to correct untrue things, and do so in public, so in good faith, let me attempt to do that. First, since you did not quote the entire post from the Sony forum let me clarify something. My post in the Sony forum was VERY long, so I agree that you should not have quoted it all, but since others may not read my post in that forum, there might be a mistaken impression that I somehow went on a rant against you. So, let me state for those reading here who don't visit that forum: I did not identify you in any way in that post, and no one reading that post would know that it was you. Second, I did not see the script you posted. I just looked at your post and see that it was edited approximately an hour and a half after the original post (the original post was at 14:55 and was last edited at 16:26). I am certain that I read your post just after it initially posted, and in fact you can see that my next post was at 15:36, which is about halfway between your initial post and your final revision. So, I don't know if you added or edited the script after your initial post. However, I can say for certain that the script I see there now is quite complete and exactly what I was looking for. Therefore, I can understand that you would be extremely upset with me for saying that you hadn't been responsive when in fact you have now provided exactly what I was asking for. I should mention that in one of my posts earlier in this thread I said: Quote:
Finally, I just now went to the Sony forum and I removed the sentence you quoted above from my post. So, I have apologized, have described how the situation arose, and have removed the offending quote. I hope that settles this. I had been working on a response to your tutorial on how improper resizing may have contributed to the bad things happening on the "KibSok_cut.avi" file, but given the circumstances, I think I'll lay low for awhile. Last edited by johnmeyer; 14th April 2011 at 22:45. Reason: edited to remove any trace of my post in the other forum |
||
14th April 2011, 21:08 | #611 | Link |
partially-informed layman
Join Date: Jan 2002
Location: Bangkok, Thailand
Posts: 314
|
Didée & -Vit-, thanks for the info.
Can anyone tell me how to correctly change the following script to output BFF instead of TFF? (I know this isn't directly QTGMC-related but I want to compare the result of this script with some others including some QTGMC versions and some BFF versions done in other ways) Code:
source=DirectShowSource("D:\My Videos\720x480-for-NTSC-DVD\challenge-Amendegw-AVCHD.MTS").assumetff() IResize(source,720,480) function IResize(clip Clip, int NewWidth, int NewHeight) { Clip SeparateFields() Shift=(GetParity() ? -0.25 : 0.25) * (Height()/Float(NewHeight/2)-1.0) E = SelectEven().Spline36resize(NewWidth, NewHeight/2, 0, Shift) O = SelectOdd( ).Spline36resize(NewWidth, NewHeight/2, 0, -Shift) Ec = SelectEven().Spline36Resize(NewWidth, NewHeight/2, 0, 2*Shift) Oc = SelectOdd( ).Spline36Resize(NewWidth, NewHeight/2, 0, -2*shift) Interleave(E, O) IsYV12() ? MergeChroma(Interleave(Ec, Oc)) : Last Weave() } Last edited by nhope; 14th April 2011 at 21:09. Reason: fixed code tag |
14th April 2011, 21:41 | #612 | Link |
Registered User
Join Date: Sep 2006
Posts: 55
|
Thanks, John, for your effort of digging into the matter. I'm going to try and play with it next week when I'm off in the country. Still, I'm not entirely convinced. Even if your test sample is very low bit rate, I'm still not sure it only sort of resembles what I get using SelectEven settings with qtgmc. And i respectfully disagree that the odd fields are remarkably different from the even ones. The problem seems to be that they are just consecutively disordered. I should have uploaded a sample of my test using the simple avs:
DirectShowSource ("E:\KibSok.avi") QTGMC (preset="fast") Lanczosresize (720,576) convertfps(50) So here, it's true, the warping is more finely accentuated in the major moving parts of my sample than with yours, but so is the detail in the unaffected more 'static' parts. And the latter comprise roughly 2/3 of the video. So I suppose it all boils down to a global psycho-visual appreciation of the subject matter. In fact if I just closed my eyes once every three seconds I'd have no problems at all But, I'll give your script an honest whirl. More importantly, I want to know how come you guys don't seem knocked off your feet by the gal in this video. |
14th April 2011, 23:05 | #613 | Link | |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Quote:
Since it works by resizing the individual fields directly, the IResize function preserves the field order of the input clip, so if you feed it BFF in, you will get BFF out. However, that won't help if the input really is TFF and you want to change it to BFF. In that case you would need to reverse the field dominance before calling IResize. Various methods exist for doing this (eg stickboy's JDL_ReverseFieldDominance), but a quick and dirty way (which loses the very first field) is SeparateFields.Trim(1,0).Weave() |
|
15th April 2011, 13:23 | #614 | Link |
partially-informed layman
Join Date: Jan 2002
Location: Bangkok, Thailand
Posts: 314
|
Thanks Gavino.
Going back to Didée's script to deal with that horror clip, I can see that the idea is to get a reasonable bobbed, 60p, full res clip and then do some fancy stuff to it, including bicubically downsizing it sequentially in stages and running QTGMC over it. Here's the resizing/filtering stage again: Code:
bicubicresize(1440,960) bicubicresize(720,960,-.8,.6) p1 = bicubicresize(720,480,-.8,.6) p2 = p1.QTGMC( "Slower", TR0=1,TR1=1,TR2=2, InputType=1 ) p2.blur(0,1).sharpen(0,.51).blur(0,1).sharpen(0,.85) i1 = assumetff().separatefields().selectevery(4,0,3).weave() # p1 # straight to 60p # p2 # plus more calmed i1 # re-interlaced p2 return(last) 1. Resizing in Vegas Pro 2. IResize "pure" script 3. QTGMC bob / Lanczos3 / no filtering > reinterlace 4. Simple bob > Didéeesque resize/filtering > reinterlace 5. Better bob (Yadif or TDeint) > Didéeesque resize/filtering > reinterlace 6. QTGMC bob > Didéeesque resize/filtering > reinterlace (=slow/ott) Each will be encoded to MPEG-2 in CCE Basic. It seems to me that there's a lot of filtering in Didée's script that may be excessive for most footage. Would anyone care to propose a "toned down" version that is more suitable for generic footage? Perhaps something between test 3 and tests 4/5/6? Resize in fewer stages perhaps? Use a faster preset for QTGMC perhaps? Or should I just go with it as is? |
16th April 2011, 02:22 | #616 | Link | |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Quote:
Yes, it will change TFF to BFF, but the resulting fields will have incorrect spatial alignment (if they were initially correct). |
|
16th April 2011, 03:05 | #617 | Link | |
Registered User
Join Date: Feb 2002
Location: California
Posts: 2,695
|
Quote:
I added an assumebff().separatefields() temporarily to the end of the script, and the temporal order was definitely correct (the initial video was tff), and I thought I saw the usual up/down movement between fields, but I guess I wasn't looking closely. I'll go back and look again. The only issue I was aware of when changing parity is that you can lose the first and/or last field in the video. But, I'm still learning ... |
|
16th April 2011, 08:06 | #618 | Link |
Registered User
Join Date: Sep 2006
Posts: 55
|
John, before running off tonight I did finally manage to do a couple of encodes with your script and it pretty much confirms that it's at best a toss-up compared with my qtgmc approach. I incorporated your crop formula to good effect. There is a slight problem though in that your formula gives me an aspect ratio that is noticeably squished horizontally. I adjusted your script for PAL usage (num=25). Perhaps something went askew there. Anyway, thanks for the old college try.
On a quite separate note regarding your 'apology' to Didee, inasmuch as the offended party has re-edited his post for the second time and removed the accusation, maybe you ought to remove your apology as well. As it stands, it actually makes you out to look like the good guy. To be more pointed, your altercation was another example of what unfortunately can happen when people abuse the prerogative to edit their own posts. I can't tell you how many times I've been thrown into a loop when people pulled such stunts with me. IMO an edit should be limited to the odd misspelling or rephrasal or such. But otherwise posts ought to remain in the spirit of what a forum really is supposed to be about: an honest running conversation between two or more parties. And if this means living with errors, omissions and delayed follow-ups so be it. I mean how often to do you go back and reread what what was posted an hour or day ago just to be sure there haven't been any 'updates'? And although it may have had the best intentions, Didee's edit should instead have been a separate follow-up. But as it stood, it made you appear not only to be presumptuous (which you were) but also a liar. I hope he at least sent you a humble little PM owning up to this. In fact his now excised 'accusation' (which by the way broke forum rule No. 9 big time) shouldn't even have appeared in this thread as it concerned a matter in a third-party forum. It should have been handled entirely by PM (or on the Sony site). With that out of the way, I wish one and all a happy Easter week. Cheers. |
16th April 2011, 10:04 | #619 | Link |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
The temporal order is correct, but top field pixels have become bottom field ones and vice versa, so will be displayed in the wrong place in the frame. Look at a still sequence and you will see immediately.
|
16th April 2011, 15:26 | #620 | Link | |
Registered User
Join Date: Feb 2002
Location: California
Posts: 2,695
|
Quote:
In looking at scripts I wrote in the past, when I ended up having to reverse fields one time a few years ago, I wrote the code below, so I must have tried the simpler approach and realized it didn't work. I thought I was solving a tougher problem back then, but I guess it was this same thing. Code:
source=AssumeBFF() even=source.trim(1,0).separatefields().selecteven odd=source.separatefields().selectodd interleave(odd,even) fixed=weave() #In the line below, use the OPPOSITE of what you chose above #because the fields have now been reversed. AssumeTFF(fixed) Last edited by johnmeyer; 16th April 2011 at 15:30. |
|
|
|