HCenc 027

[hank315]

After a long time an update:

HCenc 0.27 beta - release date 21-10-2013 (http://hank315.nl/files/HC_027/HC027_beta_21-10-2013.zip)

- support for YV16 (4:2:2) and YV24 (4:4:4) colorspace
- lossless intermediate mode implemented for all colorspaces
- Avisynth script written in logfile
- some more bugs solved

For colorspace YV16 and YV24 Avisynth 2.6 is needed, Avisynth 2.5 doesn't recognize YV16/YV24 colorspace.
HCenc doesn't upsample chroma so for 4:4:4 output you need YV24 input.
HCenc can subsample chroma, so for instance YV24 input can be subsampled to 4:2:0 output, using progressive or interlaced subsampling.
Of course you can also use the upsampling/subsampling functions of Avisynth 2.6.

[Guest]

Sweet! Thank you, Hank.

Questions: are the GUI and encoder combined in one EXE now? All I see in your ZIP is the single EXE. And what about the matrices, the DGDecode stuff, etc.?

[manolito]

Taken from the "Notes" section for 0.27 beta:

- only encoder, still working on the GUI

Looks like you need to use the GUI and all the other extras from the previous version...


@Hank
Thanks very much for the new version...:)

Could you elaborate a little on this:
- some more bugs solved

Since I have no use for the new colorspace features I'd like to know if I should upgrade from version 0.26.



Cheers
manolito

[hank315]

It's the encoder only, still working on the GUI.
So the HC.ini must be edited by hand but I hope to finish the complete package soon.
For now I will add the DGdecode.dll to the zip-file.

If you don't need the new colorspaces then there's no real need for this new beta version.
About the bugs, two come to mind:
- lossless intermediate mode is fixed for YUY2 input
- small error in the calculation of the Macro Block variance (used for adaptive quantization decision) fixed
and some more I already forgot.

[Sparktank]

:thanks: For "Avisynth script written in logfile".
Millions of small test samples will definitely come in handy now.

[hank315]

HC027 updated, now also includes GUI.

[filler56789]

HC027 updated, now also includes GUI.

:thanks:

[Sharc]

Thank you hank315! :)

[qyot27]

0.27 is exhibiting an error involving FFMS2 and AviSynth 2.6. The script is being detected as 4:4:4 even though the video file being served in is 4:2:0, and I'm not doing any colorspace conversions at all (I even went so far as to append ConvertToYV12 to the end of the script, and it still registered as 4:4:4). Converting the input to AVI first and running it through AVISource instead allows 0.27 to work as expected.

Initially I encountered the problem on our iMac (with a Sandy Bridge i5) running everything under Wine, but the window closed too quickly to see the error. Testing it on my old Pentium III I could see the 4:4:4 issue. Seen with AviSynth 2.6 MT 2013.03.09 and 2013.09.28, AviSynth 2.6a5, and AviSynth+ 2013.10.16.

[Fishman0919]

@hank315

Thank You kind Sir!

[Darksoul71]

HC027 updated, now also includes GUI.

:thanks: :thanks: :thanks:

[hank315]

@qyot27

I can replicate it, investigating...

[hank315]

Next findings using avisynth 2.6 alpha 5 and FFMS2 2.19

...
*Chroma_info = 0;
if (clip->GetVideoInfo().IsYV12()) *Chroma_info = 1;
if (clip->GetVideoInfo().IsYUY2()) *Chroma_info = 2;
if (clip->GetVideoInfo().IsYV16()) *Chroma_info = 3;
if (clip->GetVideoInfo().IsYV24()) *Chroma_info = 4;
return 0;
is part of the HCenc code.
return(0) means the function returns without errors, *Chroma_info is a function argument.

I never used FFMS2 before so I know nothing about it.
FFMS2 with YV12 (4:2:0) source returns the next values:
clip->GetVideoInfo().IsYV12() = TRUE
clip->GetVideoInfo().IsYUY2() = FALSE
clip->GetVideoInfo().IsYV16() = TRUE
clip->GetVideoInfo().IsYV24() = TRUE

*Chroma_info = 4 is set, so HCenc thinks the source is 4:4:4 and will crash.
Perhaps the FFMS2 developers can shed some light on this.

[Groucho2004]

FFMS2 with YV12 (4:2:0) source returns the next values:
clip->GetVideoInfo().IsYV12() = TRUE
clip->GetVideoInfo().IsYUY2() = FALSE
clip->GetVideoInfo().IsYV16() = TRUE
clip->GetVideoInfo().IsYV24() = TRUE
Just tried this with a little test program and I get FALSE for both YV16 and YV24.
Maybe IanB can help out with this.

[IanB]

How are you handling the AVS_linkage pointer?

Applications loading Avisynth.dll as a library need to set the AVS_linkage pointer as the very next thing after getting the IScriptEnvironment from CreateScriptEnvironment with env->GetAVSLinkage().



Also a more future proof style might be to use vi.IsPlanar with vi.GetPlaneWidthSubsampling and vi.GetPlaneHeightSubsampling. The current version only allows YV12, YV16, YV24 and YV411 but the hope is to allow arbitrary H and V chroma subsampling.

[Groucho2004]

In case you're interested, here is some sample code using the new API that has been working well for me:
#include <windows.h>
#include <wintrust.h>
#include <imagehlp.h>
#include <string>
#include "avisynth26.h"

BOOL AvisynthExportsAVSLinkage();
const AVS_Linkage *AVS_linkage = 0;

int main(int argc, char* argv[])
{
//Check if avisynth exports "AVS_Linkage" to make sure at least Avisynth 2.6 Alpha 4 is used
if (!AvisynthExportsAVSLinkage())
{
printf("\nAvisynth 2.6 (Alpha 4 and above) is required.\n");
return -1;
}

HINSTANCE hDLL = ::LoadLibrary("avisynth");
if (!hDLL)
{
cs_avserror = "Failed to load avisynth.dll";
return -1;
}

try
{
IScriptEnvironment *(__stdcall *CreateEnvironment)(int) = (IScriptEnvironment *(__stdcall *)(int))::GetProcAddress(hDLL, "CreateScriptEnvironment");
if (!CreateEnvironment)
{
printf("\nFailed to load CreateScriptEnvironment()\n");
::FreeLibrary(hDLL);
return -1;
}

IScriptEnvironment *AVS_env = CreateEnvironment(AVISYNTH_INTERFACE_VERSION);
if (!AVS_env)
{
printf("\nCould not create IScriptenvironment\n");
::FreeLibrary(hDLL);
return -1;
}

AVS_linkage = AVS_env->GetAVSLinkage();

AVSValue AVS_main;
AVS_main = AVS_env->Invoke("Import", argv[1]);

if (!AVS_main.IsClip()) //not a clip
AVS_env->ThrowError("Script did not return a video clip:\n(%s)", argv[1]);

PClip AVS_clip;
PVideoFrame AVS_frame;
VideoInfo AVS_vidinfo;

AVS_clip = AVS_main.AsClip();
AVS_vidinfo = AVS_clip->GetVideoInfo();
unsigned int uiFrames = (unsigned int)AVS_vidinfo.num_frames;

//read frames
for (unsigned int n = 0; n < uiFrames; n++)
{
AVS_frame = AVS_clip->GetFrame(n, AVS_env);
//...
//...
}

AVS_frame = 0;
AVS_clip = 0;
AVS_main = 0;
AVS_env->DeleteScriptEnvironment();
}
catch(AvisynthError err)
{
//...
}

AVS_linkage = 0;
::FreeLibrary(hDLL);

return 0;
}


