QuEnc^n - The multicore frontend for QuEnc v0.9 (Beta)

[Darksoul71]

Hi all,

since I had two weeks vacation there was some time to work on QuEnc^n :D

Grab the latest version here:
http://rapidshare.com/files/46414427/QuEnc_n_v09.zip.html

If anyone wants to mirror QuEnc^n, feel free to do so.

I can´t really provide a detailed change log since QuEnc^n has undergone a lot of changes. Most of them were to make the encoding process more solid. I´ve added support for custom matrices being used during the encoding process as well as automated adding of AVISynth filters. Thanks to some input from Mr_Odwin over at doom9 (http://forum.doom9.org/showthread.php?t=115471) I was able to get rid of my crappy AVIInfo_CLI tool which I always used to determine the frame count of the source AVS.

For more details refer to QuEnc^n.txt included in the zipfile :rolleyes:

Best regards,
D$

[danpos]

@Darksoul71

Well done, mate! ;)

Kept up,

[Revgen]

I keep getting this error message

Line 0 (File "H:\Package\QuEnc^n.exe"):

If (UBound($PID)=0) And @Error Then Exit
If (Ubound(^ERROR

Error: Variable used without being declared

Is there something I'm doing wrong?

[foxyshadis]

Does it do any kind of 1-pass scene-change detection, like ELDER? Even if you just ran the pass on a cut-down script (down that path lies madness though) and on a short segment around where you already expect to cut, it would help set it to a scene-change. But then, ELDER works on many small segments, instead of a few large ones, so maybe it's more important for that.

[Darksoul71]

@Revgen: Which CLI did u use ? If no CLI was given, QuEnc^n will currently error out like this...RTFM :)
Q: What Commandline Interface (CLI) does QuEnc^n provide ?
A: Basically QuEnc^n doesn´t really have a CLI. It simply takes all CLI params and
"forwards" them to the several QuEnc instances.
The only true parsing that QuEnc^n does is looking for source and target file
because it needs to modify them to make the multiple instances run. QuEnc^n will
also add the "-auto" and "-close" parameter if they are missing since the QuEnc
instances would either not start encoding and/or not close after encoding.


@Foxeyshadis: I dunno ELDER. QuEnc^n simply does what described in the short segment of the ReadMe:
Segmentlength=Frames# Video / Core

[Revgen]

CLI?

Do I use the Commandline Parameter tool to use this?

[Darksoul71]

Do I use the Commandline Parameter tool to use this?
Is water liquid ? :rolleyes:
...but feel free to code a GUI which translates the settings of QuEnc to CLI (basically replacing QuEnc GUI).

As I said: Its a simple AutoIt script. May be I´ll find some time in future to add a GUI but QuEnc^n was mainly coded as interface between any calling program (e.g. DVD-RB, DVD2VCD) and QuEnc. At least you are able to use it without something like an ECL generator :)

Does it do any kind of 1-pass scene-change detection, like ELDER? Even if you just ran the pass on a cut-down script (down that path lies madness though) and on a short segment around where you already expect to cut, it would help set it to a scene-change.

Ah, now I understand what you were talking about. Sry, my last post was 4:00AM local time :)


But then, ELDER works on many small segments, instead of a few large ones, so maybe it's more important for that.

This would be my initial impression. Since most people might likely use 2 or may me 4 instances of QuEnc for rather large movies this would result in long segment. Thus limiting the impact of a Segment end within a scene compared to a few hundered scenes within the whole segment.
Nevertheless that is a good point to consider an I´ll put it on my "improvment" list. Thanks.

[Revgen]

Is water liquid ? :rolleyes:
...but feel free to code a GUI which translates the settings of QuEnc to CLI (basically replacing QuEnc GUI).

As I said: Its a simple AutoIt script. May be I´ll find some time in future to add a GUI but QuEnc^n was mainly coded as interface between any calling program (e.g. DVD-RB, DVD2VCD) and QuEnc. At least you are able to use it without something like an ECL generator :)


Okay, I wasn't aware of that. I thought it was a GUI frontend for Quenc. I think I know what it's for now. Thanks.

[Revgen]

Okay I've tested it.

It's definitely faster than a than a single thread.

Great Job!:thanks:

I'll do a more complete test later.

[Darksoul71]

@Revgen:
Thnx, do you own a dual core system ?
I´m really anxious to see numbers on a dual core and a HT CPU with Dual QuEnc vs. Single QuEnc.

Thnx for testing.

[Revgen]

Yes I do.

It's a 4600+ X2 Dual-Core. It doesn't have HT though.

I'll do the tests once I get home.

[Revgen]

Okay here are the results. I timed these manually with a stopwatch.

Quenc 70: 1006 Secs 8.925 Total FPS

Quenc^n: 608 Secs 14.768 Total FPS


This is about a 65% increase.

Keep in mind that this was a 5-minute sample and the additional 30-secs of time for Quenc^n to mux the 2 videos may not affect feature length DVD's as much. I'm guessing a full DVD may give a performance boost into the 70% to 80% range.

EDIT:

Here are the settings I used

H:\Package>quencn -i J:\Progra~1\Dscaler\laker.avs -o J:\Progra~1\Dscaler\laker2
.m2v -b 4500 -maxbitrate 8000 -dc 9 -priority 3 -2 -hq -vbr -noscene -notrell -n
ocgop -interlaced -noextreme -gopsize 18 -maxbframes 2 -noqlb -nocmatrix -aspect
ratio 16:9 -tff

[danpos]

@Revgen

Impressive!:eek: This makes me think that I've to buy my MOBO+DualCore CPU ASAP! :devil:

@Darksoul71

Hmm, I hope that this result give to you a new stimulaton and so you can to take a look at QuEnc^n 'cousing' - LAN_AQE-RB ;)

Kept up,

[Darksoul71]

@Revgen:
Thank you very much ! Now I have some "true numbers". If you have the time I would be happy if you could provide results for a longer video (> 60 min). TIA...

I´m also expecting something like 70-80%. In very rare cases (very fast dual core / dual CPU systems) I the speed increase could be 80-90% but 200% speed increase is basically unrealistic.

@danpos:
Do not forget that I am basically working on LAN_AQE-RB. Think in little functions and not the "big picture" ;)

[Revgen]

@Revgen:
Thank you very much ! Now I have some "true numbers". If you have the time I would be happy if you could provide results for a longer video (> 60 min). TIA...

I´m also expecting something like 70-80%. In very rare cases (very fast dual core / dual CPU systems) I the speed increase could be 80-90% but 200% speed increase is basically unrealistic.

Yer Welcome.

I also was using a 29.97i interlaced source for the test since it was what I had available. 23.976p material could possibly bring greater benefits. I'll try a DVD movie tommorow and see what I can do.

[Revgen]

Okay I decided to use Star Wars Episode 1 WS (NTSC) for a 2hr test.

My Settings:

