Error with revision 1179 and 1181

[Fishman0919]

I'm getting an error with 1179 and 1181.... 1173 works fine.
With --progress.


E:\test\dgmpgdec\dgavcdec>TIME /T
11:20 AM

E:\test\dgmpgdec\dgavcdec>"E:\X264\x264.exe" "C:\Temp\video.A
VS" --bitrate 5930 --level 4.0 --sar 1:1 --aud --vbv-bufsize 18000 --vbv-maxrate
18000 --filter 0,0 --ref 3 --mixed-refs --bframes 3 --b-pyramid --aq-mode 1 --a
q-strength 1.0 --b-adapt 2 --keyint 24 --min-keyint 2 --direct auto --subme 9 --
trellis 2 --partitions all --8x8dct --me umh --merange 32 --psy-rd 1.0:0.3 --no-
fast-pskip --threads auto --thread-input --progress --no-psnr --no-ssim --stats
"x264HQ.log" --pass 1 --output NUL
E:\X264\x264.exe: unknown option -- progress

E:\test\dgmpgdec\dgavcdec>TIME /T
11:20 AM

E:\test\dgmpgdec\dgavcdec>PAUSE
Press any key to continue . . .


Edit: If I remove --progress, I get...


E:\test\dgmpgdec\dgavcdec>TIME /T
11:27 AM

E:\test\dgmpgdec\dgavcdec>"E:\X264\x264.exe" "C:\Temp\video.A
VS" --bitrate 5930 --level 4.0 --sar 1:1 --aud --vbv-bufsize 18000 --vbv-maxrate
18000 --filter 0,0 --ref 3 --mixed-refs --bframes 3 --b-pyramid --aq-mode 1 --a
q-strength 1.0 --b-adapt 2 --keyint 24 --min-keyint 2 --direct auto --subme 9 --
trellis 2 --partitions all --8x8dct --me umh --merange 32 --psy-rd 1.0:0.3 --no-
fast-pskip --threads auto --thread-input --no-psnr --no-ssim --stats "x264HQ.log
" --pass 1 --output NUL
E:\X264\x264.exe: unknown option -- no-psnr

E:\test\dgmpgdec\dgavcdec>TIME /T
11:27 AM

E:\test\dgmpgdec\dgavcdec>PAUSE
Press any key to continue . . .

[Sharktooth]

--progress does no longer exist. please read the x264 changelog...

[Fishman0919]

--progress does no longer exist. please read the x264 changelog...

Sorry and Thank You


Edit:

Our defaults have also changed: new defaults are --subme 7 --bframes 3 --8x8dct --no-psnr --no-ssim --threads auto --ref 3 --mixed-refs --trellis 1 --weightb --crf 23 --progress.

Not seeing that they no longer exist... just new defaults

I also noticed that in the error it's showing -- no-psnr and not --no-psnr

[J_Darnley]

If an option is on/off by default then why leave the option to enable/disable it there?

[Sharktooth]

--progress is now default so the option no longer exist. same as --no-psnr and --no-ssim... however there are new options to enable psnr (--psnr) and ssim (--ssim) ...
same happens for --mixed-refs, --weightb and --8x8dct (--no-mixed-refs, --no-weightb and --no-8x8dct)...

[Fishman0919]

--progress is now default so the option no longer exist. same as --no-psnr and --no-ssim... however there are new options to enable psnr (--psnr) and ssim (--ssim) ...
same happens for --mixed-refs, --weightb and --8x8dct (--no-mixed-refs, --no-weightb and --no-8x8dct)...


But I'm not get any errors with --mixed-refs, --weightb and --8x8dct

nor --threads auto --ref 3

E:\test\dgmpgdec\dgavcdec>TIME /T
11:51 AM