BOOL AvisynthExportsAVSLinkage()
{
BOOL bRet = FALSE;

LOADED_IMAGE li;
BOOL bLoaded = MapAndLoad("avisynth", NULL, &li, TRUE, TRUE);
if (!bLoaded)
return bRet;

DWORD expVA = li.FileHeader->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress;
PIMAGE_EXPORT_DIRECTORY pExp = (PIMAGE_EXPORT_DIRECTORY)ImageRvaToVa(li.FileHeader, li.MappedAddress, expVA, NULL);

DWORD rvaNames = pExp->AddressOfNames;
DWORD *prvaNames = (DWORD*)ImageRvaToVa(li.FileHeader, li.MappedAddress, rvaNames, NULL);
string sName = "";
int iPos = 0;

for (DWORD i = 0; i < pExp->NumberOfNames; ++i)
{
DWORD rvaName = prvaNames[i];
sName = (char *)ImageRvaToVa(li.FileHeader, li.MappedAddress, rvaName, NULL);
iPos = (int)sName.find("AVS_Linkage");
if (iPos >= 0)
{
bRet = TRUE;
break;
}
}

UnMapAndLoad(&li);

return bRet;
}

[manolito]

Since I still use AviSynth version 2.57 which does not support these new colorspaces I (falsely) assumed that I was safe from this 4:4:4 error.

Obviously I was wrong. When I try to convert some file using either ffms2 2.17 or 2.19 (plain vanilla 32bit), HC crashes with this 4:4:4 error. Strange...


Cheers
manolito

[Taurus]

Same here...Crash

ffms2 2.16, 2.17 or 2.19 on standard AviSynth version 2.58.
No MT, 32bit.

The same scripts are working reliable on HCenc 025/026.

[hank315]

Thanks for comments and advice.
A new package is uploaded but for now without the support of YV16 and YV24.
I hope to add YV16 and YV24 soon but then working properly.

@Groucho2004
Thanks, that code certainly helps.

[IanB]

An easier way to check for AvisynthExportsAVSLinkage instead of parsing the .dll export table would be just to do a ::GetProcAddress(hDLL, "AVS_Linkage"). The value returned is the address of the linkage table, but it's probably not a good idea to rely on this behaviour, instead use the "not found" error for detecting incompatible versions.

Seems I need to bump the interface version to 6 to avoid the confusion at present when I freeze the API design for release candidates.

[Groucho2004]

instead use the "not found" error for detecting incompatible versions.
I tried all kinds of things (FunctionExists, ::NotFound) through the Avisynth interface to detect the correct version but it either did not work or it crashed. Could you elaborate?

[DVB-Freak]

Hallo Hank,

I think,something going wrong with the new GUI. When I started the
GUI, Ican't select the avs-script. Nothing happens when I click on
"input file name". The Info-Box says "HC.ini successfully processed,
ERROR, invalid D2V project, can't find the VOB/MPEG files, Warning,
input file not found".

Can you reproduce the error?

[filler56789]

Suggestion (or feature request): please add a checkbox for disabling the warnings about "DVD-video compliance". In many cases, complying with the MPEG-2 specifications is more than sufficient. :) Example: I open a 512x288@25fps AVS, and I receive the message:

WARNING: resolution/frame rate mismatch

:rolleyes:

[IanB]

I tried all kinds of things (FunctionExists, ::NotFound) through the Avisynth interface to detect the correct version but it either did not work or it crashed. Could you elaborate?
Something a bit like this :- AVS_Linkage *tmp_linkage = (AVS_Linkage *)::GetProcAddress(hDLL, "AVS_Linkage");
if (!tmp_linkage)
{
printf("\nAvisynth 2.6 (Alpha 4 and above) is required.\n");
::FreeLibrary(hDLL);
return -1;
}
But as I said, probably bumping the API rev to 6 would clear the confusion.

[Groucho2004]

Something a bit like this :- AVS_Linkage *tmp_linkage = (AVS_Linkage *)::GetProcAddress(hDLL, "AVS_Linkage");
if (!tmp_linkage)
{
printf("\nAvisynth 2.6 (Alpha 4 and above) is required.\n");
::FreeLibrary(hDLL);
return -1;
}
I'm confused. You wrote instead (of your suggestion above with GetProcAddress()) use not found error. It's the "not found error" I would have liked some more info on.

But as I said, probably bumping the API rev to 6 would clear the confusion.
Yes, seems like a good idea.

[IanB]

GetProcAddress returns NULL for symbol not found.

This is nothing to do with IScriptEnvironment::NotFound, sorry for any confusion.

[Groucho2004]

GetProcAddress returns NULL for symbol not found.

This is nothing to do with IScriptEnvironment::NotFound, sorry for any confusion.
Confusion gone, thanks. :)

[Chumbo]

I've been using 025 for a long time now and just saw this and decided to grab it. I'm running on Windows 7 Ultimate 64 bit. The GUI loads fine initially, but as soon as I attempt to load an AVS file or to load an .ini file, the app crashes. I tried running it as administrator to no avail. I found this info in the event viewer if it'll help.
Faulting application name: HCgui_027.exe, version: 0.27.0.0, time stamp: 0x52685f97
Faulting module name: comdlg32.dll, version: 6.1.7601.17514, time stamp: 0x4ce7b82d
Exception code: 0xc0000005
Fault offset: 0x0003a056
Faulting process id: 0x1d6c
Faulting application start time: 0x01ced7e0720cd2ba
Faulting application path: E:\HC\HCgui_027.exe
Faulting module path: C:\Windows\syswow64\comdlg32.dll
Report Id: b48d759c-43d3-11e3-8357-00158315a310

[manolito]

This seems to fall under the "Several other bugs fixed" category...

I just noticed that the flagging of the output files has changed when using auto interlaced mode with the latest Beta release 26-10-2013. In earlier versions the progressive flag changed according to HCenc's decision if this frame was progressive or interlaced. When playing the file in DGIndex the changing flags showed up, so it was easy to see which decision HCenc had made.

In the latest beta the progressive flag is never set when using auto interlaced mode, even for fully progressive sources.

Question: Does this only relate to the flagging, or is the whole encoding done in interlaced mode whenever auto interlace is used?

In short: Feature or Bug? :eek:


Cheers
manolito

[Chumbo]

I've been using 025 for a long time now and just saw this and decided to grab it. I'm running on Windows 7 Ultimate 64 bit. The GUI loads fine initially, but as soon as I attempt to load an AVS file or to load an .ini file, the app crashes. I tried running it as administrator to no avail. I found this info in the event viewer if it'll help.
Faulting application name: HCgui_027.exe, version: 0.27.0.0, time stamp: 0x52685f97
Faulting module name: comdlg32.dll, version: 6.1.7601.17514, time stamp: 0x4ce7b82d
Exception code: 0xc0000005
Fault offset: 0x0003a056
Faulting process id: 0x1d6c
Faulting application start time: 0x01ced7e0720cd2ba
Faulting application path: E:\HC\HCgui_027.exe
Faulting module path: C:\Windows\syswow64\comdlg32.dll
Report Id: b48d759c-43d3-11e3-8357-00158315a310
I just updated HC on my Windows 8 Pro 64-bit laptop and the same thing happens. Below is the event viewer info from the Win8 crash.Faulting application name: HCgui_027.exe, version: 0.27.0.0, time stamp: 0x52685f97
Faulting module name: comdlg32.dll, version: 6.3.9600.16384, time stamp: 0x52158016
Exception code: 0xc000041d
Fault offset: 0x00038d8e
Faulting process id: 0x1434
Faulting application start time: 0x01cedd59a7a6f031
Faulting application path: D:\Apps and Utilities\hc\HC027\HCgui_027.exe
Faulting module path: C:\WINDOWS\SYSTEM32\comdlg32.dll
Report Id: e8b5126a-494c-11e3-beac-88532e4f15a9
Faulting package full name:
Faulting package-relative application ID:
I can run the command-line executable just fine on both Win7 and Win8 but I have to create the INI manually for now.

