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 7th June 2010, 12:50   #401  |  Link
kypec
User of free A/V tools
 
kypec's Avatar
 
Join Date: Jul 2006
Location: SK
Posts: 820
You're abusing the concept of CFR vs 2-pass encode, that's all. This GUI is simply not designed to do weird=illogical things.
kypec is offline   Reply With Quote
Old 7th June 2010, 16:39   #402  |  Link
Kuningas
Registered User
 
Join Date: Nov 2004
Location: Russia
Posts: 11
Concept is to use constant ratefactor advantages (reducing the quality of 'less important' high-motion frames) getting the file of needed size. It's not weird and illogical. It's the only way )
__________________
In vino veritas
Kuningas is offline   Reply With Quote
Old 7th June 2010, 19:21   #403  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,906
Quote:
Originally Posted by Kuningas View Post
Concept is to use constant ratefactor advantages (reducing the quality of 'less important' high-motion frames)
That's what both, 2-Pass and CRF do: The quality of two files of the same size, one encoded with 2-Pass and one with 1-Pass CRF, is equivalent!

I don't get the point what doing the first pass of a 2-Pass encode in CRF mode is good fore...

Quote:
Originally Posted by Kuningas View Post
getting the file of needed size. It's not weird and illogical. It's the only way )
Hitting a specific file size is what 2-Pass mode can do, but CRF cannot. So in case you need to hit a specific size, use 2-Pass. Otherwise use CRF.

It's that simple
__________________
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; 7th June 2010 at 20:00.
LoRd_MuldeR is offline   Reply With Quote
Old 7th June 2010, 22:20   #404  |  Link
Kuningas
Registered User
 
Join Date: Nov 2004
Location: Russia
Posts: 11
Quote:
Originally Posted by LoRd_MuldeR View Post
one encoded with 2-Pass and one with 1-Pass CRF, is equivalent!
CRF mode is much more smarter then 2-pass mode.
CRF raises the quantizers in "fast" scenes where the loss won't be visible anyway and lower the quantizers in "slow" scenes. While encoding in two pass average bitrate mode "high motion" scenes will get a significant higher bitrate than "static" scenes. That's why pq cann't be equivalent. In practice, CRF+second pass mode looks noticeablely better.
__________________
In vino veritas
Kuningas is offline   Reply With Quote
Old 7th June 2010, 22:49   #405  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,906
Quote:
Originally Posted by Kuningas View Post
CRF mode is much more smarter then 2-pass mode.
Nope, it isn't. Please stop spreading wrong information

Quote:
Originally Posted by Kuningas View Post
CRF raises the quantizers in "fast" scenes where the loss won't be visible anyway and lower the quantizers in "slow" scenes.
Correct, but applies to 2-Pass mode as well.

(Also you should say "blocks" instead of "scenes", now with MB-Tree rate-control being used)

Quote:
Originally Posted by Kuningas View Post
While encoding in two pass average bitrate mode "high motion" scenes will get a significant higher bitrate than "static" scenes.
Correct, but applies to CRF mode as well.

Quote:
Originally Posted by Kuningas View Post
That's why pq cann't be equivalent.
I guess you mean "CQP" (aka "constant quantizer"). And of course CQP cannot be equivalent to CRF/2-Pass. But CQP was never mentioned!


Example:

The upper one was encoded with 1-Pass CRF, the lower one was encoded as a "normal" 2-Pass:

(Note that both files have the same total size, i.e. the same average bitrate!)



You notice something regarding the bitrate distribution?

Upper: cabac=1 / ref=16 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / weightp=2 / keyint=750 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=24.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=2:1.00

Lower: cabac=1 / ref=16 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / weightp=2 / keyint=750 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=2pass / mbtree=1 / bitrate=284 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=2:1.00
__________________
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; 7th June 2010 at 23:31.
LoRd_MuldeR is offline   Reply With Quote
Old 8th June 2010, 08:04   #406  |  Link
kypec
User of free A/V tools
 
kypec's Avatar
 
Join Date: Jul 2006
Location: SK
Posts: 820
Quote:
Originally Posted by LoRd_MuldeR View Post
You notice something regarding the bitrate distribution?
Yeah, I noticed that 2-pass encode exhibits even larger variances around the local bitrate peaks - which simply proves Kuningas was wrong in his assumption. 2-pass method provides more aggressive distribution of bitrate across slow vs fast-motion scenes though the differences are probably so negligible that they cannot be observed with standard human visual quality comparisons.
LM as usually.
kypec is offline   Reply With Quote
Old 8th June 2010, 12:45   #407  |  Link
diimaan
Registered User
 
