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. |
10th December 2005, 15:16 | #462 | Link | |
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,078
|
Quote:
Just one (probably stupid) question: Is there a general rule of thumb which field should be kept and which one should be interpolated? It would be nice to be able to narrow the four different cases down to just two. Cheers manolito |
|
10th December 2005, 23:04 | #463 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
There really isn't any rule. I have heard some people claim that graphics and logos usually tend to be top field aligned.. in which case keeping the top field and interpolating the bottom field would give better results. Usually, it is simply a matter of whatever looks best to you and most of the time it is hard to tell any difference. I personally usually keep the top field for tff material and keep the bottom field for bff material out of habit.
|
11th December 2005, 06:15 | #464 | Link |
ангел смерти
Join Date: Nov 2004
Location: Lost
Posts: 9,558
|
Tritical, is there any way to get TDecimate to create 120 fps files? (I doubt it, but I thought I'd ask.) I can import a timecode file and fill in frames based on the frame rate, so far that's looking like the simplest method. Unless someone can point me to something better?
(I'm trying to finish updating avisynth.org's vfr page with a 120 fps method that doesn't suck horribly. Even cooler would be something to insert drop frames into an avi/mp4 based on a timecode file, but I doubt that exists.) Last edited by foxyshadis; 11th December 2005 at 06:22. |
11th December 2005, 10:21 | #465 | Link | |||
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
Quote:
The method for encoding 120fps currently described on the variable framerate page of avisynth.org does it such that the output from the avisynth script is a 29.970 fps file similar to what you get out of tdecimate(mode=5). A separate program (AVI60.exe) then goes through and modifies the final encoded file by inserting drop frames as needed. That process would be the same as having a separate program that goes through and inserts n-vops based on the timecode file output by tdecimate. Quote:
Quote:
As far as 120fps encodes go I am not a proponent, but currently it is pretty much the only way to deal with 24/30 mixes without using mkv and without resorting to blending. I am hoping that mp4box will eventually get the ability to create vfr mp4 files based off a timecode file in the same fashion as mkvmerge. Last edited by tritical; 11th December 2005 at 11:00. |
|||
11th December 2005, 13:38 | #466 | Link | |
ангел смерти
Join Date: Nov 2004
Location: Lost
Posts: 9,558
|
I use mkv was well, but I'm updating the page to help the people who need or want to use the different methods. Some of them were abominations, and this is the only one I haven't found a good substitute for. A method that requires Avisynth 2.0 and a variety of ancient plugins is just evil.
Quote:
I found some information searching around, though; virtualdub can now write drop frames to raise the framerate (or lower it back), so I'm going to dig through the source and ask phaeron how it works. (If you want to see, set it to direct stream copy and change the framerate to, say, 119.88, 4 of every 5 frames will be drops hardly adding any size to the avi.) Of course it's always supported drop frames for captures, but this enables a nice quick comparison. Edit: It looks as if it's simply a matter of creating zero-length frames, which are frame header "30 30 64 63" and then a 4-byte lenth "00 00 00 00". The index is composed of a collection of: the same frame header, a 4-byte keyframe flag, a 4-byte index (LSB), and a 4-byte length (LSB); drop frames simply enter zero for length. Oh, and a chunk in the beginning with fractional framerate and framecount, 16 bytes from the 4CC start. Otherwise the files are almost byte-identical, there's no groupings of frames like newer containers. I will investigate mp4 methods however. Last edited by foxyshadis; 11th December 2005 at 14:54. |
|
11th December 2005, 17:35 | #467 | Link |
Guest
Join Date: Jan 2002
Posts: 21,901
|
@tritical
In EEDI2(), I'm confused by the field parameter. The readme says that field=0 should copy through the bottom field and interpolate the top. But this script shows no difference between a and b. If I change to field=1, a difference can be seen. This suggests to me that the field settings are 0=top and 1=bottom. Am I going astray? a=assumebff.separatefields().selecteven() # bot fields only b=a.eedi2(field=0).assumebff().separatefields().selectodd() subtract(a,b) # should compare original bot to interp'ed top Last edited by Guest; 11th December 2005 at 17:39. |
11th December 2005, 19:59 | #468 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
@foxyshadis
Thanks for the info. Now you've got me really interested in making a tool to do this. I'll take a look at a converted file from vdub. @neuron2 I can't run the script you posted without adding assumeframebased() before the second separatefields call (that was changed between 2.55 and 2.56 i think). Using the following script: a=assumebff.separatefields().selecteven() # bot fields only b=a.eedi2(field=0).assumeframebased().assumebff().separatefields().selectodd() subtract(a,b) # should compare original bot to interp'ed top definitely shows a difference here. While the following scripts: a=assumebff.separatefields().selecteven() b=a.eedi2(field=0).assumeframebased().assumebff().separatefields().selecteven() subtract(a,b) a=assumebff.separatefields().selecteven() b=a.eedi2(field=1).assumeframebased().assumebff().separatefields().selectodd() subtract(a,b) show no difference as expected. Not sure what is happening to cause problems with your script. |
12th December 2005, 03:24 | #469 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
@foxyshadis
Alright, so I've almost got a working program to do the drop frame insertion for avi. It can parse all the avi header info, modify framerate/count, parse all the frame chunks and insert drop frames, and parse and modify the index. To make it less complicated to code there are currently a few restrictions: the avi can only have one stream and it must be a video stream ("00dc"), the output must be 119.88 fps, the timecode file must be v1 and can only have framerates of 17.982, 23.976, 29.970, 39.960, 59.940, and 119.88 fps, and it only supports avi files with the "idx1" index type and not opendml avi's that have the "indx"+"ix##" index. However, given the relatively specialized use of such a program I don't think that those restrictions should be much of a problem. Last edited by tritical; 12th December 2005 at 03:29. |
12th December 2005, 05:28 | #470 | Link | |
Guest
Join Date: Jan 2002
Posts: 21,901
|
Quote:
|
|
12th December 2005, 09:46 | #471 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
Finally got this thing working. [link removed]. Syntax is:
see here It will create a new 119.88fps file at "c:\path\avifile-120.avi". All restrictions mentioned above apply. So now it is possible to do a normal vfr encode with tfm/tdecimate(mode=5) with v1 timecode file output... encode the output from tdecimate to avi and then run this program on it to get a 120fps avi file. I'll give it a better name, make a readme, put the source with it, and release a full version sometime later this week. I've also fixed the edeint mode=1 problem with tdecimate and have gotten the external motion mask stuff working so there will be new version of TDeint soon too. Now it's time to sleep . Last edited by tritical; 30th December 2005 at 06:23. |
12th December 2005, 10:17 | #472 | Link |
ангел смерти
Join Date: Nov 2004
Location: Lost
Posts: 9,558
|
Whoa! Cool! You had a busy sunday.
Since it's meant to be used right out of avisynth rather than on pre-existing avis, that certainly makes sense. Not every tool can be a virtualdub. =p I'll wait for your final copy before I update the page. |
13th December 2005, 11:46 | #473 | Link | |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
Quote:
Anyways, I would advise against using the version I linked above for now as it had some bugs in modifying the offsets for the index entries. I've also gotten quite a bit more done since then and expanded the functionality... I've added a PAL mode, that creates a 50.000fps avi file, that goes along with the current 119.880 fps NTSC mode. The possible framerates in the timecode file are now: NTSC -- 119.880/n for n=1 to 25 (step=1) PAL -- 50.000/n for n=1 to 10 (step=1) It now accepts v2 timecode files as well as v1. It's also working in conjunction with mkv2vfr off haali's site, so you can take a vfr mkv file, extract the avi and timecode file using mkv2vfr, and then use this program to go straight to a 120fps avi file (assuming the framerates can be represented). The extra possible framerates also make it so you can use it in conjunction with Dedup (either with or without TDecimate) as long as the maxdrops is no greater than 5 and starting fps was 25, 50, 23.976, 29.970, etc... Once a final version of this program is done I think I will also make one to go from 120/50fps avi to a timecode file and avi without drop frames (though I think a program to do this already exists ). |
|
13th December 2005, 20:56 | #474 | Link |
Huba Huba
Join Date: Aug 2005
Location: Palumbian Jungle
Posts: 78
|
Your tfm filter from TIVTC v1.0 Beta 4 is missing mode=7, it throws an error pointing out that there's only up to 6. Beta 2 (fortunately, I it still exists unlinked on your site) is ok and has got this wonderful new mode e.g. for reversal of crappy PAL->NTSC transfers w/ decimation cycle 6. If this is not an error, you should update the documentation or people might wonder... on the other hand, nobody noticed since now :->
__________________
"The innocent have nothing to fear" :stupid: |
14th December 2005, 09:18 | #475 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
It is definitely a bug if it is telling you that. Could you post the exact script you are using to get that error and the exact error message? I can't reproduce the problem here (tfm(mode=7) works fine) and none of the code changes between beta 2 and beta 4 had anything even remotely to do with that functionality. Also could you use tfm(display=true) and make note of the version number for tfm that it shows?
|
14th December 2005, 23:06 | #476 | Link |
Huba Huba
Join Date: Aug 2005
Location: Palumbian Jungle
Posts: 78
|
Damn (i.e. somehow embarrassing to me, good for you) - I cannot reproduce the problem either and I have upgraded avisynth and the script since then. While I am quite sure that I got this error message, it might be that avisynth somehow loaded an outdated dll w/o mode 7... I'll try to be more thorough next time :-o
And on the more productive side, I've got a question: Does it help TFM to process frames and/or speed up the process noticeably if any black borders are cropped before, or shouldn't I do it because it could break field matching? In other words, is crop().tfm().resize() faster or is tfm().crop().resize() safer?
__________________
"The innocent have nothing to fear" :stupid: |
15th December 2005, 17:25 | #477 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
As far as speed is concerned it depends on how much you are cropping and what the values are. If you are only doing something like (4,0,-4,0) then it would probably be faster to crop after tfm cause the 4 off the left side will throw off the alignment which makes a difference for simd routines. However, if your crop values for the sides are multiples of 8 then that wont be a problem, or you could use crop(,,,,align=true) which would also keep alignment for the rest of the script (but will cost a few bitblt's). You'd have to be cropping quite a bit off the frame for it to make a noticeable difference in tfm's processing time I think.
For how it effects field matching, cropping off black borders can't hurt, but how much it would help depends on how much noise the borders have and how big they are. tfm's field matching routine already ignores the first 8 pixels on the left/right sides and the first 2 lines off the top and bottom because it usually tends to be junk. And if the borders have no temporal noise then they wont be having any effect in the field matching anyway. |
17th December 2005, 18:28 | #479 | Link |
Moderator
Join Date: Oct 2001
Location: Hawaii
Posts: 7,406
|
Hi-
I was creating a Lagarith uncompressed AVI before feeding it to CCE. VDubMod got almost to the end before aborting with the error: AviSynth read error: TDecimate: internal error during prebuffering (131727, 131728, 20)! And the AVI came up 60 frames short of being complete. I had done a similar encode earlier with a larger Cycle, and it had come up 100 frames short. Here's the script: LoadPlugin("F:\DivX Stuff\GKnot\DGDecode.dll") LoadPlugin("F:\DivX Stuff\GKnot\RemoveGrain.dll") LoadPlugin("F:\DivX Stuff\GKnot\TIVTC.dll") LoadPlugin("F:\DivX Stuff\GKnot\Undot.dll") MPEG2Source("K:\Harold Lloyd Comedy Collection-Vol1-Disc1\1-1\1-1.d2v") Trim(550,0) TFM() TDecimate(Mode=0,CycleR=10,Cycle=38,Chroma=False) Undot() RemoveGrain() Using TIVTC v1.0 Beta 3 for AviSynth 2.5.x Also, when using the Display parameter, it doesn't show all the frames in the Cycle before starting fresh again, so I can't see the information for most of the frames on the VDubMod screen. Did that make any sense? So I'm unable to see all the frames in the cycle to see what was kept and what was removed, and why. I don't really feel like running DebugView. I don't guess there's any workaround is there, when the cycles are large like that? |
17th December 2005, 23:16 | #480 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
Try beta 4 and see if it works ok. Beta 4 fixed the problem prebuffering was having processing the last two cycles of a clip. That's why beta 3 only managed to last one day.
Yeah, atm the display info for large cycles doesn't really work cause any text that would be written off the frame (either vertically or horizontally) is just skipped. I'll try to change that in the next release and have it wrap around to multiple columns or something. |
Tags |
tdeint, tivtc |
Thread Tools | Search this Thread |
Display Modes | |
|
|