HC encoder

[Amnon82]

... maybe we will find a lost part :D by doing this ...

[techmule]

so hank315 already has a good idea of a way to do these things.


so hank what are the next steps you intend to take, going forward, in this context.

Are you planning to integrate CQ determination in HCenc next releases, if not, whats stopping you ???

and if not, why not share these ideas with authors of other tools like Amnon, darksoul and JDobbs, so that they can implement/improve on their CQ prediction methods with HCenc!!!.

[dragongodz]

Are you planning to integrate CQ determination in HCenc next releases, if not, whats stopping you ???
to quote hank315
A while ago I also tried to implement OPV based on Constant Quantization, well not completely constant, it could vary a bit.
This sounds a lot like the method used by Darksoul and I couldn't get it to work properly either...
so no a predictable by HC OPV mode based on CQ is not on the cards.

and if not, why not share these ideas with authors of other tools like Amnon, darksoul and JDobbs, so that they can implement/improve on their CQ prediction methods with HCenc!!!.
because they already know the different formulas etc.

so let me make this clear for everybody. hank315 and i have looked at and talked about an OPV where you can set target bitrate. the quants will vary etc as needed to hit the target and give extra where eeded etc. it does a short analysis to get some informaion about the source to base the full pass on. early tests however show it needs much more work because quality was not real great and tended to slightly undersize.
so hank315 has put this on hold for now because its something that will take more time than he currently has to make it worthwhile. so please do not ask for this, it will be done one day but at the moment. until then if you really want exact size prediction then use 2 pass, end of story.

[techmule]

so let me make this clear for everybody. hank315 and i have looked at and talked about an OPV where you can set target bitrate. the quants will vary etc as needed to hit the target and give extra where eeded etc. it does a short analysis to get some informaion about the source to base the full pass on. early tests however show it needs much more work because quality was not real great and tended to slightly undersize.
so hank315 has put this on hold for now because its something that will take more time than he currently has to make it worthwhile. so please do not ask for this, it will be done one day but at the moment. until then if you really want exact size prediction then use 2 pass, end of story.

Clear enough.

Why didnt you say so earlier!!!, we cant read your minds (or were you expecting us to do so :D )

[dragongodz]

Why didnt you say so earlier!!!, we cant read your minds (or were you expecting us to do so :D )
its not my job to list or talk about things hank315 has been or is working on. for example i know whats changed in HC 0.18 but i am not about to say what things they are here incase hank315 decides 1 or more is not ready and removes it. i think people should understand that.
these last few pages have also touched on several tangents and my responses have been to different things. however if you read all of what both hank315 and i have written the general idea of what i said is there. so no i dont expect people to be mind readers but they should expect me to give out information which should not be needed either.

[techmule]

its not my job to list or talk about things hank315 has been or is working on.

Thats funny cos thats what you have done here(and i am not saying thats its a bad thing to do) and you are definitely giving an impression that you are hanks messenger.:sly:

[dragongodz]

Thats funny cos thats what you have done here(and i am not saying thats its a bad thing to do)
i have only given as much information as needed for the relevant topic so as to try and dispel some assumptions and/or assertions. i could easily have gone in to much greater detail about everything. so yes i have mentiones a little of things hank315 has worked on but not really that much.

you are definitely giving an impression that you are hanks messenger. :sly:
not at all. with the extra knowledge i have about how HC works and what has been experimented with or worked on,especially from talks with hank315, i have chosen to try and help people in this thread. whether that means dispeling what or how they think HC does something ,or letting them know something has already been experimented with so they do not have to use a lot of their own time if they do not wish to. hank315 has had no say in it and certainly not encouraged or discouraged me from doing it.
if however people would rather i say nothing and let them discuss whatever making their own assumptions well i can do that just as easily. it really doesnt worry me either way.

[asia_minor]

if anyone sees the same thing I do...

Don't get me wrong, HC is a great encoder (and the price is pretty cool too :P), so thanks again hank315 for your hard work with this nice software.

So.. I had an idea to get better conversion quality out of my source XviD avi (350MB HDTV episode) and proceeded with a sample clip of it. Aside from my idea failing, I noticed for 1st time that the colours became a little darker (green became darker green, for example). Anyone else see something similar? I was intending on maintaining the quality of the source, since the resize wasn't very much and the original bitrate was roughly half the DVD bitrate.
Settings were ~2100 kbps (DVD bitrate), 16:9, HVSBest matrix (tried the other HVSs and AVAMATx matrices too, then again, I'm open to suggestions).

Could anyone point something out (is there a way to maintain colours with the higher bitrate)? And apologies if this is the wrong place to put this post.

Again, thanks hank315 for the very nice software :)