[manolito]

In the latest beta the progressive flag is never set when using auto interlaced mode, even for fully progressive sources.

Question: Does this only relate to the flagging, or is the whole encoding done in interlaced mode whenever auto interlace is used?

In short: Feature or Bug? :eek:manolito


I found a partial answer to my question myself:
In Auto-Interlaced mode not only the progressive flag is never set, also the whole encode is done using the alternate scan method. At least this is what ReStream tells me. This applies to fully progressive sources.

I have no idea if Interlaced DCT and Interlaced Motion Estimation are also used since I do not know any way to find out about this. But it seems clear that with the current Beta the Auto-Interlaced Mode should not be used for progressive sources. It does not introduce terrible artifacts, but encoding a progressive source in interlaced mode is certainly not the most efficient way to do it...

Back to 0.26 for now...:rolleyes:


Cheers
manolito

[Chumbo]

Hank,
Any resolution coming to the UI crash? Thank you.

[hank315]

Yes, HC027 will temporary be withdrawn, too much bugs which I can't solve in a short time.
Also there's a problem using Avisynth 2.6 due to GPL issues.
So for now it's back to (stable) HC026 beta.

[Chumbo]

Thanks for the update Hank.

[qyot27]

A feature request: would it be possible to add support for pipes as input? Preferably in yuv4mpeg format.

The reason is, it's possible to use HCenc under Wine on Linux and OSX. But this requires the user to also have AviSynth installed under Wine, along with all the stuff needed to make sure AviSynth works.

If HCenc supports input from a y4m pipe, then it should be possible to use AvxSynth (or AviSynth+, after it makes the cross-platform leap) with a native build of FFmpeg, and then pipe the output of the script to HCenc running under Wine without having to mess with installing a bunch of other stuff under Wine. I'm suggesting y4m precisely because it preserves the fps/colorspace/resolution info. The upside is that the first part could take advantage of 64-bit (this would even be true on Windows, since AviSynth+ supports 64-bit now), even if HCenc itself doesn't.

[elmarikon]

Cheers!

As I see it, HCenc is still the best mpeg2 encoder available.
But I have some issues with it:

HD (1920x1080) 4:2:2 or 4:4:4 does not work at all.
The encoder comes up, shows the parameters and crashes.
I tries Version 0.25, 0.26, 0.27... All the same...

And

It would really be great to have stdin/out for the encoder so I can include it more easy in my batch files, letting ffmpeg do the decoding / filtering...


It would be great if you could find the time to look into these issues or maybe give me a workaround...


Thanx again for your great work!!


SwK

[Groucho2004]

Cheers!

As I see it, HCenc is still the best mpeg2 encoder available.
But I have some issues with it:

HD (1920x1080) 4:2:2 or 4:4:4 does not work at all.
The encoder comes up, shows the parameters and crashes.
I tries Version 0.25, 0.26, 0.27... All the same...

And

It would really be great to have stdin/out for the encoder so I can include it more easy in my batch files, letting ffmpeg do the decoding / filtering...


It would be great if you could find the time to look into these issues or maybe give me a workaround...


Thanx again for your great work!!


SwK
Way too little information.
- What Avisynth version and decoder do you use?
- Post a sample of the stream that gives trouble
- Post your script
- Elaborate on "crashes", no error message?
- Does the script run when you load it in VirtualDub?

I could probably think of some more missing info but this should suffice for now. :D

[elmarikon]

Way too little information.
-->just enough...
You will see, there is nothing special, and I allready tried many different possibilities.

- What Avisynth version and decoder do you use?
I tried several ones. 2.5.8 / MT, 2.6 / MT
All the same result.

- Post a sample of the stream that gives trouble
Several streams, I tried mpeg2source, QTSource, RawSoure, FFmpegSource


- Post your script
InputVideo and nothing else.... Maybe AssumeFPS(25)


- Elaborate on "crashes", no error message?
no message, just crashes.


- Does the script run when you load it in VirtualDub?
I don't use VDub, but it works in AVSPmod, FFmpeg, FFplay, MainConcept Encoder, Carbon Coder... And as I said, also in the preview window of the HC gui.





So as I was trying to say, the Script is okay. I tried to keep it as simple as possible.
I also tried on different computers... Same same...
In the gui I can see the preview, but before even writing the first frame to the HDD, HCenc crashes.
If I add ConvertToYV12 the encode starts, but obviously in 4:2:0. But I do need 4:2:2.
4:4:4 sources give me the same result.

[elmarikon]

Cheers again!

I just found the issue I am facing, trying to encode HD 4:2:2/4:4:4 files.

The problem seems to be that internally the encoder is working only with resolutions dividable by 16.
Since 1080 is not a multiple of 16, it crashes.
Funny enough, because when I input a SD file with a non base-16-resolution it gives an error. Not in my case though...

--> So I can encode files with a res. of 1920x1088, but not 1920x1080.


Is there any way to tweak this behavior, so I can encode my HD files?!


PS. Still stdin/out would also be a huuuuuuuuuge help for my purposes...



All the best again from HHamburg!!

[Groucho2004]

So I can encode files with a res. of 1920x1088, but not 1920x1080.
I can confirm that, just tried it myself. Looks like you found a bug. I'm sure hank315 will drop by soon and take care of it.

[hank315]

Yes, I can replicate the crash with 1920x1080 YUY2 input, it's a bug.
There will be an update soon.

[elmarikon]

Great, thanx!


Do you also consider implementing stdin/out?
Especially stdin would be very helpful, since avisynth tends to cause speedloss...

All the best from HHamburg!

[Groucho2004]

visynth tends to cause speedloss...
I find MPEG decoding very fast with Avisynth, there shouldn't be any bottleneck. How about posting the script that you think causes a slowdown.
Good decoders would include:
- DGDecodeNV (NVIDIA GPU decoding, very fast with modern graphic cards)
- DGDecode
- LWLibavVideoSource

[elmarikon]

I am not talking about a special script, but the outdated framework of avisynth itself...

Well, yes, decoding mpeg is kind of okay, but still a lot slower then with ffmpeg.
Plus, you have to create the index file...

But in most cases I am coming from ProRes, H264, uncompressed sources.
That does slow things down heavily!

(DGindexNV is closed source and pay-ware, so I am out.)



all the best!

[filler56789]

avisynth tends to cause speedloss...

Are you sure that there isn't something in your setup that is interfering negatively with Avisynth? :confused:

I can be wrong, but it seems you are the first one to complain about Avisynth's "sluggishness" w/ HCenc...

[Groucho2004]

Well, yes, decoding mpeg is kind of okay, but still a lot slower then with ffmpeg.
I was under the impression that LSMASH, FFMS2 and FFMPEG all use the same code from libav...

[qyot27]

I was under the impression that LSMASH, FFMS2 and FFMPEG all use the same code from libav...
They do. The primary difference is that the source filters for AviSynth don't necessarily multithread by default. And that only applies for computers that can multithread.

I decided to do a little test of my own:
F:\>ffmsindex -t -1 theinterview-tlr2_h1080p.mov
Writing index... done... 100%

F:\>echo FFmpegSource2("theinterview-tlr2_h1080p.mov",atrack=-1)>testavs.avs

F:\>avsmeter testavs.avs

AVSMeter 1.8.2 (x86) by Groucho2004
AviSynth+ 0.1 (r1704, x86) (MT)

