HC Encoder -vs- x264 discussion

[VideoFanatic]

Speed - Encoding Multiple Files at Once

I've just switched to your program after having used HC Encoder. Thank you, it's easy to use and works brilliantly. However I'm trying to speed it up. I have a 480i MPEG2 video with this Avisynth script:

Mpeg2Source("K:\New\episode.d2v", CPU=6)
DeGrainMedian(limitY=2, limitUV=3, mode=1, interlaced=true)

I'm converting it to H264 with your program. I used the following settings:

Mode: ABR (because I just wanted 1 pass)
Target Bitrate: 9000
Preset: SuperFast
Tuning: Film
Profile Auto
Custom x264 Parameters: --tff (because my video is interlaced)

A 1 hour 30 minute episode would take approx 1 hour 45 minutes to encode in HC Encoder at the Normal setting.
I've found that the SuperFast setting in your program is almost as fast. However in HC Encoder I usually loaded 8 instances of the program and left them to run overnight. It finished 8 episodes in about 9 hours which is much faster than if I had done them 1 by 1.

Your program doesn't seem to be able to encode multiple files at the same time - I can queue them but they still encode 1 at a time. I could load several instances of the program but that doesn't seem to make it any quicker than if I had let your program encode them 1 by 1. If I am wrong about any of this then please correct me.

If you have any suggestions to make things quicker then please let me know. I tried UltraFast but it doesn't give good quality like SuperFast.

[LoRd_MuldeR]

Your program doesn't seem to be able to encode multiple files at the same time. I could load several instances of the program but that doesn't seem to make it any quicker than if I had let your program encode them 1 by 1. If I am wrong about any of this then please correct me.

Huh? You can start as many encoding jobs at the same time as you wish ;)

Simply check the "Start job immediately" option in the "Add Job" dialog. Or use the "Start Job" button to launch an "enqueued" job from the list.

The application will also launch the next pending job for you, as soon as a running job finishes. See the "preferences" dialog for details!

Having said that, with x264 it only would make sense to run several jobs at the same time, if a single job does not utilize your CPU at 100% yet.

As soon as your CPU usage reaches 100%, running even more jobs at the same time does not result in any overall speed-up, of course.

Also note that multi-threading in x264 is extremely efficient, so often a single encoding job can utilize your CPU at 100% :)

If you have any suggestions to make things quicker then please let me know. I tried UltraFast but it doesn't give good quality like SuperFast.

Well, with "UltraFast" you are already using an extremely fast preset that sacrifices quality/efficiency for encoding speed.

I can not make any suggestions to speed-up the encode even more. Actually I wouldn't even suggest to encode that fast, at least if quality matters ;)

Anyway, when using such extremely fast encoder settings, be sure that your source (Avisynth + filters) doesn't become the bottleneck!

[VideoFanatic]

Thanks, I'll try that. When muxing the files in TS Muxer I see the following in the log window:

H264 bitstream changed: insert nal unit delimiters
H264 bitstream changed: insert pict timing and buffering period SEI units
B-pyramid level 1 detected. Shift DTS to 2 frames

Is that anything to worry about?

[LoRd_MuldeR]

Thanks, I'll try that. When muxing the files in TS Muxer I see the following in the log window:

H264 bitstream changed: insert nal unit delimiters

http://mewiki.project357.com/wiki/X264_Settings#aud

H264 bitstream changed: insert pict timing and buffering period SEI units

http://mewiki.project357.com/wiki/X264_Settings#nal-hrd

B-pyramid level 1 detected.

http://mewiki.project357.com/wiki/X264_Settings#b-pyramid

[VideoFanatic]

Thanks. I also have query about bitrates.

In HC Encoder I do Constant Quantization (which is 1 pass variable bitrate) and I set a maximum bitrate of 9000. I end up with a 4.81 GB file.

In your program I want to do the same thing to end up with a file of the same size. I just want 1 pass and I want to use a variable bitrate of 9000. The only thing I see that may do that is the ABR mode which is 1 pass but I end up with a 6.03 GB file.

