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 29th May 2020, 10:53   #9021  |  Link
tebasuna51
Moderator
 
tebasuna51's Avatar
 
Join Date: Feb 2005
Location: Spain
Posts: 6,890
Quote:
Originally Posted by Lord Dredd View Post
Would you kindly enlighten me about when and how one should use

vbv_maxrate
vbv_bufsize

I guess they do the same thing as those ffmprg commands but I was wondering how to use these if suppose I am gonna use a slower or very slow profile to encode in 2 pass or crf.

But then If VBR is what both x264 and x265 encode with then may be these are not used anymore ???
These parameters are to guarantee than you can play that encode without problems.

For instance if you store the movie with Maximum bit rate : 8 921 kb/s in a DVD (typical max read rate 5 Mb/s) you can have troubles in the points with high bitrate. But if you store the movie in a USB 2 (at least 20 Mb/s reading) all is ok.

Also related with the player to reproduce your encode, must guarantee the speed to support this max bitrate and the amount of buffer RAM (buffer size) to store the images to be decodified (related with resolution and num of ref-frames).

The easy way to control these parameters is use the parameter --level, you must know the level than your player accept. For instance a player certified to DivX Plus (--level 4.0 see Levels in this wiki) accept --vbv-maxrate 20000 --vbv-bufsize 25000.

You can see in the x264 Configuration Dialog in MeGUI how change these parameters when you select the Target Playback Device.

Of course modern players certified for UHD accept --level 5.1 and the maxrate/bufsize are so high than you don't need to limit your encode with low resolution/bitrate.

And these parameters aren't related with the Preset (slow or other) or the Encoding Mode (crf or 2pass) like you can see in the Configuration Dialog, only with the Target Playback Device.
__________________
BeHappy, AviSynth audio transcoder.
tebasuna51 is offline   Reply With Quote
Old 29th May 2020, 11:01   #9022  |  Link
Lord Dredd
a Hobby Encoder :)
 
Join Date: Feb 2016
Posts: 28
Quote:
Originally Posted by LigH View Post
VBV parameters are important when the player with a limited decoding buffer has to read from a medium with limited read speed, in contrast to a PC reading from a local harddisk with generous RAM and read speed.

That will mainly affect consumer players playing movies from an optical disc or a Flash memory stick/card, or any player (even a PC with large RAM) receiving the movie vie a network with a bandwidth close to the average bitrate.

Consumer devices and media (e.g. Blu-ray players) will have more or less publicly known specifications about their supported limits. Apart from that it may be a challenge to discover the decoding buffer capacity and the read speed...
Thanks for the explanation

Quote:
Originally Posted by tebasuna51 View Post
These parameters are to guarantee than you can play that encode without problems.

For instance if you store the movie with Maximum bit rate : 8 921 kb/s in a DVD (typical max read rate 5 Mb/s) you can have troubles in the points with high bitrate. But if you store the movie in a USB 2 (at least 20 Mb/s reading) all is ok.

Also related with the player to reproduce your encode, must guarantee the speed to support this max bitrate and the amount of buffer RAM (buffer size) to store the images to be decodified (related with resolution and num of ref-frames).

The easy way to control these parameters is use the parameter --level, you must know the level than your player accept. For instance a player certified to DivX Plus (--level 4.0 see Levels in this wiki) accept --vbv-maxrate 20000 --vbv-bufsize 25000.

You can see in the x264 Configuration Dialog in MeGUI how change these parameters when you select the Target Playback Device.

Of course modern players certified for UHD accept --level 5.1 and the maxrate/bufsize are so high than you don't need to limit your encode with low resolution/bitrate.

And these parameters aren't related with the Preset (slow or other) or the Encoding Mode (crf or 2pass) like you can see in the Configuration Dialog, only with the Target Playback Device.
Once again loads of thankies for the elaborating mate.
Now I know why a animation that I had encoded sometime back didnt play on my TV , I had used tune animation along with crf and the level came out to be 5 and I realized my TV cant play anything with level 5
Thanks
Lord Dredd is offline   Reply With Quote
Old 30th May 2020, 06:11   #9023  |  Link
imsrk48
Registered User
 