Number of frames: 3676
Length (hhh:mm:ss.ms): 000:02:33.320
Frame width: 1920
Frame height: 816
Framerate: 23.976 (24000/1001)
Colorspace: YV12

Frames processed: 3676 (0 - 3675)
FPS (min | max | average): 4.269 | 92.13 | 8.850
CPU usage (average): 94%
Thread count: 5
Physical Memory usage (peak): 69 MB
Virtual Memory usage (peak): 92 MB
Time (elapsed): 000:06:55.370

F:\>ffmpeg -benchmark -i theinterview-tlr2_h1080p.mov -f null -
ffmpeg version r66361 git-bb8de55 Copyright (c) 2000-2014 the FFmpeg developers
built on Sep 19 2014 17:19:21 with gcc 4.9.1 (GCC)
configuration: --prefix=/home/qyot27/win32_build --cross-prefix=i686-w64-mingw32- --enable-gpl --enable-version3 --dis
able-w32threads --enable-avresample --disable-doc --disable-debug --enable-fontconfig --enable-libfreetype --enable-libf
ribidi --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-openal --enable-op
engl --enable-libquvi --enable-librtmp --enable-libsoxr --enable-libvidstab --enable-libflite --enable-libgme --enable-l
ibgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libnut --enable-libopencore-amrnb --enable-libop
encore-amrwb --enable-libopenjpeg --enable-libopus --enable-libschroedinger --enable-libshine --enable-libspeex --enable
-libtheora --enable-libtwolame --enable-libutvideo --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --en
able-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --e
nable-avisynth --cpu=pentium3 --extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB -DCA
CA_STATIC -DMODPLUG_STATIC' --extra-ldflags='-mconsole -Wl,--allow-multiple-definition' --target-os=mingw32 --arch=x86 -
-pkg-config-flags=--static
libavutil 54. 7.100 / 54. 7.100
libavcodec 56. 1.101 / 56. 1.101
libavformat 56. 4.102 / 56. 4.102
libavdevice 56. 0.100 / 56. 0.100
libavfilter 5. 1.101 / 5. 1.101
libavresample 2. 1. 0 / 2. 1. 0
libswscale 3. 0.100 / 3. 0.100
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 0.100 / 53. 0.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'theinterview-tlr2_h1080p.mov':
Metadata:
major_brand : qt
minor_version : 537199360
compatible_brands: qt
creation_time : 2014-09-25 14:50:45
timecode : 01:00:00:23
Duration: 00:02:33.32, start: 0.000000, bitrate: 9430 kb/s
Stream #0:0(eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x816, 9302 kb/s, 23.98 fps, 23.98
tbr, 24k tbn, 48k tbc (default)
Metadata:
creation_time : 2014-09-25 14:50:45
handler_name : Apple Video Media Handler
encoder : H.264
Stream #0:1(eng): Data: none (tmcd / 0x64636D74), 0 kb/s (default)
Metadata:
creation_time : 2014-09-25 14:50:45
handler_name : Time Code Media Handler
timecode : 01:00:00:23
Stream #0:2(eng): Audio: aac (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 122 kb/s (default)
Metadata:
creation_time : 2014-09-25 14:50:45
handler_name : Apple Sound Media Handler
Output #0, null, to 'pipe:':
Metadata:
major_brand : qt
minor_version : 537199360
compatible_brands: qt
timecode : 01:00:00:23
encoder : Lavf56.4.102
Stream #0:0(eng): Video: rawvideo (I420 / 0x30323449), yuv420p, 1920x816, q=2-31, 200 kb/s, 23.98 fps, 23.98 tbn, 23
.98 tbc (default)
Metadata:
creation_time : 2014-09-25 14:50:45
handler_name : Apple Video Media Handler
encoder : Lavc56.1.101 rawvideo
Stream #0:1(eng): Audio: pcm_s16le, 44100 Hz, stereo, s16, 1411 kb/s (default)
Metadata:
creation_time : 2014-09-25 14:50:45
handler_name : Apple Sound Media Handler
encoder : Lavc56.1.101 pcm_s16le
Stream mapping:
Stream #0:0 -> #0:0 (h264 (native) -> rawvideo (native))
Stream #0:2 -> #0:1 (aac (native) -> pcm_s16le (native))
Press [q] to stop, [?] for help
[null @ 03f97020] Encoder did not produce proper pts, making some up.
frame= 3676 fps=9.7 q=0.0 Lsize=N/A time=00:02:33.32 bitrate=N/A
video:230kB audio:26412kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=361.344s
bench: maxrss=72144kB

F:\>ffmpeg -benchmark -i testavs.avs -f null -
ffmpeg version r66361 git-bb8de55 Copyright (c) 2000-2014 the FFmpeg developers
built on Sep 19 2014 17:19:21 with gcc 4.9.1 (GCC)
configuration: --prefix=/home/qyot27/win32_build --cross-prefix=i686-w64-mingw32- --enable-gpl --enable-version3 --dis
able-w32threads --enable-avresample --disable-doc --disable-debug --enable-fontconfig --enable-libfreetype --enable-libf
ribidi --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-openal --enable-op
engl --enable-libquvi --enable-librtmp --enable-libsoxr --enable-libvidstab --enable-libflite --enable-libgme --enable-l
ibgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libnut --enable-libopencore-amrnb --enable-libop
encore-amrwb --enable-libopenjpeg --enable-libopus --enable-libschroedinger --enable-libshine --enable-libspeex --enable
-libtheora --enable-libtwolame --enable-libutvideo --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --en
able-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --e
nable-avisynth --cpu=pentium3 --extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB -DCA
CA_STATIC -DMODPLUG_STATIC' --extra-ldflags='-mconsole -Wl,--allow-multiple-definition' --target-os=mingw32 --arch=x86 -
-pkg-config-flags=--static
libavutil 54. 7.100 / 54. 7.100
libavcodec 56. 1.101 / 56. 1.101
libavformat 56. 4.102 / 56. 4.102
libavdevice 56. 0.100 / 56. 0.100
libavfilter 5. 1.101 / 5. 1.101
libavresample 2. 1. 0 / 2. 1. 0
libswscale 3. 0.100 / 3. 0.100
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 0.100 / 53. 0.100
Guessed Channel Layout for Input Stream #0.1 : stereo
Input #0, avisynth, from 'testavs.avs':
Duration: 00:02:33.32, start: 0.000000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 1920x816, 23.98 fps, 23.98 tbr, 23.98 tbn, 23.98 tbc
Stream #0:1: Audio: pcm_f32le, 44100 Hz, 2 channels, flt, 2822 kb/s
Output #0, null, to 'pipe:':
Metadata:
encoder : Lavf56.4.102
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 1920x816, q=2-31, 200 kb/s, 23.98 fps, 23.98 tbn, 23.98 t
bc
Metadata:
encoder : Lavc56.1.101 rawvideo
Stream #0:1: Audio: pcm_s16le, 44100 Hz, stereo, s16, 1411 kb/s
Metadata:
encoder : Lavc56.1.101 pcm_s16le
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> rawvideo (native))
Stream #0:1 -> #0:1 (pcm_f32le (native) -> pcm_s16le (native))
Press [q] to stop, [?] for help
[null @ 08fcd020] Encoder did not produce proper pts, making some up.
frame= 3676 fps=7.8 q=0.0 Lsize=N/A time=00:02:33.31 bitrate=N/A
video:230kB audio:26408kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=434.953s
bench: maxrss=129592kB

F:\>

The important numbers:
AVSMeter:
FPS (min | max | average): 4.269 | 92.13 | 8.850
Time (elapsed): 000:06:55.370

