CCE & Dual processor speed

[Venkku]

Hello all,

I encode captured avi files to pal svcd(480*576) by CCE 2.5
Frameserving by virtualdub (filters: Deinterlace)
I'am using windows XP-professional

I have 2 X 1ghz pentium III-prosessors and encoding speed in cce
is about 0.500

If someone else is encoding same way, please post your encoding speeds
and hardware you are using...


Thanks,

Venkku

[LavaJockey]

I can do this test. I have a dual Athlon machine (2 x 2000 XP) and access to a dual PIII machine (2 x 866 Mhz). But I can't figure out how to frameserve from VirtualDub to CCE. The only documentation I can find for VFAPI is in Japanese. What are the steps?

Also, my CCE is version 2.64.

[Venkku]

Hi LavaJockey,

You can't frameserve from virtualdub to CCE 2.64 (as far as I know).
Use CCE 2.5. It will give you very good quality (3pass encoding)

If you manage to test your system with cce 2.5 would be very
intresting, becouse I'am planning to update my hardware.

Thanks,
Venkku

[LavaJockey]

I don't have CCE 2.5.

Yes, you can frameserve to 2.64. People have done it. How? I don't know. It has to do with frameserving from VirtualDub to TMPGEnc, and then frameserving from TMPGEnc to CCE, I think (because VirtualDub can't frameserve VFAPI maybe, I don't know).

[RemoteCtrl]

I don't quite understand why so many people want to frameserve when that is clearly a bad bottleneck for CCE and even more so with multipass. With today's HD prices everyone should afford to save an intermediate segmented AVI.

For comparison, CCE encodes PAL SVCD with 2xPIII/866 at about 1.4x realtime when using a Picvideo compressed AVI(luma=1, chroma=1) as a source. I'm using W2k and CCE SP 2.62.

[LavaJockey]

Frameserving could help me in 2 ways.

1: I won't have to spend an extra $250 on a disk to hold the intermediate AVI.

2: I don't have to be present to start CCE once VirtualDub finishes.

I don't care if frameserving is a little inefficient. Here's a bigger waste of time: VirtualDub finishes processing at 1:00 AM in the morning, but you don't wake up until 8:00 AM to start CCE on the MPEG encoding.

[RemoteCtrl]

1: I won't have to spend an extra $250 on a disk to hold the intermediate AVI.

Like I said, with today's prices. That is kind of expensive for a storage HD unless you're stockpiling, which isn't necessarily a good idea considering the price development.

2: I don't have to be present to start CCE once VirtualDub finishes.

I don't care if frameserving is a little inefficient. Here's a bigger waste of time: VirtualDub finishes processing at 1:00 AM in the morning, but you don't wake up until 8:00 AM to start CCE on the MPEG encoding.

But any amount of serious processing takes quite a long time. This gets roughly multiplied by the amount of passes and with 3-pass, chances are you'll still be waiting at 8 PM. Even if this is an extreme example, there are other advantages. Any kind of optimization gets easier and an intermediate file safeguards against lengthy re-encodes in case of an error(either user or CCE).

[uteotw]

I have dual PIII - 1.33 ghz on a VP6 and the speed of 0.5 you describe is about right.

Myself I prefer to edit the video in VirtualDub, save it and the compress with CCE.

