VideoHelp Forum
+ Reply to Thread
Results 1 to 9 of 9
Thread
  1. 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)
    MPEG2Source ("C:\Users\--\Desktop\Blood+\Full\Blood1.d2v")
    Filename = "C:\users\--\Desktop\Blood.m2v"
    WriteFile(filename, "current_frame")
    SetMTMode (2)
    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?
    Last edited by Acetyl; 25th Apr 2013 at 20:16.
    Quote Quote  
  2. 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.
    Quote Quote  
  3. 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.
    Quote Quote  
  4. 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?
    Quote Quote  
  5. Originally Posted by Acetyl View Post
    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?
    I don't know what you mean by that. It's for when you need the current frame number for some reason. For example, to write the frame number onto the frame (although there's a dedicated function for that).
    Quote Quote  
  6. This is how you do it.

    Quote Quote  
  7. 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.

    Code:
    x264.exe --preset=veryfast --crf=25  --output %1.mkv %1
    That will take a file like "My Video.AVS" and create "My Video.AVS.MKV" in the same folder. (I keep a copy of x264.exe in C:\Windows so I don't have to specify the full path to the program.) x264 can also output .MP4 and .h264. Just change the output name extension.

    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:

    Code:
    Start /b /low x264.exe --preset=veryfast --crf=25 --output %1.mkv %1
    Those commands use the veryfast preset. I change that as required for the particular video. There are many other options you can change, of course. You can right click on the icon and select Edit to change the batch file. Put other options after the preset. That way x264 will load the preset then adjust any of the options you specify. This post has a list of the presets and the options they specify:

    https://forum.videohelp.com/threads/355140-HD-Video-Compression-Best-Quality-1-3-Size-H...=1#post2233174

    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:

    Code:
                    fps     bitrate
    -------------------------------
    ultrafast       457     5066
    superfast       386     3275
    veryfast        260     2119
    medium           82     2651
    slow             52     2591
    veryslow         13     2315
    placebo           5     2351
    The exact values will vary depending on your source, and the encoding speed will vary depending on your CPU) but that should give you a rough idea of the relative differences between presets. Generally, with CRF encoding (constant quality, CRF=18 in this example, a DVD MPEG 2 source), as the preset goes up the encoding speed goes down and the bitrate goes down. Quality goes up too (as small motions are more accurately encoded) but not by as much as you might think. For example, I wouldn't say the veryslow preset looks 20 times better than the veryfast preset (the difference in encoding time). Many people wouldn't even notice the difference at normal playback speed.

    Here's the full manual of command line options:

    http://mewiki.project357.com/wiki/X264_Settings
    Last edited by jagabo; 26th Apr 2013 at 07:54.
    Quote Quote  
  8. Originally Posted by jagabo View Post
    Originally Posted by Acetyl View Post
    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?
    I don't know what you mean by that. It's for when you need the current frame number for some reason. For example, to write the frame number onto the frame (although there's a dedicated function for that).
    By "lossless" I just meant harvesting a raw frame from a stream instead of having the decoder pass it to a renderer and then capturing it, as it seems to be in most media players. In retrospect that only really half makes sense. I was running very short on sleep. I probably still am.

    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.
    Quote Quote  
  9. Originally Posted by jagabo View Post
    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:

    Code:
                    fps     bitrate
    -------------------------------
    ultrafast       457     5066
    superfast       386     3275
    veryfast        260     2119
    medium           82     2651
    slow             52     2591
    veryslow         13     2315
    placebo           5     2351
    The exact values will vary depending on your source, and the encoding speed will vary depending on your CPU) but that should give you a rough idea of the relative differences between presets. Generally, with CRF encoding (constant quality, CRF=18 in this example, a DVD MPEG 2 source), as the preset goes up the encoding speed goes down and the bitrate goes down. Quality goes up too (as small motions are more accurately encoded) but not by as much as you might think. For example, I wouldn't say the veryslow preset looks 20 times better than the veryfast preset (the difference in encoding time). Many people wouldn't even notice the difference at normal playback speed.

    Here's the full manual of command line options:

    http://mewiki.project357.com/wiki/X264_Settings
    It seems like rate control methods are best tailored to what their intended use is. However, am I right in thinking that a 2 pass encode would actually have a higher potential for loss of fine detail than just using as an example --bitrate 5000 --ratetol 100 and doing a 1 pass ABR encode. It seems like even if the encoder has extensive knowledge of the stream as a whole prior, if it's given a target bitrate and only more intelligently distributing bits in any given stream, then the potential for loss would be higher? It would just be distributing that loss more effectively and keeping to a desired overall file size.

    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 19:47.
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!