Log in

View Full Version : Simple x264/x265 Launcher v3.02 (2022-06-16)


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 [25] 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

szabi
19th December 2013, 11:30
I use several free program, but only this one got alert notification by anti-virus program.
Yes, I found this option in preferences, my suggestion it to make it default settings.

So you think Level3.1 is not available for high profile? Only main one?

r0lZ
19th December 2013, 12:36
Oh, I haven't noticed that the warning was issued by AVG. It's probably a false positive. Scan the exe files with VirusTotal.

I don't know if Level 3.1 is incompatible with the high profile. That may be caused by another option. I don't know the h264 specs enough to be sure.

szabi
19th December 2013, 12:56
Propable, yes.
I am going to see, as you wrote if "more knowledgeable persons" can answer.
Thanks.

bye
szabi

kypec
19th December 2013, 13:08
Propable, yes.
I am going to see, as you wrote if "more knowledgeable persons" can answer.
Thanks.

bye
szabi
Are you using 2-pass encoding mode? If so then please wait until 2nd pass is started and you'll see that your chosen profile "High" will be truly selected. x264 is very clever and ignores H.264 Profile for the 1st pass encoding...

LoRd_MuldeR
19th December 2013, 13:50
Oh, I haven't noticed that the warning was issued by AVG. It's probably a false positive. Scan the exe files with VirusTotal.
I use several free program, but only this one got alert notification by anti-virus program.

Please read this:
http://lamexp.sourceforge.net/doc/FAQ.html#96205e91

I originally wrote that for LameXP, but it applies to Simple x264 Launcher in the same way, of course.


Why not save the output to the same directory?
My "C" drive is ssd, which has not enough space for huge files.
Saving to same directory more logical.

The output file is saved to where you have chosen. You can select the output file when adding a new job...


Why the given profile is not used?
It is set to High but using Main.

Because the Profile is defined by which H.264 features you use. x264 sets the lowest possible Profile that supports all features you are using - setting an even higher one would be pointless.

So, if you are using only "Main" (and "Baseline") Profile features, i.e. no "High" Profile features, then x264 will set the "Main" Profile, since a "Main" Profile capable decoder suffices to playback that stream!

The "--profile" option can be used to force a specific Profile. But this only works to enforce a lower Profile! It won't pretend a higher Profile, when that isn't needed at all...

You almost always want to leave the "Profile" option on the default "Auto" setting. As soon as you use any "High" Profile features, you will see that x264 is going to set the proper Profile automatically ;)

Details:
http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles

szabi
19th December 2013, 16:50
Thanks for the answer, now the profile question is clear.
Unfortunately when the 1st pass finished and 2nd started i got an error message:
x264 [error]: 2nd pass has more frames than 1st pass (333381 vs 323980)
x264 [error]: x264_encoder_open failed
av2y [info]: D:\movie\movie.avs: 704x528, 25 fps, 333381 frames
av2y [info]: error: wrote only 556620 of 557568 bytes

WARNING: Input process exited with error (code: 1), your encode might be *incomplete* !!!
I do not understand how it is possible?
Source is the same.

LoRd_MuldeR
19th December 2013, 18:50
Looks like something weird is going on with your input script :confused:

(Or maybe, in the first pass, Avisynth simply crashed shortly before the end of the encode?)

What happens if you run this multiple times? Does it always show the same info?
avs2yuv.exe -frames 1 "your_script.avs" NUL

Also, if you open the very same script in, e.g. VirtualDub, does it play fine, all the way to the end?

szabi
19th December 2013, 22:06
Hi