quencn -i J:\star\star.avs -o J:\star\star.m2v -b 4500 -maxbitrate 8500 -dc 9 -priority 3 -2 -hq -vbr -scene -notrell -nocgop -nointerlaced -noextreme -gopsize 18 -maxbframes 2 -noqlb -nocmatrix -aspectratio 16:9

Here are the results:

Quenc 70:

7815 secs

22.965 True FPS


Quenc^n:

4278 secs

41.952 True FPS


This is about an 82.68% increase over Quenc 70. About what I figured. It would have been in the 90% area if the muxing didn't take about 4 minutes to complete. It looks like the only way we can see a 90% speed increase is if we record long stuff like Lord of the Rings or Gone With the Wind so that any muxing time should hardly affect what is encoded.

Perhaps you could design it to encode in smaller segments and mux these in the background so that by the time the last segments are done the muxing won't take forever. I think this is what ELDER does.

Other than the minor muxing speed quibble, I think this program works quite well. I'll definitely be using it for awhile.:thanks:

I'll let you know if I find any bugs.

[danpos]

@Revgen

Good testings and well detailed reports. :goodpost:

I definitively have to upgrade my machine to a DC CPU asap!! I did a price search at local market and with about 378 euros (yep, I did the exchange) I can to buy a Pentium D, motherboard and a pair of memories for dual channel usage. I hope to get them soon. :)

See ya,

[Revgen]

Hmm... I guess prices in South America must be higher than they are here. I can buy an ASUS MOBO, AMD X2 3800+ and Corsair 1 GB Dual-Channel Memory for about the same price ($485) as you're paying in Euros. Low-end Intel Pentium D Combos are in the $315-$370 range.

Perhaps you have a friends or family who can hook you up here?

Good luck with your new system.

[danpos]

@Revgen

As a matter of fact I will pay for them with my local currency, I just did the exchange for the 'euro' people has a clue about price.

And yes, the prices are quite extorsive here and this quotation (377 euros) was got with stores which work with a certain scheme of importation ...:rolleyes:

Sometime ago I'd some friend of mine doing post-doctoral in Physics (yep, I'm a physicist too) in USA, so was easy to got them but now I don't know anyone there, so I've to go for my local store ..:mad:

Anyway, thanks for yours compliments! :)

Cheers,

[foxyshadis]

If you wait until July, when Conroe (Core2), Turion X2, and a new rev of A64 X2 come out, the prices on older PDs and X2s should drop even more... not sure how much of a difference it makes by now though. (Do get a 9xx PD if you go that route, 8xx are the older heat-spewing and power-sucking ones.)

[danpos]

@foxyshadis

Thanks for the informations and tips, much appreciated. :) I'll take them into account.

Cheers,

[Darksoul71]

Hi all,

1st thanks to revgen for testing. I always prefect real-life result over theoretical aspects :cool:
Those results are really impressive. I never expected something > 80%.

I´ve never done intense investigations on the topic distributed encoding but there already were some projects (e.g. a distributed VDub thing and as already mentioned ELDER). QuEnc^n is more a side project or should I say experiment I did within a project called LAN_AQE-RB (suggested name by danpos :)).
In the first stage of the project I´ll do a script set similar to RB-Farm which enables the user to distributed encoding for DVD-RB. In the second stage I´ll do a "frontend" which will accept MPEG2, AVI and AVISynth as input.

Over at the german doom9 ligh raised the concern that dividing a video into two parts and encoding them separately will result in lower qualtiy compared to encoding the same video as one part. This is based on the fact that the encoder can distribute the "bitrate spent" better if the complete video is analysed, e.g. the movie has relatively low action level in the first segment and towards the end there is a lot of action. This could result in "too much bitrate available" for the low action segment and insufficent bitrate available for "a lot of action" part of the video.

Based on my previous observations with DVD-RB I guess this concern is irrelevant. Just think about it for a few seconds: DVD-RB does a separate M2V for each chapter. Often the resulting M2V is only 5 min long (depending on your DVD source). I never experienced serious drops in quality. So I guess such a concern is not justifiable. Otherwise DVD-RB should have choosen a different approach, e.g. encoding the video for a complete movie and splitting the resulting M2V into chunks based on the chapter informations of the DVD.

What do you think ?

@foxyshadis:
Sry, if me first reply sounded a bit harsh. I wasn´t aware what ELDER is and didn´t think too much about scene detection in the first place. While scene detection and adjustment of the segment start / end to scenes makes perfectly sense I doubt you´ll see too much quality loss simply based on the fact an additional I-Frame is added. Just think about the ratio between this additional I-frame and the complete# of I-frames in the video. I guess a simple scene detection could be done based on AVISynth but this will be on the lower part of the to-do list :)

Esp. since QuEnc^n is more or less an experiment.

@revgen again:

This is about an 82.68% increase over Quenc 70. About what I figured. It would have been in the 90% area if the muxing didn't take about 4 minutes to complete. It looks like the only way we can see a 90% speed increase is if we record long stuff like Lord of the Rings or Gone With the Wind so that any muxing time should hardly affect what is encoded.

I share your observations. Muxing in the background should not hurt the CPU too much during encoding but read below....


Perhaps you could design it to encode in smaller segments and mux these in the background so that by the time the last segments are done the muxing won't take forever. I think this is what ELDER does.


Smaller segments (# segments > #cores = # of QuEnc instances) would require a more sophicticated approach for encoding, e.g. some sort of internal joblist. Not that hard to do but I would have to deal with something else. Currently I´m using DGIndex to join the video chunks to the final video file. This works fine as long as no audio ist involved. I was simply neglecting the audio and muxing abilities of QuEnc for the following reasons:

1) I like to do audio encoding outside the video encoder mainly because of control over this process. I already have AutoIt code to extract the audio track from an AVS via AVS2WAV and encoding to MP2 via BeSweet. This gives me perfect control about all parameters (e.g. bitrate, join stereo, gain, etc).

2) Often audio does not need to be encoded (e.g. DVD transcoding with available AC3 streams).

3) Some of the DVD tools accept separate audio streams and some of them even require either a separate audio stream (e.g. DVD Lab) or require a special muxer (MPlex for DVDAuthor).

Keeping the three points in mind I don´t see a real need to do add audio support. Esp. since you can really do this in a simple batch:

QuEnc^n.exe -i c:\myAVS.avs -o c:\myAVS.m2v .my params
AVS2WAV c:\myAVS.avs c:\myWav.wav
BeSweet ...my params
mplex my params


Do you feel like audio encoding and muxing support within QuEnc^n is a "must have" ?
If yes I would rather go the approach described above.

Of course muxing the chunks in the background or using QuEnc in "generate audio and mux" mode with later merging of the segment is not a big deal, I still don´t know a bugfree (!) CLI tool which can merge MPEG2 files. From what I know MPGTX has it´s problems. I´m really not shure it the few percent speed gain (let´s not forget that merging also takes it´s time) is really worth hassle and coding time involved.