[LoRd_MuldeR]

Thanks. I also have query about bitrates.

In HC Encoder I do Constant Quantization (which is 1 pass variable bitrate) and I set a maximum bitrate of 9000.

CQ mode is the worst rate-control mode you can use!

It doesn't adapt to the content of the video at all. And it disables extremely helpful features, such as Adaptive Quantization :rolleyes:

Use CRF mode instead!

Also using CQ (or CRF) mode and a target bitrate at the same time is NOT possible. With "I set a maximum bitrate of 9000" you probably mean that you set a VBV MaxRate.

Then you should be aware that "--vbv-maxrate" does NOT set the maximum video bitrate, but the maximum bitrate at which the VBV Buffer is filled.

Also be aware that "--vbv-maxrate" does nothing, unless you set a proper "--vbv-bufsize" as well...

In your program I want to do the same thing to end up with a file of the same size. I just want 1 pass and I want to use a variable bitrate of 9000. The only thing I see that may do that is the ABR mode which is 1 pass but I end up with a 6.03 GB file.

If you want to get a file of a specific file size, use 2-Pass mode! You can't hit a specific file size with CRF (or CQ) mode at all. Though CRF mode is highly recommended otherwise.

In case you really have to hit a specific file size, but you don't have the time to run a proper 2-Pass encode, you'll have to use ABR mode...

(In 2-Pass or ABR mode, the resulting file size is a direct consequence of the target bitrate you have selected. If the file size comes out wrong, correct your target bitrate!)

[VideoFanatic]

CQ mode is the worst rate-control mode you can use!

It doesn't adapt to the content of the video at all. And it disables extremely helpful features, such as Adaptive Quantization :rolleyes:

I'm assuming you're talking about HC Encoder - What do you mean by Constant Quantization doesn't adapt to the content of the video? You also said it's the worst setting you could use? Why?

I combined 2 clips, 1 with lots of action and another is just a man being interviewed sitting in a chair.

It does 1 pass at a variable bitrate (max of 9000) and in scenes with lots of action it uses up to 9000 and in non-action scenes it uses about 4000. It gives me a good quality file as well. What's wrong with that!?

In Simple x264 Launcher


I cannot seem to get the above variable bitrate with your program like I can with HC Encoder. Here are my comparisons showing the lowest and highest bitrates I saw while the video was encoding and the resulting file size:

HC Encoder Constant Quantization (default setting) with 9000 Max Bitrate: 3900, 8800 - 61.9 MB

Simple Launcher

ABR 9000: 8800, 9200 - 76 MB
2 Pass 9000: 1st Pass: 9900, 8700 - 77 MB
CQ Quantizer 18: 9000, 7400 - 64 MB
CRF 17: 7000, 6300 - 55 MB

As you can see no matter what setting I choose with your program, I don't seem to get much of a variable bitrate. On each setting, the difference between the highest and lowest bitrate is only about 1000.

Any suggestions?

[LoRd_MuldeR]

I'm assuming you're talking about HC Encoder

No. I'm talking about x264. Thus what I said applies to Simple x264 Launcher.

HC Encoder, as far as I know, is a MPEG-2 encoder, while x264 is an H.264/AVC encoder!

MPEG-2 and H.264/AVC are two completely different video formats.

And if you move from MPEG-2 to H.264, you will be able to get MUCH better quality at the same file size.

(...or the same quality at a MUCH smaller file size)

IWhat do you mean by Constant Quantization doesn't adapt to the content of the video?

Constant Quantizer mode encodes with a constant quantizer. Not really surprising ;)

This means that you will waste a whole lot of bits in "complex" scenes, while "less complex" scenes might still not look optimal.

CRF is a much smarter rate-control mode!

Simply speaking, it raises the quantizer in "complex" scenes to save bits and lowers the quantizer in "less complex" scenes to improve quality.

