Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 Encoder GUIs

Reply
 
Thread Tools Search this Thread Display Modes
Old 18th July 2016, 13:58   #1601  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,048
Hi Kypec, actually that warning messages is created by the MUtilities library, which forms the basis of most of my applications nowadays.

Much of that code originates from the LameXP project and has been generalized for library usage. But it's an ongoing job to generalize all the code. That's why you may still find "LameXP" hardcoded in a few places.

I have now fixed (generalized) the message you are referring to. Thanks for pointing me at that! The fix is not included in v2.74 yet though.
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 18th July 2016 at 14:04.
LoRd_MuldeR is offline   Reply With Quote
Old 18th July 2016, 14:03   #1602  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,048
Simple x264 Launcher v2.74
https://github.com/lordmulder/Simple...ases/tag/v2.74

Quote:
Version 2.74 [2016-07-18]
* Updated x265 to version 2.0+2
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.


LoRd_MuldeR is offline   Reply With Quote
Old 26th August 2016, 01:07   #1603  |  Link
almosely
Registered User
 
Join Date: Dec 2006
Location: Germany
Posts: 43
Hi there,

a few minutes ago I updated Simple x264 Launcher and started a .avs-x264-encoding. Something is working wrong. The first issue is: I chose CRF 18.4 but in the joblist is stated "CRF@18". The job details is displaying the correct value, "--crf 18.4". The second issue is: I got insane quantizers listed in the logfile (I-frames Avg-QP=26.55, P-frames Avg-QP=30.35, B-frames Avg-QP=31.93). Both worked fine with the non-updated version before (I don't remember, which version that was, maybe something from april 2016). When I analyze the encoded file with AVInaptic, I get different, more realistic quantizers (I-slices avg DRF=13.91, P-sclices avg DRF=17.61, B-slices avg DRF=19.06). I know that AVInaptic normally differs from the Simple x264 Launchers logfile, but it has never been that much.

- edit -

the version before the update was: Simple x264 Launcher (Build #1026), built 2016-04-29

now it is: Simple x264 Launcher (Build #1038), built 2016-07-18

- edit -

now I downloaded the older version (2016-04-29) and just installed it over the newer one. Do I need to completely uninstall Simple x264 Launcher before or is this working okay?

- edit -

okay, I re-encoded the same test-vid with the downgraded launcher and got the following values:

- "CRF@18.4" (in the joblist)
- I-frames avg QP=14.83
- P-frames avg QP=18.54
- B-frames avg QP=20.04

AVInaptic tells me:

- I-slices avg DRF= 14.03
- P-slices avg DRF=17.71
- B-slices avg DRF=19.07

That sounds more familiar to me.

Last edited by almosely; 26th August 2016 at 01:41.
almosely is offline   Reply With Quote
Old 29th August 2016, 16:01   #1604  |  Link
Minister
Registered User
 
Join Date: Nov 2011
Posts: 11
L_M - There doesn't seem a means to do a manual 2nd pass with previously created stats with Simple x264. I wonder if you'd consider adding the option?

In my current case I'm working with 30 videos, each of which took about 30 minutes to create the first pass stats, and I need to recode them a 2nd time. For the moment I'll just use the CLI to x264 directly (rather than spend another 15 hours recreating the first passes just so I can work with Simple x264 again), but if you thought you could add those manual pass options in rate control, that would be very helpful.
Minister is offline   Reply With Quote
Old 29th August 2016, 19:56   #1605  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,048
Quote:
Originally Posted by almosely View Post
Hi there,

a few minutes ago I updated Simple x264 Launcher and started a .avs-x264-encoding. Something is working wrong. The first issue is: I chose CRF 18.4 but in the joblist is stated "CRF@18". The job details is displaying the correct value, "--crf 18.4". The second issue is: I got insane quantizers listed in the logfile (I-frames Avg-QP=26.55, P-frames Avg-QP=30.35, B-frames Avg-QP=31.93). Both worked fine with the non-updated version before (I don't remember, which version that was, maybe something from april 2016). When I analyze the encoded file with AVInaptic, I get different, more realistic quantizers (I-slices avg DRF=13.91, P-sclices avg DRF=17.61, B-slices avg DRF=19.06). I know that AVInaptic normally differs from the Simple x264 Launchers logfile, but it has never been that much.
The CRF value displayed in the job name is a rounded value - for the sake of simplicity. So this is not necessarily the exact CRF value that you specified and that will be passed to x264.

I'm pretty sure that, if you look at the actual x264 command-line (in your log), you will realize that the "correct" CRF value has been passed to x264.

Also note: In CRF mode, the QP values are allowed to fluctuate as needed. The x264 developers decided to make the CRF value live on the same scale as the QP values, but that was a completely arbitrary decision! Internally, x264 will multiply the value that you passed via --crf parameter with some "magic" number in order to compute the actual constant "rate factor" which will be used for encoding. That "magic" number has been tuned so that using --crf x roughly results in an average QP of x. Again, this was an arbitrary decision. And the tuning was done with a specific set of source clips. Consequentiality, you can not expect that --crf x will result in an average QP of exactly x. It may depend a lot on your particular source video!

In a quick test with "--crf 18.4" and "medium" preset, I got this result:
Quote:
x264 [info]: frame I:401 Avg QP:14.87 size: 35850
x264 [info]: frame P:7835 Avg QP:17.73 size: 13307
x264 [info]: frame B:19384 Avg QP:19.72 size: 5328
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 29th August 2016 at 20:18.
LoRd_MuldeR is offline   Reply With Quote
Old 29th August 2016, 20:19   #1606  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,048
Quote:
Originally Posted by Minister View Post
L_M - There doesn't seem a means to do a manual 2nd pass with previously created stats with Simple x264. I wonder if you'd consider adding the option?
Yes, re-using an existing stats file is not currently possible. Simple x264 Launcher automates the whole 2-Pass process for you. Currently I have no plans to change that, sorry.
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 29th August 2016 at 20:23.
LoRd_MuldeR is offline   Reply With Quote
Old 29th August 2016, 22:17   #1607  |  Link
Minister
Registered User
 
Join Date: Nov 2011
Posts: 11
Quote:
Originally Posted by LoRd_MuldeR View Post
Yes, re-using an existing stats file is not currently possible. Simple x264 Launcher automates the whole 2-Pass process for you. Currently I have no plans to change that, sorry.
That's ok. I appreciate your responding, and for all the great work you've done with this application. Thanks.
Minister is offline   Reply With Quote
Old 29th August 2016, 22:18   #1608  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,048
Here is a new TEST version:
https://sourceforge.net/projects/mul...9.exe/download

x265 and NVEncC updated to latest versions.
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.


LoRd_MuldeR is offline   Reply With Quote
Old 31st August 2016, 09:12   #1609  |  Link
almosely
Registered User
 
Join Date: Dec 2006
Location: Germany
Posts: 43
Thanks for your reply, Lord_Mulder,

I did know all that before ... And I showed you the difference between your latest version (working wrong) and the older version of your launcher (working right) - but I think, you did not read that. And I told you, that I see the correct crf-value in the logfile, but not in the joblist ... And I showed you too, that I know, that a p-frames Quantizer of 17.xx is completely normal for a crf 18.4 encoding, the same as a p-frame Quantizer with a value of 19.xx would be too - but a value about 30.xx is not right at all (with the actual version of your launcher), especially when the value is about 17.xx, when I encode the same video with the same crf-value with the older version of your launcher.

Either your launcher is working wrong or the used x264-version, in case of the listed, insane quantizers (they are avg quantizers, not peaks).

And, I liked it more, as the crf-value was not rounded. I often encode the same video (5% compression-test) a few times, to find out the crf value I want. A quick look into the joblist, with the correct crf value instead of a rounded one, was a lot more convenient for me.

So, I am still using the "outdated" april-version of your launcher and will not update again, till this is fixed.

Last edited by almosely; 31st August 2016 at 09:19.
almosely is offline   Reply With Quote
Old 31st August 2016, 21:18   #1610  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,048
There is nothing to be fixed

As long as Simple x264 Launcher is passing the "correct" CRF value to x264.exe on the command-line – and your confirmed yourself that it does – there is no problem on the Simple x264 Launcher side. The CRF value in the job list is irrelevant.

Furthermore: As far as I can tell, there is no problem on the x264 side either. As explained before, CRF mode does not guarantee that a CRF value of x will result in an average QP of x. CRF mode does not even guarantee that a CRF value of x will result in an average QP close to x. This may be the case for a specific set of "reference" source clips, but it is not guaranteed for all source clips. For your specific source clip it may not be the case at all!

It was a completely arbitrary decision of the x264 developers to make CRF values live on the same scale as QP values! This is just for convenience. They could have decided to make the CRF value live on a 0.0 to 1.0 scale just as well...

(If you still think x264 is doing anything wrong here, you have to bother the x264 developers. But you will probably get the same answer)
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 31st August 2016 at 21:33.
LoRd_MuldeR is offline   Reply With Quote
Old 31st August 2016, 23:37   #1611  |  Link
almosely
Registered User
 
Join Date: Dec 2006
Location: Germany
Posts: 43
Of course I still think theres a problem, but it seems to be within x264. As I said, I encoded the same video with the same parameters, once with your april-version, another time with the newest one. And I got almost twice as high quantizers with your newest one. So, there has to be a problem, but inside x264, as you guessed.

The rounded crf-value in your joblist is not irrelevant TO ME. It would help me, if it would still be the full parameter. As it would help me, if I could see, whether the automatic shutdown is active or not, without going into the prefs before - as I mentioned a few months ago. But, of course, both is YOUR decision and I have to live with that.

Thanks again, anyway, for this nice tool.
almosely is offline   Reply With Quote
Old 1st September 2016, 01:04   #1612  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,048
Quote:
Originally Posted by almosely View Post
Of course I still think theres a problem, but it seems to be within x264. As I said, I encoded the same video with the same parameters, once with your april-version, another time with the newest one. And I got almost twice as high quantizers with your newest one. So, there has to be a problem, but inside x264, as you guessed.
The meaning of the CRF values has changed many times in the history of x264. Therefore you cannot expect that a specific CRF value still has the same meaning in the "new" that it had in the "old" version.

Also, how do you know the "new" version is performing worse than the "old" version? Did you actually compare the resulting files visually? Or how did you come to the conclusion that the "new" version has a problem?

(Of course you can only compare file of the same file size, otherwise you are comparing apples and oranges. Thus, if necessary, adjust the CRF value so that both versions produce a file of the same size)
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 1st September 2016 at 01:07.
LoRd_MuldeR is offline   Reply With Quote
Old 1st September 2016, 18:45   #1613  |  Link
almosely
Registered User
 
Join Date: Dec 2006
Location: Germany
Posts: 43
I noticed a little variance in resulting quantizers for crf-encondings (listed in the logfiles of x264) over the years and different x264-versions, but never that much (from 18.xx to 30.xx). Mostly I try to get a value of around 19.0 for the average p-frames of my encodings. I did a lot of testing on my smartphone, pc, stand-alone and lcd-tv and found, that this is a very good quality-filesize-relation for me. Sometimes I need a 16.xx CRF-value to achieve that, sometimes CRF 22.xx is enough. If x264 has changed that behaviour that much, for what p-frame-quantizers should I aim now - 30, 34, 27 ... or should I use a CRF-value around 8 or something? I am used to rely on that values. Furthermore, every enconding-guide (Brother Johns ...) I ever read relies on the resulting quantizers (with CRF too) as a quality-scale and proposes something between 18-20 for good encodings. Therefore I downgraded to the older version of your launcher with the old x264-version, to still know what I am doing.

I knew that the "new" version is working wrong (or at least very different), because I updated to the newest version, did run a 5%-compression-test and got 30.xx values for the avg p-frame-quantizers in the logfile of x264 (with a CRF-value of 18.4). Then I downgraded your launcher (without deinstalling before), did the same compression-test again and got 18.xx values for the p-frames (of the same file with the same enconding-parameters). I did not compare visually neither on other ways than looking into the x264-logfiles.

-edit-

I just compared the two logfiles of these compression-tests and found, that the "new" one (with the 30.xx p-frame-quantizers) started a 10-bit-depth-encoding and the "old" one a 8-bit-depth-encoding. Perhaps that explaines the difference? But I just updated to your newest launcher, did run the test, downgraded and did run the test and never adjusted the value for the bit-depth, so maybe the standard-values of your old and new launcher-version have changed?

Last edited by almosely; 1st September 2016 at 19:17.
almosely is offline   Reply With Quote
Old 1st September 2016, 19:24   #1614  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,048
Quote:
Originally Posted by almosely View Post
I just compared the two logfiles of these compression-tests and found, that the "new" one (with the 30.xx p-frame-quantizers) started a 10-bit-depth-encoding and the "old" one a 8-bit-depth-encoding. Perhaps that explaines the difference? But I just updated to your newest launcher, did run the test, downgraded and did run the test and never adjusted the value for the bit-depth, so maybe the standard-values of your old and new launcher-version have changed?
Of course, 8-Bit vs. 10-Bit makes a significant difference. They don't even use the same QP scale, which means you can't really compare those QP values.

When creating the job, did you select "8-Bit" or "10-Bit" encoder variant? I just did a quick test and Simple x264 Launcher seems to run the "correct" encoder, as selected by the user in job creating dialog.
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.


LoRd_MuldeR is offline   Reply With Quote
Old 1st September 2016, 19:50   #1615  |  Link
almosely
Registered User
 
Join Date: Dec 2006
Location: Germany
Posts: 43
That is the question. I think, I did not select/adjust anything else than the crf-value. I just updated, draged the .avs-file in and started the encoding. I assumed, that every parameter would be the same as before the update. I think, thats what happened. I did not even think about changing the bit-depth. But I will update again and watch out for the bit-depth-parameter (the standard-value in the gui after the update) and try some encodings with the new launcher version. Sadly I do not have the former test-video to repeat everything exactly, but I will test with another video.

Last edited by almosely; 1st September 2016 at 21:55.
almosely is offline   Reply With Quote
Old 2nd September 2016, 13:00   #1616  |  Link
almosely
Registered User
 
Join Date: Dec 2006
Location: Germany
Posts: 43
So, I just updated your launcher, made a screenshot before and after that and figured out, that the standard-value for the bit-depth has changed after the update, from 8 bit to 10 bit. That's it. And I tested a little bit more. If I change "encoder", "architecture", "variant", "mode", "quantizer/crf", "preset", "tuning" and "profile" and load a saved template after that, everything is reconfigered like I saved it in the template, but not the bit-depth - this parameter is back on 10-bit. I never use 10-bit to encode. I always encode in 8-bit.

-edit-

I tested a little bit more. It seems that the bit-depth was not been saved in the templates before the update, because now I changed the bit-depth, saved a template, loaded an old template (bit-depth changed to 10 - your new standard value for this parameter), loaded the new template (bit-depth changed to 8). Okay, I will update my templates, then it should be okay.

And ... is there any possibility that your updater will not stress my firewall and fingers next time with around 10-15 clicks to allow your updater to work and complete? I have to click that much every time, because you use random and temporary names for every step in this job.

Last edited by almosely; 2nd September 2016 at 13:09.
almosely is offline   Reply With Quote
Old 2nd September 2016, 19:51   #1617  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,048
Quote:
Originally Posted by almosely View Post
I tested a little bit more. It seems that the bit-depth was not been saved in the templates before the update, because now I changed the bit-depth, saved a template, loaded an old template (bit-depth changed to 10 - your new standard value for this parameter), loaded the new template (bit-depth changed to 8). Okay, I will update my templates, then it should be okay.

And ... is there any possibility that your updater will not stress my firewall and fingers next time with around 10-15 clicks to allow your updater to work and complete? I have to click that much every time, because you use random and temporary names for every step in this job.
In the current version, just as in all previous versions, the "8-Bit" encoder variant is the default, not "10-Bit". You can easily confirm that by removing or renaming your "templates.ini", which will reset everything to the defaults.

If you look in "templates.ini" more closely, you will see that the "8-Bit" and "10-Bit" encoder variants are now saved correctly as "encoder_variant=0" and "encoder_variant=1", respectively. Also these values are loaded correctly from the INI file.

However, there has been an "issue" in some older versions, which caused the "encoder_variant" index to not be zero-based (but one-based). So, "8-Bit" had actually been saved as "encoder_variant=1". And "10-Bit" as "encoder_variant=2".

(This is a bit unfortunate, if you still have some "old" templates, yes. But it can not be fixed retrospectively. And, fixing up your "old" templates once, should be fairly trivial to do)
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 2nd September 2016 at 19:58.
LoRd_MuldeR is offline   Reply With Quote
Old 16th September 2016, 17:48   #1618  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,048
Here is a new TEST version:
https://sourceforge.net/projects/mul...5.exe/download

x265 updated to latest version.
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.


LoRd_MuldeR is offline   Reply With Quote
Old 25th September 2016, 18:31   #1619  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,048
Simple x264 Launcher v2.75
https://github.com/lordmulder/Simple...ases/tag/v2.75

Quote:
Version 2.75 [2016-09-25]
* Updated build environment to Visual Studio 2015 with Update-3
* Updated x264 to revision 2721
* Updated x265 to version 2.0+54
* Updated NVEncC to version 2.11
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.


LoRd_MuldeR is offline   Reply With Quote
Old 13th October 2016, 23:53   #1620  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,048
Here is a new TEST version:
https://sourceforge.net/projects/mul...3.exe/download

Code:
WHAT'S NEW:
* Updated x265 to version 2.1+20
* Detection of "portable" VapourSynth (see README for details!)
* Detection of "portable" Avisynth (see README for details!)
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.


LoRd_MuldeR is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 00:58.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.