imsrk48's Avatar
 
Join Date: Nov 2017
Posts: 154
Hey Guys, How can i increase a 5.1 audio channel volume using megui?
imsrk48 is offline   Reply With Quote
Old 30th May 2020, 15:46   #9024  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
@imsrk48
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???
StainlessS is offline   Reply With Quote
Old 31st May 2020, 20:33   #9025  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
I would suggest to stay a little below 100%, because lossy compression may cause decoding >100%, a.k.a. clipping.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 1st June 2020, 00:44   #9026  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
Ligh, think mine set at 96, that sound about OK ?
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???
StainlessS is offline   Reply With Quote
Old 1st June 2020, 03:58   #9027  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
96 is a fraction more than stuff-all less than 100, when translated to dB. It's -0.35dB.
An increased peak of 1dB wouldn't be too unusual for lossy encoding, and for some reason AAC seems worse than MP3 in that respect. If you want a margin for error:

0.9 = -0.91dB
0.8 = -1.9dB
0.7 = -3.09dB

I don't know how to write the equation properly, but the dB value is the log of the percentage multiplied by 20 (where 100% = 1.0)

Have I ever heard the clipping when normalising to 100? Nope.

Of course I disproved everything I just said while trying to provide examples. The peaks didn't change all that much, and all but one was lower, but I have seen an increase of close to 2dB on rare occasions. The peaks were the result of 4 times over-sampling to obtain the true peak, rather than the sample peak.

If this is any indication though, 96 should generally be fine.



PS StainlessS, I bumped into your comment here (thanks, by the way), so I thought I'd mention, if you haven't seen it, the idea inspired me to create some more MeGUI functions. In case you're interested......
https://forum.doom9.org/showthread.php?t=181500

Last edited by hello_hello; 1st June 2020 at 04:56.
hello_hello is offline   Reply With Quote
Old 1st June 2020, 15:31   #9028  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
I dont like to go too low, especially if viewing on hand held (phone) where volume of device can sometimes be quite low,
but thank you HH.
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???
StainlessS is offline   Reply With Quote
Old 4th June 2020, 15:53   #9029  |  Link
Lord Dredd
a Hobby Encoder :)
 
Join Date: Feb 2016
Posts: 28
Quote:
Originally Posted by imsrk48 View Post
Hey Guys, How can i increase a 5.1 audio channel volume using megui?
I may raise certain eyebrows but I found MEGUI wanting in audio encoding, no matter wht I did I always ended up encoding a low volume aac file ..
after many months I moved to pazera
It raises volume upto three times and its pretty efficient in encoding AAC , AC3 , MP3 ans a whole lot of other .. give it a go
Converting your 5.1 audio file to 5.1 ac3 9 mimimum would be 256 but 384 sounds very very good and aint big at all ]with volume slider all the way to right will surprise you.

=======================================

@ tebasuna51 and Hello_Hello
I am still not able to fine a way to display maximum bit-rate in a megui encoded video.

Also what are you guyz's thoughts about ABR encoding , 2 pass takes the most time but you know what you are doing , CRF well you cant really predict the size.. but I find CRF method to be pretty faster as its single pass..
DO you guys think its better to use ABR considering its 1 pass ( so less time ) plus you can predict the file size as well ??

What about the quality, will it be similar to 2pass for a given bitrate ??
I am again talking about bitrates in the range of 1500 to 2000 only ...

Also I know one should always keep thread count to 0/auto.. but to maximize CPU usage if there are no other bottlenecks, how many threads I can input just to make sure that maximum cpu is used while encoding..