Therefore CRF mode can deliver consistent quality at reasonable bitrate. CQ mode can not do this...

You also said it's the worst setting you could use? Why?

For the reason I explained in the pargraph above. And because it cannot use Adaptive Quantization.

Adaptive Quantization gives a huge improvement in quality! In CQ mode, all quantizers in all blocks are the same - by definition.

Therefore CQ mode cannot use Adaptive Quantization. All other modes (CRF, 2-Pass, ABR) can and do!

I combined 2 clips, 1 with lots of action and another is just a man being interviewed sitting in a chair.

It does 1 pass at a variable bitrate (max of 9000) and in scenes with lots of action it uses up to 9000 and in non-action scenes it uses about 4000. It gives me a good quality file as well. What's wrong with that!?

1-Pass ABR mode is okay. 2-Pass would give better quality at the same file size (i.e. same average bitrate) though.

Simply speaking, ABR mode only knows "what lies in the past", while 2-Pass also knows "what comes in the future" (that info is from the first pass).

For example, 2-Pass mode can "reserve" bits for a very complex scene at the end of the movie. ABR mode cannot know that such scene will come before it arrives there.

Of course the difference between 1-Pass ABR and 2-Pass will vanish, if you only crank up the target bitrate enough ;)

I cannot seem to get the above variable bitrate with your program like I can with HC Encoder. Here are my comparisons showing the lowest and highest bitrates I saw while the video was encoding and the resulting file size

My application offers all rate-control modes that x264 supports: CQ, CRF, ABR and 2-Pass.

They all are "variable bitrate" modes. They differ in how they control the bitrate. There are NO other rate-control modes available in x264.

There also is NO such thing as a "maximum bitrate" setting! There is VBV and you can use it in my program via custom parameters.

In order to use VBV, you would have to set both, "--vbv-maxrate xxx" and "--vbv-bufsize xxx".

However, if you don't know what VBV does and why you need it, I suggest to keep your fingers away from that...

As you can see no matter what setting I choose with your program, I don't seem to get much of a variable bitrate.

I see nothing, as the final file size does NOT say anything about the "variability" of the bitrate ;)

If you choose the same target bitrate (in ABR or 2-Pass mode), you will get the same output file size - of course!

In 2-Pass or ABR mode the following equation applies: File_Size = Duration x Target_Bitrate


For both, CQ and CRF mode, smaller quantizer (or CRF value) results in bigger file. Higher value (or CRF value) results in smaller file...

Anyway, at the identical output file size, a CRF encode would look much better than a CQ encode. Believe me!

Still, neither CQ mode or CRF mode, are designed to hit a specific file size. Once again: For that purpose we have 2-Pass (and ABR).


Also note that, for comparing quality, you always have to compare files of identical size. Anything else would be pointless...

[VideoFanatic]

I see nothing, as the final file size does NOT say anything about the "variability" of the bitrate ;)

What do you mean? I showed you the lowest and highest the bitrates went to. For CRF for example I need to use a setting of 17 in order to get good picture quality in the action scenes. The highest and lowest bitrates it used were: 7000 & 6300. On the scene with just a man being interviewed sitting in a chair, 6300 bitrate seems like too much when HC Encoder used 4000 for the same scene at 9000 Constant Quant VBV Bitrate. I looked at both the HC Encoder scene and the scene from your program and they look exactly the same so 6300 seems like a waste for that scene. But I can't set the CRF to a lower quality value because then the action scene won't be as good quality.

For the record, the test I previously showed you used the same file for each test.

Will the VBV setting you mentioned allow me to get more flexible variable bitrates such as 4000 for scenes without action and higher bitrates for scenes with lots of action? If so, could you please provide me a sample parameter to achieve that.

[Asmodian]

Will the VBV setting you mentioned allow me to get more flexible variable bitrates such as 4000 for scenes without action and higher bitrates for scenes with lots of action? If so, could you please provide me a sample parameter to achieve that.

VBV is a buffer control option not a bitrate setting.