E:\test\dgmpgdec\dgavcdec>"E:\X264\x264.exe" "C:\Temp\video.A
VS" --bitrate 5930 --level 4.0 --sar 1:1 --aud --vbv-bufsize 18000 --vbv-maxrate
18000 --filter 0,0 --ref 3 --mixed-refs --bframes 3 --b-pyramid --aq-mode 1 --a
q-strength 1.0 --b-adapt 2 --keyint 24 --min-keyint 2 --direct auto --subme 9 --
trellis 2 --partitions all --8x8dct --me umh --merange 32 --psy-rd 1.0:0.3 --no-
fast-pskip --threads auto --thread-input --stats "x264HQ.log" --pass 1 --output
NUL
avis [info]: 1920x1080 @ 23.98 fps (127968 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast FastShuffle SSEMisalign LZCNT

x264 [info]: profile Main, level 4.0
[1.3%] 1610/127968 frames, 9.22 fps, 6257.48 kb/s, eta 3:48:17

[kemuri-_9]

static struct option long_options[] =
{
...
{ "weightb", no_argument, NULL, 'w' },
{ "no-weightb", no_argument, NULL, 0 },
...
{ "mixed-refs", no_argument, NULL, 0 },
{ "no-mixed-refs", no_argument, NULL, 0 },
...
{ "8x8dct", no_argument, NULL, 0 },
{ "no-8x8dct", no_argument, NULL, 0 },
...
}

they still work because they're still there.
threads and ref were never altered to begin with.

[Fishman0919]

static struct option long_options[] =
{
...
{ "weightb", no_argument, NULL, 'w' },
{ "no-weightb", no_argument, NULL, 0 },
...
{ "mixed-refs", no_argument, NULL, 0 },
{ "no-mixed-refs", no_argument, NULL, 0 },
...
{ "8x8dct", no_argument, NULL, 0 },
{ "no-8x8dct", no_argument, NULL, 0 },
...
}

they still work because they're still there.
threads and ref were never altered to begin with.


Thank You

[jdobbs]

I personally don't know why simply changing the default required removing the option. There are lots of people with many, many batch files, or in my lots of lines of code in BD-RB that had to be modified because they failed with the new version.

But it's not my code, so the authors can do as they wish. :)

[Amefurashi]

I personally don't know why simply changing the default required removing the option. There are lots of people with many, many batch files, or in my lots of lines of code in BD-RB that had to be modified because they failed with the new version.

But it's not my code, so the authors can do as they wish. :)

Agree with that. I also noticed that the very same batch command line, without the --progress, --no pnsr and --no ssim options, in the new build now runs 60% faster than previous versions. :eek:

[jdobbs]

That's probably because any first pass "--pass 1" ignores your options now and runs in turbo mode. If you want to keep the old options (e.g. when you're using "--pass 1" because you want to generate a .stats file) you have to add "--slow-firstpass"

[LoRd_MuldeR]

That's probably because any first pass "--pass 1" ignores your options now and runs in turbo mode.

It doesn't "ignore" your options. It simply lowers specific options in the first pass (unless "--slow-firstpass" is set). Options that won't effect the second pass in a noticeable way...

[edrikk]

Sorry, but out of curiosity, why remove the parameters even if they are becoming defaults?
All that happens is that applications that use x264.exe to encode will brake/have broken and need to update... An example is an app I use call XVid4PSP. That app isn't really supported/updated anymore, so I will download the source and make the needed changes, but many will not be able to.

So again, if making such a change, why not just leave those parameters in place? If they are passed in, great... they'll do nothing... if they are not, the new functionality will still hold due to the new defaults... Going forward, people can use the "no..." to override the default.

[Dark Shikari]

Sorry, but out of curiosity, why remove the parameters even if they are becoming defaults?
All that happens is that applications that use x264.exe to encode will brake/have broken and need to update... An example is an app I use call XVid4PSP. That app isn't really supported/updated anymore, so I will download the source and make the needed changes, but many will not be able to.

So again, if making such a change, why not just leave those parameters in place? If they are passed in, great... they'll do nothing... if they are not, the new functionality will still hold due to the new defaults... Going forward, people can use the "no..." to override the default.
1. Because having useless options is stupid and clutters the interface.

2. Because x264 intentionally has an unstable ABI, and the interface is no exception.

3. Because if we don't change the options when we change defaults, people will use old GUIs not built for the new defaults and then we will get dozens of complaints when they notice that the output file has "wrong" settings.

[edrikk]

I guess I disagree (only on item 3), but at the end of the day you are the developer, and not I. :)

With respect to item 3, I think this specific case is a special exception as no new attributes are added or removed, only existing parameters have become defaults. I don't think this case would have resulted in the legacy GUI issue, but again... I'm not this app's developer, and don't know the internals. :)

[Dark Shikari]

I guess I disagree (only on item 3), but at the end of the day you are the developer, and not I. :)

With respect to item 3, I think this specific case is a special exception as no new attributes are added or removed, only existing parameters have become defaults. I don't think this case would have resulted in the legacy GUI issue, but again... I'm not this app's developer, and don't know the internals. :)Simple example:

8x8dct was not default before, now it is. Thus, in an app that wasn't updated, if someone wanted to encode for an iPhone, x264 would produce HIGH PROFILE VIDEO, and it would not work on the iPhone, and we'd get tons of frivolous bug reports.

In fact, Xvid4PSP is a perfect example: the PSP requires Main Profile, but if you used that GUI with the new x264, it would produce High Profile, which would not play!

[edrikk]

Great example, and point well made (as I expected)!
Thanks Shikari!