Thank you
Lord Dredd is offline   Reply With Quote
Old 5th June 2020, 00:15   #9030  |  Link
tebasuna51
Moderator
 
tebasuna51's Avatar
 
Join Date: Feb 2005
Location: Spain
Posts: 6,890
Quote:
Originally Posted by Lord Dredd View Post
I may raise certain eyebrows but I found MEGUI wanting in audio encoding, no matter wht I did I always ended up encoding a low volume aac file ..
after many months I moved to pazera
It raises volume upto three times and its pretty efficient in encoding AAC , AC3 , MP3 ans a whole lot of other .. give it a go
From Pazera web:
Quote:
3rd party software
To encode the video and audio files the program uses the FFmpeg encoder (ffmpeg.org).
With MeGUI you can do the same, select the proper settings.

Quote:
I am still not able to fine a way to display maximum bit-rate in a megui encoded video.
For what yo need know this?

Quote:
DO you guys think its better to use ABR considering its 1 pass ( so less time ) plus you can predict the file size as well ??
Nope, use always crf.

Quote:
What about the quality, will it be similar to 2pass for a given bitrate ??
Yes

Quote:
Also I know one should always keep thread count to 0/auto.. but to maximize CPU usage if there are no other bottlenecks, how many threads
Let Auto
__________________
BeHappy, AviSynth audio transcoder.
tebasuna51 is offline   Reply With Quote
Old 5th June 2020, 06:37   #9031  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Quote:
Originally Posted by Lord Dredd View Post
I may raise certain eyebrows but I found MEGUI wanting in audio encoding, no matter wht I did I always ended up encoding a low volume aac file ..
after many months I moved to pazera
It raises volume upto three times and its pretty efficient in encoding AAC , AC3 , MP3 ans a whole lot of other .. give it a go
Converting your 5.1 audio file to 5.1 ac3 9 mimimum would be 256 but 384 sounds very very good and aint big at all ]with volume slider all the way to right will surprise you.
That bothers me a little because increasing the volume with Pazera doesn't seem to offer any clipping protection if you increase it too much. Do you use the Normalise option when converting with MeGUI?

My little comparisons were for a 5.1ch file downmixed to stereo, because without normalisation that's when you can notice a fair volume drop, because the volume should be lowered enough when downmixing so when the channels are combined they can't exceed maximum, even if the individual channels all happen to be at maximum at the same time.

Pazera simply downmixed and increased the volume with ffmpeg like this:
-c:a pcm_s16le -ac 2 -af volume=3.00
Without the volume adjustment, it's just this:
-c:a pcm_s16le -ac 2

MeGUI would be slower if you normalise, because it requires two passes. One to check the peak levels, then a second to adjust the volume and encode.

I assume ffmpeg uses a slightly different formula for downmixng than MeGUI, and I use a downmix formula using foobar2000 that's slightly different again, hence the average volumes being different in the screenshot below.
I assume ffmpeg has a method for normalising the peaks to 0dB, but Pazera doesn't seem to offer the option in the GUI.

Pazera 1x - Standard ffmpeg downmix.
MeGUI No Normalise - Standard MeGUI downmix without normalisation.
Foobar2000 Downmix Prevent Clipping - same as "MeGUI No Normalise" but using a different downmix formula.
Pazera 3x - Standard ffmpeg downmix plus Volume=3.
MeGUI Peak Normalise 95 Percent - Standard MeGUI downmix with peak normalisation set to 95%.
Foobar2000 Downmix - downmixed without reducing the volume to prevent the possibility of clipping. In this case there wasn't any.
Pazera 3x Foobar2000 Downmix - I used Pazera to re-encode the "Foobar2000 Downmix" file above while increasing the volume 3x. The average volume increased by around 10dB but the peaks were already just under maximum, so I assume they were clipped pretty hard.

