HCenc 0.28

[hank315]

A new release: HCenc 028

- needs Avisynth 2.6 RC1 or higher
- support for mod8 resolutions

This new release expects Avisynth versions with AVISYNTH_INTERFACE_VERSION = 6.
Tested successful with:
- regular Avisynth 2.6 RC1 - RC3
- Avisynth MT by SEt (Current version 2015.02.20)
- Avisynth+ (tested r1779, r1718 or higher should work)

Download here. (http://hank315.nl)

[filler56789]

A new release: HCenc 028

:goodpost: && :thanks:

- needs Avisynth 2.6 RC1 or higher
Confirmed!
- support for mod8 resolutions
Checked :cool:

[videoh]

Hank, can you please explain how you determine if Avisynth is installed? I have a setup where I run batch files to select the version of Avisynth I want. I don't have registry entries but rather I just have the avisynth.dll directory in my PATH. I currently have AVS+ 1825 MT installed and can open a script with version() with no problem in VirtualDub. But when I run HCenc 0.28 it tells me that Avisynth is not installed. Your assistance would be greatly appreciated.

[hank315]

The registry is checked:


...
iret = RegOpenKeyEx (HKEY_LOCAL_MACHINE,& ! Key handle at root level
regpathC,& ! Path name (SOFTWARE\Avisynth)
0,& ! Reserved
KEY_READ,& ! Requesting read access
LOC(hKey)) ! Address of key to be returned
AVS_installed = (iret == ERROR_SUCCESS)
...


If AVS_installed = false a warning is generated but if there's an Avisynth.dll which can be loaded it will use that one.

[Sparktank]

:cool: Now this is an update. Thanks for your continual work.

[videoh]

If AVS_installed = false a warning is generated but if there's an Avisynth.dll which can be loaded it will use that one. Excellent, thank you very much. And thank you for the update!

[videoh]

If AVS_installed = false a warning is generated but if there's an Avisynth.dll which can be loaded it will use that one. Apparently, your code does not work on a 64-bit OS. When I test your registry call with KEY_READ | KEY_WOW64_64KEY then it works. Registry handling is a bit different for 64-bit Windows.

I suggest and request, therefore, that you eliminate the registry check entirely and just load the DLL that you find.

[hank315]

Strange, here it works OK (Win7 64 bit).:confused:
I suggest and request, therefore, that you eliminate the registry check entirely and just load the DLL that you find.
Maybe not such a bad idea, if LoadLibrary succeeds simply proceed.
Will have a look into it tomorrow, thanks for the report.

[videoh]

Strange, here it works OK (Win7 64 bit).:confused: Hmm, yes, confusing. I'll look into that a bit more also.

[qyot27]

I'm getting crashes and hangs with AviSynth+ r1825 with 0.28. The crash or hang occurs during the sampling pass - if there's a crash, it's at the switch from Phase 1 to Phase 2 (and then even crashes DrWatson), and if there's a hang, it occurs at the very end of the sampling pass, before switching to actual encoding. 0.26 is unaffected and can use r1825 without issues.

I've seen this happen on an old Celeron II (Pentium III Coppermine base) machine running WinXP, and on a mid-2011 iMac running OSX 10.10 with AviSynth+ and HCenc under Wine 1.7. The XP test was single-threaded, and the iMac/Wine case was with Prefetch(4).


EDIT: It appears that a standard 2-pass encode is fine, though, as tested on the aforementioned Celeron. So it seems to only affect the sampling pass in a *1PASS encode.

[Groucho2004]

It appears that a standard 2-pass encode is fine, though, as tested on the aforementioned Celeron. So it seems to only affect the sampling pass in a *1PASS encode.
I can reproduce this. However, it crashes with every version of Avisynth.

-> Crash dump (http://pastebin.com/2VqqMJUq)

[hank315]

I can also reproduce it and yes it will crash with every version of Avisynth.

This update should fix it (http://hank315.nl/files/HC_028/HC028_08-05-2015.zip)

And as requested by videoh Avisynth.dll is just loaded, which one can be checked with the Avisynth info button.

[videoh]

Awesome, Hank, thank you!

I confirm things work great for me now. The Avisynth Info feature is great, as it shows the path and version. Sweet.

[Groucho2004]

This update should fix it (http://hank315.nl/files/HC_028/HC028_08-05-2015.zip)

Thanks Hank, working fine here, too.

[qyot27]

Yep, it's working now. Thanks.

[manolito]

Just gave version 0.28 a short test run, it does work on my old machine. I normally use an older AviSynth version, but thanks to Groucho I can easily switch to the latest 2.6 RC3.

Question is: Why should I?

Going over the change log all I can see is support for HD output and support of more color spaces. I use HCenc ONLY for DVD creation, so these improvements do not matter for me.

Are there any other improvements in the encoding engine which would result in better quality for DVD compliant output compared to version 0.26 ?


Cheers
manolito

[Groucho2004]

I normally use an older AviSynth version, but thanks to Groucho I can easily switch to the latest 2.6 RC3.

Question is: Why should I?
There are quite a number if bug fixes from 2.5.8 -> 2.6.0, as mentioned here (http://avisynth.nl/index.php/Known_Issues). I seem to recall that you use 2.5.7 so that list may be even longer. 2.6.0 is also faster and uses less memory than previous versions.

[manolito]

Sorry, I was not clear enough...

My main question was why I should consider using HCenc 0.28 instead of version 0.26. Since all I use it for is DVD output, will version 0.28 have any advantages? (I also don't see why anyone today would use the MPEG2 format for HD output since even H.264 is almost obsolete these days).

For AviSynth the only reason I still have to use 2.57 is that I cannot live without good old DVD2SVCD. And every AviSynth version after 2.57 gives me a totally white screen in the preview window. I tried a lot of things to debug this behavior, but it is the avisynth.dll, nothing else.


Cheers
manolito

[SuLyMaN]

Bumpzor :P Interested in this too!

[Precomposed]

Where can I find the license agreement?

[ChiDragon]

Hi hank315. I've experienced a little bug in HCgui 0.28 where changing the Output filename resets my Interlacing options from interlaced TFF to interlaced BFF. Searching for the issue, I saw that Blue_MiSfit had encountered (http://forum.doom9.org/showthread.php?p=1465032#post1465032) the same oddity with 0.25.

I created a short video showing this easily-repeatable nuisance: https://youtu.be/3x64gG5VmWU

[hank315]

Some minor GUI bugs are fixed, including this one.

Can be downloaded here. (http://hank315.nl)

[Sparktank]

:goodpost::thanks:

Great stuff! Thanks for another update.
I'd hate to see the day this ends.

[Precomposed]

I'm encoding progressive content for PAL and have clients complaining that the quality is terrible when played back on a TV.

Settings 1: Interlacing options is set to 'progressive'. Chroma downsampling is 'progressive', BFF
Settings 2: progressive sequence is checked

Hank, I just read in another thread that you recommend disabling 'progressive sequence' for PAL. So I will try this next. However, using MediaInfo I analyzed a progressive PAL encode from Apple Compressor and Adobe Encore that look great on TV for the client. The only difference between the HC Encoder file and the ones from Apple and Adobe is that the HC Encoder version specifies the 'Scan Order: Bottom Field First'.

HC Encoder seems to force the scan order as TFF or BFF. There does not seem to be a way to have it not be set like the Adobe and Apple progressive PAL encodes. Any way we can disable setting the scan order?

[manolito]

Hi Jon,

looks like you have some reading about the MPEG2 flags ahead of you... :p

If you encode progressive content then technically there is no field order.

There is only one field order flag, this is the TFF flag. It can either be set (for TFF) or not set (for BFF). HCenc behaves like any other encoder, it just sets the flag or not.

Now comes the confusing part:
A lot of vieving devices do observe the field order flag even for progressive content. And it is allowed to set the TFF flag for progressive content, but ONLY if the "Progressive Sequence" flag is NOT set. (The TFF flag in this case has a different meaning, it specifies frame pulldown)

From an older thread:
mp3dom
18th June 2012, 10:24
Progressive + TFF flag is allowed when Progressive Sequence is OFF (this also allows to switch from progressive to interlaced - and vice versa - encoding in the same stream), it's not allowed when Progressive Sequence is ON (in that case it should be Progressive + BFF and switch from progressive to interlaced - and vice versa - is not possible)

So your HC.ini file should have these entries for encoding progressive:

*PROGRESSIVE
*TFF

The *PROG_SEQ parameter should NOT be set.

The chroma downsampling parameter must only be set if you are converting color space like 4:2:2 to 4:2:0.


BTW there is no need to reencode your existing source files. You can use a tool called "ReStream" to repair the flagging of your encodes. Check "Frametype progressive" and "TFF", uncheck "Progressive sequence".


Cheers
manolito

[Precomposed]

There is only one field order flag, this is the TFF flag. It can either be set (for TFF) or not set (for BFF). HCenc behaves like any other encoder, it just sets the flag or not.



Why do the encodes from Adobe and Apple not have a 'Scan Order' entry in MediaInfo then?

Here is the MediaInfo print out for the Adobe encode:

Video
Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings, BVOP : Yes
Format settings, Matrix : Default
Format settings, GOP : M=3, N=12
Duration : 20s 0ms
Bit rate mode : Variable
Bit rate : 6 483 Kbps
Maximum bit rate : 7 500 Kbps
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.625
Time code of first frame : 00:00:00:00
GOP, Open/Closed : Open
GOP, Open/Closed of first frame : Closed
Stream size : 15.5 MiB (100%)

Here is HC Encoder for a similar PAL progressive clip:

Video
Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings, BVOP : Yes
Format settings, Matrix : Custom
Format settings, GOP : Variable
Duration : 1mn 0s
Bit rate mode : Variable
Bit rate : 6 750 Kbps
Maximum bit rate : 7 500 Kbps
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Scan order : Bottom Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.651
Time code of first frame : 00:00:00:00
GOP, Open/Closed : Open
GOP, Open/Closed of first frame : Closed
Stream size : 48.3 MiB (100%)

What would explain the omission of the scan order in the Adobe encode?


A lot of vieving devices do observe the field order flag even for progressive content. And it is allowed to set the TFF flag for progressive content, but ONLY if the "Progressive Sequence" flag is NOT set. (The TFF flag in this case has a different meaning, it specifies frame pulldown)

From an older thread:


So your HC.ini file should have these entries for encoding progressive:

*PROGRESSIVE
*TFF

The *PROG_SEQ parameter should NOT be set.

The chroma downsampling parameter must only be set if you are converting color space like 4:2:2 to 4:2:0.


BTW there is no need to reencode your existing source files. You can use a tool called "ReStream" to repair the flagging of your encodes. Check "Frametype progressive" and "TFF", uncheck "Progressive sequence".


Cheers
manolito

This is PAL progressive content, so no pulldown is being done. Are you saying I should set Frametype Progressive, TFF, and no progressive sequence for PAL progressive content (25p)? I did this and the file is marked as Top Field First with MediaInfo (as expected). This is different than the Adobe and Apple files.

Here is the MediaInfo for the TFF encoded video:

Video
Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings, BVOP : Yes
Format settings, Matrix : Custom
Format settings, GOP : Variable
Duration : 1mn 0s
Bit rate mode : Variable
Bit rate : 6 750 Kbps
Maximum bit rate : 7 500 Kbps
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.651
Time code of first frame : 00:00:00:00
GOP, Open/Closed : Open
GOP, Open/Closed of first frame : Closed
Stream size : 48.3 MiB (100%)

[Precomposed]

I think I found the problem. After opening my original HC encode in ReStream, it is showing the "Progressive Sequence" flag not being set. It appears I tried to specify -prog_seq in the command line instead of in the ini file.

Both the Adobe and Apple PAL progressive files have 'Frametype progressive' and 'progressive sequence' enabled. Top field first is disabled.

Thanks for your help manolito.

[Sparktank]

You could also set zones for parts that need less bit rate (end credits, etc) and boost parts that would need it the most.
If you're using 2 passes, it will look better.

[manolito]

Glad you got it working...

Specifying Frametype progressive and TFF and not using Progressive Sequence has always worked best for me. CCE SP does it that way by default.

Other encoders (all libavcodec based encoders) do it differently. They check Frametype progressive AND Progressive Sequence and do not set the TFF flag.

Both ways are technically correct, and in theory any TV should play those encodes properly. But in real life things are often a little different.


Cheers
manolito

[LogicDeLuxe]

There is a long standing issue in HCenc. Sometimes, a single GOP happens to be of much lower quality then it should be. I found an example clip which can be used to reliably reproduce this issue: http://gratissaugen.de/test/dttest.m2v

With that certain clip, it encodes as it should with "maximum (kb/s)" set to 9000, "dc prec" to 10, "autogop" to 15, "closed gops" off, "interlaced tff" "check max bitrate" on and "Constant Quantization" set to 6.0, and B and P factors to 1.0.
However, if I set quantization to 5.0 or lower, I get massive artifacting at the fast zoom out.

A lower quantization setting should never lead to a worse quality, right? In the worse case, it should be the same quality, if the bitrate limit is reached.

With "dc prec" set to 8, "closed gops" on, or "maximum (kb/s)" set to 9800, quantization 5.0 seems to work fine, but the issue appears again at quantization 4.0 or lower.

I also encountered this issue in 2-pass encodings before, though it doesn't seem happen with this clip.

I tested this with HCenc 0.28 and also with the older 0.26, 0.25, 0.23, which I still have on my disk. The behaviors in each are very similar.

This is what the 4th GOP (and only that) looks like, despite high settings:
http://gratissaugen.de/test/dttest.jpg

[Emulgator]

A thought: The demanded low quantisation factor seems to fail with a bit-greedy zooming-in scene
because the quantisation factor wants to spend more bits then the given bitrate limit is willing to budget for.
So starving of bits because the bitrate limit of 9Mbps prevails ?

[LogicDeLuxe]

So starving of bits because the bitrate limit of 9Mbps prevails ?I would expect the GOP in question to be encoded at the 9Mbps limit in case the wanted quantization factor would require a higher bitrate. But in this case, that GOP isn't even close to that.

I checked with Bitrate viewer:

With q=6, it reports 6617 kbps on the 4th GOP, which is the highest rated GOP in this snipped, and it looks just like you would expect with that quantization factor. Also the GUI shows q=6.0 throughout the encoding, indicating that it isn't running out of bits so far.

With q=5 however, I only got 2618 kbps for the same GOP while all other GOPs are encoded at a slightly higher bitrate.
It also sais "underflow, fixing VBV" inbetween, which doesn't explain such a low bitrate in this GOP, though. It shouldn't be less then with q=6, right?

Here is the frame log for q=6:
frame type length enc.type % scantype intraVLC
------------------------------------------------------
0 I 31543 I 0 alt 14
1 P 4736 I 0 alt 14
2 B 4291 I 1 alt 14
3 P 4113 I 0 alt 14
4 B 4239 I 1 alt 14
5 B 4370 I 0 alt 14
6 P 5432 I 0 alt 14
7 B 5675 I 0 alt 14
8 B 5199 I 0 alt 14
9 P 4194 I 0 alt 14
10 B 3922 I 1 alt 14
11 B 3456 I 0 alt 14
12 P 1960 I 0 alt 14
13 B 2956 I 0 alt 14
14 B 2882 I 0 alt 14
15 I 31507 I 0 alt 14
16 B 2776 I 0 alt 14
17 B 2655 I 0 alt 14
18 P 1967 I 0 alt 14
19 B 2942 I 0 alt 14
20 B 2738 I 0 alt 14
21 P 4020 I 0 alt 14
22 B 3166 I 0 alt 14
23 B 4524 I 1 alt 14
24 P 4405 I 1 alt 14
25 B 4864 I 1 alt 14
26 B 4821 I 0 alt 14
27 P 5307 I 0 alt 14
28 B 5244 I 0 alt 14
29 B 5370 I 0 alt 14
30 I 31627 I 0 alt 14
31 B 2789 I 0 alt 14
32 B 2695 I 0 alt 14
33 P 63167 I 100 alt 14
34 B 2593 I 0 alt 14
35 B 2065 I 0 alt 14
36 P 35611 I 1 alt 14
37 B 5914 I 1 alt 14
38 B 4114 I 1 alt 14
39 P 4676 I 1 alt 14
40 B 4738 I 1 alt 14
41 B 4579 I 1 alt 14
42 P 70276 I 58 alt 14
43 B 60786 I 41 alt 14
44 B 57494 I 57 alt 14
45 I 73639 I 46 alt 15
46 B 61944 I 55 alt 15
47 B 61766 I 53 alt 15
48 P 63069 I 1 alt 15
49 B 61942 I 28 alt 15
50 B 34353 I 8 alt 15
51 P 24723 I 1 alt 15
52 B 13314 I 2 alt 15
53 B 13796 I 1 alt 15
54 P 23062 I 1 alt 15
55 B 5529 I 1 alt 15
56 B 7968 I 1 alt 15
57 P 27498 I 1 alt 15
58 B 9710 I 1 alt 15
59 B 13866 I 2 alt 15
60 I 70448 I 3 alt 15
61 B 17358 I 5 alt 15
62 B 10420 I 1 alt 15
63 P 10852 I 1 alt 15
64 B 7119 I 1 alt 15
65 B 7109 I 2 alt 15
66 P 12819 I 4 alt 15
67 B 8020 I 2 alt 15
68 B 7384 I 1 alt 15
69 P 15433 I 1 alt 15
70 B 12978 I 4 alt 15
71 B 5563 I 1 alt 15
72 P 15384 I 1 alt 15
73 B 10523 I 4 alt 15
74 B 12876 I 2 alt 15
75 I 72902 I 2 alt 15
76 B 5229 I 1 alt 15
77 B 4219 I 1 alt 15
78 P 9271 I 1 alt 15
79 B 4538 I 1 alt 15
80 B 4003 I 1 alt 15
81 P 8422 I 2 alt 15
82 B 8330 I 1 alt 15
83 B 8346 I 1 alt 15
84 P 36146 I 9 alt 15
85 B 5656 I 1 alt 15
86 B 25560 I 7 alt 15
87 P 39102 I 15 alt 15
88 B 21480 I 1 alt 15
89 B 22497 I 1 alt 15
90 I 66711 I 1 alt 15
91 B 28659 I 17 alt 15
92 B 2525 I 1 alt 15
93 P 22115 I 6 alt 15
94 B 17177 I 7 alt 15
95 B 13263 I 1 alt 15
96 P 18307 I 2 alt 15
97 B 7179 I 1 alt 15
98 P 15145 I 4 alt 15
99 B 7603 I 1 alt 15

and for q=5:
frame type length enc.type % scantype intraVLC
------------------------------------------------------
0 I 35078 I 0 alt 15
1 P 5530 I 0 alt 15
2 B 4565 I 1 alt 15
3 P 5163 I 0 alt 15
4 B 4804 I 1 alt 15
5 B 4728 I 0 alt 15
6 P 6278 I 0 alt 15
7 B 6426 I 0 alt 15
8 B 5991 I 0 alt 15
9 P 5489 I 0 alt 15
10 B 4394 I 1 alt 15
11 B 3950 I 0 alt 15
12 P 3011 I 0 alt 15
13 B 3629 I 0 alt 15
14 B 3698 I 0 alt 15
15 I 35073 I 0 alt 15
16 B 2988 I 0 alt 15
17 B 2723 I 0 alt 15
18 P 2380 I 0 alt 15
19 B 3127 I 0 alt 15
20 B 2732 I 0 alt 15
21 P 4620 I 0 alt 15
22 B 3352 I 0 alt 15
23 B 5019 I 1 alt 15
24 P 5220 I 1 alt 15
25 B 5644 I 1 alt 15
26 B 5211 I 0 alt 15
27 P 6411 I 0 alt 15
28 B 6036 I 0 alt 15
29 B 6479 I 0 alt 15
30 I 35313 I 0 alt 15
31 B 2923 I 0 alt 15
32 B 2771 I 0 alt 15
33 P 68088 I 100 alt 15
34 B 3234 I 0 alt 15
35 B 2357 I 0 alt 15
36 P 42276 I 1 alt 15
37 B 7433 I 1 alt 15
38 B 5191 I 1 alt 15
39 P 5439 I 1 alt 15
40 B 4733 I 1 alt 15
41 B 4409 I 1 alt 15
42 P 76088 I 58 alt 15
43 B 67082 I 41 alt 15
44 B 60374 I 57 alt 15
45 I 16402 I 46 alt 14
46 B 16204 I 55 alt 14
47 B 15336 I 53 alt 14
48 P 14975 I 1 alt 14
49 B 12925 I 28 alt 14
50 B 16298 I 8 alt 14
51 P 16282 I 1 alt 14
52 B 12864 I 2 alt 14
53 B 13530 I 1 alt 14
54 P 15414 I 1 alt 14
55 B 4150 I 1 alt 14
56 B 6985 I 1 alt 14
57 P 12326 I 1 alt 14
58 B 9038 I 1 alt 14
59 B 13551 I 2 alt 14
60 I 79342 I 3 alt 15
61 B 21389 I 5 alt 15
62 B 12953 I 1 alt 15
63 P 13276 I 1 alt 15
64 B 8044 I 1 alt 15
65 B 8150 I 2 alt 15
66 P 15733 I 4 alt 15
67 B 9032 I 2 alt 15
68 B 8108 I 1 alt 15
69 P 20599 I 1 alt 15
70 B 15593 I 4 alt 15
71 B 7030 I 1 alt 15
72 P 22190 I 1 alt 15
73 B 12333 I 4 alt 15
74 B 18847 I 2 alt 15
75 I 82296 I 2 alt 15
76 B 6587 I 1 alt 15
77 B 5243 I 1 alt 15
78 P 12925 I 1 alt 15
79 B 5169 I 1 alt 15
80 B 4609 I 1 alt 15
81 P 11136 I 2 alt 15
82 B 9384 I 1 alt 15
83 B 9136 I 1 alt 15
84 P 43568 I 9 alt 15
85 B 6870 I 1 alt 15
86 B 30623 I 7 alt 15
87 P 47576 I 15 alt 15
88 B 26456 I 1 alt 15
89 B 28669 I 1 alt 15
90 I 73605 I 1 alt 15
91 B 34809 I 17 alt 15
92 B 3696 I 1 alt 15
93 P 27362 I 6 alt 15
94 B 20690 I 7 alt 15
95 B 15941 I 1 alt 15
96 P 22243 I 2 alt 15
97 B 8461 I 1 alt 15
98 P 19342 I 4 alt 15
99 B 9080 I 1 alt 15

[ChiDragon]

Some minor GUI bugs are fixed, including this one.

Can be downloaded here. (http://hank315.nl)
Thank you! I forgot to say it back in August. :o

[hank315]

@LogicDeLuxe

This is a bug, it is easily reproducible with this clip. Seems the VBV code screws up and for some reason raises the quantizers sky high.
If VBV checking is turned off it runs OK but that's not the proper way to solve it :)

Thanks for the bug report.
Will investigate further.

EDIT:
This issue should be solved now.

Can be downloaded here (http://hank315.nl/files/HC_028/HC028_21-12-2015.zip)

[filler56789]

EDIT:
This issue should be solved now.

Can be downloaded here (http://hank315.nl/files/HC_028/HC028_21-12-2015.zip)

Many thanks for the new build :thanks:

[manolito]

Many thanks for the new build :thanks:

+1
What a nice Xmas present... :thanks:

[manolito]

Version 0.28 much slower than 0.26?

An AVStoDVD user over at VideoHelp just reported a much longer encoding time after switching from 0.26beta to 0.28.

He was using 1-pass VBR for a 2h 30min source file. The only difference in the encoding parameters was that he used Spline16Resize for HC 0.26 and Lanczos4Resize for HC 0.28.

For HC 0.26 his encoding time was 2h 22min, for 0.28 the encoding took 3h 20min.

This seems like a huge difference. Is there any explanation for this?


Cheers
manolito

[Andouille]

The original post of this user with his logs (contains the HC.ini) can be found here:
http://forum.videohelp.com/threads/277852-AVStoDVD-Support-Thread?p=2426363&viewfull=1#post2426363

You should read the rules.
The logs clearly indicates a pirated file.

[manolito]

@ Andouille

Alright, I wasn't aware of the source... (and I also refuse to be the copyright police, and since you are not a moderator, you should report such posts to a mod instead of reminding me to read the rules)
Deleted the link in my last post.


But the original question is still valid: Why is HCenc 0.28 so much slower than version 0.26?


Cheers
manolito

[Groucho2004]

But the original question is still valid: Why is HCenc 0.28 so much slower than version 0.26?
I assume that 0.26 is the Beta version from Hank315's website.

I just tried to reproduce this with a similar source file and the same settings, 0.28 is slightly faster in my case.

The idle priority setting may influence the encoding speed when something else is running in the background or the user is doing something else during the encode.

[manolito]

Thanks Groucho,

I also tried to reproduce this with no success, for me version 0.28 is just as fast as 0.26 beta.

But the user at VideoHelp is not pursuing this any further, he went back to 0.26 and is happy with it.

So I'd say: Case closed... :devil:


Cheers
manolito

[Richard1485]

Hank, when being fed frame-numbers for 23.976fps video, does HCenc assume that they are drop or non-drop?

[hank315]

Non-drop-frame timecode is always assumed for input.
Output is also non-drop except for 23.976 --> 29.97 pulldown.

[Richard1485]

Thank you, Hank. That's useful information. :)

[LogicDeLuxe]

I've just noticed another bug which only occurs when "interlacing options" is set to "auto detect".
Here is an example clip where I can reliably reproduce this issue: http://abmischung.de/tmp/dsn107.m2v
A jittering box appears above his head at the brightest bar.