To workaround to waste of time you describe (when you're not around) I use a scripting tool to replace my keyboard and mouse inputs.

It's called Auto It (http://www.hiddensoft.com/AutoIt/).

The syntax is very easy and it's freeware. You just have to create conditions depending on the existence of Windows and dialogs and it will run the whole process for you.

My script asks me for the avi location, the vcf, what video bitrate, how many passes and what audio bitrate, then it will run the whole chain of events and will also multiplex the final file for me... when I come back from work (or wake up) I just have to burn the file... I could even script the burning process but I prefer to do it manually.

Obvisouly, I can script several encoding tasks which is usefull when you have captured several videos and want them ready quickly.

uteotw

[LavaJockey]

Like I said, with today's prices. That is kind of expensive for a storage HD unless you're stockpiling, which isn't necessarily a good idea considering the price development.

$250 is the minimum price for these drives. I don't know what you mean by stockpiling, but I predict it won't help me figure out how to frameserve to CCE.

But any amount of serious processing takes quite a long time. This gets roughly multiplied by the amount of passes and with 3-pass, chances are you'll still be waiting at 8 PM.

I don't do multi-pass. I don't see how your comment about still waiting at 8pm makes sense. So what? The point is that if I do separate VirtualDub, then CCE, then VirtualDub, then CCE stages, which is what I need to do, then whenever I'm not around in between stages, the CPUs go idle. If they are idle half the time, that means I need twice as much computing power to get the job done in the same time. That cost $$$. Frameserving saves those $$$.

I agree with you about the intermediate file being useful in the case of an encoding error. If those errors happen often enough, then frameserving no longer makes economic sense.

[LavaJockey]

It's called Auto It (http://www.hiddensoft.com/AutoIt/).

I must say, that might be the most helpful information I've seen here in a while! I'll give that a try.

I see that you specify mouse clicks by screen position: (X, Y). What about programs, like VirtualDub, that pop up at a different location every time you run them? The (X,Y) positions would change based on where the VirtualDub window is located.

[kinneera]

If the only filter you are using in VirtualDub is a deinterlace filter, you would be very well served by switching to AVISynth (deinterlace filters are one of the easiest to use, there are plenty of guides). It is a much faster frameserver. Using AVISynth, even with bicubic resizing, I can achieve 0.8x realtime on a single PIII 800 when encoding to half-D1, so you should be able to achieve extremely good encoding speed.

[uteotw]

About Auto It :

x , y mouse location can be related to the active windows

I try to avoid mouse input as much as I can and use keybord shortcuts instead but sometimes you have to use the mouse.

One tip is to give time to some dialog or some command to react... don't hesitate to use the "Sleep" command after some input.

One other good one is "WinWait" and for safety reason always make sure the window , dialog you want to interact with is the active , in this case use "WinActivate" command.

[LavaJockey]

My task is pretty simple:
Start VirtualDub
Load Processing Settings
Load AVI file
Save as AVI
and when that completes:
Start CCE
Add the output from above
Encode
and then I do the same thing again.

Any chance you can send me your AutoIt script, which I can then use as a starting point?[/list][/b]

[kinneera]

If you're spending your time learning a scripting language, it would be so much better spent learning AVISynth...

[VidGuy]

I'm using dual Athlon 1800s with AviSynth and YUV encoding from DVD2AVI and am getting about 1.7 x realtime on a fullscreen 720 x 480
encode and about the same on a 352 x 480 encode - haven't yet tried 480 x 480 on the dual Athlon.

[LavaJockey]

If you're spending your time learning a scripting language, it would be so much better spent learning AVISynth...

Can AVISynth frameserve directly to CCE 2.6.4?

Can I use the same filters in AVISynth that I do in VirtualDub?

Why is the time better spent learning AVISynth?

[kinneera]

Can AVISynth frameserve directly to CCE 2.6.4?

No, but neither can VirtualDub. This is an issue with CCE - if you have 2.6.4 I should think you wouldn't have any trouble getting 2.5, and from an encoder quality perspective, they are basically the same.

Can I use the same filters in AVISynth that I do in VirtualDub?

Yes. AVISynth has a large set of documented built-in filters and community developed filters, in addition to the method for invoking VirtualDub filters. If you want to use a filter written for VirtualDub, you may have to find information on how to invoke it as a method call, but this shouldn't be any harder than learning AutoIt scripting.

Why is the time better spent learning AVISynth?

AVISynth is a much faster frameserver. As a scripting language, it certainly isn't any harder than AutoIt. I have used AutoIt, and while it is an excellent tool for some situations, IMHO it is overkill here. It can also be unreliable when you have to do manual pausing and/or mouse positioning, no matter how hard you try.

[LavaJockey]

No, but neither can VirtualDub. This is an issue with CCE - if you have 2.6.4 I should think you wouldn't have any trouble getting 2.5, and from an encoder quality perspective, they are basically the same.

Well, if I had CCE 2.5, and decided to use it, then I'd probably simply frameserve from VirtualDub directly.

I did figure out how to frameserve to CCE 2.64. It involves frameserving from VirtualDub to TMPGEnc, and then frameserving from TMPGEnc to CCE; the problem is that you have to use VFAPI to convert the project file from TMPGEnc, and that does all the audio processing
upfront, which takes up to an hour, which kinda defeats the purpose for me (I basically want to go from the AVI file, through the VirtualDub filter chain, to CCE, and then out to MPEG2 file without me having to be there other than at the very beginning, when I ininiate the whole process).

[lucindrea]

well ... back to speeds ....
useing dvd2avi -> cce on a dual 1G althlon w2k my average is around 1.07

[kinneera]

I did figure out how to frameserve to CCE 2.64. It involves frameserving from VirtualDub to TMPGEnc, and then frameserving from TMPGEnc to CCE; the problem is that you have to use VFAPI to convert the project file from TMPGEnc, and that does all the audio processing
upfront

Newer versions of TMPGEnc are able to work with AVISynth files, so you could work through TMPGEnc if you have to. As for the audio, with AVISynth you would be able to serve a video-only stream, so that problem would go away. Then you could just process the audio separately, and multiplex at the end.

[LavaJockey]

Newer versions of TMPGEnc are able to work with AVISynth files, so you could work through TMPGEnc if you have to. As for the audio, with AVISynth you would be able to serve a video-only stream, so that problem would go away. Then you could just process the audio separately, and multiplex at the end.

Yuck. But thanks for the help. Maybe I ought to try the CCE 2.50 route. Does anyone know what the differences are between CCE 2.50 and CCE 2.64? I didn't find anything on the web.

[uteotw]

kinneera : I agree that AVIsynth is good but this is not the point... Depending on the filters used , frameserving directly to the encoder can double the total encoding time. I need to use smart denoise quite often and it kills the encoding time... at 720x576 it runs at 5fps on my machine. Which is 0.2 realtime... I usually do a 3pass vbr in CCE. CCE can compress at 0.7 realtime on my machine so I prefer to save first an edited AVI and then compress it , rather than frameserving it. Frameserving would take 13 hours on my machine to compress 40 minutes of video.... spliting the process "only" takes" 7 hours. Now because I'm never around to kick in all the tasks... editing , demuxing audio/video , compressing video with CCE , compressing audio , and multiplexing... I use Auto It to pilote all my apps.

LavaJockey : I'll send you my script with some comment in it otherwise it's not that clear to follow.

About differences between CCE 2.50 and 2.64... Other than the matrice selection I know about one improvement (bug fixing) for sure... with CCE 2.50 it used to mess up the encoding of frame containing a moving checker (black and white squares) shapes. This checker "thingy" was in the introduction credits of a comedy show called "The Good Guys" I used to encode and after swithing to CCE 2.62 the buggy frames never occured anymore. I've read somewhere that the checker shape is usually a hard test for a MPEG encoder. So I guess CCE 2.62 and 2.64 must contain improvement (bug fixes) in the encoding engine.

uteotw

[kinneera]

@uteotw: For your purposes, I agree that AutoIt is appropriate. However, the person who my recommendations were targeted at clearly stated previously that he does not use multi-pass encoding, and that he does do direct frameserving. Thus, I stand by my assessment that AutoIt is completely inappropriate for his needs, and just as much (if not more) work to learn than AVISynth - all just to stick himself with a slower frameserver.

As for CCE 2.5 vs 2.6, what you describe is probably not a bug so much as a revision of certain portions of the encoding algorithm - it is worth bearing in mind that only the decoding is standardized. So as long as you don't need to encode checkerboard patterns on a regular basis (probably a safe assumption), then the difference is mostly just minor bug fixes pertaining to functions that few people use, and the loss of the ability to do direct frameserving. Clearly many people are perfectly happy with 2.5, so I would definitely recommend going the AVISynth -> CCE 2.5 route. Much simpler, much faster.

[uteotw]

kinneera : my bad... I missed your comment and I totaly agree that for CBR frameserving is the best solution and is indeed what I do when creating VCDs.