If you're cranking the volume while re-encoding 5.1ch audio (without downmixing), I think you're very likely to cause the peaks to be clipped. It'd be no different to re-encoding stereo audio with peaks already at or close to 0dB, while cranking the volume.
The Track Gain column is a ReplayGain thing. You can ignore it. The Volume and Peak columns show the average and peak levels according to an EBU R128 scan, which is what I was interested in.





Quote:
Originally Posted by Lord Dredd View Post
@ tebasuna51 and Hello_Hello
I am still not able to fine a way to display maximum bit-rate in a megui encoded video.
None of my encodes display it. Maybe it's something written by ffmpeg or a particular build of x264.

Quote:
Originally Posted by Lord Dredd View Post
Also what are you guyz's thoughts about ABR encoding , 2 pass takes the most time but you know what you are doing , CRF well you cant really predict the size.. but I find CRF method to be pretty faster as its single pass..
DO you guys think its better to use ABR considering its 1 pass ( so less time ) plus you can predict the file size as well ??
Don't even consider contemplating the possibility of using ABR encoding. The encoder starts encoding and adjusts the quality to hit the target bitrate as it goes, because all it can do is guess. Find a shortish sample with a complex picture (and lots of movement) and encode them both at the same low bitrate using 2 pass and ABR and you should see the difference.
x264's rate control methods

Quote:
Originally Posted by Lord Dredd View Post
Also I know one should always keep thread count to 0/auto.. but to maximize CPU usage if there are no other bottlenecks, how many threads I can input just to make sure that maximum cpu is used while encoding.
If memory serves, the default of zero means the thread count is 1.5x the number of CPU cores.

Last edited by hello_hello; 5th June 2020 at 07:37.
hello_hello is offline   Reply With Quote
Old 5th June 2020, 07:31   #9032  |  Link
Lord Dredd
a Hobby Encoder :)
 
Join Date: Feb 2016
Posts: 28
Thanks a bunch T
Take care Bud
Stay safe

EDIT :
To make the first pass faster i have set FFMS Thread count to 0 without any crashes , issues or stuff
Hope thats okay..

EDIT02
: Totally missed your post @ Hello_Hello
many thanks , But i used pazera to convert very high bitrate 5.1 ac3 audio to 2 channel aac audio.
and sometimes 5.1 high bitrate ac3 to 5.1 384kbps ac3

EDIT03 :
I read your post that you linked @Hello_Hello , TBH I would always want to encode the videos ( whenever my encoding bug starts to bite ) using CRF only..
I had started with a number of my DVDs ( a few years back ) and after converting a few i kept all the raw files in a HDD to experiment later , by the time Blurays got cheaper and once a tried a BR too.though my system needs a update as far as the ardware is concerned.

but the crux is I saw huge huge files when there was grain in the source video, crf gave big files and i stayed with 2 pass..
TBH even now I wonder about a simple degrain filter of avisynth coz I just cant get myself to use those complex filters lol

Same is with sharpening and denoising
I am experimenting with what you told about using the x264 inbuilt noise reducer and I am sure this will prove utterly helpful..
will be trying sharpen() filer only coz the videos that I am working on were professionally made, and then filtered, edited and made into a final copy by an office mate who is a specialist..

I am trying to hammer em a bit more just for the heck of it, you always learn new things by looking at professional material.

Last edited by Lord Dredd; 5th June 2020 at 15:23.
Lord Dredd is offline   Reply With Quote
Old 6th June 2020, 15:09   #9033  |  Link
Lord Dredd
a Hobby Encoder :)
 
Join Date: Feb 2016
Posts: 28
Quote:
Originally Posted by hello_hello View Post
That bothers me a little because increasing the volume with Pazera doesn't seem to offer any clipping protection if you increase it too much. Do you use the Normalise option when converting with MeGUI?

My little comparisons were for a 5.1ch file downmixed to stereo, because without normalisation that's when you can notice a fair volume drop, because the volume should be lowered enough when downmixing so when the channels are combined they can't exceed maximum, even if the individual channels all happen to be at maximum at the same time.

