This content has been marked as final. Show 203 replies
Very nice...excellent work, gentlemen. I'll be trying it on a few projects very soon.
Nice work. And, the website supporting it is well designed; clean and well organized.
Well done, Jim. I have NitroPDF Pro, so I can help on that front. I plan on doing a multi-part video tutorial, so if there are technical edits to your procedure that I think are worth submitting for your approval, they'll probably come during/after the tutorial's creation.
My web site can host streaming video, so when the tutorial is done, it'll be no problem to host it there as well.
Wow, Jim... You were correct when presaged that pt. IV will something different! That's pretty cool. Obviously, I need to find a little time to go through everything.
I saw that you renamed my package to dv2film -- I have no problem with that, but I wish you'd made me aware that you changed the function name within the .avsi file. That means that previous examples posted on this thread (and more importantly, those in the usage examples in the .txt file) will not function when called verbatim, which will be an issue for those who try to follow the instructions.
It may also be a problem that you've renamed the .avsi file -- as those who downloaded the old one may have conflicting function names and mismatched versions of helper functions. You shoudl remind users who have downloaded the old "dv60i2film.avsi" delete that and the "dv60i2film.txt" file from their plugins folder.
I have uploaded a new version that has dv2film() as an "alias" to dv60i2film(). Please replace the version on your site with this one ASAP, so that it will work both ways.
The reason I named the function dv60i2film() is that it ONLY works with 60i material. I have separate functions for 50i, for example, and other variants (such as 30p or 25p) won't really work at all.
Eventually, however, I'd like the dv2film() sub-function to call the appropriate function based on whether input is 60i or 50i -- possibly I'll have made functions to better deal with 25p or 30p sources as well.
I thought about telling you, but I kind of waned it to be a surprise. Plus I didn't want to say anything until I knew I could pull it off.
That's a good call on the text file. I forgot to change the usage examples. Also, I did want to go over some changes in the text file, see what you think. I had some ideas about making it easier for less than technical folks to understand. (Hell I'm pretty technical and even I had to 'figure it out'.)
I guess we have our first upgrade. Version 1.1 will be up tomorrow.
(I understand your point about working only with normal video. I took the 60i out mostly to make a better name, but also because it's kind of a pet peeve of mine. Specs should always and only list whole frames, never fields, IMO. Hence the bottom FAQ on the Home page.)
> Specs should always and only list whole frames, never fields, IMO
Well, it seems most camera manufacturers prefer to specify 60i/50i... but, the real reason I use this terminology is that, in reality, I am converting 60 fields to 24 frames. Those fields are turned into full frames (via interpolation, etc.) -- but 60:24 is a good way of visualizing the relationship of input to output.
Nice design, Jim. To fix the problem of the template shifting to the left (in certain browsers) when the right-scroll bar is introduced, try adding this to your css:
margin: 0 0 1px;
Thanks, Jeff. I had noticed that using Firefox 3.
Cool site, will keep my eye on it.
One question though, does Dv2film do any color or grain filtering to simulate film, or is this simply a native-30i to 24p conversion?
Jim -- I'm not sure you have the right to locate and distribute AviSynth, VirtualDub, Cedocida, ABS, etc. on your server. It is best to provide links to the original (official) locations.
>I'm not sure you have the right...
'Tis better to ask for forgiveness than permission. :)
Two other notes about the site:
1. I saw Dan Isaac's name mentioned in the document, but it could be a bit more prominent. (Bold, color? Something that is proportional to the huge credit he deserves.) Similarly, some sort of kudos to Jim and Jeff Belune should be in order, for their tireless beta testing efforts.
2. I don't know if this is inline with your goal for the site -- but would you consider adding a forum? Granted, there's this forum here, but if that's the case, maybe you could have a resources page that links to this forum, and eventually will have a home for Jeff Belune's video tutorials, as well as I'm sure the Wiki articles that Eddie is already probably devising. Seems like this page will be needed eventually.
(Would it be helpful if King Leonard made a subfolder for DV2film threads in the Premiere forum? Maybe Adobe wouldn't allow that?)
It does appear these programs are all GPL'd, Dan. So it shouldn't be an issue.
I do have some ideas for something a little more substantial than just kudos, Jeff, but specifics are being withheld until something is actually in place.
The idea for a forum on the site is already being considered. Technical details are being worked out. But thank you for the suggestion. Those kinds of ideas are always valuable.
Okay, I was going to keep this off-list, but since there seems to be a developing attitude here, I will post publicly.
I'm surprised at you, Jeff. You should know better. I know that you want the copyright and licensing for your tutorials and other of your several works, however free or restricting they actually are, honored by those who view and use them. I would expect that you would give the authors of these open-source tools the same courtesy.
It was really poor form for you to change the name of Dan's scripts without consulting him first. Initially, I didn't notice that you had dropped "60i" from the name of the script function, all I noticed was that you had capitalized the F in Film. Dan has already pointed out how your arbitrary change invalidated the script templates in his *extensive* documentation, but even if that damage had not been done, it was a professional discourtesy to him to not even ask his permission to execute the name change.
As Jim rightly pointed out on the dv2Film web site, this whole evolution has been a "labor of love" by those involved in the development and testing of dv2Film. It may seem that I am going overboard by pointing out what you may (or may not) feel are small transgressions, but when one has donated a lot of their time and effort for the common good, with no hope of monetary compensation, honor and respect become part of the expectation and the reward. A little of what drives the open source community has been lost here, and I'd like to get back to doing what's right.
>It was really poor form for you to change the name of Dan's scripts without consulting him first.
It was a gamble. I was torn between asking and offering him the surprise of what I had in mind. I went for the surprise. (I hope he doesn't mind too much.)
> I would expect that you would give the authors of these open-source tools the same courtesy.
True, fair 'nuff.
The new version is tested and uploaded. (I just capitalized a couple of F's for consistency. The idea here being that dv sucks, and Film rules, so Film gets the upper case.)
Don't get me wrong, Jim. I'm very glad that there is a dedicated page for this but I am slightly miffed that you changed the function name without discussing it with me. After all, I am the one who needs to maintain the package so it's good for me to know if it has been altered in any regard. No biggie. Let's move on.
If you want this to be the official home of the package, there are a few things that should be done:
1.) Instead of simply having links to directly download AviSynth, etc. there needs to be a separate page for each package. Give the authors credit and provide a link to their site(s). This is important, as many of these tools are updated/patched from time to time and this would allow users access to the latest versions. There should also be basic information about each tool:
a.) DV Codec -- It is a little risky to have users simply download and install Cedocida. Some people may already have usable DV codecs (MainConcept, Matrox, Canopus, etc.) that they prefer. Since Windows only allows one codec to serve DVSD, installing Cedocida will steal association for this FOURCC and may cause their other DV codec to disappear from the codec options in VFW applications.
There are also options beyond DV: Matrox users may opt for the Matrox MPEG2 I-frame codec. Cineform's codec is also good option for those who own it. DVCPro, M-JPEG, lossless, etc. are also viable options. DV happens to be what Premiere handles best natively, but people who use other tools may prefer something else with better quality.
b.) VirtualDub -- this needs "installation" instructions (or lack-of-installation, if you will). I suggest telling users to make a c:\Program Files\VirtualDub folder and place the files in there -- then copy & paste a shortcut to VirtualDub.exe on their desktop. Otherwise, users may simply extract the .zip to their desktop and (upon first launch) VirtualDub will write some keys to Registry about its current location. Not the end of the world, but a little bit messy.
c.) AviSynth -- there certainly needs to be information about what it is and what it does. If users encounter any issues with installation, plugins, etc. you will likely be unable to help them. Providing a link to http://avisynth.org is essential -- and it is also a good idea to provide supplementary links to http://avisynth.org/warpenterprises/ and http://forum.doom9.org/ . As one who is benefitting from the genius of AviSynth, I feel there is some obligation of advocacy. Users should be encouraged to learn as much about this tool as possible -- so that they can get the results they need and eventually to contribute important improvements to the process.
d.) ABatch Scripter -- this also needs a description and a link to their homepage.
e.) dv2film -- You and I need to find a way by which I can always provide you with the latest version. Perhaps I should create a "sticky" link on my (real) website that will always return the latest version.
2.) There needs to be an HTML version of my description of all script parameters on your site.
3.) It's great that you've got a "Standard" and "4x3 -> 16x9" page but there should be others:
a.) 1080/60i -> 1080/24p (or 720/60p -> 720/24p, which should work
exactly the same)
b.) 1080/60i or 720/60p -> 480/24p
c.) PAL <-> NTSC conversions
The HD workflows would be particularly practical for those who have intermediary .AVI codecs, such as Cineform or Matrox. There is also the option of using Elecard Converter Studio, ProCoder or similar software to create HD MPEG2 files that can be edited in Premiere.
Looks like I have my work cut out for me. But this is exactly what this part of the series is for. What's up there now was very much a first effort, just to have something people could look at and actually use. I'm sure many improvements will come to the site, and I hope to the script.
That's a good first list, Dan. Thanks.
Notes on some other sections on your site:
Home / What kind of video can dv2Film be used on?
Actually, it can currently be used on all of these sources:
480/60i, 480/60p, 576/50i, 576/50p, 720/60p, 720/50p, 1080/60i, 1080/50i
The only requirement beyond that is that AviSynth must be able to read the file. This would include just about any AVI codec or DirectShow compatible format, MPEG2, and AVCHD -- though the latter two require additional plugins.
The workflow as outlined on your page may be slightly different, but all of these formats will "work" with the functions provided in the package. You may want to mention this fact. As I said before, it is essential that we eventually provide some HD workflows also.
Home / What's the difference between 30i and 60i?
You need to get past your personal peeve and begin referring to things as 60i -- like it or not, fields-per-second is much more relevant that frames per second (that's why it's used by camera manufacturers). "Fields" are the lowest common denominator and an accurate descriptor of the temporal resolution of the video. In truth, "60i" is 60 interlaced half-resolution frames per second. From a processing standpoint, that is much more meaningful. Adobe has opted for the frames-per-second scheme so that the name of the preset matches the timebase of the editing mode. This is totally irrelevant to processing raw footage.
Processing / Prepare your footage
"Follow the blank link to the left for specific instructions how"... Huh?
Processing / Folder Structure
Instead of folders called "30i" and "24p", how about "original" and "converted"? Not only does this circumvent your peeve, but it provides flexibility for those whose sources are 50i or 60p -- and those who want to output PAL 25p instead. "24p" is also not the most accurate folder name for hard-telecined output via PulldownMethod. More generic names will accomodate all sources and possible settings.
Processing / Process Footage
The Cedocida options should be discussed on the DV Codec download page (because some users may opt not to install or use it). Simply provide a link to it here. You may also want to include a screen capture of the codec settings dialog -- this will make it easier to understand and follow.
Processing / Export
"Encore will add the pulldown for you when you go to make the DVD" This is not true: Encore will blend 24p into 30p, which is even worse than adding pulldown.
At some point we should post a how-to using DebugMode FrameServer and HC Encoder. The quality is better and encoding is much faster. That done, a link should be placed here.
Processing / Process Footage
Your comments about the speed of processing are totally dependent on the speed and configuration of the user's computer. Running multi-threaded AviSynth on my Q6600 will probably get me 3x what you're seeing on your P4. Feel free to mention that it is slow, but perhaps you are overstating it.
More good stuff. Thanks, dude.
On your "standard" conversion workflow page, you should mention that this works for both 4x3 and 16x9 sources. It may also be worthwhile to mention that VirtualDub's output will be "unflagged", so you'll need to use "Interpret Footage" for 16x9 material in PPro, Encore, AE, etc. and probably something similar in other programs as well.
Another tip: If you are processing 16x9 footage you can use DVDate to add the 16x9 flag to the RIFF header.
Processing / Create Scripts:
I see you have opted for BlendMethod=1 on the "standard" conversion, but Blendmethod=5 on the "4x3->16x9" page. I assume the latter was a compromise based on its longer processing time.
I might suggest using BlendMethod=5 for all examples. It is fast and quite good. Although I agree that "1" is really cool and can give the most realistic time conversion, it is very slow (impractically so for HD material) and can give goofy results from time to time as you've seen. There should perhaps be a page about "To MoComp or not to MoComp" explaining the differences in quality, performance and reliabilty of mocomp vs. field blending.
To my eye, BlendMethod=5 looks excellent -- Jeff and Hal also seem to feel it is very good. (note to self: make BlendMethod=5 the default setting, along with DeintMethod=2 ... I should have done that last time around).
>On your "standard" conversion workflow page, you should mention that this works for both 4x3 and 16x9 sources.
I wasn't sure just how to make that clear. This is definitely a work in progress.
>I assume the latter was a compromise based on its longer processing time.
Actually, no. It was in deference to you and Jeff finding it acceptable. But honestly, I keep doing test after test, and I keep coming back to the conclusion that BlendMethod=1 is the best in all cases. But it looks a little stuttery without Motion Compensation.
I was kind of hoping you might look into that ghosting anomaly further while I start work on the already proposed site changes. I would really love to get that resolved.
>note to self: make BlendMethod=5 the default setting, along with DeintMethod=2
I agree for now, especially about Deint. But can I entice you to work towards the goal of making iM=2 and Blend=1 the workable default for NTSC?
I won't say no - yet. I'm not a big fan of scripts on a web page. I have a script blocker in my browser and it does a wonderful job of blocking a hell of a lot of crap that's out there on the 'Net, but it's a pain in the *** when people design friendly web sites that use script. I'd prefer the good guys stick purely with XHTML. So I rather like the idea of having no scripts/cookies on the site.
But, if someone were to write one...
>Actually, it can currently be used on all of these sources:
480/60i, 480/60p, 576/50i, 576/50p, 720/60p, 720/50p, 1080/60i, 1080/50i
OK, which ones can currently be converted to 480p/24 without additional lines of script, using only the currently included parameters?
> which ones can currently be converted to 480p/24 without additional lines of script, using only the currently included parameters?
Well, only 480/60i (lower field first) and 480/60p will output 480/24p.
Other formats will output their native resolution (i.e: 1080 in = 1080 out). So that:
Any .AVI that is 60p will work as expected.
Any .AVI that is 60i will work as expected, so long as it is lower field first (you'll need an AssumeTFF() after AviSource() if it's not).
You're correct to show the type of workflow you have (standard DV in, 24p out) and state that this workflow is for standard 60i DV input, but it shouldn't be said that the package will not work with other formats.
> it does a wonderful job of blocking a hell of a lot of crap that's out there on the 'Net, but it's a pain in the *** when people design friendly web sites that use script.
> I'd prefer the good guys stick purely with XHTML
You can't do s**t with (x)HTML. No interactivity, no image rollovers, no expanding menus, no way to test browser and plugin versions... People like you are the bane of every web designer. For some reason "Canary in a Coalmine" by the Police keeps running through my head as I type this. :)
I've been testing out some workflows for HDV material. I'm actually coming up with some interesting solutions for batching stuff.
What's very cool is that DGIndex allows you to use an AVS Template (which you can use instead of AVS Batch Scripter) to index, demux, and create the scripts automatically in one step via a DOS batch file. So, imagine there are 2 different HDV script templates:
1.) HDV 60i (or 60p) -> HD 24p
2.) HDV 60i (or 60p) -> 480p
Even better, if you create and save a Processing Settings file in VirtualDub for your compression options, you can run the command line version of VirtualDub (vdub.exe) to automatically compress the output from the scripts as they're created. This makes an HDV 60i -> 24p conversion extremely simple: Just customize the paths in the .bat file and run it... done.
Granted, for #1 above this will require a suitable HD .AVI codec like Cineform, Matrox HD I-frame, or possibly DVCProHD.
It's also got me thinking that a similar process could be made for "normal" DV60i -> DV24p conversions, but the DOS batch approach would be way too clunky. At some point I may consider programming and comiling these in command line executables that will prompt for options. It's possible that the entire dv2film process can be accomplished this way, for both HDV and DV sources and/or output.
The thread is "Putting It All Together"... Maybe this is the best way to do that.
>Well, only 480/60i (lower field first) and 480/60p will output 480/24p.
OK. So I wasn't far off when I said it works with only NTSC video. Just from an organizational point, I'd like to fix all the web site issues relating to getting 480p/24 output, as that will probably be the most useful. Once that's done, then we'll have a solid template to start adding instructions for other things, like HD, NTSC/PAL conversion, slow-motion, etc.
(By the way, what camera delivers 480p/60?)
>You can't do s**t with (x)HTML. No interactivity, no image rollovers, no expanding menus
Yeah. :) Like I said, it blocks all that crap. Just keep thing simple, I say.
>It's possible that the entire dv2film process can be accomplished this way,
That is actually an idea I've been toying around with. The ideal scene here is to have a single application with a GUI that users can use to choose the files to convert, choose their conversion settings and then choose the folder to write the new files to, all under one roof. Much like DVFilm Maker, but one that actually works well.
That would also be something you could monetize, if you chose.
> By the way, what camera delivers 480p/60
All Pansonic HVXs, I believe. Even though the script won't handle .mxf files, you can wrap them in DVCPro .avi containers. The JVC GY-HD100U also has 60p, but I believe it's MPEG2 ts (which would instead follow the HDV workflow)
You can also use an external deinterlacer to pre-convert stuff to 60p. It could potentially be used for 60p animation also.
> have a single application with a GUI
I don't really have a desire to make a commercial product from this. I'm think about a nice command line utility with an .ini where paths and last settings used are stored.
I can probably write it fairly easily a "shell script" in Perl and use perl2exe to compile it... like a DOS batch on steroids :) Once that's done, perhaps I'll play around with providing a GUI -- But that's too much work and not enough fun.
>All Pansonic HVXs, I believe.
I was under the impression they would do 720p/60, not 480p/60.
>You can also use an external deinterlacer to pre-convert stuff to 60p. It could potentially be used for 60p animation also.
The first one makes more sense, but wouldn't it be better to just create animations at 24p to begin with? I mean, if I had a 24p camera, I'd never have started this series.
The new Home page is up.
> if I had a 24p camera, I'd never have started this series.
You could consider a 35 mm adapter. DOF has more to do with the Film Look than getting it progressive.
>DOF has more to do with the Film Look than getting it progressive.
I disagree. I get a great film look without an adapter.
I guess it's all a matter of opinion.
I can create a nice bokeh when I need to. Still looks like video at 30i, though. 24p really is the largest contributing factor to the "film look", as covered on the Home page.
>24p really is the largest contributing factor to the "film look", as covered on the Home page.
I second that!!