Join Date: Jun 2010
Posts: 106
Hi LM

Code:
PipeBuffer by LoRd_MuldeR <mulder2@gmx.de>, Version 1.03

Usage:
  pipebuf.exe <program_out> [<args>] : <program_in> [<args>] : [<buffer_size>]

Options:
  <program_out>  Executable to read stdout from
  <program_in>   Executable to write stdin to
  <args>         Optional command-line arguments
  <buffer_size>  Pipe buffer in MByte [0]
i want to pass the buffer size as 4m for my encode!
can you show it in a simple example for me?

my avs (m1.avs):
Code:
Loadplugin("D:\dgmpgdec158\DGDecode.dll")
Loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\AutoCrop.dll")

mpeg2source("D:\sample\dvd2avi.d2v")

Crop(0,56,-8,-56)
Spline64Resize(848,360)
how can i pass the input via pipebuf and then to the launcher or x264_64!

Last edited by diimaan; 8th June 2010 at 12:48.
diimaan is offline   Reply With Quote
Old 8th June 2010, 13:45   #408  |  Link
diimaan
Registered User
 
Join Date: Jun 2010
Posts: 106
I just copied this from the clipboard!

Code:
D:\x264_x64.2010-04-25\pipebuf.exe D:\x264_x64.2010-04-25\avs2yuv.exe D:\sample\m1.avs - : D:\x264_x64.2010-04-25\x264_x64.exe --preset slower --crf 21.0 --level 30 --sar 1:1 --output NUL --frames 1035 --demuxer y4m --stdin y4m - : 4
so the 4 in the above mentioned code means 4 MB?
and in the place of NUL if i mention a mkv or h264 and run from the pipebuf cli will it encode?

like say

Code:
@echo off
"D:\x264_x64.2010-04-25\pipebuf.exe" D:\x264_x64.2010-04-25\avs2yuv.exe D:\sample\m1.avs - : D:\x264_x64.2010-04-25\x264_x64.exe --preset slower --crf 21.0 --level 30 --sar 1:1 --output D:\m1.mkv --frames 1035 --demuxer y4m --stdin y4m - : 4
pause
or am I doing anything wrong here?

Last edited by diimaan; 8th June 2010 at 13:50.
diimaan is offline   Reply With Quote
Old 8th June 2010, 13:49   #409  |  Link
diimaan
Registered User
 
Join Date: Jun 2010
Posts: 106
wow it's running man...
thanks LM...

but my doubt is that, do we have to mention the frames if we are not running a benchmark and running a real encode?

Last edited by diimaan; 8th June 2010 at 13:55.
diimaan is offline   Reply With Quote
Old 8th June 2010, 14:34   #410  |  Link
diimaan
Registered User
 
Join Date: Jun 2010
Posts: 106
on a windows 64 vista machine!

1280 720 video
crf 22
only SAR 1:1 mentioned no other custom commands

Code:
Source: D:\sample\m1.avs
Preset: Slow
Tuning: None
Profile: High
Params: --sar 1:1

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 1035 frames, 10.40 fps, 2175.10 kb/s
encoded 1035 frames, 10.29 fps, 2175.10 kb/s
encoded 1035 frames, 10.52 fps, 2175.10 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 1035 frames, 11.01 fps, 2174.50 kb/s
encoded 1035 frames, 11.01 fps, 2174.50 kb/s
encoded 1035 frames, 10.56 fps, 2174.50 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 1035 frames, 10.78 fps, 2174.50 kb/s
encoded 1035 frames, 11.01 fps, 2174.50 kb/s
encoded 1035 frames, 11.01 fps, 2174.50 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 1035 frames, 11.01 fps, 2174.50 kb/s
encoded 1035 frames, 11.01 fps, 2174.50 kb/s
encoded 1035 frames, 11.01 fps, 2174.50 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 1035 frames, 11.01 fps, 2174.50 kb/s
encoded 1035 frames, 11.01 fps, 2174.50 kb/s
encoded 1035 frames, 11.01 fps, 2174.50 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 1035 frames, 11.01 fps, 2174.50 kb/s
encoded 1035 frames, 10.78 fps, 2174.50 kb/s
encoded 1035 frames, 10.56 fps, 2174.50 kb/s
but it stops on 8 MByte!
I can see ppl running the benchmark till 128MByte! but how?
diimaan is offline   Reply With Quote
Old 9th June 2010, 08:53   #411  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,906
Quote:
Originally Posted by diimaan View Post
I just copied this from the clipboard!