Pazera simply downmixed and increased the volume with ffmpeg like this:
-c:a pcm_s16le -ac 2 -af volume=3.00
Without the volume adjustment, it's just this:
-c:a pcm_s16le -ac 2

MeGUI would be slower if you normalise, because it requires two passes. One to check the peak levels, then a second to adjust the volume and encode.

I assume ffmpeg uses a slightly different formula for downmixng than MeGUI, and I use a downmix formula using foobar2000 that's slightly different again, hence the average volumes being different in the screenshot below.
I assume ffmpeg has a method for normalising the peaks to 0dB, but Pazera doesn't seem to offer the option in the GUI.

Pazera 1x - Standard ffmpeg downmix.
MeGUI No Normalise - Standard MeGUI downmix without normalisation.
Foobar2000 Downmix Prevent Clipping - same as "MeGUI No Normalise" but using a different downmix formula.
Pazera 3x - Standard ffmpeg downmix plus Volume=3.
MeGUI Peak Normalise 95 Percent - Standard MeGUI downmix with peak normalisation set to 95%.
Foobar2000 Downmix - downmixed without reducing the volume to prevent the possibility of clipping. In this case there wasn't any.
Pazera 3x Foobar2000 Downmix - I used Pazera to re-encode the "Foobar2000 Downmix" file above while increasing the volume 3x. The average volume increased by around 10dB but the peaks were already just under maximum, so I assume they were clipped pretty hard.

If you're cranking the volume while re-encoding 5.1ch audio (without downmixing), I think you're very likely to cause the peaks to be clipped. It'd be no different to re-encoding stereo audio with peaks already at or close to 0dB, while cranking the volume.
The Track Gain column is a ReplayGain thing. You can ignore it. The Volume and Peak columns show the average and peak levels according to an EBU R128 scan, which is what I was interested in.







None of my encodes display it. Maybe it's something written by ffmpeg or a particular build of x264.



Don't even consider contemplating the possibility of using ABR encoding. The encoder starts encoding and adjusts the quality to hit the target bitrate as it goes, because all it can do is guess. Find a shortish sample with a complex picture (and lots of movement) and encode them both at the same low bitrate using 2 pass and ABR and you should see the difference.
x264's rate control methods



If memory serves, the default of zero means the thread count is 1.5x the number of CPU cores.


Yes I always used to use normalize option when I used to downmix 5.1 to stereo 128kbps HE or LC AAC.

You may be right about me cranking up the volume levels in pazera , BUt I ll be honest I found the audio much m,uch better on both my LG and Panasonic TVs , But yet to listen to this audio with my soundbar and home theater ( long story lock down has put off a lot of repair works )

But I am game if you could guide me about which options to choose and which boxes to tick while downmixing a 5.1 DD to a 2 channel stereo & also converting a 5.1 AC3 DD or ATmos to 384kbps DD


===============

Apart from a few questions asked above I had some more queries about MEGUI
just yesterday I found a profile zip from 3 or may be 4 years back and in that qpmin was set to 10 and qpmax was set to 51
But in MEGUI x264 profiles they have been changed to 0 and 81 ( 69) actually whats your opinion : for lower , low and average bitrates x264 encodes what should be the values , are there some other settings as well in SLOWER profile apart from --nr that you guys feel should be changed to have better results.

whats your view of ref frames and bframes ( wrt slower profiles ) , some people advocate cranking them up a bit more especially bframes especially for low bitrate videos ???

This is a mediainfo detail of a 200MB video
I was surprised how a 200MB video of this much duration have bitrate that high.. This is some a friend of mine sent to me this morning, I have asked him to share the video as well but I dunno... I could make out its been encoded using Medium x265 profile with a crf of 23.5 but its totally beyond my understanding, Either this video has fabke info added to it or may be there is some secret recipe...