You can lower qcomp, set it to something lower than 1.0 (e.g. --qcomp 0.8), have a look at X264_Settings (http://mewiki.project357.com/wiki/X264_Settings).

[LoRd_MuldeR]

What do you mean? I showed you the lowest and highest the bitrates went to.

How did you measure that?

Also, even if you know the highest bitrate peak and the lowest bitrate bitrate of a file, this doesn't say anything about how "variable" the bitrate is!

You could have a video that uses a fixed bitrate of 100 kbps for 99.9% of the time, but has one single 10000 kbps bitrate spike.

Obviously such video would have a minimum bitrate of 100 kbps and a maximum of 10000 kbps. Still a "variability" is pretty much non-existing ;)

If you really want to express the "variability" as a number, you should use the Standard Deviation:
http://en.wikipedia.org/wiki/Standard_deviation

For CRF for example I need to use a setting of 17 in order to get good picture quality in the action scenes.

I highly doubt that. Usually ~20 should give very good quality.

Do you actually watch the video in motion or do you step through the video frame-by-frame? The latter can be highly misleading.

Furthermore, if you still use "Superfast" preset, you are butchering x264's quality for speed!

You can't expect very good compression efficiency and very fast encoding speed at the same time. It's just not possible.

Tweaking "speed -vs- quality" always is a trade of. And if you decide to tweak massively towards speed, don't complain about quality ;)

The highest and lowest bitrates it used were: 7000 & 6300. On the scene with just a man being interviewed sitting in a chair, 6300 bitrate seems like too much when HC Encoder used 4000 for the same scene at 9000 Constant Quant VBV Bitrate. I looked at both the HC Encoder scene and the scene from your program and they look exactly the same so 6300 seems like a waste for that scene. But I can't set the CRF to a lower quality value because then the action scene won't be as good quality.

You really can't compare MPEG-2 (HC Encoder) bitrates to H.264/AVC (x264) bitrates.

H.264/AVC is at least two generations ahead of MPEG-2 and x264 is the best H.264/AVC encoder available on the planet.

Compared to MPEG-2, with x264 you can now easily get away with 1/2 to 1/3 the bitrate for the same quality.

(And that still is a pretty conservative estimation!)


H.264 encoded by x264:
http://mirror05.x264.nl/Dark/website/x264_1260.png

MPEG-2 encoded by HC Encoder:
http://mirror05.x264.nl/Dark/website/hcenc_1260.png

Note that both clips were encoded at the very same average bitrate of 1000 kbps!

Source:
http://mirror05.x264.nl/Dark/website/compare.html

Will the VBV setting you mentioned allow me to get more flexible variable bitrates such as 4000 for scenes without action and higher bitrates for scenes with lots of action? If so, could you please provide me a sample parameter to achieve that.

VBV does the exact opposite. VBV limits the bitrate fluctuations within the restrictions of the VBV buffering model.

As said before, don't use VBV, unless you understand what it does and why you need it...

[VideoFanatic]