Now back to the current conversation at hand...


EDIT:
Just came across ColorMatrix. Might that do something?

EDIT2:
Bingo... ColorMatrix works like a charm. Have no idea what exactly is going on with those funky coefficients as parameters, and adapted an example from CCE, and it just works :) Now to get rid of those compression block artifacts....
OK... darn, looks like I need a higher bitrate to do what I want to do.

[Mug Funky]

xvid uses mpeg-1 coefficients... mpeg-2 uses (you guessed it) mpeg-2 coefficients :)

colormatrix was designed to fix this, so your search yielded good results :)

btw, try configure xvid, go to "decoder options" and turn on deblocking and deringing. you'll lose a bit of sharpness, but that's not a show stopper on an HD source... this should take care of the blocks in your source.

[asia_minor]

Thanks for reply. Apparently, from what I can tell by comparison, deblocking and deringing doesn't seem to do much (Enabled in XviD decoder, using another AVISynth script to do everything else in HC).
And now the settings are 3000 kbps, 16:9, "Ultimate" matrix. These seem to do the job pretty nicely.

[Boow]

I just tried the hc encoder out using avi2dvd but the last two encode have been blocky. the source are pretty good quality. So is there any way to get rid of the blocks. a list of settings for a good encode.

[Mug Funky]

@ Boow: show us yours and we'll show you ours :)

so long as your bitrate is over 3500 kbps or so, there shouldn't be any obvious blocking. you can probably go even lower.

[Boow]

Well I just viewed the source for one of my avi's at full screen and found out it was blocky to begin with. So i guess I shouldn't of been in a hurry. I redid the other movie with Quenc and it came out a lot better. I will give hc another chance with some dvds of mine I want to backup and see how that goes.

[alvarez]

Hello,

First, I'd like to repeat what's probably been told at least 1000 times already: Thanks for this great encoder!

Now, to the point: I'd like to ask whether building in a new option specifying the location of the intermediate database file would be possible. Right now it's placed in the directory of where .exe is, but (for me at least) it would be more convenient if it could be stored in the same directory as other intermediate files.

With best regards,

:alvarez:

[Mr_Odwin]

Hello,

First, I'd like to repeat what's probably been told at least 1000 times already: Thanks for this great encoder!

Now, to the point: I'd like to ask whether building in a new option specifying the location of the intermediate database file would be possible. Right now it's placed in the directory of where .exe is, but (for me at least) it would be more convenient if it could be stored in the same directory as other intermediate files.

With best regards,

:alvarez:

I'd like to second this request. (I think I've requested it previously, but it was a short reply in a large thread, and was probably overlooked.)

[Piper]

Hello all,

I'm wondering if I've come across a bug in HCEnc v0.21 as my resulting encodes appear to be ignoring the 16:9 flag.