Other than the minor muxing speed quibble, I think this program works quite well. I'll definitely be using it for awhile.
I'll let you know if I find any bugs.

Yes, please do so... :D

Regards,
D$

[Revgen]

Hi all,

1st thanks to revgen for testing. I always prefect real-life result over theoretical aspects :cool:
Those results are really impressive. I never expected something > 80%.

I´ve never done intense investigations on the topic distributed encoding but there already were some projects (e.g. a distributed VDub thing and as already mentioned ELDER). QuEnc^n is more a side project or should I say experiment I did within a project called LAN_AQE-RB (suggested name by danpos :)).
In the first stage of the project I´ll do a script set similar to RB-Farm which enables the user to distributed encoding for DVD-RB. In the second stage I´ll do a "frontend" which will accept MPEG2, AVI and AVISynth as input.

Over at the german doom9 ligh raised the concern that dividing a video into two parts and encoding them separately will result in lower qualtiy compared to encoding the same video as one part. This is based on the fact that the encoder can distribute the "bitrate spent" better if the complete video is analysed, e.g. the movie has relatively low action level in the first segment and towards the end there is a lot of action. This could result in "too much bitrate available" for the low action segment and insufficent bitrate available for "a lot of action" part of the video.

Based on my previous observations with DVD-RB I guess this concern is irrelevant. Just think about it for a few seconds: DVD-RB does a separate M2V for each chapter. Often the resulting M2V is only 5 min long (depending on your DVD source). I never experienced serious drops in quality. So I guess such a concern is not justifiable. Otherwise DVD-RB should have choosen a different approach, e.g. encoding the video for a complete movie and splitting the resulting M2V into chunks based on the chapter informations of the DVD.

What do you think?

I haven't seen much of a difference between the single-thread or multi-thread videos in terms of video quality. The file size of the multithread video is only 2mb larger than the single-thread one which isn't enough to make a difference.

My previous experience with ELDER tells me the video quality difference shouldn't be too much. The real problem is making sure that everything is muxed correctly. 708145 (ELDER Author) has been having multiple issues with MP4Box because it won't mux correctly sometimes.



Do you feel like audio encoding and muxing support within QuEnc^n is a "must have" ?


I wouldn't say so. I typically add audio into the video when I author my DVD after I'm done encoding. But then again, I can't speak for everyone.

That being said, so far the app works great as it is. I don't see any reason to rush.

[Darksoul71]

Updated QuEnc^n.

Download Link as in first post:
http://de.geocities.com/dark_soul_71/QuEnc_n.zip

Added messagebox if QuEnc^n is called without CLI. Also the bug below shouldn´t happen anymore:
Line 0 (File "H:\Package\QuEnc^n.exe"):

If (UBound($PID)=0) And @Error Then Exit
If (Ubound(^ERROR

Error: Variable used without being declared

[Revgen]

Looks good. You even added a new icon for it.

[robot1]

Over at the german doom9 ligh raised the concern that dividing a video into two parts and encoding them separately will result in lower qualtiy compared to encoding the same video as one part. This is based on the fact that the encoder can distribute the "bitrate spent" better if the complete video is analysed, e.g. the movie has relatively low action level in the first segment and towards the end there is a lot of action. This could result in "too much bitrate available" for the low action segment and insufficent bitrate available for "a lot of action" part of the video.

Based on my previous observations with DVD-RB I guess this concern is irrelevant. Just think about it for a few seconds: DVD-RB does a separate M2V for each chapter. Often the resulting M2V is only 5 min long (depending on your DVD source). I never experienced serious drops in quality. So I guess such a concern is not justifiable. Otherwise DVD-RB should have choosen a different approach, e.g. encoding the video for a complete movie and splitting the resulting M2V into chunks based on the chapter informations of the DVD.

What do you think ?
I have to agree with Ligh.
DVD-RB splits the encoding in cells, but every cell has a different bitrate, according to the original one. This allows to have a very good bitrate distribution, which reproduces the original distribution.
The very first release of DVD-RB used the same bitrate for every cell (like your project), but the quality was worse.
Probably with only two segment you will not have a great decrease, but the result shouldn't be as good as the one you get with a single encoding.

[Darksoul71]

DVD-RB splits the encoding in cells, but every cell has a different bitrate, according to the original one. This allows to have a very good bitrate distribution, which reproduces the original distribution.
The very first release of DVD-RB used the same bitrate for every cell (like your project), but the quality was worse.

Ah ! I wasn´t aware of that. OK, then DVD-RB has a benefit compared to "my "solution.

Probably with only two segment you will not have a great decrease, but the result shouldn't be as good as the one you get with a single encoding.
That was my main point when I answered ligh !

I think the majority of users will run eigher two or may be four instances of QuEnc at the same time for a standard movie. So unless you choose a very low bitrate, have a very short movie or a very "unbalanced" movie (slow in the begin and a lot of action in the end) the impact in quality should not be too visible.

To find out more about ligh´s claim, a lot of testing with different material and comparision of segmented vs. full encoding would be required. Unforunately I don´t have time for this.

May be there is an approach to "prescan" the movie ? But this would eat up some of the speed increase. Personally I can and will live the the impact in quality !

Thanks for sharing your thougts !

[Revgen]

Actually I believe ELDER also works this way. I'll have to ask 708145 to make sure though.

[Darksoul71]

@Revgen:
Could you clarify ? What do you mean with "this way" ?
The "prescanning" I´ve mentioned or the assigning of different bitrates to the segment ?

To me the most smart way to do "multi core" encoding unfortunately requires an encoder which works with OPV size prediction:
1) Do OPV prediction for complete movie
2) Encode n segments on n cores with the calculated Q-Value

[Revgen]

ELDER assigns different bitrates to different segments. At least I believe so. Once again, I'll have to check with 708145 (ELDER author) and find out.

I don't know about the other stuff though.

[Darksoul71]

Ah, ok !
If one can suggest an easy to implement algorithm to distribute the bitrate differently for the segments I´m happy to hear. May be using selectRangeEvery and do some sort of "Action Estimation" based on the Scene differences ?

[708145]

A not so short note first:
ELDER is capable of just using 4 chunks, just use the -c option to specify number of chunks :p
More chunks is there to improve load balancing on several cores since the segments differ in encoding speed your total time would otherwise depend on the slowest part! More segments help with resume as well, aka shutdown during encode and continue later (maybe after some gaming session or TV capture or holidays or...)

Ah, ok !
If one can suggest an easy to implement algorithm to distribute the bitrate differently for the segments I´m happy to hear. May be using selectRangeEvery and do some sort of "Action Estimation" based on the Scene differences ?

A complete 1st pass was my pick which is the most accurate and reasonably fast.
But even when you got relative difficulty of the chunks how would you encode them without a stats file? I hope CBR is out of the question.