Code:
D:\x264_x64.2010-04-25\pipebuf.exe D:\x264_x64.2010-04-25\avs2yuv.exe D:\sample\m1.avs - : \
D:\x264_x64.2010-04-25\x264_x64.exe --preset slower --crf 21.0 --level 30 --sar 1:1 --output NUL \
--frames 1035 --demuxer y4m --stdin y4m - : 4
so the 4 in the above mentioned code means 4 MB?
Yup.

Quote:
Originally Posted by diimaan View Post
and in the place of NUL if i mention a mkv or h264 and run from the pipebuf cli will it encode?
The "NUL" device will simply discard everything you write on it. Writing the output to the NUL device makes sense for the first pass of a 2-Pass encode.

Of course for the second pass of a 2-Pass encoder or for a 1-Pass CRF encode you would specify a "real" file there...

Quote:
Originally Posted by diimaan View Post
but it stops on 8 MByte!
I can see ppl running the benchmark till 128MByte! but how?
The buffer sizes to test are hard-coded. In older versions more (and bigger) buffer sizes were tested.

That was before it turned out that such very large buffers don't help

But of course you can still test arbitrary buffer sizes by calling pipebuf.exe/x264.exe manually from the console.
__________________
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; 9th June 2010 at 08:59.
LoRd_MuldeR is offline   Reply With Quote
Old 10th June 2010, 13:19   #412  |  Link
Kuningas
Registered User
 
Join Date: Nov 2004
Location: Russia
Posts: 11
Nope, it isn't. Please stop spreading wrong information

I'll try. )

Also you should say "blocks" instead of "scenes", now with MB-Tree rate-control being used

I don't use mbtree for some reasons.

I guess you mean "CQP" (aka "constant quantizer").

I meant pq aka "picture quality".

And of course CQP cannot be equivalent to CRF/2-Pass. But CQP was never mentioned!

"The advantage of the CRF mode is that it suits the human
perception much better than the QP mode. For example it will raise the quantizers in "fast" scenes where the
loss won't be visible anyway and lower the quantizers in "slow" scenes. Therefore the CRF mode should
give the same subjective quality as QP mode, but it usually achieves a significant higher compression. It's
recommended to prefer CRF mode over QP mode, although CRF is a bit slower. When switching from QP to
CRF mode, you may want to slightly lower the quantizer. This should give approximately the same file size
as before, but better visual quality! Another important advantage of CRF mode is that it will benefit from
adaptive quantization, something that QP mode can't do."

So, CRF is much more subjectively closer to CQP than 2pass mode.

The good example of using crf + 2pass: I encode with CRF and try to get the file size not bigger than X. But it unfortunately become a bit larger. What to do? Start new encoding and loose time for 2 passes? Or I can use stats from CRF mode and make just 2nd pass. It's obvious.

So. The rule is - use CRF or CRF+2pass (when you missed).

Here's real HD comparision (Anger Management BD CEE AVC).

crop + spline36resize+

selectTotal=framecount()/50
selectrangeevery(selectTotal,50)

CRF:


Commandline for x264:
"C:\Programs - W7\x264_x64.2010-04-25\pipebuf.exe" "C:\Programs - W7\x264_x64.2010-04-25\avs2yuv.exe" Q:\HDProjects\anger\anger.avs - : "C:\Programs - W7\x264_x64.2010-04-25\x264_x64.exe" --crf 17.50 --level 4.1 --ref 12 --no-fast-pskip --bframes 8 --weightp 2 --no-mbtree --b-pyramid normal --b-adapt 2 --deblock -3:-3 --subme 10 --trellis 2 --partitions all --me umh --merange 48 --thread-input --vbv-bufsize 62500 --vbv-maxrate 50000 --aq-mode 1 --aq-strength 0.8 --psy-rd 1.0:0 --ssim --output Q:\HDProjects\anger\anger-crf175-aq08-psy100-b8-1629-me48-2.mkv --frames 2505 --demuxer y4m --stdin y4m - : 4