Quote:
Format/Info : High Efficiency Video Coding
Format profile : Main@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 42 min 28 s
Bit rate : 8 007 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.161
Stream size : 2.38 GiB
Writing library : x265 2.5+9-fdf39a97ecb8:[Linux][GCC 6.4.0][64 bit] 8bit+10bit+12bit
Encoding settings : cpuid=1050111 / frame-threads=3 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=23 / keyint=250 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=2 / limit-refs=3 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=3 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-reuse-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=23.5 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=0 / no-limit-sao / ctu-info=0
Default : Yes
Forced : No
Lord Dredd is offline   Reply With Quote
Old 6th June 2020, 20:10   #9034  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Lord Dredd,
When it comes to being able to hear everything without the loud parts being stupidly loud, I'd recommend trying the Dynamic Audio Normalizer. I use my PC as a media player so I downmix and compress the audio as it's being played (via ffdshow and a WinAmp plugin), but for the TV in another room I generally downmix to stereo and compress with the DAN.

A relativity easy way to try it (hopefully) is to download the portable version of foobar2000 I uploaded here. You'll also need ffmpeg. There's a text file with some instructions included. Once you're done you can load an audio file into a playlist, right click, select convert, and a list of my conversion presets will pop up. One is called "Downmix and Compression - Dynamic Audio Normalizer" or something similar. Select that preset and the output will be AAC. It's not overly high bitrate as I generally use it to create a temporary copy of the audio for watching in another room, but it's easy enough to edit/create a preset with higher bitrate AAC.

If you want to hear what it does, there's a zip file attached to this post with some samples nobody bothered listening to. I was trying to show how much better it is than the method the OP was using. The idea is to compare the level of the speech at the beginning with the level of the loud stuff at the end. Ideally the loud stuff stays at the same volume while the quiet stuff gets louder. The audio in the zip file with the DAN settings I use is called "f=150 b=1.flac". There's another DAN example included using someone else's settings for comparison, although I prefer mine.

Edit: Thinking about it, Pazera lets you add stuff to the ffmpeg command line. Use it to downmix to stereo and add the following to the custom command line section. Leave the volume at 1x.
-af dynaudnorm=f=150:b=1
I haven't tested it, but it should work. I assume if you convert to AAC, Pazera uses ffmpeg to encode. The difference between doing it that way and my foobar2000 preset, is my preset uses ffmpeg to compress with the DAN, but it pipes the audio to QAAC for the actual encoding (and I probably downmix to stereo a little differently).
It'd possibly also work if you add it to the custom command line section for the formats where MeGUI uses ffmpeg for encoding, but if you do, don't enable peak normalising, or at least try it with and without.

I can't offer much of an opinion on qpmin/qpmax as I never play with them.

In theory, a higher number of reference and B frames should increase the possibility of compressing more for a given bitrate, but as a rule I just use the slow or slower preset and the number of reference and B frames that preset uses. How effective increasing the number of ref and B frames is, probably also depends on the motion estimation algorithm being used. I'm not much of an x264 tweaker but under x264's standard error stream in the MeGUI log file, there's information on reference and B frame usage.

ref P L0: 60.3% 16.9% 15.4% 3.5% 3.4% 0.4% 0.0%
ref B L0: 93.8% 4.7% 1.1% 0.4%
ref B L1: 99.0% 1.0%

I can't remember how to interpret it properly but the above was the result of the MeGUI command line below. Someone else may be able to explain it, but the way I remember it is if the numbers at the end of each line are zero or very close to it, you're into wasting CPU cycles territory if you increase the number of ref/B frames further.

"C:\Program Files\MeGUI\tools\x264\x264.exe" --level 4.1 --preset slow --tune film --crf 18.0 --min-keyint 25 --b-adapt 2 --vbv-bufsize 50000 --vbv-maxrate 50000 --me umh --stitchable --colormatrix bt470bg --sar 1:1 --frames 36931 --output "D:\0111.mkv.mkv" "D:\0111.mkv.avs"