About muxing: I solved the muxing issue I had which had to do that mp4box used the timestamps of the chunks instead of the order given in the command line! :S

One open issue:
If someone wants to contribute a GUI for ELDER I can spend my time on the advanced rate control modes I plan like an CRF like mode for xvid and the high fps mode called xvid50p which is optimized for 50p and 60p encodes more and more people out there are doing. At same quality 50p consumes just ~20% more than 25p using xvid50p! So it's time for fluid motion!

bis besser,
708145

[Darksoul71]

Hi all,

I´ve added something I called ADB (= Adaptive bitrate distribution) to QuEnc^n.
This feature is currently considered as experimental but my tries with up to 16
segments per movie looked promising.


01:25:20 >>Average Filesize for Samples: 14.15 MB
01:25:20 >>Average Bitrate specified in CLI: 3789 kBit/s
01:25:20 >>Filesize for Sample # 0: 13327331 Bytes
01:25:20 >>Filedeviation for Sample # 0: -10.2 %
01:25:20 >>Bitrate Correction Factor for Sample # 0: 1.1020043816206
01:25:20 >>Corrected Bitrate Factor for Sample # 0: 4175
01:25:20 >>Filesize for Sample # 1: 18010574 Bytes
01:25:20 >>Filedeviation for Sample # 1: 21.36 %
01:25:20 >>Bitrate Correction Factor for Sample # 1: 0.786447448742894
01:25:20 >>Corrected Bitrate Factor for Sample # 1: 2980
01:25:20 >>Filesize for Sample # 2: 12177049 Bytes
01:25:20 >>Filedeviation for Sample # 2: -17.95 %
01:25:20 >>Bitrate Correction Factor for Sample # 2: 1.17951038757939
01:25:20 >>Corrected Bitrate Factor for Sample # 2: 4469
01:25:20 >>Filesize for Sample # 3: 15849839 Bytes
01:25:20 >>Filedeviation for Sample # 3: 6.8 %
01:25:20 >>Bitrate Correction Factor for Sample # 3: 0.932037782057119
01:25:20 >>Corrected Bitrate Factor for Sample # 3: 3531


How does it work ?

Simple ! :cool:

I run a CQ encoding with a value of 1 for 1% of each segment. After this I calculate the average size over all samples and also calculates the deviation in % of each sample from the average. This deviation is used to "correct" the target bitrate.
Since a negative deviation indicates less action than a positive deviation, I simply adjust the average bitrate by the deviation. So -20% deviation translates directly to 20% less bitrate for this segment. Of course the relation between complexity and size is not a linear one but this is simply a first try.

If experiments show that a direct multiplication is "too strong" I can add a "weighting" factor to this correction.

Since my experiments indicate strong deviations for each segment, I´ll change the encoding approach of QuEnc^n for the next version. Instead of simply partitioning the movie in n segments for n CPUs, I´ll cut the movie into pre-definable chunks (e.g. you like to use 5 minute segments) and feed "n" CPUs until all segments are encoded. This should provide a more balanced bitrate distribution.

You can grab QuEnc^n v0.3 from here: http://de.geocities.com/dark_soul_71/QuEnc_n.zip

@708145:
But even when you got relative difficulty of the chunks how would you encode them without a stats file? I hope CBR is out of the question.

Could you clarify what you are talking about ? I don´t get it.

BTW: One approach to do parallel encoding for two-n pass could be like this:
1) Separate your movie into n chunks
2) Launch one encoder per CPU / network node in a 1st pass for each chunk.
3) Analyse the log files generated for each chunk and adjust the bitrate distribution according to all those log files specific for a chunk.
4) Repeat encoding in 2nd pass for each chunk with adjusted bitrate
5) Merge all chunks
Voilà ! Good quality and parallel encoding possible.
This requires of course an encoder like CCE which is able to do 1st pass and 2nd pass independently, is able to do a 2nd pass based on a previously generated log file and good knowledge how to analyse and adjust the log file in relation to all log files.

I don´t see a reason why "n" logs do not equal to one big log file generated in one run if you analyse them all and modify the bitrate value accordingly. Similiar to my ADB approach but much more sophisticated.

What do the MPEGEncoder devs amongst us think ?

Regards,
D$

[708145]

Hi all,

I´ve added something I called ADB (= Adaptive bitrate distribution) to QuEnc^n.
This feature is currently considered as experimental but my tries with up to 16
segments per movie looked promising.



:) Much closer to the ELDER approach already. Difference is that I have scene accurate chunk division :cool:


@708145:

Could you clarify what you are talking about ? I don´t get it.


As I understood it, you were talking about compression test + 1pass encoding. Thus I was asking about your 1pass mode.


BTW: One approach to do parallel encoding for two-n pass could be like this:
1) Separate your movie into n chunks
2) Launch one encoder per CPU / network node in a 1st pass for each chunk.
3) Analyse the log files generated for each chunk and adjust the bitrate distribution according to all those log files specific for a chunk.
4) Repeat encoding in 2nd pass for each chunk with adjusted bitrate
5) Merge all chunks
Voilà ! Good quality and parallel encoding possible.
This requires of course an encoder like CCE which is able to do 1st pass and 2nd pass independently, is able to do a 2nd pass based on a previously generated log file and good knowledge how to analyse and adjust the log file in relation to all log files.

I don´t see a reason why "n" logs do not equal to one big log file generated in one run if you analyse them all and modify the bitrate value accordingly. Similiar to my ADB approach but much more sophisticated.


Distributed 1st pass will work of course. Even if chunk borders are dfferent in 1st vs. 2nd pass as in ELDER. Just some stats file reading and writing needed ;)

But why don't you provide a GUI for ELDER? As I see it it can do all the things you are implementing already :devil:

Anyway, good to see someone working on another parallel encoder. I thought I was the only one who was interested in cluster encoding (or aren't you?)

bis besser,
T0B1A5

[Revgen]

:) Much closer to the ELDER approach already. Difference is that I have scene accurate chunk division :cool:


Is somebody getting jealous?:D

All kidding aside, it's good that both of you are contributing to the dual-core movement in encoding apps. I appreciate and look forward to the progress your both making.

[Darksoul71]

Much closer to the ELDER approach already. Difference is that I have scene accurate chunk division
Hm, how did you do this ? Is a simple AVISynth script with motion detection a good aproach ?

As I understood it, you were talking about compression test + 1pass encoding. Thus I was asking about your 1pass mode.
Oh, my bad ! I´m doing a CQ compression test for each segment and afterwards I run a normal 2-pass encoding with adjusted bitrate. Unfortunately QuEnc has not such a fine divided CQ scale to get close enough to the target size within +/- 10%. I´ve already talked to dragondgodz about this...

But why don't you provide a GUI for ELDER? As I see it it can do all the things you are implementing already
I´m writting console scripts myself and shall prodive a GUI ? Hmmm.......:confused:

While I think that ELDER works similiar to my approach it´s still more geared towards XVid encoding and not for DVD-compliant MPEG2 streams. If you see a way for a flexible interface in Elder to enable it for both MPEG2 and MPEG4, then drop me a PM.

I thought I was the only one who was interested in cluster encoding (or aren't you?)
I´m interested both in Multicore Encoding as well as in networked / cluster encoding. Have a look here.

http://www.vmesquita.com/forum/index.php?topic=6454.0

Bis noch besser,
D$ :cool:

[708145]

Hm, how did you do this ? Is a simple AVISynth script with motion detection a good aproach ?


I have a description on the ELDER wiki. Basically I do a dumb partitioned 1st pass, then analyze the stats and reencode the neccessary overlap. Then the 2pass chunks are generated and I produce the correct stats files that a normal xvid run would have produced.


Oh, my bad ! I´m doing a CQ compression test for each segment and afterwards I run a normal 2-pass encoding with adjusted bitrate. Unfortunately QuEnc has not such a fine divided CQ scale to get close enough to the target size within +/- 10%. I´ve already talked to dragondgodz about this...


Compression tests with just 1% are not very accurate by design. My approach results in a total error below 1% for a 2hour movie.


While I think that ELDER works similiar to my approach it´s still more geared towards XVid encoding and not for DVD-compliant MPEG2 streams. If you see a way for a flexible interface in Elder to enable it for both MPEG2 and MPEG4, then drop me a PM.


ELDER targets all codecs that I personally use: xvid and x264 for now with snow and theora support planned. A DivX developer signalled interest once as well but I guess management stopped him from providing a CLI :p
In general every codec that provides a CLI interface will work. I just don't encode MPEG2 that's why it's missing.


I´m interested both in Multicore Encoding as well as in networked / cluster encoding. Have a look here.


Nice. The sister project of ELDER already runs on up to 16 cluster nodes and encodes 1920x1080x60fps in realtime to high profile AVC :p
The backport to ELDER still depends on avisynth development for linux since my complete cluster code is unix based and I don't feel like porting that to windows given its very limited cluster capabilies.

bis besser,
T0B1A5

[Darksoul71]

Hi Tobias,

Compression tests with just 1% are not very accurate by design
This depends on what you call accurate. For me a video which is within 95 to 105% of the target size is still accurate enough. If the file is a bit to small I usally don´t care since I feel the urgent need to fill up my DVD-R. If the video is too large (even by 10%) you still have the option to use a compressed domain transcoder like regjig or requant. You normally don´t notice any drop in quality.

For my use (estimation of "Action level" within the segment) I feel that 1% is certainly enough to get at least a guess.

In general every codec that provides a CLI interface will work. I just don't encode MPEG2 that's why it's missing.
Hm, but for adjusting the segment borders to the scene changes requires being able to read the STATS files, or ?
Thus you are not only depending on the encoder providing a CLI but also being able to read the stats file, right ?
Hm, may be it´s possible to do a "simple" AVISynth script which drops the frames with scene changes to a text file.

ince my complete cluster code is unix based and I don't feel like porting that to windows given its very limited cluster capabilies.
Does ELDER work with real clustering ?

[708145]

Hi Darksoul,


Hm, but for adjusting the segment borders to the scene changes requires being able to read the STATS files, or ?
Thus you are not only depending on the encoder providing a CLI but also being able to read the stats file, right ?
Hm, may be it´s possible to do a "simple" AVISynth script which drops the frames with scene changes to a text file.


If I can't read the stats of the target codec then I'd use xvid to determine 1st pass stats and chunk borders and then encode 2pass to the target codec.

If I can read and write the target stats directly it will be much better and faster of course. :)


Does ELDER work with real clustering ?


If by real you mean 42 nodes in a mixed 32bit/64bit network then yes :>
But I can use them for very short tests only as their prime purpose is _not_ video coding. :p

bis besser,
T0B1A5

[Darksoul71]

*BUMP*
QuEnc^n has been updated...
See first post....

[micotito]

unable to open file..

What could be causing this problem.

Everytinh goes right, open 4 instances and do enconding, but after quenc closes a popup windows with unable to open file error, it seem that it cannot open dgindex to multiplex using v09 , avisynth 2.57 and dgindex 1.4.9.

with version 03 I got a different popup with unable to execute external program DGIndex & " " & DGIndex_CL

I just merge encoded files manually and its OK but cannot make it finish by itself.

Also in V09 I can't see the command line parameters logged.

this is my log

17:20:15 >>Corrected Bitrate Factor for Sample # 3: 7666
17:20:15 >>Instance #0 of QuEnc has been started !
17:20:15 >>Commandline for QuEnc Instance #0: "C:\movie\QuEnc\QuEnc.exe" -i "C:\movie\5000_000.AVS" -o "C:\movie\5000_000.M2V" -b 8333 -maxbitrate 8333 -1 -hq -novbr -aspectratio 4:3 -nointerlaced -mpeg2mux noaudio -dc 10 -priority 5 -auto -close -silent
17:20:15 >>Instance #1 of QuEnc has been started !
17:20:15 >>Commandline for QuEnc Instance #1: "C:\movie\QuEnc\QuEnc.exe" -i "C:\movie\5000_001.AVS" -o "C:\movie\5000_001.M2V" -b 8333 -maxbitrate 8333 -1 -hq -novbr -aspectratio 4:3 -nointerlaced -mpeg2mux noaudio -dc 10 -priority 5 -auto -close -silent
17:20:15 >>Instance #2 of QuEnc has been started !
17:20:15 >>Commandline for QuEnc Instance #2: "C:\movie\QuEnc\QuEnc.exe" -i "C:\movie\5000_002.AVS" -o "C:\movie\5000_002.M2V" -b 8333 -maxbitrate 8333 -1 -hq -novbr -aspectratio 4:3 -nointerlaced -mpeg2mux noaudio -dc 10 -priority 5 -auto -close -silent
17:20:15 >>Instance #3 of QuEnc has been started !
17:20:15 >>Commandline for QuEnc Instance #3: "C:\movie\QuEnc\QuEnc.exe" -i "C:\movie\5000_003.AVS" -o "C:\movie\5000_003.M2V" -b 7666 -maxbitrate 8333 -1 -hq -novbr -aspectratio 4:3 -nointerlaced -mpeg2mux noaudio -dc 10 -priority 5 -auto -close -silent
17:21:20 >>Instance #1 of QuEnc has closed !
17:21:20 >>Instance #2 of QuEnc has closed !
17:21:21 >>Instance #3 of QuEnc has closed !
17:21:51 >>Instance #0 of QuEnc has closed !
17:21:52 >>Instance #1 of QuEnc has closed !
17:21:52 >>Instance #2 of QuEnc has closed !
17:21:53 >>Instance #3 of QuEnc has closed !
17:22:23 >>All instances of QuEnc have been closed !

