I'm not much of a scripter, nor programmer it would seem. The syntax just falls apart in my mind.
I'm attempting to deinterlace a 25 FPS mpeg2 stream. I have all the proper project files, and I'm using GTGMC. I can't figure how to have it write to a file after processing frames. This is what I have so far. It works, it just dumps the frames after calculating, instead of writing them to disk.
SetMTMode (5, 16)
Filename = "C:\users\--\Desktop\Blood.m2v"
QTGMC ( Preset="Placebo", Edithreads=4 )
WriteFileStart(filename, """ "This is the header" """)
WriteFileEnd(filename, """ "Now the script was closed" """)
I'm fine with using "Placebo" for an initial test. I plan to compare it against other settings when it's actually working.
I suppose I'm imagining this running sequentially for every frame, and it makes sense. But it doesn't work, so it probably doesn't really make sense at all.
Anyone see the issue?
+ Reply to Thread
Results 1 to 9 of 9
Last edited by Acetyl; 25th Apr 2013 at 19:16.
AviSynth cannot write video files. It only process video for other programs. WriteFileX is for debugging, not for the video itself. Open the AviSynth script in an editor that supports AviSynth scripts as input. VirtualDub, for example (I usually use it to preview scripts). Or you could use the x264 command line encoder. For simply viewing the results of the script you can even use a media player, though QTGMC will be too slow to get realtime playback.
current_frame is the current frame number, not the video frame. Useless for what you're doing. Forget all the WriteFileX stuff. And don't use the multithreading options until you've got a working script. Not to mention you need a multithreaded build of AviSynth to use multithreading anyway. The regular build of AviSynth isn't multithreaded.
Use a QTGMC preset like "fast" rather than "placebo" for testing, especially if your processing a long video. You'll see your results much more quickly.
I see. I was wrongly thinking AVISynth could be made to function as more than just a raw frameserver. Doesn't make sense in retrospect.
Command line utilities are something I'm much more familiar with. Didn't know x264 had something so readily accessible.
I do have a multithreaded version of AVIsynth. Reluctant to use the 2.6 alpha, but a test of the script using the fast preset with MPC-HC seems to function properly. I guess I'll have to see.
Appreciate the feedback.
Just out of curiosity. You mentioned "Current_frame" just referencing the current frame number. Would that mean this function has use in harvesting "lossless" frames from a stream?
This is how you do it.
I keep a batch file on the Desktop for x264 encoding. That way I can drag an AVS script onto the icon to encode it. Here's a minimalist command line suitable for use in a batch file.
x264.exe --preset=veryfast --crf=25 --output %1.mkv %1
Acually, I usually use the Start command to run it at low priority so x264 only use idle CPU time. That leaves the computer usable for other stuff while the encoding is running in the background:
Start /b /low x264.exe --preset=veryfast --crf=25 --output %1.mkv %1
The x264 developers sometimes change the presets so that list may not be 100 percent accurate. Here's an example of roughly what you can expect from the presets. Preset, encoding speed (fps), bitrate (kbps) of the final encoding:
fps bitrate ------------------------------- ultrafast 457 5066 superfast 386 3275 veryfast 260 2119 medium 82 2651 slow 52 2591 veryslow 13 2315 placebo 5 2351
Here's the full manual of command line options:
Last edited by jagabo; 26th Apr 2013 at 06:54.
I had gotten a few test encodes done, but your next post was very helpful, I appreciate that. I'm currently working on deinterlacing "Texhnolyze", which appears to be in a 2:3 pulldown...and doesn't appear to be telecined either. So I suppose QTGMC isn't what is needed at the moment. But getting it to work showed quite a lot of what I was missing in mind.
I appreciate the assistance.
But the --bitrate --ratetol method can have the potential to yield a higher file size, or a lower one, depending on the source file, the settings etc. But it maintains less of a capacity for loss and a higher adaptability. If my understanding is right, that is. Which logically, it probably doesn't work the way I'm understanding it.
Is it possible to use a method similar to --ratetol in conjunction with a two pass encode? Or is that the VBV min / max options...
I think the sleep deprivation might be getting the better of me, in any case. I'll just have to test it rather than leave walls of text scattered everywhere in an attempt to consolidate my own thoughts reasonably.
Last edited by Acetyl; 30th Apr 2013 at 18:47.