HCenc 0.28 - Page 2

ChiDragon · 4th August 2015, 04:23

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 the same oddity with 0.25.

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

hank315 · 16th August 2015, 21:07

Some minor GUI bugs are fixed, including this one.

Can be downloaded here.

Sparktank · 16th August 2015, 22:30

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

Precomposed · 19th August 2015, 21:27

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 · 20th August 2015, 00:04

Hi Jon,

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

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:

Quote:

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 · 20th August 2015, 00:32

Quote:

Originally Posted by manolito

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?

Quote:

Originally Posted by manolito

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 · 20th August 2015, 01:34

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 · 20th August 2015, 02:11

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 · 20th August 2015, 02:27

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 · 11th November 2015, 12:54

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:

Emulgator · 12th November 2015, 19:24

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 · 12th November 2015, 23:42

Quote:

Originally Posted by Emulgator

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:

Code:

 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:

Code:

 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 · 15th November 2015, 08:54

Quote:

Originally Posted by hank315

Some minor GUI bugs are fixed, including this one.

Can be downloaded here.

Thank you! I forgot to say it back in August.

hank315 · 22nd November 2015, 17:11

@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

filler56789 · 22nd December 2015, 12:49

Quote:

Originally Posted by hank315

EDIT:
This issue should be solved now.

Can be downloaded here

Many thanks for the new build

manolito · 22nd December 2015, 14:33

Quote:

Originally Posted by filler56789

Many thanks for the new build

+1
What a nice Xmas present...

manolito · 5th January 2016, 00:10

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 · 5th January 2016, 20:16

Quote:

Originally Posted by manolito

The original post of this user with his logs (contains the HC.ini) can be found here:
http://forum.videohelp.com/threads/2...=1#post2426363

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

manolito · 5th January 2016, 21:55

@ 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 · 5th January 2016, 23:18

Quote:

Originally Posted by manolito

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.

16th August 2015, 21:07	#22 \| Link
hank315 HCenc author Join Date: Nov 2003 Location: Netherlands Posts: 570	Some minor GUI bugs are fixed, including this one. Can be downloaded here. __________________ HCenc at: http://hank315.nl

16th August 2015, 22:30	#23 \| Link
Sparktank 47.952fps@71.928Hz Join Date: Mar 2011 Posts: 940	Great stuff! Thanks for another update. I'd hate to see the day this ends. __________________ Win10 (x64) build 19041 NVIDIA GeForce GTX 1060 3GB (GP106) 3071MB/GDDR5 \| (r435_95-4) NTSC \| DVD: R1 \| BD: A AMD Ryzen 5 2600 @3.4GHz (6c/12th, I'm on AVX2 now!)

19th August 2015, 21:27	#24 \| Link
Precomposed Registered User Join Date: Jan 2011 Location: Southern California Posts: 13	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? __________________ Jon Geddes

20th August 2015, 02:11	#28 \| Link
Sparktank 47.952fps@71.928Hz Join Date: Mar 2011 Posts: 940	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. __________________ Win10 (x64) build 19041 NVIDIA GeForce GTX 1060 3GB (GP106) 3071MB/GDDR5 \| (r435_95-4) NTSC \| DVD: R1 \| BD: A AMD Ryzen 5 2600 @3.4GHz (6c/12th, I'm on AVX2 now!)

11th November 2015, 12:54	#30 \| Link
LogicDeLuxe Registered User Join Date: Nov 2004 Posts: 106	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: __________________ AMD Ryzen 5, 16 GM RAM, Nvidia GTX 1060, Linux Mint

4th August 2015, 04:23	#21 \| Link
ChiDragon Registered User Join Date: Sep 2005 Location: Vancouver Posts: 600	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 the same oddity with 0.25. I created a short video showing this easily-repeatable nuisance: https://youtu.be/3x64gG5VmWU

20th August 2015, 01:34	#27 \| Link
Precomposed Registered User Join Date: Jan 2011 Location: Southern California Posts: 13	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.

20th August 2015, 02:27	#29 \| Link
manolito Registered User Join Date: Sep 2003 Location: Berlin, Germany Posts: 3,079	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

12th November 2015, 19:24	#31 \| Link
Emulgator Big Bit Savings Now ! Join Date: Feb 2007 Location: close to the wall Posts: 1,545	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 ? __________________ "To bypass shortcuts and find suffering...is called QUALity" (Die toten Augen von Friedrichshain) "Data reduction ? Yep, Sir. We're that issue working on. Synce invntoin uf lingöage..."

22nd November 2015, 17:11	#34 \| Link
hank315 HCenc author Join Date: Nov 2003 Location: Netherlands Posts: 570	@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 __________________ HCenc at: http://hank315.nl Last edited by hank315; 21st December 2015 at 22:36. Reason: issue solved

5th January 2016, 00:10	#37 \| Link
manolito Registered User Join Date: Sep 2003 Location: Berlin, Germany Posts: 3,079	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 Last edited by manolito; 5th January 2016 at 21:53.

5th January 2016, 21:55	#39 \| Link
manolito Registered User Join Date: Sep 2003 Location: Berlin, Germany Posts: 3,079	@ 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 Last edited by manolito; 6th January 2016 at 00:33.