[Darksoul71]

@micotito:
I have no clue what is happening. Since I´ve been using QuEnc^n v0.9 together with DIKO for tons of DivX which I´ve converted to DVD without any hickups I do not understand this problem. This was using DGIndex v.1.4.6 though. From the log file I think everything worked out fine.

What also wonders me is that you do not see the DGIndex part of the CLI since this is normally logged also like this:
>Commandline for DGIndex: -IA=1 -FO=0 -YR=2 -TN=1 -OM=0 -BF=[C:\Eigene Dateien\AutoIt Projekte\QuEnc^n v0.9 (simplyfied)\DGIndex\Files.lst] -DSD=0 -DRC=0 -DSA=0 -OFD=[F:\FitDVD_blade_2163_kBit] -EXIT -HIDE

I´ve attached the latest QuEnc^n version to this posting (You have to wait until some of the moderators approves it). Please try the encoding again and post your results. This version has some more logging like this:
07:57:43 >>All instances of QuEnc have been closed !
07:57:43 >>Filesize of file & D:\DIKO Working\movie1._huffy_000.M2V in Byte: 916749336
07:57:43 >>Filesize of file & D:\DIKO Working\movie1._huffy_001.M2V in Byte: 814192846
07:57:43 >>Commandline for DGIndex: -IA=1 -FO=0 -YR=2 -TN=1 -OM=0 -BF=[D:\DIKO Working\movie1.LST] -DSD=0 -DRC=0 -DSA=0 -OFD=[D:\DIKO Working\movie1] -EXIT
08:00:47 >>Filesize of file & D:\DIKO Working\movie1.mpv in Byte: 1730942188
08:00:47 >>Merging of M2V files finished !

In the meanwhile I´ll grab DGIndex 1.4.9 and have a look at the documentation if something changed. One question though: Have you overwritten the dgindex included in the QuEnc^n dir ?

Edit: One thing that makes me wonder: Why is your encoding time so fast ? It´s something like 1 minute until your encoding is finished. Was your sample so short ? Please try a longer snippet.

Best regards,
D$

[micotito]

The reason that the dgindex part was not logged is because autoit break on trying to open files.lst for writing.

I resolved that problem and is encoding fine.



Now I found a great bug when calculating segstart and segend for cores > 2

I have a quad Q6600 and when seeing at result the 1st quarter plays OK and the the second is the same as first but starting on frame 1 why.? because of this

If (($i > 0) And ($i < $Cores - 1)) Then

AddLine ($SegmentAVS, "SegStart = 1+"& ($i-1) &"*SegLen")
when $i == 1 for core 1
(
$i-1 = 0 so (0*seglen) = 0 then 1 + 0*SegLen =1

Then core #1 stars enconding from frame 1 also end on $ * SegLen = SegLen
)
AddLine ($SegmentAVS, "SegEnd = " & $i & "*SegLen")
EndIf

I thing this should be

If (($i > 0) And ($i < $Cores - 1)) Then
AddLine ($SegmentAVS, "SegStart = 1+"& $i &"*SegLen")
AddLine ($SegmentAVS, "SegEnd = " & $i+1 & "*SegLen")

; AddLine ($SegmentAVS, "SegStart = 1+"& ($i-1) &"*SegLen")
; AddLine ($SegmentAVS, "SegEnd = " & $i & "*SegLen")
EndIf

Also I made another change just to enconde audio, when quEnc is called with novideo parameter it just call quEnc with commandlineRaw

If (StringLower ($CmdLine[$i]) = "-auto") Then $AutoIncluded = 1
If (StringLower ($CmdLine[$i]) = "-close") Then $CloseIncluded = 1

If (StringLower ($CmdLine[$i]) = "novideo") Then
$Command = Chr(34) & $QuEnc & Chr(34) & " " & $FullCLI & " -auto -close "
AddLog ($MyLog, "Enconding audio" & $CmdLineRaw)
RunWait ( $Command )
$NoCLI = 1
Exit
EndIf

[micotito]

Forgot to mention that the problem with DGIndex was solved simply by moving my DgIndex folder under quEnc^n folder, it's coded to open files.lst under dgindex inside Script Path.

I had dgindex at the same level as QuEnc^n so it was not working

[Darksoul71]

@micotito:
Damn, you are right ! Thanks for pointing out. I was too stupid to fully test the segment algorithm. I´ll modify QuEnc^n accordingly and release it after some testing. Since I only own a dualcore the bug didn´t show up during all my encoding.

I´ll also remove the DGIndex reference within the MergeM2V function. This is a leftover from older development :)

Thanks once again for pointing out the bugs and essentially fixing them :cool:

Best regards,
D$

[Darksoul71]

Hi all,

unfortunately I had a stupid bug in the segment formula which causes incorrect segment AVISynth code if more than two cores were specified. Since I only used QuEnc^n on a dual core the bug didn´t show up to me. Honestly my testing efforts were as limited as my spartime :)

Thanks to micotito again for pointing out and essentially fixing it :)

Such things happen when you change core functionality of an application (which is of course only a lame for too less testing *ggg*).

You can grab the updated version of QuEnc^n here:
http://www.megaupload.com/de/?d=1ZRNS7KI

Sorry for the hassle !

Best regards,
D$

[dirio49]

Hi.

Version 0.9b . I just complited it with the version of autoitscript (2.4.6.0), because the new version is supposed to be faster in what it does.

http://rapidshare.com/files/54017592/QuEnc_n_v0.9b.7z.html
later

[Darksoul71]

@dirio49: May I ask what for what reason you recompiled QuEnc^n ?
because the new version is supposed to be faster in what it does.

Could you clarify this statement ? What shall the new version do faster :confused:

OK, the most recent version of QuEnc^n is compiled with AutoIt Version 3.2.4.9

When you write 2.4.6.0 I think you are talking about v3.2.6.0, aren´t you ?