x264 [info]: frame I:56 Avg QP:17.33 size: 99584
x264 [info]: frame P:505 Avg QP:18.70 size: 52507
x264 [info]: frame B:1944 Avg QP:20.94 size: 25136
x264 [info]: consecutive B-frames: 1.9% 0.9% 3.8% 15.5% 22.0% 39.4% 9.1% 3.6% 3.7%

2-PASS:


Commandline for x264:
"C:\Programs - W7\x264_x64.2010-04-25\pipebuf.exe" "C:\Programs - W7\x264_x64.2010-04-25\avs2yuv.exe" Q:\HDProjects\anger\anger.avs - : "C:\Programs - W7\x264_x64.2010-04-25\x264_x64.exe" --bitrate 6200 --pass 2 --stats Q:\HDProjects\anger\anger-crf175-aq08-psy100-b8-1629-me48-2pass.mkv.x264-stats --level 4.1 --ref 12 --no-fast-pskip --bframes 8 --slow-firstpass --weightp 2 --no-mbtree --b-pyramid normal --b-adapt 2 --direct auto --no-dct-decimate --deblock -3:-3 --subme 10 --trellis 2 --partitions all --me umh --merange 48 --thread-input --vbv-bufsize 62500 --vbv-maxrate 50000 --aq-mode 1 --aq-strength 0.8 --psy-rd 1.0:0 --ssim --output Q:\HDProjects\anger\anger-crf175-aq08-psy100-b8-1629-me48-2pass.mkv --frames 2505 --demuxer y4m --stdin y4m - : 4

x264 [info]: frame I:56 Avg QP:17.66 size:102710
x264 [info]: frame P:505 Avg QP:21.39 size: 45379
x264 [info]: frame B:1944 Avg QP:21.11 size: 26195
x264 [info]: consecutive B-frames: 1.9% 0.9% 3.8% 15.5% 22.0% 39.4% 9.1% 3.6% 3.7%

CRF - 2-PASS:


As you can see CRF gives more bitrate for static scenes than 2-PASS. And don't waste it - look at first mega leap on bitrate viewer screen.
And look at quants )
__________________
In vino veritas

Last edited by Kuningas; 10th June 2010 at 17:09.
Kuningas is offline   Reply With Quote
Old 11th June 2010, 04:31   #413  |  Link
7ekno
Registered User
 
Join Date: Jul 2007
Posts: 389
Can prove anything you want if you "gimp" parameters to prove it ... mb-tree and b-pyramids would help bring CRF closer to your "two pass" graph ...

7ek
7ekno is offline   Reply With Quote
Old 20th June 2010, 11:23   #414  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,906
Updated x264 binaries to r1649 (Komisar's builds).
__________________
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 20th June 2010, 15:08   #415  |  Link
komisar
Registered User
 
komisar's Avatar
 
Join Date: Aug 2008
Location: Minsk, Belarus
Posts: 235
LoRd_MuldeR, small typo?
__________________
..::[I am live here]..::..[My x264 CLI/VFW builds and tools]::..
komisar is offline   Reply With Quote
Old 20th June 2010, 16:04   #416  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,906
Quote:
Originally Posted by komisar View Post
LoRd_MuldeR, small typo?
Indeed
__________________
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 27th June 2010, 17:41   #417  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,906
Updated x264 binaries to r1659 (Komisar's builds).
__________________
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 10th July 2010, 14:53   #418  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,906
Updated x264 binaries to r1666 (Komisar's builds).
__________________
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 10th July 2010, 14:55   #419  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,906
Quote:
Originally Posted by kypec View Post
Another small request LM if I may...
After the encoding process completed there is output window shown with report details which is fine of course.
When CRF was used (1-pass method in general probably) there is only one option presented for right-click: Copy to clipboard.
This is also good and I like it this way because frankly, what other actions could anyone want to do with final report, isn't it?
However, when 2-pass encode completes, the window has different right-click menu:

[...]

IMHO it's rather counter-productive this way because I need to make two clicks now to get the contents copied into clipboard (first Select all, then Copy).
Could this menu be replaced to be identical with CRF style report, please?
Done.
__________________
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 12th July 2010, 12:46   #420  |  Link
kypec
User of free A/V tools
 
kypec's Avatar
 
Join Date: Jul 2006
Location: SK
Posts: 820
a lot LM!

I guess you made a little typo here...

Last edited by LoRd_MuldeR; 10th July 2010 at 15:52. Reason: Update x264 binaries to r1659

Last edited by kypec; 12th July 2010 at 12:53.
kypec 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 10:59.


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