I do not want to try running it again, because the first pass was running almost 6 hours.
I guess you can imagine my happiness when this error occured, on the last frame.
In other topic (http://forum.doom9.org/showthread.php?p=1658392#post1658392) dissgussion was about to load script to virtuadub, set fast recompress, select ffdshow video codec ffv1 and save the script to uncompressed avi.
And give it to x264 for encoding.
This way there is no quality loss just more steps and lots of disc space needed.
Tomorrow I will check it.

LoRd_MuldeR
19th December 2013, 23:22
I do not want to try running it again, because the first pass was running almost 6 hours.
I guess you can imagine my happiness when this error occured, on the last frame.

Happy or not, you won't get around debugging your Avisynth script, if you want to fix the issue.

In other topic (http://forum.doom9.org/showthread.php?p=1658392#post1658392) dissgussion was about to load script to virtuadub, set fast recompress, select ffdshow video codec ffv1 and save the script to uncompressed avi.
And give it to x264 for encoding.
This way there is no quality loss just more steps and lots of disc space needed.
Tomorrow I will check it.

Creating a lossless intermediate file from your Avisynth script might make sens for a 2-Pass encode, if you use very slow filters. Either that or simply use CRF mode ;)

szabi
20th December 2013, 08:11
Thanks, I started saving it by huffyuv in virtualdub, colorspace yv12, predictor: plane.
Estimated time 6hours, and predicted file size is 87GB.
I hope that will be successfull.

VideoFanatic
25th December 2013, 20:27
Could you please tell me what is the correct SAR for 4:3 720p?

I have upscaled the Standard Definition video to 960 x 720 and I've added 160 pixels each to the left and right border to make a total of 1280 x 720.

For 720 x 480 4:3 I have a SAR of 8:9 and the video displays correctly but when I do the same thing for the 720p upscaled video, the picture doesn't appear wide enough - it's squashed.

I'm using the "ARS Calculator" program to give me the correct SAR. It works fine for standard definition but it doesn't seem to give the correct values for 4:3 720p.

LoRd_MuldeR
25th December 2013, 21:21
If with 720p you mean 1280x720 - the resolution commonly associated with "720p" - then the DAR almost certainly is 16:9, which corresponds to a SAR of 1:1.

But if we are talking about 720x480 footage (aka "480p", aka "NTSC"), then the DAR most likely is either "classic" 4:3 or "anamorphic" 16:9, which corresponds to a SAR of 8:9 or 32:27, respectively.

It should very easy to spot whether a DAR of 4:3 or a DAR of 16:9 look correct - because picking the wrong one will result in eggheads ;)

VideoFanatic
25th December 2013, 21:28
Thanks 1:1 works great. Also when viewing a 720 x 480 video there's an option on my media player to play in 16:10 which makes the picture slightly wider on each side by about an inch but to my eyes it still looks in proportion (although I know it's not). What SAR should I use to get that effect in 720 x 480 and in 4:3 720p?

And would that SAR be Bluray compatible or does it not matter what SAR is used?

LoRd_MuldeR
25th December 2013, 21:34
As said before, with 480p (720x480), you can get a DAR of 4:3 or 16:9 by applying a SAR of 8:9 or 32:27, respectively.

Furthermore, AFAIK, BluRay doesn't use anamorphic video for the "HD" resolutions (720p and above) at all, so those should all use a SAR of 1:1. Anamorphic video is still used for NTSC (480p) and PAL (576p) - for historical reasons.

For details, please have a look here:
http://www.x264bluray.com/

VideoFanatic
29th December 2013, 14:31
Thanks. I'm also getting a problem where my encodings keep failing within a couple of minutes of the encoding starting. My script is pretty simple, I'm downscaling 1080i 25fps to 720p 50fps. I'm using the following customer parameters: --sar 1:1. Here's my script:

setmtmode(5,12)
DGSource("X:\Video.dgi")
setmtmode(2)

AssumeTFF()
QTGMC(Preset="Super Fast")

Lanczos4Resize(1280,720)

That makes a 720p 50fps video. The error message says: WARNING: Input process exited with error code: -1073741819.

Is there another program I could use to give a more detailed error message so I could see what's causing the problem?

I use QTGMC all the time when re-encoding 720 x 480i MPEG2 to h264 and the encodings never fail so I don't understand why they're failing for HD? I'm using the latest version of DGIndexNV to index the file which is read by your program. I use DGIndex for MPEG2s.

LoRd_MuldeR
29th December 2013, 14:39
int x = -1073741819;
printf("%d = 0x%08X\n", x, x);

-1073741819 = 0xC0000005

It means that Avisynth, or more likely one of the plug-in's you are using, has crashed - with STATUS_ACCESS_VIOLATION (http://www.tenox.net/links/ntstatus.html) (0xC0000005) error.

In case of a "hard" crash, you won't get any useful error message, as the program just dies. You may be able to locate in which module and function it crashed using a debugger though.