My source fed to HCEnc is 704x480 anamorphic NTSC -> PAL conversion (25fps). In HCEnc, I set the 16:9 setting, but I used a GOP of 18 (I'm not sure why I did this). The m2v when played back in zoom player or windows media player plays back at 4:3 which I later discovered after running the m2v file through DGPulldown and burning to DVD via DVDAuthorGUI and Nero 7 in Vista.

Any ideas on why or how the 16:9 flag is either being ignored or is not being written to the file? It's been a while since I've encoded a source like this, so perhaps I'm only missing some small step. I'll encode again with GOP 15, but I doubt GOP has anything to do with setting the AR flag.

Thanks

[45tripp]

You can check/change the DAR flag with restream.

If it's indeed a problem, can you recreate it?
And provide as much info as you can?

gl

[Ebobtron]

Hello all,

I'm wondering if I've come across a bug in HCEnc v0.21 as my resulting encodes appear to be ignoring the 16:9 flag.

Thanks

Check your log file or do a short clip with the log file this time.

[hank315]

I'd like to ask whether building in a new option specifying the location of the intermediate database file would be possible.This will be in the next release.

[alvarez]

This will be in the next release.

Thanks a lot!

:alvarez:

[Piper]

You can check/change the DAR flag with restream.

If it's indeed a problem, can you recreate it?
And provide as much info as you can?

gl

Thanks for the suggesting restream, I'd forgotten about this handy little app. Indeed, the AR in the .m2v file was set correctly and I discovered the cause only minutes after reading your post. The real issue was my son had played with the dvd player and messed around with its AR settings. What threw me however was that Zoom Player wasn't picking up the AR flag (regardless of AR setting). Media Player Classic dealt with it correctly however.

A non issue..sorry for the bother. Thanks.

[Mole]

Hello all,

I'm wondering if I've come across a bug in HCEnc v0.21 as my resulting encodes appear to be ignoring the 16:9 flag.

My source fed to HCEnc is 704x480 anamorphic NTSC -> PAL conversion (25fps). In HCEnc, I set the 16:9 setting, but I used a GOP of 18 (I'm not sure why I did this). The m2v when played back in zoom player or windows media player plays back at 4:3 which I later discovered after running the m2v file through DGPulldown and burning to DVD via DVDAuthorGUI and Nero 7 in Vista.

Any ideas on why or how the 16:9 flag is either being ignored or is not being written to the file? It's been a while since I've encoded a source like this, so perhaps I'm only missing some small step. I'll encode again with GOP 15, but I doubt GOP has anything to do with setting the AR flag.

Thanks

According to the DVD specs, 16:9 Anamorphic is only supported on full D1 resolutions (720x576/480)

This may be the reason why the the AR flag is ignored on your encodes.

[MysticE]

I have been playing around with HCenc and have found the results to be very nice. I usually use it to convert 25 f/s music videos to NTSC. My knowledge is limited, but I always see that pulldown should be used to get to 29.97 NTSC. It appears that HCenc's pulldown will only work with a 23.976 source, 25 f/s is ignored.

Am I missing something here?

[jdobbs]

Encode it at 25fps, then use Neuron2's DGPulldown against the output. Up until he wrote that code, I'm not sure anyone else had given much thought to converting that way. It also makes sure your audio stays in sync.

[Sagittaire]

I have been playing around with HCenc and have found the results to be very nice. I usually use it to convert 25 f/s music videos to NTSC. My knowledge is limited, but I always see that pulldown should be used to get to 29.97 NTSC. It appears that HCenc's pulldown will only work with a 23.976 source, 25 f/s is ignored.

Am I missing something here?

You must use pulldown with 23.976 fps source. Use pulldown with 23.976 progressive source (at playback only, progressive internaly) make 29.970 interlaced NTSC output.

[jdobbs]

If I understood correctly, I think in this case he's talking about converting PAL to NTSC by applying pulldown to a 25fps source. The TFF/RFF pattern would be different than if it were a 23.976fps source. That's why you'd have to use DGPulldown to do it instead of HC.

[MysticE]

If I understood correctly, I think in this case he's talking about converting PAL to NTSC by applying pulldown to a 25fps source. The TFF/RFF pattern would be different than if it were a 23.976fps source. That's why you'd have to use DGPulldown to do it instead of HC.
That's exactly what I meant. I have quite a few XviD music videos that I'm converting to 16:9 NTSC for play on my Plasma. All of them are 25fps. Using ChangeFPS(29.97) in my scripts is an easy fix and is fine for my vids, but I'm trying to understand the process a bit more and was confused as to why DGPulldown will convert 25fps but HCenc chooses not to.

Thanks

[vlada]

almost all movies are recorded at 24fps. In order to get them into NTSC standard, you need to convert them to 30fps (29,97 respectively). This is called 3:2 pulldown. You get a movie with the same length as original, but some fields are duplicated. The video looks like if it was interlaced.

To convert film material to PAL the video (including sound) is simply sped up to 25 fps.

So to get a "real NTSC" from 25fps, you need to slow it down to 24 fps (use AssumeFPS function in Avisynth) a then apply 3:2 pulldown in HC. You also need to slow down your music. But I'm not sure this is something you really want to do with music. You need to make a decision: worse video quality - choppy or blurred (your old method) or slowed down music (as described above).

As suggested, DGPulldown might be able to make a pulldown from 25 to 30 fps. But I never tried it because I live in a PAL country.

[jdobbs]

If you do it the first suggested way you will have material that virtually impossible to sync.

Of course on the other hand, you could just use DGPulldown on the source to convert it directly and have a perfect match.

[totya]

Hi,

In HC encoder GUI, I see:

dc precision 8-10
8:recommended for low bitrate
9:recommended for normal bitrate
10:recommended for high bitrate

Exactly how many kb/s these settings (8-10) ?
Example : 8bit 0-3500kb/s 9bit 3500-6000kb/s

Thank you.

[Boulder]

It's impossible to say that some value is high bitrate, some not. It depends on the source material - 3000kbps might be a lot for some while for some it's not.

[totya]

It's impossible to say that some value is high bitrate, some not. It depends on the source material - 3000kbps might be a lot for some while for some it's not.

Ok, thanks...

[gizzin]

Ya, 3000kb should just be a guideline to achieve good quality. There's lot of movies that would need more than, Saving Private Ryan is a good example probably needs something more like 4000kb

[totya]

Hi, i don't understand this; if source is captured avi from TV (720x576 YV12 PAL progressive, with lagarith lossless video codec) the result speed is "normal".
pass 1 (fps) 29.7
pass 2 (fps) 12.4

But, if this avi noise filtered, speed is worst (?!)
pass 1 (fps) 31,5
pass 2 (fps) 4,5

HC Profile:
profile: BEST
frames: 0 717
framerate: 25.000
aspect ratio: 4:3
bitrate Kb/s: 9200
max. bitrate Kb/s: 9500
pulldown: no
closed gops: no
VBV check: yes
scene change det.: yes
interlaced: no
goplen,B-pic: AUTO
dc_precision: 10
scan method: ZIGZAG
bias: 0
chapter frames: 0
time code: 0 0 0 0
CPU: SSSE3
matrix: MPEG
luminance gain: no

input avs is equally:
AviSource("_temp_.avs",true)

HC is latest version.

With CCE, total converting time:
unfiltered avi: 68 sec
filtered avi: 64 sec (!)

Thank you.

[Boulder]

I have a feeling that there is VBV buffer underflows going on, and the encoder needs to re-encode those GOPs where it occurs. You can doublecheck that by disabling VBV check in HC (just to doublecheck, don't do that when doing something you are going to use later on).

[totya]

I have a feeling that there is VBV buffer underflows going on, and the encoder needs to re-encode those GOPs where it occurs. You can doublecheck that by disabling VBV check in HC (just to doublecheck, don't do that when doing something you are going to use later on).

Your answer is perfect, thank you!
(Set VBV check is off)

If source is noiseless, and bitrate is very high, this is cause extremly slow working -> default setting is bad.

Suggest in HC application develpoment : if underflow is frquent, try VBV underflow checking is OFF. Example, in settings 2 tab, put new checkbox : vbv underflow check auto off

Thank you!

[Boulder]

If you don't check for VBV underflows, you will run into playback problems if they occur. There is a good reason for the VBV check to be there.

[totya]

If you don't check for VBV underflows, you will run into playback problems if they occur. There is a good reason for the VBV check to be there.

Then HC encoder extremly slow, if source video is noiseless, and bitrate is high... :(

[MrC]

Is there a command line argument for closing all GOPs? I have tried

-CLOSEDGOPS

but it does not work.

:confused::)

Bye
________
buy volcano vaporizer (http://vaporizers.net/volcano-vaporizer)

[Sir Didymus]

The parameter:
*CLOSEDGOPS
is fully supported by HC, but not as a c/l argument. You should place the line above in a suitable initialisation file (HC.ini).

This is fully described in the first pages of the encoder manual...

Cheers
SD

[MrC]

...but not as a c/l argument....

That was my fear... :rolleyes:

:)

Tnx
________
DR400 (http://www.cyclechaos.com/wiki/Suzuki_DR400)

[hank315]

I will add it as a c/l command in the next release.

[MrC]

I will add it as a c/l command in the next release.

:thanks:

Bye
________
YZ250F (http://www.cyclechaos.com/wiki/Yamaha_YZ250F)

[Boulder]

Post your script, also save and post the ini file for the HC encode.

[MrC]

@hank315

Is there the possibility to set HCenc priority level (I mean: idle, low, normal, etc.)? If not may you add this option to next release? As a c/l command too?

Thanks for your great job

:)

Bye
________
herbal store (http://herbalhealthshop.com)

[Boulder]

I think the actual encoder thread is running at idle priority already.

EDIT: yes, it's confirmed here: http://forum.doom9.org/showthread.php?p=992826#post992826

[FredThompson]

Interesting. Try running HC and QuickPAR at the same time. They do NOT play well together.

[MrC]

I think the actual encoder thread is running at idle priority already.

EDIT: yes, it's confirmed here: http://forum.doom9.org/showthread.php?p=992826#post992826

I do not know if single threads are running in idle, but my system (P4@2.4GHz) slows down a lot when HCenc is encoding. By changing (Task Manager) HCenc.exe priority to low, my system survives quite well....

:confused:

Bye
________
starcraft replays (http://screplays.com)

[hank315]

ATM the actual encoding threads are running at a low priority, the main program runs at normal priority.
I just implemented a priority setting in the next release (settings: idle, low, normal, high) which will set the priority for the main program and all threads.
Will be available as a c/l command too.

[Potlood]

I was reading posts about Bitrate Redistribution in the DVD-RB Forum. Would it be possible to include something like that in HCEnc? (plus providing option to choose sample-size and to run an extra encoding pass) Since there is already an OPV option which is used for Bitrate Redistribution calculations. And the new DVD-RB version will get an option to use HC for Bitrate Redistribution even if you want to use another encoder for the other passes. So why not just include it in HCEnc itself?