FFmpeg (source file):
frame= 3676 fps=9.7 q=0.0 Lsize=N/A time=00:02:33.32
bench: utime=361.344s (00:06:01.344)

FFmpeg (testavs.avs):
frame= 3676 fps=7.8 q=0.0 Lsize=N/A time=00:02:33.31
bench: utime=434.953s (00:07:14.953)


This was on a Pentium III-era Celeron. A much newer computer is going to have the advantage of better SIMD and multithreading, and a tiny bit of necessary overhead because there's a library sitting in the middle is going to be irrelevant.

[hank315]

A new version of HCenc (version 027) can be found here (http://hank315.nl).
You will need Avisynth 2.6 alfa 4 or higher to run this one.
It also runs with Avisynth+.

All color spaces are fully operational, the 1080 vertical resolution is fixed.
Possible input color spaces: YV12, YV16, YV24 (planar) and YUY2 (interleaved), possible output 4:2:0, 4:2:2 and 4:4:4.

[Emulgator]

Many thanks, Hank ! But where is the 027 link ?

Never mind, had to refresh browser cache....its there.

[qyot27]

The newest beta of 0.27 crashes immediately on my Pentium III with a 'This is not a valid Win32 application' message. It worked on a Sandy Bridge under Wine, so I'm not sure if it's because of OS stuff or because the binary might have been compiled for SSE2 (or something higher).

[Groucho2004]

The newest beta of 0.27 crashes immediately on my Pentium III with a 'This is not a valid Win32 application' message. It worked on a Sandy Bridge under Wine, so I'm not sure if it's because of OS stuff or because the binary might have been compiled for SSE2 (or something higher).
Just a hunch:
According to PE Explorer it seems that Hank has switched to a newer compiler/linker (2012?) and the newer VS versions use SSE2 as default unless "arch:IA32" or "arch:SSE" are specified.

[filler56789]

HCenc 0.27 displays the same error message on my Pentium-4 which runs under Windows XP.
The problem definitely has nothing to do with SSE2 support.

[Brazil2]

The newest beta of 0.27 crashes immediately with a 'This is not a valid Win32 application' message.
Same error message here on XP, for both the GUI and the CLI, with a Core2Duo.

[Emulgator]

Oopsi. Lets unpack and see.
GUI start on XP32SP3 with Core2Duo T7600G:
'HCgui_027.exe is not a valid Win32 application'
CLI: The same. Hm.

[Sparktank]

Runs (both) for me on a Sandy Bridge / Win7 (x64).

[Taurus]

Same here:
WinXp SP3 32bit: No Go

Win7 32bit & 64: Yes
It's not a hardware mockup.

Just tested on an old lame AMD Notebook (Win7/x64): Yes

[Groucho2004]

WinXPSP3: fail
WinXP64: fail

[qyot27]

Just a hunch:
According to PE Explorer it seems that Hank has switched to a newer compiler/linker (2012?) and the newer VS versions use SSE2 as default unless "arch:IA32" or "arch:SSE" are specified.
VS2012's (or higher) defaults were what I was thinking of, but I didn't know which compiler was typically used here.

I was also later able to confirm that it's not SSE2 doing it, since I could run them on the same Pentium III under Ubuntu by using Wine (and I realized, after I shut the computer down last night, that if it had been SSE2, the crash wouldn't have come with that error message).

But VS2012 (and higher) also defaults to not using the XP compatibility toolset.

[hank315]