Anyway, this problem obviously is not related to x264 or Simple x264 Launcher. All you can do at this point is stripping down your Avisynth script and find out which plug-in is responsible.

And, most important, get rid of the unstable mess called Avisynth-MT for now and try again with a stable Avisynth ;)

johnchoi
1st January 2014, 18:24
I would like to request 2 features be added to Simple x264 Launcher:


The ability to fully add jobs to Simple using the command line with no other input/dialogs necessary. While the --add function currently exists all it does is add the file you specify to the Add New Job dialog box. What I would like is the ability to add the complete job with no GUI input necessary. For example a command like this: "x264_launcher.exe --input Video.avs --output Video.mkv --template 720pHD". This would require a template to already exist. The end goal of these commands would be to allow people to add jobs to Simple x264 Launcher using batch files or scripts.


The ability to re-order jobs currently in queue in Simple x264 Launcher. Currently if I have 3 jobs in queue and I add a 4th that I want to run ahead of those 3 I have to delete the 3 existing jobs and then re-add then. A simple Up/Down ability for the queue or a Low, Normal, High priority setting for queue management would be great.

LoRd_MuldeR
1st January 2014, 18:35
The ability to fully add jobs to Simple using the command line with no other input/dialogs necessary. While the --add function currently exists all it does is add the file you specify to the Add New Job dialog box. What I would like is the ability to add the complete job with no GUI input necessary. For example a command like this: "x264_launcher.exe --input Video.avs --output Video.mkv --template 720pHD". This would require a template to already exist. The end goal of these commands would be to allow people to add jobs to Simple x264 Launcher using batch files or scripts.

You are not the first one to ask for this. It's one of the things I'm planning for future versions. No ETA though ;)

The ability to re-order jobs currently in queue in Simple x264 Launcher. Currently if I have 3 jobs in queue and I add a 4th that I want to run ahead of those 3 I have to delete the 3 existing jobs and then re-add then. A simple Up/Down ability for the queue or a Low, Normal, High priority setting for queue management would be great.

Adding job priorities seems reasonable. I will consider this feature for a future version...

LoRd_MuldeR
30th January 2014, 15:27
Here is a new test version with improved command-line support:
http://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_x64.2014-01-29.exe/download

You can now add new jobs directly (no dialog) by using:
x264_launcher.exe --add-job <source_file> <destination_file> <template>

Note that the template can be specified as "-" to encode with x264 default settings.

LoRd_MuldeR
3rd February 2014, 16:17
Yet another test version with improved command-line support:

New jobs will now be started immediately or added to the queue - depending on the user's preferences.

Also there are two new CLI options that can be used to enforce that a new job will be started immediately or to enforce that a new job will added to the queue.

johnchoi
3rd February 2014, 20:35
Yet another test version with improved command-line support:
http://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_x64.2014-02-03.exe/download

New jobs will now be started immediately or added to the queue - depending on the user's preferences.

Also there are two new CLI options that can be used to enforce that a new job will be started immediately or to enforce that a new job will added to the queue.
For those wondering, the options are listed in the ReadMe.txt file and are:

--[no-]force-start .............. Next job will [not] be started immediately
--[no-]force-enqueue ............ Next job will [not] be appended to queue

LoRd_MuldeR
7th February 2014, 14:05
Simple x264 Launcher v2.31 has been released.

Chumbo
9th February 2014, 20:12
Simple x264 Launcher v2.31 has been released.
Thanks. BTW, it looks like the download link, for the installer, is still for the 2013-12-14 release.

LoRd_MuldeR
9th February 2014, 20:24
Thanks. BTW, it looks like the download link, for the installer, is still for the 2013-12-14 release.

No, the download link was okay. Just the wrong name for the correct file. Should be fixed now ;)

Chumbo
9th February 2014, 20:25
No, the download link was okay. Just the wrong file name. Should be fixed now ;)
Man that was quick! :) Thanks.

lansing
20th February 2014, 07:22
Hi, today when I was trying to encode a dvd, the process ended with an error after three hours. Here the error message from the log.


av2y [info]: xyz.avs: 720x550, 60000/1001 fps, 523236 frames
av2y [info]: error: Unknown ResampleHQ internal error. occurred while reading frame 139815

WARNING: Input process exited with error (code: 1), your encode might be *incomplete* !!!