According to MediaInfo your example isn't 200MB. Maybe you looked at the size of the audio stream by mistake.

Stream size : 2.38 GiB

Last edited by hello_hello; 7th June 2020 at 09:59.
hello_hello is offline   Reply With Quote
Old 6th June 2020, 21:47   #9035  |  Link
tebasuna51
Moderator
 
tebasuna51's Avatar
 
Join Date: Feb 2005
Location: Spain
Posts: 6,890
Quote:
Originally Posted by Lord Dredd View Post
...for lower , low and average bitrates x264 encodes what should be the values , are there some other settings as well in SLOWER profile apart from --nr that you guys feel should be changed to have better results.
Nothing, please let the defaults than developers select for each profile.
Do you think than there are somebody than know better the encoder than the developers?

Select crf, preset, Target Playback device and encode.

Modify defaults can work ok for a movie but bad for another.
Don't exist miracle settings, let defaults.

Quote:
whats your view of ref frames and bframes ( wrt slower profiles ) , some people advocate cranking them up a bit more especially bframes especially for low bitrate videos ???
Select preset VeriSlow (8 bframes, 16 ref-frames) or Placebo (16 bframes, 16 ref-frames)

Some playback devices can't support many bframes/ref-frames, don't forget the --level parameter.
__________________
BeHappy, AviSynth audio transcoder.
tebasuna51 is offline   Reply With Quote
Old 6th June 2020, 23:08   #9036  |  Link
tebasuna51
Moderator
 
tebasuna51's Avatar
 
Join Date: Feb 2005
Location: Spain
Posts: 6,890
Quote:
Originally Posted by hello_hello View Post
ref P L0: 60.3% 16.9% 15.4% 3.5% 3.4% 0.4% 0.0%
ref B L0: 93.8% 4.7% 1.1% 0.4%
ref B L1: 99.0% 1.0%

I can't remember how to interpret it properly but the above was the result of the MeGUI command line below. Someone else may be able to explain it, but the way I remember it is if the numbers at the end of each line are zero or very close to it, you're into wasting CPU cycles territory if you increase the number of ref/B frames further.
Preset slow implies --ref 5 and --weightp 2 is the default, then:

ref P L0: 60.3% of P frames have 1 reference
16.9% of P frames have 2 references
15.4% of P frames have 3 references
3.5% of P frames have 4 references
3.4% of P frames have 5 references
0.4% of P frames have 6 references
0.0% of P frames have 7 references (weightp 2 accept 2 more than the limit of --ref 5)

ref B L0: 93.8% of B frames have 1 back reference
4.7% of B frames have 2 back references
1.1% of B frames have 3 back references
0.4% of B frames have 4 back references

ref B L1: 99.0% of B frames have 1 forward reference
1.0% of B frames have 2 forward references

The % of B frames with 4 ref is very low, if the encode is a 1080p can't have 5 ref with --level 4.1 --vbv-bufsize 50000

Like you say search for more ref is waste the time.
__________________
BeHappy, AviSynth audio transcoder.
tebasuna51 is offline   Reply With Quote
Old 7th June 2020, 00:01   #9037  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Awesome tebasuna51. Thanks!

Edit: Looking again I picked a SD encode to use as an example, but at least we know what it all means now.

Last edited by hello_hello; 7th June 2020 at 01:18.
hello_hello is offline   Reply With Quote
Old 8th June 2020, 13:15   #9038  |  Link
Lord Dredd
a Hobby Encoder :)
 
Join Date: Feb 2016
Posts: 28
Thanks a lot for the insight again @ Hello_Hello
Will try and do the downmixing first then. as far as that stream size goes , I think the encoder has removed real info and added source info to the video. This is actually what the video mediainfo shows.

