EclPRO v0.52 - ProCoder support in DVD-RB (now v1.10) [Archive] - Page 5

borgraf

3rd August 2005, 21:55

I'll be the first to admit that I know very little about colorspace conversion and what impact it might have. I was looking through avisynth.org and noticed under "Q3.7: How do I convert between the colorspaces ? (http://www.avisynth.org/Section+3%3A+Filters%2C+plugins+and+colorspaces)" this note: Note that converting between colorspaces isn't completely lossless, and doing several conversions back and forth may degrade your signal. The first conversion back and forth does not hurt your source, but if you use three or more, it may.So it looks like it isn't a big deal here, but like I said i'm no expert :)

robot1

3rd August 2005, 22:03

Here is the new version:
EclPRO v0.42 beta (http://rapidshare.de/files/3624233/EclPROv0.42.zip.html)

- Fixed a bug with national characters (èéò...) - Thanks to Rockas for pointing it out.
- AlwaysGOP15 now overrides Autoparameters (if you specify both AlwaysGOP15=1 and Autoparameters=1 in the EclPRO.ini, the Goplength is always 15, and the Autoparameters affects only the DC Precision parameter).

Rockas

3rd August 2005, 22:12

Alternative download at:
http://dvd-rb.dvd2go.org/modules.php?name=Downloads&d_op=viewdownload&cid=24

wmansir

4th August 2005, 05:37

Unfortunately ECLpro does not work with the version of ProCoder Express that comes with Edius3 Trial. It failed at the Aspect Ratio selection stage. I tried to do a manual encode, but got an AVI read error when starting the conversion, so perhaps this verison does not support .avs.

In case you want to take a look it's available here (http://www.canopus.us/US/support2/support_demosoft.asp). You have to create an account to access the download page. It's a 200MB download. The version included is "ProCoder Express for Edius". Which I see you dropped support for some time ago.

robot1

4th August 2005, 13:26

I dropped the support of "Procoder Express for Eidus" because the previous version was buggy.
I'll check the new one: if it is as good as Procoder Express 1.12, I will add the support again.

A64

5th August 2005, 07:13

robot1

6th August 2005, 09:50

The version of Procoder Express 1.12 that sells for $60 also stops at the Aspect Ratio. I have only tried the ECLPro .40 and .27. .27 makes it further than .40 with Procoder Express 1.12. I tried the tip of another user previously to use PTFB, but it would not rebuild after encoding.
Does it work with EclPRO .27?

It's strange, because .27 should work with previous versions, not with Procoder Express 1.12...
Have you checked if the rebuilt dvd is ok, expecially a the transition poin from one chapter to another, or if some frames are missing?

What's the date of the file PrcExprs.exe?
I would check if your version is older or newer than mine.

I hope to fix the support for every version.

A64

9th August 2005, 05:31

I will get the size, etc when I get home. The download comes from the Canopus site --> Support --> Driver Downloads for the registered owners. It shows that it is PCE_v112.zip and is newer than the version on their FTP site. The same is also true as it turns out for the full Procoder 2.0. Don't waste your time with the one on the FTP site since it is older than the one through this same access. Now you do have to be a legit owner that registered.

SomeJoe

6th October 2005, 05:25

Does it work with EclPRO .27?

It's strange, because .27 should work with previous versions, not with Procoder Express 1.12...
Have you checked if the rebuilt dvd is ok, expecially a the transition poin from one chapter to another, or if some frames are missing?

What's the date of the file PrcExprs.exe?
I would check if your version is older or newer than mine.

I hope to fix the support for every version.

Hi robot1,

Could I assist you in getting this fixed? I have the same issue with the v1.12 of ProCoder Express. EclPro 0.42 hangs at the Aspect Ratio, 0.27 gets through most of the settings but fails to start the conversion.

I'd be happy to test any fix or get you any information you need.

robot1

6th October 2005, 17:05

Thank you.
I'll work at it in the weekend.
Anyway, I've to find a solution to let EclPRO work with every (minor) subversion of ProCoder Express, as Canopus keeps changing the GUI

SomeJoe

7th October 2005, 15:48

Thank you.
I'll work at it in the weekend.

:thanks: I'll be around this weekend if there's anything I can assist with (test new ECLPro version, post screenshots of ProCoder Express, etc.) I'll check this thread.

robot1

13th October 2005, 22:20

Changelog:
Rewritten (again) routines to support various ProCoder Express versions.
Removed ProCoder 2.0 legacy mode (it's not needed, as the original mode works fine)
EclPRO v0.50 (http://rapidshare.de/files/6246242/EclPROv0.50.zip.html)

I think now it should work even with ProCoder Express for Edius - it's possible to download a trial of Edius3, as pointed by wmansir.

If I don't have reports of further bugs, I think this could become the v1.00 final.
For the final release I'll change the licence to GPL and I will release the sources.

There's just one thing I'm investigating.
I've had reports of problems using ProCoder 1.5 and NuMenu4U.
Please, send me reports to track this bug via PM or mail.

Thanks to SomeJoe for his testing.

MarkP

14th October 2005, 17:43

Changelog:
Rewritten (again) routines to support various ProCoder Express versions.
Removed ProCoder 2.0 legacy mode (it's not needed, as the original mode works fine)
EclPRO v0.50 (http://rapidshare.de/files/6246242/EclPROv0.50.zip.html)

Has anyone successfully downloaded this? I guess not cos the link url has a .html extension (see below)
URL=http://rapidshare.de/files/6246242/EclPROv0.50.zip.html

all it does is open a page at rapidshare can it be downloaded anywhere else ?
In the meantime will use 0.42
Cheers
Mark

robot1

14th October 2005, 17:55

In the rapidshare page, scroll down and press FREE at "Select your download".
Then you go to another page, with the exact link - you must disable any downloader as getright & co.

Anyway, I'm attaching the zipfile (as soon as a mod approves it).

MarkP

14th October 2005, 18:50

Strange way to download but never mind got it now thanks

robot1

19th October 2005, 18:27

Changelog:
- Fixed support for 704x480 and 704x576 - valid DVD resolutions - in ProCoder2.
- Changed licence type to LGPL

Download (rapidshare.de):
EclPRO v0.52 (http://rapidshare.de/files/6488569/EclPROv0.52.zip.html)

I'm attaching the download also to this message.

Boulder

23rd October 2005, 17:03

Sorry for the late reply.
I can't answer to your question.
We should know how does Procoder work internally.
If it works in YUY2 workspace, the conversion in avisynth is harmless.
If it works in YV12, probably it could better if the conversion is omitted.

Anyway, I don't think it works in YV12... but it's just a guess.
Probably someone in the Other MPEG 1/2 Encoders (http://forum.doom9.org/forumdisplay.php?s=&daysprune=&f=62) could answer this question?
Better late than never..

ProCoder prefers RGB as the input colorspace. In fact, you should use ColorYUV(levels="pc->tv").ConverttoRGB24() as the last item in your Avisynth script to avoid changes in colors.

It's no wonder the encoder is a bit slow just like TMPGEnc which also processes internally in RGB24.

SkVid

3rd January 2006, 19:38

Opening an .ECL file with the settings for vbr with EclPRO, Procoder 2 comes up with CQ Settings - even if the .ECL file is written by DVD-RB.
What is wrong? Is it the new Procoder update to version V2.04.02 ?

Thanks or your help.

robot1

3rd January 2006, 19:53

I hope they haven't changed the file format in a minor revision
:confused:
You could try opening the .ecl with an older version of EclPRO (0.42 or older), using legacy=1 in the eclpro.ini

Could you post the content of your item.ecl?
Thank you.

SkVid

3rd January 2006, 20:38

I tried with 0.27 beta in legacy mode but it stoped with the message in the attachment.
But after that I can't reproduce the error with the CQ thing anymore. I had this error since yesterday and had many tries. Now it works fine. All VBR settings are correct.
Sorry for the post above but nevertheless you helped me. Thanks.

wmansir

10th January 2006, 02:59

hey, robot1

I was playing around with Eclpro with the big3 process. I had some problems getting it to work with BatchCCEWS (which handles automated encoding) Eclpro support is a new addition and I think the problem is on that program's end.

But I was using the project .ecl files to manually encode with eclpro and ProCoder didn't like the file names. It would load up to the Convert page, but when I hit the Convert button it said something about the file name. I went to the Target page and tried to change the base name there, but it didn't help.

Eventually I figured out if I removed the first period from these filename settings in the .ecl it worked fine. (I made the removed '.' red)

vid_file0=G:\SCRUBS_VOBID\VTS__01_V005.4~3_1.mpv
vid_file1=G:\SCRUBS_VOBID\VTS__01_V005.4~3_1.mpv
vaf_file=G:\SCRUBS_VOBID\VTS__01_V005.4~3_1.vaf
aud_file=G:\SCRUBS_VOBID\VTS__01_V005.4~3_1.mpa

http://img242.imageshack.us/img242/1120/procoderinvalidname25jv.gif

http://img242.imageshack.us/img242/4097/procoderinvalidname13cd.gif

I know at one point Eclpro would output to a temp file and rename to the final target name, but I wasn't sure if that was for a similiar problem or for another reason. I thought perhaps that mechanism could be used in this case to make Eclpro more CCE compatiable, if it's still in the code.

I'm not sure if BatchCCE has a work around for this or not, considering the above file names are standard big3 project filenames I imagine it must if ProCoder is to work. I'll post this info in the batchCCE dev thread too just incase.

Thanks for your work.

jdobbs

10th January 2006, 12:39

Better late than never..

ProCoder prefers RGB as the input colorspace. In fact, you should use ColorYUV(levels="pc->tv").ConverttoRGB24() as the last item in your Avisynth script to avoid changes in colors.

It's no wonder the encoder is a bit slow just like TMPGEnc which also processes internally in RGB24.So this means I should do the RGB conversion above in the AVS files for ProCoder encodes?

jdobbs

10th January 2006, 13:07

I just did some testing -- and on my system using the ConvertToRGB24 slows it down noticably...

Boulder

10th January 2006, 14:35

I did once ask Canopus about it and they said that ProCoder works internally in RGB24.

They were very vague about it though.

EDIT: not YCbCr but RGB24

EDIT2: just timed it myself. RGB input is indeed slower so it must be YUY2 that it wants. I just don't know why their tech support said that RGB is the preferred route. Maybe he meant importing from some of their editing programs? My bad :stupid:

robot1

11th January 2006, 00:18

hey, robot1

I know at one point Eclpro would output to a temp file and rename to the final target name, but I wasn't sure if that was for a similiar problem or for another reason. I thought perhaps that mechanism could be used in this case to make Eclpro more CCE compatiable, if it's still in the code.

I'm not sure if BatchCCE has a work around for this or not, considering the above file names are standard big3 project filenames I imagine it must if ProCoder is to work. I'll post this info in the batchCCE dev thread too just incase.

Thanks for your work.

I will look at this issue tomorrow.
Thank you for your tests.

jdobbs

11th January 2006, 00:38

Boulder

11th January 2006, 07:01

How does it do with YV12?
I remember that some time ago I tried feeding YV12 data in ProCoder without a YV12 decoder installed. It resulted in an error message which said that a suitable decompressor was not found. For example, HC doesn't mind whether a decoder is found or not so that would suggest that ProCoder at least doesn't use YV12 data directly but converts it - probably to YUY2 first.

robot1

20th March 2006, 00:35

Updated first post with the version 1.00RC1.
If there aren't other bugs, I could consider this one as the final release.

spyhawk

4th May 2006, 06:04

Using EclPro v1.00RC1 to load an ECL file, I notice there's a couple of difference when I compare the values in Procoder2 Target window with ECL file.

First, the avg bitrate in Procoder2 window is lower than ECL. It is not exact as in ECL file. e.g. in ECL, vbr_brate_avg=3423 but in Procoder2 it is 3420. Changing avg bitrate in Procoder2 has no effect - it just changes back to 3420. It's often 2 or 3 numbers lower.

Second, given the source is interlaced, framed based, and bottom field first as seen in DGIndex Info, ECL file has top_first=0 but in Procoder2 window it is Upper/Top Field First. I verified the encoded m2v via DGIndex and it sure is TFF. Note that HC encoded m2v is BFF, similar to the source.

Will this different field order affect playback after rebuilding?

I notice when I have Alwaysframe=1 it is always TFF and when Alwaysframe=0 it is BFF. Is this supposed to be this way?

I tried field based encoding for interlaced source, as recommended by readme, and I don't see any much difference. However, one of my standalones cannot display the video correctly, like a very bad striped-line reception. Frame based encoding is more compatible for my standalones.

Since Procoder takes longer than HC, and appears to look better in segments, can I substitute some HC segments with Procoder ones, knowing that HC segment is BFF and dc_prec=9, and Procoder segment is TFF and dc_prec=10? I would think that there will be problem with playback?

If there is a way to make Procoder read BFF, that'll be great, as I see some HC segments are blocky.

spyhawk

4th May 2006, 18:49

Anyone knows the answer to my last question regarding segment substitution as this is related to Rebuilder question when I go to Rebuild phase?

robot1

4th May 2006, 21:08

First, the avg bitrate in Procoder2 window is lower than ECL. It is not exact as in ECL file. e.g. in ECL, vbr_brate_avg=3423 but in Procoder2 it is 3420. Changing avg bitrate in Procoder2 has no effect - it just changes back to 3420. It's often 2 or 3 numbers lower.
ProCoder rounds the value. It's not a problem, as an encoder is NEVER accurate to the byte.

Second, given the source is interlaced, framed based, and bottom field first as seen in DGIndex Info, ECL file has top_first=0 but in Procoder2 window it is Upper/Top Field First. I verified the encoded m2v via DGIndex and it sure is TFF. Note that HC encoded m2v is BFF, similar to the source.

Will this different field order affect playback after rebuilding?

It will not affect the playback, as DVD-RB takes care of the field order in the rebuild phase. Anyway, I've to check this, as it should reflect the ecl.

I notice when I have Alwaysframe=1 it is always TFF and when Alwaysframe=0 it is BFF. Is this supposed to be this way?
I will chech this also, but, as stated above, it's not a problem with DVD-RB

I tried field based encoding for interlaced source, as recommended by readme, and I don't see any much difference. However, one of my standalones cannot display the video correctly, like a very bad striped-line reception. Frame based encoding is more compatible for my standalones.
Neither I can see much difference. Frame based is more compatible, as stated in the readme.

Since Procoder takes longer than HC, and appears to look better in segments, can I substitute some HC segments with Procoder ones, knowing that HC segment is BFF and dc_prec=9, and Procoder segment is TFF and dc_prec=10? I would think that there will be problem with playback?

If there is a way to make Procoder read BFF, that'll be great, as I see some HC segments are blocky.
I think it's safe to substitute HC and ProCoder segments, but I've never tested this, and only jdobbs could be more precise.
Anyway, you could test and report.

spyhawk

5th May 2006, 03:59

Thanks for responding.

It will not affect the playback, as DVD-RB takes care of the field order in the rebuild phase. Anyway, I've to check this, as it should reflect the ecl.You're right, the field order is correct (BFF) in the rebuild phase, after I'm done with the whole Procoder encoding phase as a test.

Looks like substituting HC segment with Procoder segment is OK. There's no playback problem in any of the standalones.

wmansir

11th August 2006, 02:31

If you are using EclPro and DVD-RB you might find this program useful. Splash Killer (http://www.digitallis.co.uk/pc/SplashKiller/index.html) It makes Windows much more usable when you have many short segments encoding.

robot1

22nd June 2007, 10:46

This new version supports ProCoder 3 and Rhozet Carbon Coder, as these new encoders use the same .pcp format of ProCoder 2.

Tests and feedbacks are welcome.

Fishman0919

22nd June 2007, 12:46

This new version supports ProCoder 3 and Rhozet Carbon Coder, as these new encoders use the same .pcp format of ProCoder 2.

Tests and feedbacks are welcome.

robot1, any changes from the test ver?

robot1

22nd June 2007, 13:46

robot1, any changes from the test ver?

No, it's just the version you tested, with the sources and an updated readme file.

Fishman0919

22nd June 2007, 16:54

OK, thank you :)

kumi

22nd June 2007, 20:22

Thanks robot1. Especially for the AutoParameters fix in 1.01 :)

kumi

13th October 2007, 05:32

I am unable to encode anything with ProCoder 3 (under DVD-RB 1.26.5 & EclPro 1.10)

I get a popup on every segment that DVD-RB tries, with the message:

Grass Valley ProCoder 3
One or more targets could not be restored from the project file.

The item01.ecl.pcp project files give the same error if opened manually. I can see the Target List is empty in the ProCoder 3 window.

The same item01.ecl.pcp files are error-free when opened in ProCoder 2.

kumi

28th October 2007, 21:59

Just a quick update, I'm pretty sure my problem is not related to EclPro. I believe the "targets" in the error message refers to the Target Presets in ProCoder. For some reason, none of the MPEG2 presets are available to ProCoder 3, even though they exist in C:\Program Files\Common Files\Grass Valley\ProCoder 3\System Presets .

PS: Thanks for version 1.11, robot1!

Fishman0919

31st October 2007, 19:59

EclPRO v1.11 can be download form this Link (http://forum.doom9.org/showthread.php?p=1058648#post1058648)

ironD

25th November 2007, 10:04

Keep um coming haven't had a problem yet

Robot1

D:thanks:

Fishman0919

4th December 2007, 22:41

AVG Anti-Spyware is showing EclPro is malware. Sure its a false positive.

robot1

4th December 2007, 22:50

AVG Anti-Spyware is showing EclPro is malware. Sure its a false positive.
If I'm not mistaken, it's the old Awido product.
From time to time, they decide it's a malware. In the last version I haven't compressed with UPX the program, hoping to solve the problem, but probably I have not.
For what version of EclPro was the report related?

Fishman0919

5th December 2007, 03:03

version 1.11

dirio49

5th December 2007, 03:50

I think, I has to do with Autoitscript, Because people use it to write viruses too. ;) And antivirus companies I think just put now anything that is made by autoit scipt as virus.

jdobbs

8th December 2007, 15:28

All at once McAfee is now flagging ECLPRO.EXE also, even older versions - and it never did before.

robot1

10th December 2007, 18:54

Rumbah

11th December 2007, 03:20

I got a similar problem with my Cuttermaran provider and some virus scanners. It is written in Autohotkey, a similar scripting language, and I had to tell the scanner producer that it's a false positive and a few days later it was gone.

jdobbs

11th December 2007, 14:13

I'm very sad for these reports.
I see no way to solve this problem (which is a problem of the AntiVirus producers), other than mail them and ask to correct.
I release also the sources for EclPRO, and AutoIT is a secure application (you can find more here (http://www.autoitscript.com/autoit3/downloads.shtml) )

From ProCoder 2.0, the .pcp file is a simple .xml file: it could be possible to write an .ecl->.pcp translator in other programming languages - using the code from EclPRO as example. Anyway I don't have enough time right now, and ProCoder 1.5 or express users would be cut off.
I'm certain there is no issue. I'm especially disappointed in the anti-virus software developers. It's just silly to make anything written in AutoIt get flagged as a virus just because someone somewhere wrote a virus in AutoIt. Good thing they didn't decide to flag all "C" code as a virus to -- since most viruses are written in C... ;)