I'm not sure where should I look for help with this problem.

LoRd_MuldeR
20th February 2014, 11:44
Seems pretty obvious where the problem occurred:

av2y [info]: error: Unknown ResampleHQ internal error. occurred while reading frame 139815

Try to kick out the ResampleHQ plug-in and then try again. If it runs through fine then, you probably need to bother the ResampleHQ author ;)

BTW: You are using "stable" Avisynth or Avisynth-MT or Avisynth+ ???

lansing
20th February 2014, 17:16
BTW: You are using "stable" Avisynth or Avisynth-MT or Avisynth+ ???

Avisynth+.

I'll try to run a quick encode with only ResampleHQ and without to see how it goes.

LoRd_MuldeR
20th February 2014, 21:25
Avisynth+.

I'll try to run a quick encode with only ResampleHQ and without to see how it goes.

Try stable Avisynth 2.5 with one of the built-in resize filters. You can still try the "fancy" stuff once you have a working baseline.

lansing
22nd February 2014, 04:17
Try stable Avisynth 2.5 with one of the built-in resize filters. You can still try the "fancy" stuff once you have a working baseline.

I broken my script into parts and encoded them each, but still couldn't reproduce the problem. Guess I'll have to settle for another resizer.


And for this program, can you add a confirm pop up if the user click abort job, just in case any misclick. Also, can you add a button or context menu option to open the output folder for the selected job?

LoRd_MuldeR
22nd February 2014, 05:02
And for this program, can you add a confirm pop up if the user click abort job, just in case any misclick.

Adding that is not a big deal. The question is more whether I like to have yet another popup window.

Also, can you add a button or context menu option to open the output folder for the selected job?

Right-click -> "Explore job" should do exactly this ;)

lansing
22nd February 2014, 06:11
Adding that is not a big deal. The question is more whether I like to have yet another popup window.

I believe that it should be a necessary safe guard to have that, just like having a confirm pop up when the program is about to overwrite an existing file.


Right-click -> "Explore job" should do exactly this ;)

Good to know that ;), didn't understand what it meant before.

LoRd_MuldeR
26th February 2014, 18:58
Here is a new experimental build with rudimentary x265 encoding support:
http://sourceforge.net/projects/muldersoft/files/Simple%20x264%20Launcher/Testing/x264_x64.2014-02-26.exe/download

http://i.imgur.com/nQwrBCDs.png (http://i.imgur.com/nQwrBCD.png)

DeeSeven
28th February 2014, 15:29
I've been using simple x264 for a while now with no troubles, I updated to the latest and greatest and I get this error

your revision of x264 is too old.

I've tried updating to the latest x264 and I get the same error. I've been replacing the x264 .exes in here C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset

is that right? I'm running a 64 bi win 8 machine

LoRd_MuldeR
28th February 2014, 18:45
I've been using simple x264 for a while now with no troubles, I updated to the latest and greatest and I get this error

your revision of x264 is too old.

I've tried updating to the latest x264 and I get the same error. I've been replacing the x264 .exes in here C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset

is that right? I'm running a 64 bi win 8 machine