You can lower qcomp, set it to something lower than 1.0 (e.g. --qcomp 0.8), have a look at X264_Settings (http://mewiki.project357.com/wiki/X264_Settings).

I did try different settings for that but all it seems to do is increase or lower the overall bitrate. For example the lowest and highest bitrates used were: 7100 & 8200. It's still not using lower bitrates like 4000 for the non action scenes.

[VideoFanatic]

For CRF for example I need to use a setting of 17 in order to get good picture quality in the action scenes.


I highly doubt that. Usually ~20 should give very good quality.

Do you actually watch the video in motion or do you step through the video frame-by-frame? The latter can be highly misleading.

My video is from a VHS to DVD conversion. The conversion wasn't done very well. It has a good picture but it's peppered with compression artefacts such as blocking and picture noise.

I demuxed the DVD to an MPEG2 and ran it through your program with Avisynth and removed the noise and h264 got rid of the blocking. I did it on Superfast CRF 17 and got a good picture. I tried 18 and above but that lowered the quality. Lower than 17 didn't have any major improvements for me to justify a higher file size. I compared the videos by watching them on my 37" HD TV.

[LoRd_MuldeR]

That sounds kin of contradictory. If your DVD source is "peppered with compression artifacts" it obviously doesn't have a "good picture".

Even if the original VHS tape had an acceptably quality, if the DVD source you are now working with contains a lot of compressions artifacts, then it's considered a "bad quality" source.

Also I don't quite understand why you want to re-encode, if your current DVD source already has bad quality :confused:

Re-encoding never can improve quality. It always hurts quality! That's called "generation loss". At best, the additional quality loss caused by the re-encoding is negligible.

Last but not least, encoding to H.264 does not get rid of the blocking! Why should it?

If you feed x264 with a "blocky" source, it will try to retain those blocks. That's because they are part of the source. x264 can't magically remove blocks that are in the source.

Maybe an "ultra-low bitrate" H.264 re-encode can smooth out your source so much, that the "blocking" artifacts (that were present in the source) become less prominent, because there now is new (more prominent) "smearing" problem. But that's obviously NOT what you want :p

The so-called "In-Loop Deblocking" filter of H.264 is intended to avoid blocks introduced by the H.264 encoding. Not to remove blocks already present in the source...

(If possible somehow, go back to the original VHS source, capture to an uncompressed file and compress it with x264 directly!)

[VideoFanatic]

I just wanted to say thanks for your program. It's working really well for me. However I wanted to reply to some of your comments.

I don't have the original VHS tape any more, just my VHS to DVD conversion which I then demuxed to MPEG2. It's a good picture but it's peppered with compression artefacts and picture noise. By good I mean that it isn't blurred so much that I can't see the detail on people's faces.
HERE (http://dl.dropbox.com/u/57941257/MPEG2%20Original%20File.mpg) is the 1 minute sample file (please view it on your TV)

I want to re-encode to remove the compression artefacts such as blocking and the picture noise. This is my Avisynth script:

Mpeg2Source("K:\New\phoenix\Fast and slow scene.d2v", CPU=6)
DeGrainMedian(limitY=2, limitUV=3, mode=1, interlaced=true)
AddBorders(8, 0, 8, 0)

In your program I selected CRF 17.0, VeryFast, Film, --tff --sar 10:11
Please re-encode the video yourself to see what it looks like on your TV with the above settings.

As you say there is a loss of quality from the original MPEG2 but I still think this looks better than the original file as the blocking and noise is removed. What do you think?

Blocking

You said h264 doesn't remove the blocking. You are correct in that if I didn't use CPU=6 then it wouldn't remove the blocking.

However I remember asking in a forum how to remove blocking and I was told that h264 has better deblocking than CPU=6. I saved my MPEG2 video in VideoRedo h264 and found that h264 does remove the blocking. So that's why I thought your program would remove the blocking. Why does Videoredo remove the blocking but your program does not?

[LoRd_MuldeR]

HERE is the 1 minute sample file (please view it on your TV)

That source clearly is interlaced. So I hope you applied a proper deinterlacing filter!

By looking at your script, it seems you don't :eek:

As an initial experiment, try to insert Yadif(mode=1) (http://avisynth.org.ru/yadif/yadif.html) immediately after the Mpeg2Source().

Example:
http://www.mediafire.com/file/vfgi9evak258g4w/MPEG2 Original File.mkv

Note: Even if you don't want to deinterlace, i.e. keep it interlaced, you would probably have to deinterlace before applying filters. That's because most filters don't work correctly on interlaced video.

And, if you don't deinterlace (keep it interlaced), you would of course have to re-encode as interlaced !!!

As you say there is a loss of quality from the original MPEG2 but I still think this looks better than the original file as the blocking and noise is removed. What do you think?

In my experience, removing noise can have a very negative effect.

That's because noise actually can be pretty effective in hiding the lack of detail (by "faking" detail) and it can even help to hide compression artifacts.

Once you filter out the noise (which itself will always destroy some detail), the defects of your source can become much more apparent...

You said h264 doesn't remove the blocking. You are correct in that if I didn't use CPU=6 then it wouldn't remove the blocking.

It's not the re-encoding to H.264 that removes the blocking! It's the post-processing filter of your MPEG-2 decoder (or some dedicated "deblocking" filter you apply after the MPEG-2 decoder) that "removes" the deblocking! The re-encoding to H.264 is just a necessary evil you have to accept. That's because you can not apply video filters (such as deblocking) without re-encoding. So if you have to re-encode anyway, H.264 is the right choice.

Also you have to be aware that "deblocking" post-processing filters work completely different, compared to H.264's "In-loop Deblocking". Those post-processing are applied after the source has been decoded and they aim to "reduce" visible blocking artifacts that are present in the video. The H.264 "In-loop Deblocking" filter is an integral part of H.264 encoding/decoding and aims to prevent the occurrence of blocks. Again: It does not aim to remove blocks that were present on the source.

Last but not least: Even if you apply a "deblocking" post-processing filters, this won't magically make all artifacts in your source go away! Such filters always are a trade-off. They might be able to smooth out blocking artifacts, indeed, but they also kill details and sharpness at the same time. Thus you have to be careful! And of course you must not blame the side-effects of your "deblocking" post-processing filter to the later H.264 encoding!

[VideoFanatic]

Why would I want to deinterlace it? It's an interlaced video for viewing on my TV. I was always told that you shouldn't de-interlace a video for viewing on your TV as it will lower the quality.

Most of the filters I use work on interlaced videos. I know that for some filters I need to deinterlace a video for them to work but that's not a problem because I can just use another filter (in the same script) to re-interlace it.

You said h264 doesn't remove blocking if it's already in the original video, it only removes blocking which occurs during the h264 encoding process.

But if you were to re-encode that MPEG2 sample I gave you with Videoredo to TS h264, Force Recode to 720 x 480 with an Average Bitrate of 9000 and Max Bitrate of 9000 then view the file on your TV - it does remove the blocking. I didn't use any scripts, I simply saved the video in Videoredo. It even got rid of some of the noise.

So I'm confused as to why you said h264 doesn't remove the blocking! How come Videoredo removed the blocking without scripts yet your program (without scripts) does not?

[LoRd_MuldeR]

Why would I want to deinterlace it? It's an interlaced video for viewing on my TV. I was always told that you shouldn't de-interlace a video for viewing on your TV as it will lower the quality.

That's not the whole truth. It was maybe right for old CRT screens, but modern LCD or Plasma screens (or projectors) only display progressive images.

The only reason why you can watch "interlaced" video on a LCD/Plasma screen at all, is because the screen will deinterlace the video for you "on the fly" ;)

Depending on what deinterlace filter you use in software (and what deinterlacer your TV uses), the deinterlacing result in software can be worse -or- MUCH better than what the TV does.

And, if you want to apply video filters that simply don't work (correctly) in interlaced video, then you often MUST deinterlace. Whether you want or not...

Last but not least: If you keep the video interlaced, you MUST tell the encoder (e.g. x264) to encode it as interlaced (i.e. by setting "--interlaced"). Otherwise the video gets destroyed! :scared:

If, until know, you we encoding interlaced video with x264, but you did not tell x264 that the video is interlaced, it is clear that you got horrible results :rolleyes:

Most of the filters I use work on interlaced videos. I know that for some filters I need to deinterlace a video for them to work but that's not a problem because I can just use another filter (in the same script) to re-interlace it.

You can't "re-interlace" video unless it has been deinterlaced before. And, if you plan to re-interlace, you must use a "bobbing" deinterlacer.

Applying a video filter, which is not intended for interlaced video, on a video that is interlaced (and has not been deinterlaced beforehand) will simply destory the video.

You can't fix that afterwards! You have to deinterlace before the filter. And then, optionally, you can re-interlace after the filter.

You said h264 doesn't remove blocking if it's already in the original video, it only removes blocking which occurs during the h264 encoding process.

Correct.

Though instead of "it only removes blocking which occurs during the h264 encoding process", I would rather say, the H.264 In-Loop Deblocking filter avoids additional blocking due to the H.264 encoding process.

It's not like H.264 adds the blocking artifacts and then removes them in some kind of additional post-processing step. Instead it's more like the blocking artifacts never actually get added.

But if you were to re-encode that MPEG2 sample I gave you with Videoredo to TS h264, Force Recode to 720 x 480 with an Average Bitrate of 9000 and Max Bitrate of 9000 then view the file on your TV - it does remove the blocking. I didn't use any scripts, I simply saved the video in Videoredo. It even got rid of some of the noise.

Sorry, I have no idea what kind of processing "Videoredo" (whatever that is) did behind the scenes to attenuate the "blocking" artifacts in your source.

But whatever it did, the re-encoding alone was not the reason to see fewer blocks.

Well, except for one case: As said before, if you re-encode at an extremely low bitrate, then the re-encoding may mangle your source so much, that the blocks (along with all other detail !!!) get smoothed away.

So I'm confused as to why you said h264 doesn't remove the blocking!

Because re-encoding to H.264 alone certainly won't make Blocking artifacts go away in a magic way. It's a simple matter of fact.

How come Videoredo removed the blocking without scripts yet your program (without scripts) does not?

Ask the developer of that software. He might be able to tell you what kind of post-processing his software applies.

[VideoFanatic]

You said if I want to keep it interlaced then I must specify the following in your program: --interlaced
In the help screen for your program I never even saw that option anywhere. Where is it? All I found was --tff
Does -tff not specify interlaced?

So should I use the following?: --interlaced --tff

Previously I just used --tff and I loaded the video in Videoredo and it said the video was interlaced so I thought it worked.

Most of the scripts I use work with interlaced videos. However some only work with progressive videos so all I do is the below to use a progressive only filter with an interlaced video. It deinterlaced it then re-interlaces it once the filters have done their job.

Mpeg2Source("File.d2v", CPU=6)
Load_Stdcall_plugin("C:\Program Files\AviSynth 2.5\plugins\yadif.dll")
AssumeTFF()
Yadif(mode=1, order=1)
mdata = DePanEstimate(dxmax=0)
Vinverse()
DePanStabilize(last, data=mdata, initzoom=1.05, dxmax=0, dymax=4)
SeparateFields()
SelectEvery(4,0,3)
Weave()

[LoRd_MuldeR]

You said if I want to keep it interlaced then I must specify the following in your program: --interlaced
In the help screen for your program I never even saw that option anywhere. Where is it? All I found was --tff
Does -tff not specify interlaced?

So should I use the following?: --interlaced --tff

Previously I just used --tff and I loaded the video in Videoredo and it said the video was interlaced so I thought it worked.

Interlaced video can have different field orders. It's either "top field first" or "bottom field first". That's what "--tff" and "--bff" specify.

AFAIK, you don't have to set "--interlaced" too, if you already set set "--tff" or "--bff" correctly.

Most of the scripts I use work with interlaced videos. However some only work with progressive videos so all I do is the below to use a progressive only filter with an interlaced video. It deinterlaced it then re-interlaces it once the filters have done their job.

Mpeg2Source("File.d2v", CPU=6)
Load_Stdcall_plugin("C:\Program Files\AviSynth 2.5\plugins\yadif.dll")
AssumeTFF()
Yadif(mode=1, order=1)
mdata = DePanEstimate(dxmax=0)
Vinverse()
DePanStabilize(last, data=mdata, initzoom=1.05, dxmax=0, dymax=4)
SeparateFields()
SelectEvery(4,0,3)
Weave()

So you deinterlace (in bob mode!) first, then apply the filters and finally re-interlace.

Looks like the right thing to do, if you want to keep your video interlaced...