A new build (10-10-2014) can be downloaded here (http://hank315.nl).
Should work on XP now.

[StainlessS]

Dank u wel Hank315.

[Emulgator]

XP32SP3:
"Runtime Error!
The application has requested the runtime to terminate in an unusual way..."

[Groucho2004]

I'm getting "Avisynth version too old..." with every version I use. I guess there's something wrong with the avisynth detection.

[StainlessS]

No problems here.

Test clip:
528x368_4:3@25FPS YV12, 6:12secs
VB Verifier and Preview ON
All other settings as default.
XP32SP3, Core Duo 2.4GHz, 4GB

Avisynth plugins used include Auto Luma Levelling via RT_QueryLumaMinMax and
auto cropping via RT_QueryBorderCrop, DeBlock, FFT3DFilter, Crop, Levels.
Clip had 44.1 KHz audio.

Avisynth Version v2.6A5 CVS(10130920, ICL10) [by Groucho2004].
Shows in GUI as Avisynth File Version 2.6.0.4, Creation date 18-9-2013.
Checked out dll in system32 and file version and creation date as shown in gui,
10130920 shown as modification date in dll properties, as shown by Version in avisynth.

EDIT: I seem to recall IanB saying that eg 2.6.0.4 is actually 2.6A5, 2.6.0.0 was v2.6A1, so maybe 2.6.0.4 is actually correct (but misleading).

EDIT: Perhaps HCEnc should be showing same date as Avisynth Version(), ie modification date rather than creation date.

[filler56789]

Over here, they STILL greet me with the message
"whatever.EXE is not a valid Win32 application".

EDIT 1:

Just to be sure, I re-downloaded the archive,
re-overwrote the old .EXEs, and this time,
only the Devil knows why, no error message anymore :eek: :confused:

I ran a test encode on a short AVS file (250 frames @ 1920x1080),
and "the job was completed successfully" ---

--- but since YMMV, maybe it still is too early for a celebration...

EDIT 2: Additional tests:

YUY2 -> 4:2:2 @ 1920x1080 == O.K.

YV24 -> 4:4:4 @ 1920x1080 == O.K.

[Groucho2004]

I'm getting "Avisynth version too old..." with every version I use. I guess there's something wrong with the avisynth detection.
Just as I suspected - HC expects avisynth.dll to reside in the Windows system directory for some reason.
Works now.

[filler56789]

Feature request: allow encoding of sources with mod-8 dimensions (e.g., 488x360, or 600x1000). TMPGenc supports them since ages ago.

[Taurus]

I can confirm HCenc 027 (10-10-2014) is running now on:
WinXp 32bit SP3
Win 7 64bit
Win 8.1 64bit
So far no crashes, no runtime errors.
toi,toi,toi, :p

[Midzuki]

Apparently, another not-so-minor issue...

from http://forum.videohelp.com/threads/367757-GUI-for-dvdauthor-authoring-success-but-won-t-play-on-set-top-devices?p=2351289&viewfull=1#post2351289

Slighty worried about that 'make dvd compliant' setting if it does not deal with the colorspace issue.

[Emulgator]

Now tested on Win7U64, HC027 worked here because I had Avisynth 2.6.0.4 sitting there from the start.
Now got it to work on XP32SP3 too, my Avisynth there was too old, 2.60 MT...

[GMJCZP]

Thanks for the program. I've been using for years.

I did a test comparing with the version 0.26 and I'm noticing that the latter is yielding slightly higher PSNR values ​​over 0.27.
Put another way, based on PSNR, 0.26 is more efficient that 0.27, is it now the new version calculates PSNR otherwise?

Note: I also noticed that with 0.26 in "scantype" just appeared "zigzag", with 0.27 appeared "zigzag" and "alt", do not know if this has to do with the values ​​of PSNR.

Otherwise, all good in WXP SP3.

INFORMATION UPDATE!: just used MSU Video Quality Measurement Tool 3.0 and this was the result:

HC 0.26: APSNR AVG: 46.36278
HC 0.27: APSNR AVG: 46.25840

Why these results?

[hank315]

@filler56789: Feature request: allow encoding of sources with mod-8 dimensions (e.g., 488x360, or 600x1000).
Will be in the next release.

@Groucho2004: the Avisynth detection is done by detecting the occurence of "AVS_Linkage" in the DLL, about the same as you posted here (http://forum.doom9.org/showpost.php?p=1650005&postcount=16).

@GMJCZP: Yes, I know PSNR is a bit lower. Some internal settings have changed which were optimized for PSNR but were not that logical.
If your goal is to get the highest PSNR it is best to turn off scene change detection and use a fixed GOP.
Using *PSYOFF, which will turn off some psy settings like fade detection and lowering Quants for low luminance MacroBlocks, will also raise PSNR but it's certainly not recommended (that's why this option is hidden).


For those who are interested some info:
Used compiler is VS2012 for the C++ part which is only about 100 lines.
Most code is still Fortran which is compiled with the Intel Visual Fortran 2013 compiler.
The hand-written assembler code (not in-line code) is assembled using Nasm 2.10.09.
The VS2012 linker uses /SUBSYSTEM:WINDOWS as the default but for WIN XP /SUBSYSTEM:WINDOWS,"5.1" is needed, that's why the first version didn't load on XP.

[Groucho2004]

@Groucho2004: the Avisynth detection is done by detecting the occurence of "AVS_Linkage" in the DLL, about the same as you posted here (http://forum.doom9.org/showpost.php?p=1650005&postcount=16).
The Avisynth detection works fine in HCEnc as long as the DLL is in the Windows system directory.
I usually don't use that, my avisynth.dll is in another directory to which the "PATH" environment variable points.
I always load the DLL implicitly ("LoadLibrary("avisynth");") so the system finds it if it is in one of the valid directories.

[GMJCZP]

@hank315

I just did the test SSIM (precise) under the same conditions of PSNR, and MSU threw this:

HC 0.26:
AVG: 0.99034

HC 0.27:
AVG: 0.99013

I must clarify that the original video has a lot of movement.

Maybe someone thinks "well, there's nothing to be alarmed because the difference in values ​​is small" but pragmatically (and possibly unfair) I must say that 0.27 is less than 0.26 on two quality parameters (mean values, of course​​).

I worry that, in haras optimize its structure, the program may suffer in his magical performance.

Note: I tried to do the VQM test but for some unknown reason MSU crashes.

[Lars2500]

Can anyone confirm that HCenc 0.27 no longer generates bit-identical output files after consecutive runs?

I have tried HCenc 0.25, 0.26 beta and 0.27 beta, and output files always come out identical.

However in 0.27, they are always slightly different.

Input file is an YV12 .avi file of about an hour.

If others can confirm it, there may be a memory corruption issue in 0.27.

My HC.INI file:

*INFILE hc.avs
*OUTFILE video.m2v
*BITRATE 4000
*MAXBITRATE 8500
*NOSMP
*PROFILE best
*GOP 12 2
*DEADZONE 0 0
*DC_PREC 8
*PROGRESSIVE
*TFF
*TIMECODE 0 59 59 0
*INTRAVLC 0
*MATRIX fox1
*CHAPTER 12
7741
19462
26597
30154
39200
50469
58781
63017
71192
76773
83486
85568

[hank315]

@GMJCZP
Some tests on a clip I often use as a final test:
HCenc 0.26: PSNR=47.12, SSIM=83.83
HCenc 0.27: PSNR=47.07, SSIM=83.64
As expected 0.27 is a bit lower but for me metrics aren't the holy grail.
Try any other MPEG2 encoder (Quenc, X262, TMPGenc, Procoder, CCE, just to name a few) on your clip with the same encoding settings and you will see large differences.

@Lars2500
Can you tell which processor you used for this.
It helps me to simulate the code execution path of the encoder for the different SIMD instructions used.

[GMJCZP]

@GMJCZP
Some tests on a clip I often use as a final test:
HCenc 0.26: PSNR=47.12, SSIM=83.83
HCenc 0.27: PSNR=47.07, SSIM=83.64
As expected 0.27 is a bit lower but for me metrics aren't the holy grail.
Try any other MPEG2 encoder (Quenc, X262, TMPGenc, Procoder, CCE, just to name a few) on your clip with the same encoding settings and you will see large differences.

I wonder: why are PSNR, SSIM, VQM, etc?
IMHO, the comparison with other programs could be discussed in another thread, to which I have some experiences.

Do not want to get into controversy, all I want is for version 0.27 is equal to or better than previous.
Your program has always seemed phenomenal. ;)

[Lars2500]

Hank,

I did some more tests already. (In fact, all my machines are burning currently doing HCencodes all the time. :))

Unfortunately the issue is quite hard to catch, but here are my observations:

- It is processor independent - for example, I have one machine with an AMD Phenom X4 965 running Windows XP 32-Bit, and another with an Intel Core i3 running Vista 64-Bit. Different output occurs on both of them. I also tried different *CPU settings to no avail.

- It is source dependent - while most of my 13 test input files always generate different output during each run, there are also some where output is sometimes identical, and I also have one where it always comes out identical. (Input files are all of the exact same format - YV12 25fps 720x576 .avi files of about 60 minutes length -, only with different content.)

- The problem seems to occur during the first encoding pass already, as the HC01.dbs file already becomes different at some offset (never the same, unfortunately).

- Using SMP seems to make a difference - with *NOSMP removed the probability of getting identical output is greatly improved.

Testing is done by only putting HCenc.exe in an empty folder along with the HC.ini and input .avs and .avi file, and directly launching HCenc.exe. Then renaming the output file and repeating the process a few (at least 3, usually 5) times, and binary-comparing the output files. I also test on different machines to rule out any hardware errors.

Other software used: AviSynth 2.6 MT 2013.09.28 by SEt, Lagarith lossless compression codec for the input .avi file.

As an example, here are the different sizes of the output files after 5 consecutive runs using a "critical" input file:
Run 1: 1,712,492,826 bytes
Run 2: 1,712,492,298 bytes
Run 3: 1,712,492,528 bytes
Run 4: 1,712,487,993 bytes
Run 5: 1,712,491,804 bytes

None of the above problems occur with HC027 beta (26-10-2013). Using the same HC.INI and input files, the executable from that version always creates identical output files.

You should eventually (hopefully) be able to reproduce the problem by using the following HC.INI, and simply trying out some PAL input files in the format described above.
*INFILE hc.avs
*OUTFILE video.m2v
*BITRATE 4000
*MAXBITRATE 8500
*NOSMP
*PROFILE best
*GOP 12 2
*DC_PREC 8
*PROGRESSIVE
*TFF
*INTRAVLC 0
*MATRIX fox1

An unrelated little inconsistency I found during testing: When using no path in *OUTFILE, i. e. only specifying a filename, then with *FRAMELOG enabled the framelog.txt is always created in the root folder of the output drive, instead of the output folder.