I generally set the minimum required revision to the latest stable (http://git.videolan.org/?p=x264.git;a=shortlog;h=refs/heads/stable) x264 revision.

Of course the x264 binaries that ship with Simple x264 Launcher will be at least that revision, to make sure that everything works out-of-the-box. Why not simply stick with the provided binaries?

Atak_Snajpera
28th February 2014, 19:30
Detection of AVS properties does not work for my simple script.

Simple x264 Launcher (Build #808), built 2014-02-26

Job started at 2014-02-28, 19:23:10.

Source file : C:\temp\RipBot264temp\job1\job1.avs
Output file : C:\Users\Dave\Desktop\job1.mkv

--- SYSTEMINFO ---

Binary Path : C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2
Avisynth : Yes
VapourSynth : N/A

--- SETTINGS ---

Encoder : x265 (H.265/HEVC), x64, 8-Bit
Source : Avisynth (avs)
RC Mode : CRF
Preset : Medium
Tuning : None
Profile : Auto
Custom : (None)

--- CHECK VERSION ---

Detect video encoder version:

Creating process:
"C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x64\x265_8bit_x64.exe" --version

x265 [info]: HEVC encoder version 0.7+232-fec3cab870437c10
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE SSE2Fast SSSE3 SSE4.2 AVX

Detect video source version:

Creating process:
"C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x86\avs2yuv_x86.exe"

Avs2YUV 0.24bm2

> x265 version: 0.7+232
> Avs2YUV version: 0.24.2

--- GET SOURCE INFO ---

Creating process:
"C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x86\avs2yuv_x86.exe" -frames 1 C:\temp\RIPBOT~1\job1\job1.avs NUL


FAILED TO DETERMINE AVS PROPERTIES !!!

Job1.avs
DirectShowSource("C:\Users\Dave\Desktop\112.MTS",audio=false)

LoRd_MuldeR
28th February 2014, 19:39
Detection of AVS properties does not work for my simple script.

If you run this from the console manually, what output do you get? :confused:
"C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x64\x265_8bit_x64.exe" -frames 1 C:\temp\RIPBOT~1\job1\job1.avs NUL

From you log it looks like it didn't generate any text output at all...

Atak_Snajpera
28th February 2014, 19:52
It works in console but not in gui
http://i.cubeupload.com/KeRyxP.png

LoRd_MuldeR
28th February 2014, 20:09
That doesn't make much sense to me. Does it only happen with DirectShowSource() or with other scripts too?

Atak_Snajpera
28th February 2014, 20:32
That doesn't make much sense to me. Does it only happen with DirectShowSource() or with other scripts too?

It works with this script
LoadPlugin("..\RawSource.dll")
video1=RawSource("E:\_Video_Samples\y4m\crowd_run_1080p50.y4m")
video2=RawSource("E:\_Video_Samples\y4m\park_joy_1080p50.y4m")
video3=RawSource("E:\_Video_Samples\y4m\ducks_take_off_1080p50.y4m")
video4=RawSource("E:\_Video_Samples\y4m\in_to_tree_1080p50.y4m")
video5=RawSource("E:\_Video_Samples\y4m\old_town_cross_1080p50.y4m")

return video1+video2+video3+video4+video5

This also works

LoadPlugin("\DGDecode.dll")
video=MPEG2Source("C:\Temp\RipBot264temp\job3\job3.d2v")


but it does not work with DirectShowSource

Check this video https://mega.co.nz/#!pE0E2QyQ!vn7Gqyl97u1ca8rPNb--IrgroYHV-ZkOekzORgbj7XA

LoRd_MuldeR
28th February 2014, 20:52
So, obviously, the detection code is working fine. Must be some oddity with DirectShowSource() or the particular DirectShow decoder filter.

[EDIT]

Works fine for me with your clip, using FFVideoSource:
Simple x264 Launcher (Build #808), built 2014-02-26

Job started at 2014-02-28, 21:19:25.

Source file : C:\Temp\Dwm 2014-02-28 20-14-23-60.avs
Output file : C:\Temp\Dwm 2014-02-28 20-14-23-60.hevc

--- SYSTEMINFO ---

Binary Path : E:\DeLpHi\x264_x64_launcher\bin\Release
Avisynth : Yes
VapourSynth : D:\VapourSynth\core32

--- SETTINGS ---

Encoder : x265 (H.265/HEVC), x64, 8-Bit
Source : Avisynth (avs)
RC Mode : CRF
Preset : Superfast
Tuning : None
Profile : Auto
Custom : (None)

--- CHECK VERSION ---

Detect video encoder version:

Creating process:
E:\DeLpHi\x264_x64_launcher\bin\Release\toolset\x64\x265_8bit_x64.exe --version

x265 [info]: HEVC encoder version 0.7+232-fec3cab870437c10
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE SSE2Fast SSSE3 Cache64 SlowShuffle

Detect video source version:

Creating process:
E:\DeLpHi\x264_x64_launcher\bin\Release\toolset\x86\avs2yuv_x86.exe

Avs2YUV 0.24bm2

> x265 version: 0.7+232
> Avs2YUV version: 0.24.2

--- GET SOURCE INFO ---

Creating process:
E:\DeLpHi\x264_x64_launcher\bin\Release\toolset\x86\avs2yuv_x86.exe -frames 1 C:\Temp\dwm201~1.avs NUL

C:\Temp\dwm201~1.avs: 2048x1152, 30030/1001 fps, 1362 frames

Resolution: 2048x1152
Frame Rate: 30030/1001
No. Frames: 1362

--- ENCODING VIDEO ---

Creating input process:
E:\DeLpHi\x264_x64_launcher\bin\Release\toolset\x86\avs2yuv_x86.exe C:\Temp\dwm201~1.avs -

Creating encoder process:
E:\DeLpHi\x264_x64_launcher\bin\Release\toolset\x64\x265_8bit_x64.exe --crf 22.0 --preset superfast --output "C:\Temp\Dwm 2014-02-28 20-14-23-60.hevc" --frames 1362 --y4m -

y4m [info]: 2048x1152 30030/1001 fps i420, frames 0 - 1361 of 0
x265 [info]: using cpu capabilities: MMX2 SSE SSE2Fast SSSE3 Cache64 SlowShuffle
x265 [info]: HEVC encoder version 0.7+232-fec3cab870437c10
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: Main profile, Level-5 (Main tier)
x265 [info]: WPP streams / pool / frames : 36 / 4 / 2
x265 [info]: CU size : 32
x265 [info]: Max RQT depth inter / intra : 1 / 1
x265 [info]: ME / range / subpel / merge : hex / 44 / 1 / 2
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 10 / 4 / 0
x265 [info]: b-pyramid / weightp / refs : 1 / 0 / 1
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-22.0 / 0.0 / 0
x265 [info]: tools: cfm esd rd=3 lft sao-lcu sign-hide

Atak_Snajpera
28th February 2014, 20:54
My chain looks like this Haali + ffdshow (libavcodec for avc)

Atak_Snajpera
1st March 2014, 17:09
Problem was solved after re-boot. Weird...
Sorry Lord_Mulder for raising false alarm ;)

Bozotheclown
14th March 2014, 10:48
Welcome everyone,

Very nice and useful app for x264 stuff.

few questions:

1. It's possible to add new button labeled as "SAVE" for saving modified parameters in existing template?

2. Add option for edit existing "Job".

3. If m2ts container officially supported as input? There is no such ext on "all supported files" in "Open Source File" window. But program accepted this kind of file.

LoRd_MuldeR
14th March 2014, 16:19
1. It's possible to add new button labeled as "SAVE" for saving modified parameters in existing template?

Possible? Yes. Will it be added? Maybe ;)

2. Add option for edit existing "Job".

Well, at least when the job is not started yet, this should be possible. But requires extra work.

3. If m2ts container officially supported as input? There is no such ext on "all supported files" in "Open Source File" window. But program accepted this kind of file.

Simple x264 Launcher is just a front-end to x264/x265. So what works (or does not work) solely depends on the encoder! If you use a x264 build with FFM2-support enabled (as is the case with the included builds), it can read almost everything thanks to FFMS2/libav. However, as far as I remember, TS/M2TS is known to be a particular problematic format for FFMS2. As for x265, all it can read is "raw" YUV4MPEG at the moment, nothing else.

Of course you can always load your M2TS file via Avisynth or VapurSynth, for both x264 and x265. I recommend DGDecodeNV.

VideoFanatic
29th March 2014, 12:44
I was using an old version of Simple x264 Launcher that I was quite happy with. I got fed up with the "this version is more than 6 months old" message every time I started the program so I downloaded the latest version.

I thought the program was supposed to be portable, it just extracts the files to a folder? However there's an entry in the Programs and Features section in Windows which suggests it installed the program.

Also, when installing the program there was a popup saying it was out of date so I clicked the button to update it, it appears to be updating mplayer. The top of the window says "download complete, verifying signature".

The progress window says "Failed to verify signature" at the bottom and the install has paused. The only button available to click is the cancel button.

Not very happy. What's going on?

LoRd_MuldeR
29th March 2014, 14:17
I thought the program was supposed to be portable, it just extracts the files to a folder? However there's an entry in the Programs and Features section in Windows which suggests it installed the program.

Correct, the program is 100% portable - in the sense that it does not require any additional "runtime libraries", "frameworks" or "codecs" to be installed on the system. It's 100% self-contained.

You can even rename the program file to x264_launcher_portable.exe in order to enable a "real" portable mode, in which case the program will keep all it's INI files directly in the program directory.

Though using the "real" portable mode is only recommended if you want to carry around the program on your USB stick. Otherwise, I highly recommend to keep the INI files at %LOCALAPPDATA%.


As far as the installer is concerned, it doesn't do anything but extracting the program files to the selected directory (just like an SFX archive) and create the shortcuts to the program.

In newer versions we also have a proper uninstaller now, because a lot of people asked for it. They don't believe that deleting the installation directory plus the (now defunct) shortcuts can be sufficient.

But that's pretty much what the uninstaller does. So it's just a convenience feature. And of course the uninstaller will show up under "Programs and Features", so people can find it ;)