Even if v3.2.6.0 might be faster in some things I don´t see a benefit in recompiling QuEnc^n since the overhead by QuEnc^n is really small. Take a look at the log and you´ll see it:
06/09/2007 03:13:35 >>----------------------------------------------------------------------------
06/09/2007 03:13:35 >>QuEnc^n v0.91.2 - the multicore frontend for QuEnc
06/09/2007 03:13:35 >>Using AutoIt Version 3.2.4.9
06/09/2007 03:13:35 >>QuEnc^n is stored in path C:\Eigene Dateien\AutoIt Projekte\QuEnc^n v0.91.2 (logging)
06/09/2007 03:13:35 >>----------------------------------------------------------------------------
06/09/2007 03:13:35 >>QuEnc^n was called with the following commandline -i "D:\Action\FitDVD_Der Knochenjaeger_1750.AVS" -o "D:\Action\FitDVD_Der Knochenjaeger_1750.MPV" -b 1750 -maxbitrate 8500 -2 -aspectratio 4:3 -hq -vbr -nointerlaced -trell -silent -auto -close -priority 5 -mpeg2mux noaudio -noextreme
06/09/2007 03:13:35 >>----------------------------------------------------------------------------
06/09/2007 03:13:35 >>Generated Commandline: -i "D:\Action\FitDVD_Der Knochenjaeger_1750_000_CompCheck.AVS" -o "D:\Action\FitDVD_Der Knochenjaeger_1750_000_CompCheck.M2V" -b 1 -maxbitrate 8500 -2 -aspectratio 4:3 -hq -vbr -nointerlaced -trell -silent -auto -close -priority 5 -mpeg2mux noaudio -noextreme -nocmatrix
06/09/2007 03:14:37 >>CLI for Adaptive Bitrate CQ=1 Run #0: "C:\Eigene Dateien\AutoIt Projekte\QuEnc^n v0.9b (simplyfied)\QuEnc.exe" -i "D:\Action\FitDVD_Der Knochenjaeger_1750_000_CompCheck.AVS" -o "D:\Action\FitDVD_Der Knochenjaeger_1750_000_CompCheck.M2V" -b 1 -maxbitrate 8500 -2 -aspectratio 4:3 -hq -vbr -nointerlaced -trell -silent -auto -close -priority 5 -mpeg2mux noaudio -noextreme -nocmatrix
06/09/2007 03:14:37 >>Filesize for Adaptive Bitrate CQ=1 Run #0: 17212104
06/09/2007 03:14:37 >>Added up Filesize for Adaptive Bitrate CQ=1: 17212104
06/09/2007 03:14:37 >>Generated Commandline: -i "D:\Action\FitDVD_Der Knochenjaeger_1750_001_CompCheck.AVS" -o "D:\Action\FitDVD_Der Knochenjaeger_1750_001_CompCheck.M2V" -b 1 -maxbitrate 8500 -2 -aspectratio 4:3 -hq -vbr -nointerlaced -trell -silent -auto -close -priority 5 -mpeg2mux noaudio -noextreme -nocmatrix
06/09/2007 03:15:34 >>CLI for Adaptive Bitrate CQ=1 Run #1: "C:\Eigene Dateien\AutoIt Projekte\QuEnc^n v0.9b (simplyfied)\QuEnc.exe" -i "D:\Action\FitDVD_Der Knochenjaeger_1750_001_CompCheck.AVS" -o "D:\Action\FitDVD_Der Knochenjaeger_1750_001_CompCheck.M2V" -b 1 -maxbitrate 8500 -2 -aspectratio 4:3 -hq -vbr -nointerlaced -trell -silent -auto -close -priority 5 -mpeg2mux noaudio -noextreme -nocmatrix
06/09/2007 03:15:34 >>Filesize for Adaptive Bitrate CQ=1 Run #1: 18064206
06/09/2007 03:15:34 >>Added up Filesize for Adaptive Bitrate CQ=1: 35276310
06/09/2007 03:15:34 >>Starting Calculation for Adaptive Bitrate Distribution (ABD) !
06/09/2007 03:15:34 >>Average Filesize for Samples: 16.82 MB
06/09/2007 03:15:34 >>Average Bitrate specified in CLI: 1750 kBit/s
06/09/2007 03:15:34 >>Filesize for Sample # 0: 17212104 Bytes
06/09/2007 03:15:34 >>Filedeviation for Sample # 0: -2.42 %
06/09/2007 03:15:34 >>Bitrate Correction Factor for Sample # 0: 1.02415507744432
06/09/2007 03:15:34 >>Corrected Bitrate Factor for Sample # 0: 1792
06/09/2007 03:15:34 >>Filesize for Sample # 1: 18064206 Bytes
06/09/2007 03:15:34 >>Filedeviation for Sample # 1: 2.42 %
06/09/2007 03:15:34 >>Bitrate Correction Factor for Sample # 1: 0.975844922555675
06/09/2007 03:15:34 >>Corrected Bitrate Factor for Sample # 1: 1708
06/09/2007 03:15:34 >>Generated Commandline: -i "D:\Action\FitDVD_Der Knochenjaeger_1750_000.AVS" -o "D:\Action\FitDVD_Der Knochenjaeger_1750_000.M2V" -b 1792 -maxbitrate 8500 -2 -aspectratio 4:3 -hq -vbr -nointerlaced -trell -silent -auto -close -priority 5 -mpeg2mux noaudio -noextreme -nocmatrix
06/09/2007 03:15:34 >>Instance #0 of QuEnc has been started !
06/09/2007 03:15:34 >>Commandline for QuEnc Instance #0: "C:\Eigene Dateien\AutoIt Projekte\QuEnc^n v0.9b (simplyfied)\QuEnc.exe" -i "D:\Action\FitDVD_Der Knochenjaeger_1750_000.AVS" -o "D:\Action\FitDVD_Der Knochenjaeger_1750_000.M2V" -b 1792 -maxbitrate 8500 -2 -aspectratio 4:3 -hq -vbr -nointerlaced -trell -silent -auto -close -priority 5 -mpeg2mux noaudio -noextreme -nocmatrix
06/09/2007 03:15:34 >>Generated Commandline: -i "D:\Action\FitDVD_Der Knochenjaeger_1750_001.AVS" -o "D:\Action\FitDVD_Der Knochenjaeger_1750_001.M2V" -b 1708 -maxbitrate 8500 -2 -aspectratio 4:3 -hq -vbr -nointerlaced -trell -silent -auto -close -priority 5 -mpeg2mux noaudio -noextreme -nocmatrix
06/09/2007 03:15:34 >>Instance #1 of QuEnc has been started !
06/09/2007 03:15:34 >>Commandline for QuEnc Instance #1: "C:\Eigene Dateien\AutoIt Projekte\QuEnc^n v0.9b (simplyfied)\QuEnc.exe" -i "D:\Action\FitDVD_Der Knochenjaeger_1750_001.AVS" -o "D:\Action\FitDVD_Der Knochenjaeger_1750_001.M2V" -b 1708 -maxbitrate 8500 -2 -aspectratio 4:3 -hq -vbr -nointerlaced -trell -silent -auto -close -priority 5 -mpeg2mux noaudio -noextreme -nocmatrix
06/09/2007 05:43:22 >>All instances of QuEnc have been closed !
06/09/2007 05:43:22 >>Filesize of file & D:\Action\FitDVD_Der Knochenjaeger_1750_000.M2V in Byte: 525415834
06/09/2007 05:43:22 >>Filesize of file & D:\Action\FitDVD_Der Knochenjaeger_1750_001.M2V in Byte: 547077243
06/09/2007 05:43:22 >>Commandline for DGIndex: -IA=1 -FO=0 -YR=2 -TN=1 -OM=0 -BF=[D:\Action\FitDVD_Der Knochenjaeger_1750.LST] -DSD=0 -DRC=0 -DSA=0 -OFD=[D:\Action\FitDVD_Der Knochenjaeger_1750] -EXIT -HIDE
06/09/2007 05:45:15 >>Filesize of file & D:\Action\FitDVD_Der Knochenjaeger_1750.MPV in Byte: 1072493084
06/09/2007 05:45:15 >>----------------------------------------------------------------------------
06/09/2007 05:45:15 >>Adding file D:\Action\FitDVD_Der Knochenjaeger_1750.LST to logfile
06/09/2007 05:45:15 >>D:\Action\FitDVD_Der Knochenjaeger_1750_000.M2V
06/09/2007 05:45:15 >>D:\Action\FitDVD_Der Knochenjaeger_1750_001.M2V
06/09/2007 05:45:15 >>----------------------------------------------------------------------------
06/09/2007 05:45:15 >>Merging of M2V files finished !