And another observation regarding quality, comparing HCenc 0.26 beta and 0.27: Output has visibly improved in 0.27 with complicated content, like fire. 0.26 already was excellent in that aspect, but with the same settings there is even less visible blocking when doing a direct frame comparison. In other words, great work! Unfortunately, my habit of doing each encode twice and comparing the output files for verification makes the new version useless for me at the moment. :(

[SuLyMaN]

I want to thank Hank for this fantastic FREE encoder. Keep up the good work man!

[tvholic]

If I run HCenc_027.exe with no parameters, and press the Esc key while the window with the "Input not complete" message is up, the window closes but the process remains running indefinitely.

Also, if I press the "exit" button I get an "encoding in progress" message box, but if I press Alt-F4 or click on the "Close" icon in the upper right corner the window closes with no message box.

[AlanHK]

I also get "Avisynth version too old" message and abort from HCenc_027

I do have Avisynth 2.6.0.5
with Avisynth.dll in c:\Windows\system32.

When I click on "Avisynth info" in HCGUI 0.26 and 0.27, it says:
(Incidentally, it would be nice if I could copy the text from the "info" window instead of having to retype it.)

Avisynth installation found d:\Avisynth
Avisynth.dll NOT found in system32\avisynth.dll

However, in both cases, if I load an AVS file in the GUI, it then says

Avisynth.dll loaded
Avisynth successfully initialised



I run WinXP, so that's probably the problem.
Other programs using Avisynth run: VirtualDub, AvsP, MeGUI.

Rolled back to HCenc_026 and that still works and encodes as usual.

[TheSkiller]

I run WinXP, so that's probably the problem.Don't think so. I have encoded several times using HCenc_027 on my WinXP SP3 machine and had no issues.

[GMJCZP]

I also get "Avisynth version too old" message and abort from HCenc_027

I do have Avisynth 2.6.0.5
with Avisynth.dll in c:\Windows\system32.

When I click on "Avisynth info" in HCGUI 0.26 and 0.27, it says:
(Incidentally, it would be nice if I could copy the text from the "info" window instead of having to retype it.)

Avisynth installation found d:\Avisynth
Avisynth.dll NOT found in system32\avisynth.dll

However, in both cases, if I load an AVS file in the GUI, it then says

Avisynth.dll loaded
Avisynth successfully initialised



I run WinXP, so that's probably the problem.
Other programs using Avisynth run: VirtualDub, AvsP, MeGUI.

Rolled back to HCenc_026 and that still works and encodes as usual.

For curiosity, you installed an old program that let you do everything in one, like the Gordian Knot? Try to have only one version of Avisynth.
If this is your case uninstall everything related to Avisynth, including configurations (of course, your filters and others supports elsewhere), then passes a program to clean registry, such as CCleaner and finally reinstall your current and fresh version of Avisynth.

Make sure before you re-install the program on two things:
- That there exists no other Avisynth.dll (in C: )
- That at the time of the installation is best to let the program do it all automatically.

I have WXP SP3 and HC027 version works correctly.

[Emulgator]

Alan HK: A hint...

Avisynth installation found d:\Avisynth

Which kind of Avisynth resides in your path D:\ ?

[AlanHK]

Alan HK: A hint...



Which kind of Avisynth resides in your path D:\ ?

AVS 2.6.0 Alpha 5 [130918]
The avisynth.dll is in System32 despite what HC thinks

[GMJCZP]

Avisynth 2.6.0.5
Win32
the avisynth.dll however is in System32

Could it be that you have installed on C: and D: operating systems?
The only way you solve this is to start from zero, as I indicated earlier.

[AlanHK]

Could it be that you have installed on C: and D: operating systems?
The only way you solve this is to start from zero, as I indicated earlier.

Windows is in C:\Windows.
That's the only OS.
Programs I install are in D:\ unless they insist on being in C:

Anyway, I'm not going to uninstall and reinstall everything for the sake of HC_027, especially since I have no expectation that it would actually work. I will just use 026 rather than go through all that. Since every version of HC up to this has worked with my setup, I am pretty sure the problem is with 027, not Avisynth.

I looked in the registry and the only mentions of avisyth.dll have the correct location.

[GMJCZP]

Windows is in C:\Windows.
That's the only OS.
Programs I install are in D:\ unless they insist on being in C:

Anyway, I'm not going to uninstall and reinstall everything for the sake of HC_027, especially since I have no expectation that it would actually work. I will just use 026 rather than go through all that. Since every version of HC up to this has worked with my setup, I am pretty sure the problem is with 027, not Avisynth.

I looked in the registry and the only mentions of avisyth.dll have the correct location.

It is not to alarm you, but you could have a time bomb, possibly in the near future more programs you install will give you problems, remember that WXP is not as solid as W7, for example.

[AlanHK]

It is not to alarm you, but you could have a time bomb, possibly in the near future more programs you install will give you problems, remember that WXP is not as solid as W7, for example.

If by "time bomb" you mean new programs being incompatible with XP, I'm aware of that.
I happen to run many old programs I'm quite attached to and will stick to the the OS that supports them, not v-v.

Actually I only "upgraded " to XP from Win2k last year because MS's new compilers deliberately dropped support making new programs incompatible.

Currently it seems programs using Qt5 are don't work properly with XP, where Qt4 is fine. But the pain of going to a new Windows isn't worth the hassle of porting my current software ecosystem, if it's even possible.

[GMJCZP]

If by "time bomb" you mean new programs being incompatible with XP, I'm aware of that.
I happen to run many old programs I'm quite attached to and will stick to the the OS that supports them, not v-v.

Actually I only "upgraded " to XP from Win2k last year because MS's new compilers deliberately dropped support making new programs incompatible.

Currently it seems programs using Qt5 are don't work properly with XP, where Qt4 is fine. But the pain of going to a new Windows isn't worth the hassle of porting my current software ecosystem, if it's even possible.

When I refer to time bomb is a program that normally function under normal conditions and installed with its default configuration, due to conficts no longer work. Windows XP is friendly but like old man who is to be treated with care, as any older person. :)

[AlanHK]

When I refer to time bomb is a program that normally function under normal conditions and installed with its default configuration, due to confict no longer work. Windows XP is friendly but like old man who is to be treated with care, as any older person. :)

avisyth.dll is in the default location, yet HC can't find it.

Anyway, I'll wait to see if Hank has any response before nuking my PC.

[Sparktank]

yet HC can't find it

Have you tried reinstalling Avsynth again? (with the installer then copy the dll again)

Installer: AviSynth 2.6.0 Alpha 5 [2013-09-18]
DLL: AviSynth 2.6 MT [2013-09-28]

[AlanHK]

Have you tried reinstalling Avsynth again? (with the installer then copy the dll again)

Installer: AviSynth 2.6.0 Alpha 5 [2013-09-18]
DLL: AviSynth 2.6 MT [2013-09-28]

Yeah, I did that three or four times, rebooted. The whole voodoo thing.

[qyot27]

