"HcEnc doesn't do CBR encoding" - what's the nearest thing?

[2Bdecided]

Usually, when encoding home movies, one hour is more than enough for any one to sit through, and the only limit on bitrate is what the various DVD players owned by relatives can cope with. One gets upset with 9Mbps DVD-Rs.

I tried 1-pass VBR, with average 7Mbps and peak 7.5Mbps, thinking that would be fine.

The result was 5.8Mbps average, and there was obvious "twitching" and blocking in various scenes - especially darker scenes, scenes with lower motion etc. Because I'd got deshaker in the AVIsynth script, the "sampling" phase took as along as the "encoding" phase.

Would constant quantiser be a better bet? What shall I try? It seems to pick 7 on average, so maybe 5 with a bitrate cap?


I know this sounds like an idiotic newbie post, but I've played around quite a bit with HcEnc over the years (starting with 0.22), and when it uses 7-8Mbps I've been quite happy with the quality - the problems is making it use 7-8Mbps!

Cheers,
David.

P.S. HcEncGUI 0.25: interlaced, TFF, MPEG matrix, DC 9, 15 AUTOGOP, "PAL", scene detection on, "best", LUMGAIN 0 (probably a very bad choice?)

[smok3]

you can start with quant 3 or 4 and observe how often the bitrate limit kicks in, if it is very often, then just make it 5,6,7,etc.

[manolito]

LUMGAIN 0 (probably a very bad choice?)
If your encode shows problems in darker and static scenes then you should definitely set LUMGAIN to a higher value (at least 2, maybe higher). You should also play with the *AQ parameter. Default is 2, but sometimes it helps to use higher values.

Regarding your question about CBR, have a look here:
http://forum.doom9.org/showthread.php?p=1465032#post1465032
A few posts further down Hank himself tells us that encoding in CBR mode is a very stupid idea...:D


Cheers
manolito

[2Bdecided]

I shall try all the suggestions - thank you.

Regarding your question about CBR, have a look here:
http://forum.doom9.org/showthread.php?p=1465032#post1465032
A few posts further down Hank himself tells us that encoding in CBR mode is a very stupid idea...:D...and two posts further down Mug Funky explains why it's not (sometimes) ;)

Cheers,
David.

[2Bdecided]

you can start with quant 3 or 4 and observe how often the bitrate limit kicks in, if it is very often, then just make it 5,6,7,etc.

Years back, I thought just setting it to 1 and letting it hit the bitrate limit would be good enough, but it didn't work back then (http://forum.doom9.org/showthread.php?t=142416). (you were in that thread too). Maybe 4, 5 etc will work OK now. I'm not entirely sure. I'll try.

I don't mind testing - I do hours of it in AVIsynth - but when I just what to dump less than one hour of video onto a DVD, it seems a simple don't-need-to-test-it-everytime / don't-need-to-analyse-the-video solution should be possible.

Cheers,
David.

[smok3]

wow, you are right, i'am not geting any smarter, hopefully software did :)

[2Bdecided]

Tried CQ 4, max 8Mbps, quality best, CQ_PB 1.00, etc - and got some gridding/blocking pulsing with each GOP on any slightly challenging moments.

Will try to post samples in a couple of weeks.

Any other ideas in the meantime?

Cheers,
David.

[manolito]

2-pass VBR,
Average Bitrate == Max Bitrate
Bias=100

will be the closest to CBR you can get...


Cheers
manolito

[2Bdecided]

Many thanks for your reply manolito. Yes, of course you're right. But the disadvantage there is running a slow AVIsynth script twice, or generating a very large lossless file. Plus either way, HcEnc spends time analysing before encoding which is (at least partly) unnecessary in this instance.

It's not that I'm desperate to have CBR - even if the cap is 7.5Mbps, I don't mind the bitrate dipping to 1Mbps if it doesn't look any worse at that moment. It wouldn't help me with shorter videos, but it wouldn't hurt either if it looked the same. The problem is, it seems the one-pass solutions do reduce the bitrate below the cap in a way that visibly impacts quality. Two pass solutions avoid this problem, but at the cost of time.

