Converting on the fly to Canopus HQ

wags

Member
Oka go figure this out.

Once I get a few cips on the timeline with some editing done with Version 4, then conversion on the fly cannot keep up. But if I open a new project and try it keeps up no problems? However I have to shut Edius down first then open up as a new project and away it goes converting on the fly no probs.

I also can open a new project, import a heap of clips, dump them on the timeline with titles and a sound track, then try the conversion on the fly and it worked no problems. So it must be after I have spent some time editing or something that causes the conversion on the fly not to keep up.

Version 3 did not have this problem as I imported many tapes on the fly and did quite abit of editng with it.

I know if I had a super computer if might not be a problem but It is abit odd..maybe a bug. I have updated to 4.03 The CPU is anywhere around 85 to 100% when converting HDV to the Canopus HQ on the fly.
 
By "converting on the fly" you mean you're doing a capture from a HDV source to Canopus HQ AVI, right?

Only thing I can think of is that the timeline referencing of files is causing EDIUS to seek or something. Do you have any MPEG files in the timeline? By default EDIUS will create an index file in the background for MPEG sources.

That's about all I can think of short of running out of physical memory and causing swapping to disk.

Brandon
 
Hi Brandon
Thanks for that.

Yes I am going from HDV to the Canopus HQ codec in realtime.
Version 3 was doing it no problems. Sucked in heaps of tapes (400GIGS) even after editing quite abit.

Version 4 will do it but once I have built abit on the timeline it will not keep up.
If I close the program and open it up again under a new project, it will capture no problems. If I add a heap of clips to the new project it still works no problem.

It's only after I have been editng for abit that it then makes it hard for the computer to convert the HDV on the fly. If I also try to import just normal HDV m2t it has a problem as well. Not though if I start with a clean project? Go figure.

If I open up Version 3 it does it no problems at all, batch caputerd heaps and converted on the fly, so I don't think it's the computer even though it's only a 3 GIG HT PC. I have 2 GIGs of Ram.

The only files I have on the timeline are the Canopus HQ ones.

Maybe Titlemotion or Herolyph is causing it?
 
Check Task Manager and see what the memory usage of EDIUS is when you have capture problems versus when you don't.

A memory leak (or just EDIUS needing more memory to keep track of things in the timeline) would cause EDIUS to use increasing amounts of memory, eventually you'd start swapping to disk, and that'd slow everything down.

You could also try putting your buffer size down in EDIUS and see if that changes how "big" a project needs to get before you have problems.

Oh... and if you have the audio waveforms shown, try closing them.

Brandon
 
Hi Brendon

Gee that was quick.
I was just about to report it to Canopus but will have a look at what you suggested first.

Stay tuned....

Cheers
Paul
 
Okay
When I open a new project it's at....

PF usage is at 985 when the tapes playing viewing in the capture window, and then goes to 996 when I hit record and it starts converting.

When I try it in a project I have been working on it's around 1.03-1.09 PF

I have 2 GIGs of ram.
Audio Waveform is closed.

Buffer, where is that?

Cheers
Paul
 
Ram memory usage.

When it cannot convert with a working project. 630-640 Megs. CPU 100%
When it can convert with a new project, 550-570. CPU 85 - 100%

Got 2 GIGS of Ram.
 
And abit more....

If I open a new project and add a heap of files to the timeline with a title and audio track it still converts no problems.

If I edit like 5 mins of stuff on the timline or work in it for abit, It starts to fail in converting the HDV on the fly and even will not import normal m2t?

Version 3 did not have this problem. I sucked in like over 400 GIGS on the fly with Version 3 and edited heaps.
 
Just thought I would keep adding to this post with more info on this problem.

I uninstalled both Edius 3 and 4.03 from the computer.

Installed the Demo 4 version and opened up a smalll project I was making with the 4.03. Still the same and not only that it would not even take in a native m2t stream, just kind of max the CPU out and ground to a hold in the capture window.

Next I closed the program down and opened it up again starting a new project. Fired up the caputre window and away it went converting on the fly to the Canopus HQ codec. Next I stopped it and changed setting to just capture m2t stream and away it went as well.

Strange or what.

Version 3 has not got this problem so it looks like I will have to use it to batch capture etc and then import them into Version 4 untill this is sorted out.

BTW just usings the mpeg capture by itself, the computer cannot keep up loosing out about 5-10 minutes into the conversion. This means that the mpeg capture program must take up more power to convert on the fly than inside the program itself? go figure??

Now I know some of you may say get a faster computer, but you have to admit it's some kind of bug..and I have over 400GIGS of on the fly conversion from Version 3 already and 4 can do it as well as long as I start a new project for the capture..
 
Okay I think I might be onto something here.

Could someone open up Edius in a HDV project and import a HD wmv clip into their bin then try to convert on the fly?

I think thats it.....:)
 
Do you have version 3 and version 4 installed on the same machine? The engineers tell us that's not supported, because some files are shared and conflict.
 
I have it sorted now.
I had a HD wmv file in the project bin that I was messing around with on the timeline. Once I had deleted it out of the project bin and saved the project as and restarted Edius, Version 4 began to keep up converting on the fly again.

I also found a audio file that was ripped form a CD with Windows Media Player that caused the exact same thing. Ripping them with the built in disc capture the audio clips worked fine.

The reason 4 would stop after awhile was because I was importing that audio clip in each time after a while.
 
Back
Top