HCenc 023 released

[txporter]

Been doing some testing with setmtmodes and MT calls with HCenc 0.24 beta 2-16-10. I am having odd irregularities with 1-pass VBR.

If I run this script (on 1080i 6min sample clip), it takes quite a long time to go through sampling (~14-15mins) and then it hangs at the end (never starts 2nd pass, and actually I cannot kill the encode with the exit button either...need to kill in Task manager).
setmtmode(5)
MPEG2Source("video.d2v",cpu=3)
setmtmode(2)
TFM()
TDecimate()
Undot().FluxsmoothT(5)
setmtmode(5)
MT("LSFMOD()",threads=4)
Bicubicresize(1280, 720)
TextSub("video.srt")
Distributor()

If I run that same script through 1-pass constant quant, it seems to process fine @ ~9.5fps.

If I run this script through 1-pass VBR, it completes sampling in ~3.5mins and goes on through 2nd pass fine. Encoding rate is ~8.4fps.
MPEG2Source("video.d2v",cpu=3)
MT("
TFM()
TDecimate()
Undot().FluxsmoothT(5)
LSFMOD()
",threads=4)
Bicubicresize(1280, 720)
TextSub("video.srt")

I would like to use the setmtmode version since it is faster, but it doesn't play nice with sampling. Is this expected?

HC.ini
*DBPATH I:\ToConvert
*LLPATH J:\temp
*BITRATE 4000
*MAXBITRATE 8000
*PROFILE best
*AUTOGOP 12
*AVSMEMORY 512
*INTRAVLC 2
*MATRIX hclow
*LUMGAIN 2

encoding parameters (CLI):
%hcenc% -i %~nA.avs -o %~nA.m2v -1pass -b 5000 -maxbitrate 10000 -progressive -log %~nA.log


UPDATE: The initial script runs fine in lossless mode as well. I guess however sampling is happening, it doesn't like the fact that setmtmode sends consecutive frames to different threads.

As far as lossless mode goes, it seems to use up all the resources on my computer. Everything is very sluggish when it is encoding (I do not notice this when doing 2-pass or 1-pass vbr or CQ). I am showing 90+% cpu utilitization and 95% of the physical memory used (even though HCenc_024.exe only shows using 640mb of 4GB). The encode is 52% complete for the 1st pass and the HC01.lls file is still 0kb in my lossless temp directory (GUI shows lossless file size of 10GB). Is this what everyone else sees as well when using lossless?

[rcubed]

As far as lossless mode goes, it seems to use up all the resources on my computer. Everything is very sluggish when it is encoding (I do not notice this when doing 2-pass or 1-pass vbr or CQ). I am showing 90+% cpu utilitization and 95% of the physical memory used (even though HCenc_024.exe only shows using 640mb of 4GB). The encode is 52% complete for the 1st pass and the HC01.lls file is still 0kb in my lossless temp directory (GUI shows lossless file size of 10GB). Is this what everyone else sees as well when using lossless?

txporter,
If you have sufficient physical drives in your system things will run faster if you place the source on one drive, the target on another, and the lossless file on another. The idea is to minimize the seeks for the reads and writes involved during the encoding process. If it is all on one drive a big cause of slow encoding is due to one single drive having to do a lot of seeks. If you have two physical drives putting the lossless on one drive and the source and target on another would probably work better. If you only have one drive it'll take longer.

Hope this helps

rcubed

[txporter]

txporter,
If you have sufficient physical drives in your system things will run faster if you place the source on one drive, the target on another, and the lossless file on another. The idea is to minimize the seeks for the reads and writes involved during the encoding process. If it is all on one drive a big cause of slow encoding is due to one single drive having to do a lot of seeks. If you have two physical drives putting the lossless on one drive and the source and target on another would probably work better. If you only have one drive it'll take longer.

Hope this helps

rcubed

Ok, thanks for the pointers on that. I had source and target on same drive and lossless file on another. Doesn't the lossless file ever get written out? I never saw the .lls file go above 0kb. I may just stick with 1-pass VBR with the MT calls rather than trying to deal with setmtmode. The total encode time still ends up being less than dealing with the lossless file and the computer resources are not so taxed.

Is there a way to use 1 avs for the sampling phase and a different one for the 2nd pass?

[rcubed]

txporter,
If you are using a My Computer window to monitor the Lossless file size you may have to do a View/Refresh on the window to get the file size to reflect the actual size. I don't remember is the filesize is only available once the sourcing program has closed (closed might not be correct term) the file or not. I would think the file size would be visible after the 1st pass of a 2 pass encode using refresh.

The lossless file is of most use if you have an AVIsynth script that is very time consuming and uses a lot of slow filters. If you have a simple .avs file to just open the file, the lossless may actually make the process run slower. I had some files that had to use the filter Mrestore. Lossless in that case made the 2nd pass significantly faster.

Perhaps Hank can shed more light.

rcubed

[txporter]

txporter,
If you are using a My Computer window to monitor the Lossless file size you may have to do a View/Refresh on the window to get the file size to reflect the actual size. I don't remember is the filesize is only available once the sourcing program has closed (closed might not be correct term) the file or not. I would think the file size would be visible after the 1st pass of a 2 pass encode using refresh.

The lossless file is of most use if you have an AVIsynth script that is very time consuming and uses a lot of slow filters. If you have a simple .avs file to just open the file, the lossless may actually make the process run slower. I had some files that had to use the filter Mrestore. Lossless in that case made the 2nd pass significantly faster.

Perhaps Hank can shed more light.

rcubed

Yes, what you said about the file size/My computer is exactly what I thought. I refreshed it multiple times (before and after 1st pass) and never saw the file size change.

Yeah, I understand the reasoning behind using Lossless. My scripts are not too complicated (Src, TIVTC, denoise, sharpen, resize, hardsub), but I do see a 2-3X framerate improvement using it. I would rather use 1-pass VBR since it is faster still and I am not extremely concerned about final file size (not for DVD). Anyhow, thanks for your thoughts.

[txporter]

Hmm, apparently the setmtmode/1-pass VBR issues are not the same for my 2 core laptop as my 4-core desktop. The sampling phase can complete on the laptop. Perhaps it is due to the # of threads? Sampling with/without setmtmode(2) seems to take the same amount of time (rather than ~10X as seen on desktop machine).

Laptop is also Window XP SP3 32-bit rather than Vista64. Avisynth and plugins are the same though.

[rcubed]

Anyhow, thanks for your thoughts.

txporter,
You are more than welcome.

rcubed

[Revgen]

I'll check out the new version as soon as I get a chance.

[AlanHK]

In HC 0.24 the progress in percent shown on the toolbar often gets way out of step with the actual percent, as shown in the app window. Eg, here 20% and 40%.

Or is it now supposed to indicate the percentage of the total job -- 40% of 1st pass of 2 = 20% of job?

[txporter]

I had noted this also. Yes, it appears to be percentage of total on the menu bar and percentage of current in the actual window itself.

[hank315]

I had noted this also. Yes, it appears to be percentage of total on the menu bar and percentage of current in the actual window itself.
Yes, this was on request by mikenadia, well there's some logic in it.

[soneca]

I'm sorry for my English ...

The 0.23 version has always worked very well, as all older, but this latest version does not work with DVD Rebuilder, the HCenc begins encode and suddenly crashes. HCenc not respond.

I use 32-bit Windows 7 + i7 920 + 3GB ram

Any idea what might be happening?

[Emulgator]

A little wish to hank315, easy to fulfill:
Can we have UserData string editable or at least empty ?
At the moment I am running HC streams through Restream to get rid of UserData,
I have to do a Closed Caption remux while authoring and fear DVDLabPro2 may block CC muxing as long as Private stream contains UserData.
This behaviour of DLP has been confirmed by others.

[manolito]

Just adding *NOUSERDATA to HC.ini will do the trick...

Cheers
manolito

[Emulgator]

Many thanks, manolito !

Edit: Unfortunately this does not work here with 0.24 beta 16-02-2010.

*NOUSERDATA is not represented in ini window.
If I edit manually in .ini using Editor, HC removes this line from HC.ini. Hm.

Mediainfo still shows |HCEnc 0.24.0.0 - (c) 2004/2010|

[Emulgator]

Another finding with 0.24 beta 16-02-2010:
If I bring progressive footage and rely on HC to find the proper progressive/interlaced setting and scan order
HC throws sometimes progressive, sometimes interlaced frames and scanorder also flips with this if I can believe the framelog.

Only if I force progressive I get 100% progressive frames encoded now.
This had worked before nicely in 0.24 beta 2009 10 20 and 2009 11 27.
Can anybody repeat this ?

Edit: Now after scrutiny the bug seems to dissolve,
now it works as it should, building 100% progressive frames.
I had it for the last 4..5 encodes sometimes coming up with around 5..10% interlaced frames...?

2nd Edit: No. Never mind.
My "autodetect" setting was not respected, I had not saved to HC.ini,
so HC took the shortcut and used the last setting which was forced progressive.

The flipping is still there, here is just one example.
720x576 PAL progressive, 700frames, motion menu with fly-in animation at the beginning.
The pattern comes out different everytime, here we have mostly interlaced:

frame type length enc.type % scantype intraVLC
------------------------------------------------------
0 I 39727 P 0 zigzag 14
1 P 32052 I 0 alt 14
2 B 21046 I 0 alt 14
3 P 33572 I 0 alt 14
4 B 22586 I 0 alt 14
5 B 21109 P 0 zigzag 14
6 P 35575 P 0 zigzag 14
7 B 23509 P 0 zigzag 14
8 B 23816 I 0 alt 14
9 P 43956 I 0 alt 14
10 B 25767 P 0 zigzag 14
11 B 26307 I 0 alt 14
12 P 50873 I 0 alt 14
13 B 28835 I 0 alt 14
14 B 29688 I 1 alt 14
15 I 65591 I 0 alt 15
16 P 50899 I 0 alt 15
17 B 16144 I 0 alt 15
18 P 57696 I 1 alt 15
19 B 20473 I 0 alt 15
20 B 18363 I 0 alt 15
21 P 59330 I 0 alt 15
22 B 22151 I 1 alt 15
23 B 21120 I 0 alt 15
24 P 64970 I 1 alt 15
25 B 22966 I 1 alt 15
26 B 21626 I 0 alt 15
27 P 61241 I 1 alt 15
28 B 22638 I 1 alt 15
29 B 21590 I 1 alt 15
30 I 91832 I 1 alt 15
continuing like that until end:
695 B 18781 I 1 alt 15
696 P 39473 I 1 alt 15
697 B 18252 I 1 alt 15
698 B 18357 I 1 alt 15
699 I 41558 I 1 alt 15


I remember this behaviour coming up with HC 0.23,
HC 0.22 was clean in PROG/INT decision, the earlier 0.24s were clean too.

[manolito]

This is from Hank himself at Doom10:
To disable the user data in HCenc, use the latest beta (16-02-2010) and add the next command in the ini file: *NOUSERDATA
I believe this will only work when calling HC directly, not from the GUI.

For the progressive / interlaced autodetect mode I noticed this flipping from the beginning. But does it really hurt if some progressive frames are encoded in interlaced mode? I was never able to point a finger on a reproduceable quality issue resulting from this behaviour. The other way around would be a real problem, so I believe that Hank wanted to play it safe and switch to interlaced if in doubt.

Cheers
manolito

[txporter]

For the progressive / interlaced autodetect mode I noticed this flipping from the beginning. But does it really hurt if some progressive frames are encoded in interlaced mode? I was never able to point a finger on a reproduceable quality issue resulting from this behaviour. The other way around would be a real problem, so I believe that Hank wanted to play it safe and switch to interlaced if in doubt.

Cheers
manolito

I have also noted this flipping for all versions of 0.24beta that I have used as well as 0.23. The only reason that I noted it was because it was causing playback of HC encoded files on my Tivo to move up and down a line or two between some frames when I used autodetect (I didn't check, but it was likely due to scan type switching). It created a strobe-like effect. I simply force progressive or interlaced based on input and no longer see this effect.

[hank315]

For the progressive / interlaced autodetect mode I noticed this flipping from the beginning. But does it really hurt if some progressive frames are encoded in interlaced mode? I was never able to point a finger on a reproduceable quality issue resulting from this behaviour. The other way around would be a real problem, so I believe that Hank wanted to play it safe and switch to interlaced if in doubt.
Yes, it's biased to interlaced because as you said it won't hurt that much to encode progressive as interlaced... it only takes a few extra bits.

A little wish to hank315, easy to fulfill:
Can we have UserData string editable or at least empty ?
At the moment I am running HC streams through Restream to get rid of UserData,
I have to do a Closed Caption remux while authoring and fear DVDLabPro2 may block CC muxing as long as Private stream contains UserData.
This behaviour of DLP has been confirmed by others.
Editable isn't an option because it can be screwed up pretty easy (start code emulation), I will just dump the user data.

I have also noted this flipping for all versions of 0.24beta that I have used as well as 0.23. The only reason that I noted it was because it was causing playback of HC encoded files on my Tivo to move up and down a line or two between some frames when I used autodetect (I didn't check, but it was likely due to scan type switching). It created a strobe-like effect. I simply force progressive or interlaced based on input and no longer see this effect.
IMHO the switching between progressive/interlaced frames shouldn't cause playback issues :confused:

[mp3dom]

Switching between progressive/interlaced frames shouldn't cause any playback issues, but switching between field/frame structure should (if I'm not wrong, the specs says that both field and frame structure need to be supported, but doesn't say if the structure could be changed in the stream during playback, so some (old) chipset shows the strobe-effect (on some it shows some kind of macroblocks). The same problem appear with ProCoder that does the same automatic field/frame structure.

[Emulgator]

I can confirm that this flipping is visible on certain chipsets, so dependent on player/TFT combinations.

Panasonic BD-50 -> Loewe 37" is one of those.
Occasionally appearing thin (bunch of single HD pixel wide horizontal lines where interlaced motion parts should appear)
Picture upsized by player to 1920x1080, so pointing to player chipset bug.

I believe this (*NOUSERDATA)will only work when calling HC directly, not from the GUI.
I see, I was using GUI.

[manolito]

Switching between progressive/interlaced frames shouldn't cause any playback issues, but switching between field/frame structure should (if I'm not wrong, the specs says that both field and frame structure need to be supported, but doesn't say if the structure could be changed in the stream during playback, so some (old) chipset shows the strobe-effect (on some it shows some kind of macroblocks). The same problem appear with ProCoder that does the same automatic field/frame structure.
But AFAIK HC is not even capable to encode with field structure. To make sure I just checked a DVD I made with HC using DGIndex, and while it does flip between progressive and interlaced all the time, the structure indicator is frozen at "FRAME".

Cheers
manolito

[Boulder]

But AFAIK HC is not even capable to encode with field structure. To make sure I just checked a DVD I made with HC using DGIndex, and while it does flip between progressive and interlaced all the time, the structure indicator is frozen at "FRAME".

Cheers
manolito
I think the issue is due to the DVD player or TV deinterlacing the frames where interlaced encoding has been used.

[txporter]

IMHO the switching between progressive/interlaced frames shouldn't cause playback issues :confused:

Yeah, I didn't expect to have a problem with it (and my PC didn't care), but playback on the Tivo was affect. /shrug It works fine if I just specify prog/int, no biggie.

I posted it some time ago in this thread, but wanted to bring it up again in case you missed it. Is it possible to get HCenc to work with setmtmode when using 1-pass VBR? Or maybe use two different avs files for the sampling phase versus the 2nd pass? MT works fine with 1-pass sampling, but setmtmode takes much longer and many times will cause HCenc to crash/hang.

[Boulder]

You need to have Distributor() as the last item in your Avisynth script to make SetMTMode work with HC.

[txporter]

You need to have Distributor() as the last item in your Avisynth script to make SetMTMode work with HC.

Yes, that I understand. It works fine with lossless or 2-pass mode, it just doesn't play well with the 1-pass mode sampling.

[hank315]

New HCenc024beta (http://hank315.nl/files/HC024_beta_04-04-2010.zip)

As usual some bug fixes, some changes to the 1pass VBR mode and user data is removed.
The TFF/BFF flag can now be set on progressive encodes, also Progressive Sequence can be set.

[Boulder]

Yes, that I understand. It works fine with lossless or 2-pass mode, it just doesn't play well with the 1-pass mode sampling.Perhaps the sampling part of the script (I assume HC uses Avisynth to create the sample clip) should be moved after Distributor(). However, this is something that must be done inside HC.

[Chumbo]

New HCenc024beta (http://hank315.nl/files/HC024_beta_04-04-2010.zip)

As usual some bug fixes, some changes to the 1pass VBR mode and user data is removed.
The TFF/BFF flag can now be set on progressive encodes, also Progressive Sequence can be set.
Thank you for the update. Just FYI, the encoder still "crashes" under Windows 7 64bit after it's finished. For some reason the "MPEG2 encoder has stopped working" message pops up when the encoder successfully completes and then closes.

The same happens from the GUI after the encode. Let me know if there's something you want me to test for. I've recorded a flash video of the problem. I'll PM you the link.

[soneca]

The same happens here with Windows 7 32bit.

[Emulgator]

BTW, here HC 0.24 beta 16-02-2010 in 32-bit and 64-bit version
worked without problems on a Win7U64 with i7-920XM CPU.

[txporter]

New HCenc024beta (http://hank315.nl/files/HC024_beta_04-04-2010.zip)

As usual some bug fixes, some changes to the 1pass VBR mode and user data is removed.
The TFF/BFF flag can now be set on progressive encodes, also Progressive Sequence can be set.

I tested the new beta with using setmtmode and 1-pass VBR. It seems to work now! One question though, is Distributor() no longer needed? If I use Distributor(), I get an immediate crash of HCenc. If I do not, it runs fine. I tested with and without the setmtmodes in the avs file and it does appear to result in a higher encode speed even without Distributor() [4.7fps with setmtmodes and 3.3fps without].

[Chumbo]

BTW, here HC 0.24 beta 16-02-2010 in 32-bit and 64-bit version
worked without problems on a Win7U64 with i7-920XM CPU.
HC works just fine. It's just that it "crashes" for whatever reason when the encoder finishes and closes which means I can't run multiple batch commands one after the other. The same with the GUI.

One of my computers is the same configuration as you mention but this problem is consistent on all my Win7U64 on the i7 920, 950 Quad-Core and my Core Duo P8800 notebook.

[hydra3333]

Hi Hank,
http://forum.doom9.org/showthread.php?p=1390290#post1390290 and
http://forum.doom9.org/showthread.php?p=1390298#post1390298
mentions what could be a bug with HCenc when using avisynth MT0.7 and Neuron2's DGMultiSource. HCenc crashes fatally, mostly.
Seems suggestive of an initialisation type bug.
Cheers

[Emulgator]

Hank,new 0.24 beta :As usual some bug fixes, some changes to the 1pass VBR mode and user data is removed.
The TFF/BFF flag can now be set on progressive encodes, also Progressive Sequence can be set.
And many thanks, Hank !
A second donation from me is coming soon.

[manolito]

New HCenc024beta (http://hank315.nl/files/HC024_beta_04-04-2010.zip)

As usual some bug fixes, some changes to the 1pass VBR mode and user data is removed.
The TFF/BFF flag can now be set on progressive encodes, also Progressive Sequence can be set.

Thanks very much for this new version...
Some findings / questions:

I just finished an encode in 1pass VBR mode (it was this problematic source where I got major blocking towards the end of the clip with earlier 0.24 versions), and it came out perfectly. One thing I noticed was that the latest version takes almost twice as long for the sampling phase compared the the previous version. Higher percentage of frames used for sampling and creating the compression curve?

And a question concerning the flagging for progressive streams:

Previous versions of HC (as well as QuEnc) would flag a progressive encode with "Frametype Progressive" and would also set the "Progressive Sequence" Flag. The TFF flag was not (and could not be) set.

CCE SP on the other hand would flag a progressive encode as "Frametype Progressive", but the "Progressive Sequence" flag is not set. But the TFF flag is always set for a progressive encode.

The latest HC beta now gives the user the freedom to use all possible combinations for flagging a progressive encode. My question now is if there is any advantage to set the "Progressive Sequence" flag in addition to the "Frametype Progressive" flag. Do decoders care at all? I never had any issues with DVDs created by CCE where the "Progressive Sequence" flag is never set.


Cheers
manolito

[Emulgator]

I found "Progressive Sequence not set" to be an advantage for certain DVD player/TFT combos.
CCE streams would play fine in such combos, whereas HC streams, although encoded properly, would give a brief flicker sometimes.
Reflagging HC to "Progressive Sequence not set" using ReStream helped in such cases.
I used it ever since on HC and was fine.
Others may not encounter any problems at all regardless of setting, but I preferred to do as CCE does from then on.

[sneaker_ger]

How do I have to set the new HC to act in the same way as CCE? "progressive + TFF" or is there anything else? It kinda irritates me having to set field order on progressive streams.

[manolito]

To act like CCE SP you must specify *PROGRESSIVE and *TFF for a progressive encode.

But you do not have to set field order for a progressive encode. AFAIK the standard says that the TFF flag has no meaning whatsoever for a progressive stream, decoders should ignore it.

The reason why I like to have the TFF flag set even for a progressive encode is that I convert a lot of TV captures where the movie itself is progressive, but the end credits are often interlaced TFF. Since I am too lazy to convert the credits separately it comes in very handy if the encoder sets the TFF flag. If it doesn't (like previous versions of HC or QuEnc) then these end credits will be displayed with the wrong field order which looks terrible.

Cheers
manolito

[sneaker_ger]

But you do not have to set field order for a progressive encode. AFAIK the standard says that the TFF flag has no meaning whatsoever for a progressive stream, decoders should ignore it.

Well, the new HC requires you to choose a field order. Standard is BFF.

The reason why I like to have the TFF flag set even for a progressive encode is that I convert a lot of TV captures where the movie itself is progressive, but the end credits are often interlaced TFF. Since I am too lazy to convert the credits separately it comes in very handy if the encoder sets the TFF flag. If it doesn't (like previous versions of HC or QuEnc) then these end credits will be displayed with the wrong field order which looks terrible.

If your setup separates/deinterlaces frames flagged progressive something is wrong to begin with, isn't it? :confused:

[manolito]

Well, the new HC requires you to choose a field order. Standard is BFF.Wrong. The new HC does not require you to choose a field order for progressive encodes. There is nothing like a BFF flag, only a TFF flag exists which can be set or not set. For progressive encodes this flag is not set by default. So just do not specify *TFF in HC.ini, and everything will be like it used to be in previous versions.

If your setup separates/deinterlaces frames flagged progressive something is wrong to begin with, isn't it?
Wrong again. I watch my movies through a standalone DVD player connected to a CRT TV. By definition this TV can only display fields, not whole frames. So the DVD player does indeed separate fields all the time, regardless if the content is progressive or interlaced. Even if you have an LCD TV which does display whole frames, as long as your standalone DVD player is connected to this TV through an analog connection, the player will separate the fields and the TV will have to rebuild the frames (and deinterlace if necessary).

Cheers
manolito

[sneaker_ger]

Wrong. The new HC does not require you to choose a field order for progressive encodes. There is nothing like a BFF flag, only a TFF flag exists which can be set or not set. For progressive encodes this flag is not set by default. So just do not specify *TFF in HC.ini, and everything will be like it used to be in previous versions.

Ah, I see. I only looked at the GUI options. And it seems to not set "*BFF" in the ini if you select BFF.

Wrong again. I watch my movies through a standalone DVD player connected to a CRT TV. By definition this TV can only display fields, not whole frames. So the DVD player does indeed separate fields all the time, regardless if the content is progressive or interlaced. Even if you have an LCD TV which does display whole frames, as long as your standalone DVD player is connected to this TV through an analog connection, the player will separate the fields and the TV will have to rebuild the frames (and deinterlace if necessary).

Ana..what? ;) Didn't think of that - you're right again.

[hank315]

I just finished an encode in 1pass VBR mode (it was this problematic source where I got major blocking towards the end of the clip with earlier 0.24 versions), and it came out perfectly. One thing I noticed was that the latest version takes almost twice as long for the sampling phase compared the the previous version. Higher percentage of frames used for sampling and creating the compression curve?
Yes, higher sample rate:

- old code -
perc=0.5
if (nframes < 200001) perc=0.6
if (nframes < 50001) perc=0.7
if (nframes < 20001) perc=0.8
if (nframes < 12001) perc=1.0
if (nframes < 6001) perc=1.5
if (nframes < 3001) perc=2.0

- new code -
perc=0.8
if (nframes < 200001) perc=1.0
if (nframes < 50001) perc=1.2
if (nframes < 20001) perc=1.5
if (nframes < 12001) perc=2.0
if (nframes < 6001) perc=3.0
if (nframes < 3001) perc=4.0


I'm thinking of setting the TFF flag by default, also on progressive sources.
If the playback device decides to separate the fields it's better to have TFF set.
Only for Digital Video source it will be BFF by default.

ATM I'm migrating from XP 32bit to WIN7 64bit so I can run tests with it soon.

[Emulgator]

I'm thinking of setting the TFF flag by default, also on progressive sources.
If the playback device decides to separate the fields it's better to have TFF set.
Only for Digital Video source it will be BFF by default.

I support that.

[blanco]

Hi. There's a problem with one of the parameters. Passing -filesize input at the command line results in a very low calculated average bitrate used. For example at the command line, I pass an avs file, an ini file (has bitrate setting) and then a single -filesize argument which has a reasonable number such as 4395283 kilobytes for 1 hr 36 min 23.976 movie, which HC should calculate to around ~6000 kbs but instead HC calculates ~250 kbs when it starts encoding.


I have encountered the same problem.
-Filesize input at the command line option does not work properly.
I loaded a 60000 frames videofile and set desired filesize at 960000. HCenc calculated an average bitrate of 270 kbs!

If i encode 5001 frames of the same video and set desired filesize at 90000 kilobytes, HCenc does calculate and encode at the right bitrate (+2000 kbs).

Is it a bug or did I do something wrong?

[JoeH]

When encoding using HCEnc on a Core i7 overclocked to 3.8GHz I usually only get about 20% processor usage, with speed around "realtime". Is this normal?

When encoding DVDs with TMPGEnc Authoring Works I tend to get around 80% CPU usage, with 4x realtime speed.

If this is normal for HCEnc, I would like to add a feature request to improve Core i7 support. If not, any ideas to improve encoding times and up that processor usage? Thanks!

[um3k]

Are you doing any processing in AviSynth? If so, that could be slowing down the process, as regular AviSynth is not multithreaded. There are mods to make it so that you might want to look in to.

[soneca]

Here operates at full
i7@2.66 with DVDRebuilderPro + HCenc 0.23

http://i131.photobucket.com/albums/p305/soneca1/Forum/ram.png

[hank315]

-Filesize input at the command line option does not work properly.
I loaded a 60000 frames videofile and set desired filesize at 960000. HCenc calculated an average bitrate of 270 kbs!

If i encode 5001 frames of the same video and set desired filesize at 90000 kilobytes, HCenc does calculate and encode at the right bitrate (+2000 kbs).

Is it a bug or did I do something wrong?
I can replicate it, it's certainly a bug, filesize > 262143 will screw up.
Will be fixed in the next release, thanks for the report.

[JoeH]

Are you doing any processing in AviSynth? If so, that could be slowing down the process, as regular AviSynth is not multithreaded. There are mods to make it so that you might want to look in to.

I was using it with MultiAVCHD, which does in fact use AviSynth.

Here operates at full
i7@2.66 with DVDRebuilderPro + HCenc 0.23

OK - that's good to know it's not a limitation of HCEnc. I'll try to solve it by other means then.