So please stop releasing any "new version". It´s one thing to change something for yourself and another thing simply to "recompile" the sources with a newer AutoIt version. If you find a bug, tell me ! I´ll fix it and release a new version.

Even if I´ve included the sources of QuEnc^n I still hold the copyright and dislike such activities. :devil:

Regards,
D$

[dirio49]

Easy man.

Just thought the new version of autoit script could help.
I did not even release a new version, and i don't plan too.
Like i said in the comment i though that maybe the new speed
improvements could help. Sorry if i caused any trouble/confusion.
yeah, i mean v3.2.6.0 :)
Later
From the web site (http://www.autoitscript.com/autoit3/docs/history.htm)
Changed: General performance improvements (currently around 30-40% over 3.2.4.9)


BTW, Where can i find HcEnc^n ?
thanks

[Darksoul71]

Hi mate,

sorry, my initial reaction might have been a little harsh.....

ok, here´s my main point:
While you are right that the newer version of AutoIt promises 30-40% general perfomance improvements (wow, a vague statement which could be directly from a politician ;)), you simply missed the point what this means in essence for QuEnc^n.

Speaking technically the complete process of "distributed encoding" here can be broken down to parsing a single string (CLI from QuEnc), writing several textfiles (the AVISynth based segments) and calling a few external applications.

When you disable ABD (Adaptive Bitrate Distribution) the parsing of the CLI, writing the segment files and calling two QuEnc instances take only a second (according to the log file).

My guess: If the time logging would be exact enough to also measure milliseconds one would see that the complete process only takes 500 to 600 ms at a max.

The complete encoding of a movie takes mostly one to two hours. Now even if we would be able to cut down the overhead caused by QuEnc^n to something like 200-300 ms the user would simply not see any difference.

So please next time prior you think about doing something like this, compile / change the tool and test yourself. Unless you see a true perfomance increase, do not "release" it :cool:

The easiest way would be to contact me and ask: Hey D$, do you think recompiling QuEnc^n with the new version of AutoIt adds any value ?

Then you would directly get the answer: "No, I don´t think so" but I also may have said: "Hey, cool ! Thanks for the info. This will really speed up something".

For HCEnc^n I suggest you follow the discussion over at VMequita:
http://www.vmesquita.com/forum/index.php?topic=8443.0

...but be careful not only to grab the initial package and get the updated version(s) for HCEnc^n as well.

Take care,
D$

[dirio49]

Hi :)
I see you point.

All is good.
Later.

[Boow]

How do I use quenc^n with dvd2svcd? I tried to use it but I got an error "cannot find file" I did notice that the two files weren't joined into one I used the dgiindex that came with dvd2svcd. Is this the problem.

[Darksoul71]

Hm, haven´t used DVD2SVCD for ages.
How old is the DGIndex included with it ?
You should always use the latest version from Neurons page:
http://neuron2.net/dgmpgdec/dgmpgdec.html

Try with the newer DGIndex version and report back if it worked.

Honestly I´ve never tested QuEnc^n with DVD2SVCD but if newer versions of QuEnc are supported then I see no reason why QuEnc^n should fail...

[Boow]

got it working like the guy said above the dgindex folder needs to be in the quenc^n directory. perhaps it would be possible to make your prog work with dgindex from anywhere.

[Darksoul71]

Folks,

grab the latest version here:
QuEnc^n v0.91.2:
http://rapidshare.com/files/56501292/QuEnc_n_v0.91.zip.html

QuEnc^n (at least this recent version) looks for QuEnc.exe and DGIndex in its folder. If one of the exe´s is not found it asks the user to browse for them.

It would be also nice if one reports which version of QuEnc^n was used with which other program versions. I did a few versions of QuEnc^n and some of them have different minor flaws.

[Darksoul71]

Hi all,

I´ve made some changes to QuEnc^n:

The first major update is the usage of Restream (a great utility coded by ssh) to correct the timecodes in the resulting merged M2V files.
This should solve most issues that can occur when using QuEnc^n such as
- incorrect length detected by DVD Authoring tool
- failed muxing with MPLEX
- Problems with other muxing tools.

The second change I did:
QuEnc^n does not pause anymore when you click on the skull in the tray.

A few people reported problems with the default setting which pauses the script once you click on the icon.

Grab QuEnc^n v.0.91.3 here:
http://rapidshare.com/files/68137269/QuEnc_n_v0913.zip.html

Have fun,
D$

[Darksoul71]

@smok3:
I do know what has happened but your posting vanished.
To answer your question nevertheless:
There is currently no mirror. My suggestion to you and anyone interested in the progress of HCEnc^n and QuEnc^n is to follow my postings in the threads over at VMesquita (the website of DIKO):
http://www.vmesquita.com/forum/index.php?topic=8443.45

I usually post over there first when I release a new version.

Best regards & nice weekend,
D$

[smok3]

i found a working link, so i deleted my post :thanks:

question: edit: nm, i found the answer - audio wont encode.

[Darksoul71]

@smok3:
yes, audio currently does not work and honestly I do not see the need for it. There are tons of tools out there for audio encoding (Aften, Besweet, etc) and muxing as well (MPlex, Imago Muxer, etc). The only benefit would be that you call only one program.

[smok3]

yes, the benefit is simplicity and probably speed?, right now on dual cpu-er hc022 is faster (will check also on my home opteron).

p.s. iam doing 1.hc video, 2.twolame audio 3.mplex multiplex

[Darksoul71]

Hm, simplicity is definitely a good point if you do not use custom AutoIt scripts for batch generation like I do.

Speed is not a valid point :)

Ok, to be more specific:
It´s hard to compare speed for different encoders. Esp. QuEnc has tons of options which slow down the encoder a lot.

I did some tests with HCEnc^n using HCenc 0.21, HCEnc^n using HCEnc 0.22 (single threaded) and HCEnc 0.22 running multithreaded. The ^n-concept proved to be faster than HCEnc running MT :)

Check the VM thread for details...