I really want to use HcEnc because it offers clearly better quality at a given bitrate than the other free (and a couple of the cheaper pay) solutions I've tried. It's perfect when I need to fit more than ~1 hour onto a DVD, but usually I burn shorter DVDs (who wants to watch home movies for more than an hour? ;) ), and it's a shame encoding these takes so long. I know I should get a faster PC and yet another HDD to make speed and lossless file capacity less of an issue, but some way of making HcEnc do single pass capped VBR without impacting the quality would be great.


FWIW my 8Mbps max disc glitched on my DVD player, while the 7.5Mbps max disc didn't. I've had 9Mbps discs that would barely play at all (on other players), and never had a problem at 7Mbps or below. All DVD-R, various media.

Cheers,
David.

[jclampy]

FWIW my 8Mbps max disc glitched on my DVD player, while the 7.5Mbps max disc didn't. I've had 9Mbps discs that would barely play at all (on other players), and never had a problem at 7Mbps or below. All DVD-R, various media.

What software do you use to author and what software do you use to burn? Also what speed do you burn at? I burn at the slowest selectable speed for less chance of reading problems.

Also make sure all variables are DVD compliant. Even check things like stream settings for the material you are putting on the DVD are the same throughout.

Lastly, run your encoded .m2v with DGIndex 'preview mode' and notice what the final maximum bitrate peak is for video. You might be surprised to find it higher than you would like. If you add that with your audio bitrate you might find the overall total going beyond the DVD spec bitrate limits. Which can cause glitching on playback in standalone players.

[2Bdecided]

Thanks jclampy - I still have the files+discs so will check.

I just used muxman to author and Nero to burn. Fastest speed though (16x on 16x media). Single encode (so no transitions to worry about). This was as basic a DVD as you could get. Normally use DVD architect if menus etc are required, but muxman if not.

Cheers,
David.

[jclampy]

Yep, run them through preview in DGIndex.

Also, I think the recommendation is to not burn faster than 4x for standalone DVD players. I use 2x myself because I got some really old players that still work. ;)

Edit1:
Also I have read that Nero can give problems sometimes, I have read is recommended to use ImgBurn instead. Muxman is suppose to be ok, I didn't have luck with it and so use DVDlab-Pro2 in demo mode. I am still looking for better authoring software but I'll use the 30 day trial for now. I am using Nero to burn some tests at the moment which appear to be going alright but I will probably use ImgBurn for the final burning.

Edit2:
If you are not making/needing a menu then just use DVDlab-Pro2 it has a wizard for creating a DVD with no menu and all you do is drag your video .m2v and audio file into the boxes and it does the rest. It is still possible to set chapter points in this mode. Don't burn with it though, use ImgBurn or Nero to burn the image file or VOB's video folder afterwards.

Edit3:
I think DVDlab-Pro2 might use Muxman internally. DVDLab-Pro2 also will check your input files for DVD compliancy and throw up messages if not. Don't worry about 'Closed GOP' messages as an 'Open GOP' should be fine for chapter creation if you also use 'Scene change detection' when encoding in HCenc.

Edit4:
Lastly, how grainy is your source video? If your video is too grainy you may find that is the cause of exceeding bitrates, if that is the case once you have checked with DGIndex. If so, Are you using any denoisers?
Spatial Smoothers work within indivdual still frames. So although you might look at still frames and say your video looks good, you also have to think about what is happening between frames.
Temporal Smoothers work on the pixel changers that are happening between frames. This can combat 'blocks' from appearing. I recommend FluxSmoothT (The Temporal one) try starting at 6 and raise or lower it as needed. It is fast and is adjustable so not destructive. You need to flick through frames and see if you notice a difference as it doesn't work on still frames in the sense that spatial smoothers do. Look for pixelation in moving frames, heavy pixelation may turn to 'blocks' so try to make it so they don't blatantly stand out should be enough.

[manolito]

but some way of making HcEnc do single pass capped VBR without impacting the quality would be great.
I totally agree, and some time ago I tried a few things in this respect. Since HC does not support a Min_Bitrate parameter, I tried some other parameters to get a higher bitrate at darker and static scenes. This is what I came up with:

1. Use a high bitrate matrix (like Fox), or use the Manono1 matrix which is specifically designed to assign more bitrate to darker and static scenes.

2. Set the *AQ and *LUMGAIN parameters higher than the defaults.

3. Play with the *MINBRFAC paramter. Set it to a value of 2 maybe...
Quote: Originally Posted by manolito
I am curious about the new features. Is the *MINBRFAC command an equivalent to a Min Bitrate parameter? Is raising the value above the default 1.0 recommended to help avoid artifacts in dark scenes?

It manipulates the lower part of the compression curve, so yes higher values will prevent artifacts in dark scenes.


Now do a *CQMAXBITRATE encode with a max bitrate of 8500 or a little lower. Start with a quantizer of maybe 3 and set it to a higher value if the bitrate limiter kicks in too often (like smok3 explained).

FWIW my 8Mbps max disc glitched on my DVD player, while the 7.5Mbps max disc didn't. I've had 9Mbps discs that would barely play at all (on other players), and never had a problem at 7Mbps or below. All DVD-R, various media.
Unfortunately this is not only related to the highest bitrate spikes, but also very much to how the encoder and muxer manage the VBV buffer. In my experience I can safely set the max bitrate in HC to 8500 (using a single 224 kbps audio track). If Muxman has no problem with these streams then the resulting DVD would ALWAYS play on any player I had access to.

So I suspect either a burning issue or a player problem. I use IMGBurn at 8x burning speed, and I never had problems even with cheapo blanks (it probably helps that my Benq burner has WOPC = Walking Optimum Power Calibration).


And finally my recommendation for fast and good quality high bitrate CBR encodes:
Use QuEnc

A long time ago MugFunky published some encoder test results, and IIRC for high bitrates QuEnc was hard to beat. Ever since then I use QuEnc CBR 8000 for such encodes where bitrate is not an issue.



Cheers
manolito

[2Bdecided]

Yep, run them through preview in DGIndex.I'm going to show my ignorance here. Sometimes I remember seeing the bitrate in DGindex, and sometimes I see the box blank. You don't mean I've got to sit and watch the video in Preview, do you?

What is it that determines whether it shows bitrate and bitrate (average) values, or not, when saving a d2v (which is what I normally use it for)?

Can't I use VirtualDub's MPEG statistics, or some other MPEG analyser (I had one on my desktop, but seen to have deleted it - plotted a graph - some options seemed to show bizare results), to check the bitrate?

Cheers,
David.

[2Bdecided]

And finally my recommendation for fast and good quality high bitrate CBR encodes:
Use QuEnc

A long time ago MugFunky published some encoder test results, and IIRC for high bitrates QuEnc was hard to beat. Ever since then I use QuEnc CBR 8000 for such encodes where bitrate is not an issue.I've used that too. My impression was that, with challenging moments, it didn't look quite as good. I'll have to re-test properly.

Cheers,
David.

[jclampy]

I've used that too. My impression was that, with challenging moments, it didn't look quite as good. I'll have to re-test properly.

Cheers,
David.

That is the reason why the 1st pass of 2 pass encoding is so advantageous. I too noticed what you did; QUenc or whatever encoder in 1 pass mode is always going to have the chance of 'hicups' on heavy scene changes. That is why even though I really wanted the speed of 1 pass cbr I just couldn't sacrifice quality and in the end and went with 2 pass vbr HCenc.

Sorry I don't know all the 'ins and outs' with DGIndex. That is just the program I use and yes I would let it preview whole video to get the averages at the end. Note that for testing purposes I only using about 6 minutes of footage.

[Richard1485]

That is the reason why the 1st pass of 2 pass encoding is so advantageous. I too noticed what you did; QUenc or whatever encoder in 1 pass mode is always going to have the chance of 'hicups' on heavy scene changes. That is why even though I really wanted the speed of 1 pass cbr I just couldn't sacrifice quality and in the end and went with 2 pass vbr HCenc.

If you want the speed of one-pass encoding, have you tried using Constant Quantization in HCenc? I use it when I don't care about file size.