(Note: The paranoid user, who believes that the installer program does some evil things - which of course it doesn't - may still extract the program files with 7-Zip and bypass the installer altogether)

Also, when installing the program there was a popup saying it was out of date so I clicked the button to update it, it appears to be updating mplayer.

What makes you believe the Simple x264 Launcher Auto-Updater was downloading "mplayer" updates?

Well, one of our update servers is located at "mplayer.savedonthe.net" and maybe you got confused by that. But let me assure you that not only MPlayer updates are hosted there :p

The top of the window says "download complete, verifying signature".

The progress window says "Failed to verify signature" at the bottom and the install has paused. The only button available to click is the cancel button.

Of course all updates I distribute have a PGP signature attached, so potential attackers cannot slip in "malicious" files. And my Auto-Update utilities won't install any updates, unless they have verified the signature :cool:

If you get "Failed to verify signature", it means the signature verification has failed for some reason. Probably it's just a failed/corrupted download. Though, this could also mean that you have just been protected from an attack!

In any case, it should be obvious that the update installer won't go on after the signature check has failed, so simply try again! And if the update fails multiple times, I will need to have a closer look...

VideoFanatic
29th March 2014, 14:25
OK thanks. Why after uninstalling does it say I need to reboot if it's merely just deleted the files since the program is portable?

What's the point of the signature thing? If it didn't need a signature then it would have downloaded fine?

I have now renamed the installation file to: x264_launcher_portable.exe but when I open the file it's still asking me to install it?

LoRd_MuldeR
29th March 2014, 14:44
OK thanks. Why after uninstalling does it say I need to reboot if it's merely just deleted the files since the program is portable?

NSIS decides by itself when it needs to reboot.

If it requests a reboot, that probably means one of the files that were supposed to be deleted was locked at the time the uninstaller was run.

What's the point of the signature thing?

Digital signatures make sure that the files you are downloading are genuine, i.e. they have been created by me and have not been modified since then.

Thus it prevents that:

The download can be modified while it's traveling trough the Internet from the update server to your computer - which otherwise would easily be possible.
If somebody manages to break into one of my update mirrors, he can modify the files unnoticed, e.g. replace the original files with "malicious" ones.
If one of my update mirrors is no longer under my control, e.g. because the domain name now belongs to somebody else, the new owner can start distributing "malicious" files.
I will still be able to distribute any updates, if I ever loose my private signing key :p


Recommended reading:
http://en.wikipedia.org/wiki/Digital_signature
http://en.wikipedia.org/wiki/GNU_Privacy_Guard


If it didn't need a signature then it would have downloaded fine?

Nope. Without the signature, the Auto-Updater simply would have no way to know whether the file it just downloaded is genuine or malicious.

In other words: Without the signatures, the Auto-Update process would be inherently insecure! :eek:

I have now renamed the installation file to: x264_launcher_portable.exe but when I open the file it's still asking me to install it?

Did you rename the installer or the program? Renaming the installer has no effect at all! :confused:

Renaming the program itself has exactly one effect: The program will now keep all of it's INI files in the same directory where the EXE file is located. And this is usually not recommended.

(As said before: The "real" portable mode is only recommended if you want to carry around the program on your USB stick, but not for normal "local" usage)

r0lZ
29th March 2014, 16:13
The program will now keep all of it's INI files in the same directory where the EXE file is located. And this is usually not recommended.May I ask why it's not recommended? I install many programs in portable mode whenever possible on my D: HDD, because that way I don't need to re-install them if I need to format my system disc and re-install Windows. I find that technique very convenient, or at least much more convenient than installing the programs in the default location "C:\Program Files". So, if for any reason, that technique could have a drawback or be insecure, please let me know.