@ tebasuna51 : Indeed the developers know best , I donno 0.00000000001% TBH , Hence I keep lurking here time and again
I dont think I ll ever use any other preset than SLOWER, ever
As advised gonna stick to what the devs have pointed


One thing thats still a mystery to me is why all x265 encoded videos via MEGUI are cooler in color, do we need to tweak something or add something to the commandline to keep the colors similar to the source ..
Thanks
Lord Dredd is offline   Reply With Quote
Old 8th June 2020, 14:34   #9039  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
The x265 thing might be a rec.601 vs rec.709 vs rec.2020 issue.
https://en.wikipedia.org/wiki/Rec._601
https://en.wikipedia.org/wiki/Rec._709
https://en.wikipedia.org/wiki/Rec._2020

YV12 has to be converted to RGB on playback for display, and SD, HD and UHD use different formulas. It's more likely the player is making an assumption based on resolution and that's why the colors look different. Or the video card's drivers are borked. What's the resolution of the source and encode?
YV12 sources should just be decompressed and re-encoded as YV12 without a conversion to RGB and back (unless you're converting to RGB in a script for a filter that requires it), so re-encoding itself shouldn't change the colors, unless you downscale or upscale. For example, a SD source would usually be converted to RGB on playback using rec.601, but if you upscale to HD the player will probably use rec.709 instead, so you either need to convert the colors or set the correct colorimetry in the encoder configuration.
The difference between rec.601 and rec.709 isn't huge, but rec.2020 is a lot different.

The x264 encoder configuration offers the ability to write the correct colorimetry info via the GUI. It appears the x265 encoder configuration doesn't yet.

Did you have a listen to the samples of audio dynamic rage compression I linked to?

Last edited by hello_hello; 8th June 2020 at 14:38.
hello_hello is offline   Reply With Quote
Old 10th June 2020, 08:33   #9040  |  Link
Lord Dredd
a Hobby Encoder :)
 
Join Date: Feb 2016
Posts: 28
Quote:
Originally Posted by hello_hello View Post
The x265 thing might be a rec.601 vs rec.709 vs rec.2020 issue.
https://en.wikipedia.org/wiki/Rec._601
https://en.wikipedia.org/wiki/Rec._709
https://en.wikipedia.org/wiki/Rec._2020

YV12 has to be converted to RGB on playback for display, and SD, HD and UHD use different formulas. It's more likely the player is making an assumption based on resolution and that's why the colors look different. Or the video card's drivers are borked. What's the resolution of the source and encode?
YV12 sources should just be decompressed and re-encoded as YV12 without a conversion to RGB and back (unless you're converting to RGB in a script for a filter that requires it), so re-encoding itself shouldn't change the colors, unless you downscale or upscale. For example, a SD source would usually be converted to RGB on playback using rec.601, but if you upscale to HD the player will probably use rec.709 instead, so you either need to convert the colors or set the correct colorimetry in the encoder configuration.
The difference between rec.601 and rec.709 isn't huge, but rec.2020 is a lot different.

The x264 encoder configuration offers the ability to write the correct colorimetry info via the GUI. It appears the x265 encoder configuration doesn't yet.

Did you have a listen to the samples of audio dynamic rage compression I linked to?
yes and I gotta say I found
Quote:
f=2000 g=23 m=15 b=1
to be most vibrant , the first three sounded alright the
Quote:
f=150 b=1
was also great but the other one had beefed up audio volumes so to me that sounded well.

I am not an expert and and I listened to them on my desktop speaker which is okish


Regarding the color so I never convert to RGB ever
AS i am these days trying on alreday converted videos so by and large all scripts use
Quote:
fpsnum=24000, fpsden=1001, colorspace="YUV420P8
at the end of source in avisynth..

strangely similar avisynth for a x264 video works well but when used with x265 cools the color off..
any tick you might wanna suggest to keep the colors as close to trhe original as possible.
Lord Dredd is offline   Reply With Quote
Reply

Tags
megui

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 14:19.


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