If people want CBR and experience hiccups during scene changes, wouldn't using two-pass CBR solve this? QUenc seems capable of two-pass CBR encoding.

[jclampy]

Jeff B, I think with both your options you are also not to worried about quality?

Have you tried 2 pass CBR yourself? A quick search found these two threads from back in the day here:
http://www.trustfm.net/forum/viewtopic.php?f=4&t=20
http://forum.doom9.org/archive/index.php/t-115371.html

CBR since is 'constant bitrate'; ie: the bitrate is suppose to be at constant maximum all the time and not fluctuating would have no use for a second pass.

Ofcourse I know nothing about how QUenc has been programed but I assume the 2 pass encoding was intended for the VBR encoding functionality which QUenc also does.

Anybody know any differently?

[Richard1485]

Jeff B, I think with both your options you are also not to worried about quality?

What is that supposed to mean? For a start, my second "option" was a question. What is it about constant quantization encoding that leads you to suppose that I don't care about quality? I set a quant value that will deliver the quality that I want.

CBR since is 'constant bitrate'; ie: the bitrate is suppose to be at constant maximum all the time and not fluctuating would have no use for a second pass.

Yes; I know what the word "constant" means. There is a theoretical benefit to performing a second pass with CBR, which is why a number of encoders offer it. Whether you can see the difference with your eyes is debatable, but yes I tried it years ago, when I read up on the issue, and thought it offered some improvement.

Try reading these threads:

http://forum.videohelp.com/threads/193806-CBR-vs-2-pass-VBR-comparison-%28really-3%29
http://forum.videohelp.com/threads/148236-What-is-the-difference-between-CBR-1-PASS-and-CBR-2-PASS

[jclampy]

Hmm, I will have to try some tests myself and see what happens. Last time I looked at QUenc with 1 pass CBR I noticed it was doing something a bit weird, I'll retest before elaborating.

Edit1:
This thread has some interesting points on the debate of 1pass CBR and 2pass CBR;
http://forum.videohelp.com/threads/111604-2-pass-CBR-in-CCE-Basic-better-than-CBR-in-TMPGEnc

I am testing QUenc at the moment. 1 Pass CBR in QUenc seems slower (maybe 50% less fps?) than 1 Pass VBR in HCenc. 2 pass CBR in QUenc will then be doubling that slowness.

Still, will post results once it finishes. I'll have to keep track of the time when I run 2pass CBR as it doesn't keep a running total of encoding time.

Edit2:
Actually even though the reported fps of encoding was about 50% of HCenc, when I timed a QUenc 2pass CBR encode it actually took the same amount of time as HCenc 2pass VBR encode. So it takes the same amount of time.

Will comment on the quality soon. QUenc doesn't spit out a .log file.

Edit3:
Ok, put a 1pass CBR and a 2pass CBR test encode through DGIndex 'preview' and noticed that the 1pass CBR had overshot the maximum bitrate by 151kb/s while the 2pass CBR encode had no overshoot at all.

Just trying to ascertain any macroblocking or artifacting now.

Edit4:
Forget it, 2pass CBR mode turned out like crap!
Macroblocking was about 10 times worse than 1pass CBR mode.

QUenc 1pass CBR = Noticeable Macroblocking on high speed movement or scene changes.
QUenc 2pass CBR = Actually turned out about 10x worse than 1pass CBR, way too many frames with Macroblocking.
HCenc 2pass VBR = No Macroblocking in my testing.

Here are my QUenc settings for reference;
8000 bitrate
High Quality ticked
Use Trellis Quant ticked
2 pass encoding ticked
"Extreme & slow" Settings UNTICKED
12 GOP Size
2 Max B-Frames
Force Closed GOP UNTICKED
Scene Detection ticked
10 DC Precision
8000 Max bitrate
Process Priority Normal
Matrix I used the New Fox one.
Any other settings, if I didn't mention it then I didn't use it.

Video test was PAL 6 minutes 4:3 progressive 352x576 footage from uncompressed Analog source cleaned up via Avisynth script.
QUenc was latest version 0.75 Alpha included with AVStoDVD version 2.42

[2Bdecided]