Save the info generated by AVSInfoTool (http://forum.doom9.org/showthread.php?t=170647) and post it.

[AlanHK]

Save the info generated by AVSInfoTool (http://forum.doom9.org/showthread.php?t=170647) and post it.

General info below, the whole thing attached.
Like I said, the correct version in the correct location.


[General Info - Avisynth.dll]
Version String: AviSynth 2.60, build:Sep 18 2013 [17:36:36]
File Version: 2.6.0.4
Directory: C:\WINDOWS\system32
Timestamp: September 18, 2013, 15:37:18
MT Support: No

[Plugin Directories]
d:\AviSynth\plugins

[Supported Color Spaces]
YUY2, Y8, YV12, YV16, YV24, YV411, RGB24, RGB32

[Internal Functions (357)]

[GMJCZP]

All right. Have plugins directory separately on D:. That's fine but seems to be missing information.
I guess you are using LoadPlugin and Import in your scripts.

[AlanHK]

All right. Have plugins directory separately on D:. That's fine but seems to be missing information.
I guess you are using LoadPlugin and Import in your scripts.

Once you select the install directory (for me, d:\Avisynth) the plugins subdirectory is default. Any dll or avsi I put there is available in a script without an explicit load or import.

See http://avisynth.nl/index.php/Plugins
Plugin autoload and name precedence v2
The directory is stored in the registry
[HKEY_LOCAL_MACHINE\SOFTWARE\Avisynth]
"plugindir2_5"="c:\\program files\\avisynth 2.5\\plugins"


Which of course in my case is
"plugindir2_5"="d:\\Avisynth\\plugins"


Anyway, HC's problem isn't plugins.

[tvholic]

The avisynth.dll is in System32 despite what HC thinks

Check to make sure your "windir" environment variable is pointing to "C:\WINDOWS" (Control Panel -> System -> Advanced -> Environment Variables -> System variables). That seems to be how HC is locating avisynth.dll (%windir%\system32\avisynth.dll).

[AlanHK]

Check to make sure your "windir" environment variable is pointing to "C:\WINDOWS" (Control Panel -> System -> Advanced -> Environment Variables -> System variables). That seems to be how HC is locating avisynth.dll (%windir%\system32\avisynth.dll).


It is. A lot of things would be broken if that was wrong.


HC claims that it's looking there, but can't see the file.

Avisynth installation found d:\Avisynth
Avisynth.dll NOT found in system32\avisynth.dll





dir avis*
Volume in drive C has no label.
Volume Serial Number is D80C-0FAC

Directory of C:\WINDOWS\system32

18/09/2013 03:37 PM 400,384 avisynth.dll

[Groucho2004]

@AlanHK
There is nothing wrong with your Avisynth install, you'll have to wait until hank315 can look into this.

[Lars2500]

Avisynth.dll NOT found in system32\avisynth.dll
Is that the exact wording?

When I delete the avisynth.dll from my system32 folder, the error message in HCGUI is:
Avisynth.dll NOT found in C:\WINDOWS\system32\avisynth.dll

[AlanHK]

Is that the exact wording?

Yes.
Maybe it is looking in the wrong folder after all.
Does the gui info state the full path when it does find it?

[Lars2500]

Does the gui info state the full path when it does find it?

No, it then just displays Avisynth file version and creation date.

Assuming that in your case HCenc really searches for the Avisynth.dll in the "system32" folder (i.e., relative path instead of absolute), you can probably simply create a folder named "system32" inside your HCenc folder, and put the Avisynth.dll there.

That would not explain the bug, but at least work around it.

[AlanHK]

Assuming that in your case HCenc really searches for the Avisynth.dll in the "system32" folder (i.e., relative path instead of absolute), you can probably simply create a folder named "system32" inside your HCenc folder, and put the Avisynth.dll there.

d:\hcenc\system32\avisyth.dll didn't work,
But d:\system32\avisyth.dll made HC_gui happy.

Now it says: "Avisynth file version 2.6.0.4, creation date 20-11-2014"

But HCenc still aborts saying: "Avisynth version too old, need at least 2.6.0.4"

However, if I launch the encode from HCgui, then HCenc does work.

Normally however I use a a batch file (below) to launch HCenc directly. I just use the gui to work out the bitrate, then paste that into my script.

set rate=3000
set ar=16:9
set hc=D:\HCenc\HCenc_027
set mpgd=G:\vid\mpg\

for %%A in (
501.avs
502.avs
503.avs
504.avs
) do (
%hc% -i %%~fA -o %mpgd%%%~nA.m2v -b %rate% -aspectratio %ar% -pulldown -profile best -matrix qlb -frames all -2pass -maxbitrate 8000 -log %%~dpAhenc.log -avsreload -lossless
)


I launch the batch file from the G: drive, where I keep my videos.
So, I made G:\system32\avisynth.dll
Now HCenc can find avisynth.dll and work.


So, I guess all this shows HC can't work out my "windir" folder and assumes it's the current drive root directory.

[tvholic]

So, I guess all this shows HC can't work out my "windir" folder and assumes it's the current drive root directory.

"windir" doesn't propagate to batch files because it's lower case. Add this to the top of your batch file that launches HC:

set windir=%systemroot%

Or, you could switch to TCC/LE (free, http://jpsoft.com/tccle-cmd-replacement.html) as your command interpreter.

[AlanHK]

"windir" doesn't propagate to batch files because it's lower case. Add this to the top of your batch file that launches HC:

set windir=%systemroot%


OK. That's weird, but it works.

I don't get this case business though.
If I create a system variable xxx and then launch a command, it has the variable XXX.
(typing "set" to list all the environment variables)

But has neither windir nor WINDIR.
Even if I create a variable WINDIR it isn't exported,though others with random names are.

WTF?


And I don't need to do any of that for hcenc_026.

[tvholic]

Even if I create a variable WINDIR it isn't exported,though others with random names are.


You're right. You can't set that one in the master environment because the lower-case system variable with the same name will override it.

[Lars2500]

"windir" doesn't propagate to batch files because it's lower case.

This is not true.

It was the case with Windows 95 and COMMAND.COM but is no longer with CMD.EXE.

Edit: I have to correct myself. Even in Windows XP there is still a COMMAND.COM which can be used to process batch files. And there %windir% does not work.

AlanHK, do you happen to run your batch files inside a COMMAND.COM prompt, instead of CMD.EXE?

[tvholic]

Edit: I have to correct myself. Even in Windows XP there is still a COMMAND.COM which can be used to process batch files. And there %windir% does not work.


Yes, that sounded like the situation. I didn't want to go too far down that path, but the command processor is specified by the "ComSpec" environment variable.

[AlanHK]

AlanHK, do you happen to run your batch files inside a COMMAND.COM prompt, instead of CMD.EXE?
Actually, I use Far as my shell.
(http://www.farmanager.com/)
It has a Norton Commander style two-pane file screen and a command line.

I start Far itself with a batch, so I added a set to it.

set windir=%systemroot%
c:\Far\Far.exe
exit

Now my HC batch files (launched from Far) work with hc_027.
That's an acceptable workaround.

Obviously my setup and way of using HC isn't common, which is why maybe no one else has come across this problem. But I do believe it exposes issues in HC, especially in how it reports errors.

If it can't find avisynth.dll, it shouldn't report "Avisynth version too old", which sends you on a wild goose chase looking for the old version HC is accessing and has people reinstalling Avsiynth over and over.
If it gets a blank "windir" it should fall back, maybe use systemroot (or why not do it anyway, does it work in all supported Windows versions?). Or do whatever it did in version 0.26, since that works regardless. Or at least report the actual error, like: "No windir environment setting found." Not assume Windows is installed in the root of the current drive.


================
More diagnosis: Far does use %comspec% (cmd) for its command processor.
But I use a convoluted way of launching it, for compatibility with some old DOS programs I run from Far.
I use a pif, point the pif at the batch which starts Far.
The pif allows me to use EMS memory, which XP doesn't make available if you just start a Windows program directly.
Maybe the pif emulates "command" in what it passes from the environment, it's supposed to be for legacy apps.

Sorry if my simplifications of my setup confused matters. I thought a command line was a command line, now I know it's a lot more involved.

[Lars2500]

But I use a convoluted way of launching it, for compatibility with some old DOS programs I run from Far.
I use a pif, point the pif at the batch which starts Far.
The pif allows me to use EMS memory, which XP doesn't make available if you just start a Windows program directly.
Maybe the pif emulates "command" in what it passes from the environment, it's supposed to be for legacy apps.

Yes, that's exactly it.

[qyot27]

With the recent refactoring of AviSynth+'s internal version code to make it more maintainable and identify itself consistently, HCenc 0.27 now errors out with the 'too old' message on AviSynth+ r1718 and higher.

This doesn't seem to make any sense to me, since earlier in the thread the explanation was that the check determined whether AVS_Linkage is present, and as far as I know (and the git log reports), that's not something AviSynth+ has done anything to. The thing that's actually changed is the versioning code.

Since 2.6 RC1 bumped the AVISYNTH_INTERFACE_VERSION to 6 and AviSynth+ integrated the RC1 changes @ r1718 (the versioning changes started being committed at the same time as RC1 is all; a basic change occurred before the beginning of the RC1 patchset, a much more robust version shortly afterward), the check should probably just simply check whether GetVersion() returns a value of 6 or higher.