Sorry I don't know all the 'ins and outs' with DGIndex. That is just the program I use and yes I would let it preview whole video to get the averages at the end.Hang on a second - I'm not too worried if the average is a little high, and VirtualDub will report this without playing it. One possible concern is occasional unwanted peaks (or buffer overflows), and DGindex won't show me this at the end. It won't even show the highest peak. I'm hoping HCenc is already verifying the buffer. Is there other software that will do?


Given your verification that QUenc doesn't look as good, this brings me back to wishing that HCEnc 1-pass VBR didn't throttle the bitrate (and the quality) so much.

Cheers,
David.

[manolito]

@jclampy

Here are my QUenc settings for reference;
8000 bitrate
High Quality ticked
Use Trellis Quant ticked
2 pass encoding ticked
"Extreme & slow" Settings UNTICKED
12 GOP Size
2 Max B-Frames
Force Closed GOP UNTICKED
Scene Detection ticked
10 DC Precision
8000 Max bitrate
Process Priority Normal
Matrix I used the New Fox one.
Any other settings, if I didn't mention it then I didn't use it.

Video test was PAL 6 minutes 4:3 progressive 352x576 footage from uncompressed Analog source cleaned up via Avisynth script.
QUenc was latest version 0.75 Alpha included with AVStoDVD version 2.42

With your settings you actually are NOT using Trellis, you are using Multithreading instead. And Multithreading in HQ mode is broken in the latest Quenc 0.75 Alpha2. So your test is a little unfair towards QuEnc.

Have a look:

Only HQ with multi-threading enabled isn't OK, skipping of MBs in P and B frames doesn't work correct.
Taken from this post:
http://forum.doom9.org/showthread.php?p=1084767#post1084767

Could you repeat your test using QuEnc 0.72?
In this case please untick Trellis (there have been many reports that it actually decreases quality).


Cheers
manolito

[jclampy]

@jclampy



With your settings you actually are NOT using Trellis, you are using Multithreading instead. And Multithreading in HQ mode is broken in the latest Quenc 0.75 Alpha2. So your test is a little unfair towards QuEnc.

Have a look:


Taken from this post:
http://forum.doom9.org/showthread.php?p=1084767#post1084767

Could you repeat your test using QuEnc 0.72?
In this case please untick Trellis (there have been many reports that it actually decreases quality).


Cheers
manolito

Oh, sorry I deleted my source file this morning. A couple of days ago I was thinking of trying a few different ideas with QUenc to make sure the matrix I was using wasn't causing problems. I was so happy with my results from HCenc that I forgot all about it.

Interesting points you have brought up. Ok, please take my result with a grain of salt as I can't test it further at this time. I hope to have another encoding project in the next couple of weeks or month and will try to revisit QUenc then.

I would just like to add that my source was quite hard on encoders too, dark footage with bright lights flashing and also fast camera movements with panning and zooming, etc... On more neutral footage I think QUenc might have an easier job, especially if you are using CBR.

[jclampy]

Hang on a second - I'm not too worried if the average is a little high, and VirtualDub will report this without playing it. One possible concern is occasional unwanted peaks (or buffer overflows), and DGindex won't show me this at the end. It won't even show the highest peak. I'm hoping HCenc is already verifying the buffer. Is there other software that will do?


Given your verification that QUenc doesn't look as good, this brings me back to wishing that HCEnc 1-pass VBR didn't throttle the bitrate (and the quality) so much.

Cheers,
David.

Hmm, I thought DGIndex did show the highest peaks because the maximum bitrate number was always higher than what was in the HCenc logs. Not sure about where 'buffer overflows' is logged, is that the buffer bar that can be toggled visible in the HCenc window while it is encoding? Not sure if that info is logged or not and whether it is connected with the maximum bitrate overshooting or if when the average bitrate gets 'adjusted'?

In regards to Quenc, as posted just above in my reply to Manolito, I would like to try a few more things out with Quenc in the future. Maybe if you get a chance you could try some small tests of 5 minutes footage and see how it goes?

Anyway, please tell us how you get on or what you end up going with because is very interesting. Thanks.