The new B-frame decision (--bframes 16 and you)

[LoRd_MuldeR]

I'll try to get a debug build. Nevertheless it seems the new version doesn't show the behavior to prefer 16 B-Frames anymore:
x264 [info]: consecutive B-frames: 11,1% 30,1% 50,6% 3,3% 1,2% 3,0% 0,3% 0,1% 0,1% 0,1% 0,1% 0,0% 0,0% 0,0% 0,0% 0,0%

Now it would make sens to lower "Max. Consecutive B-Frames" to ~6, right ???

[Dark Shikari]

It appears that this patch correctly detects fades!

Before and after (blue == inter, red/orange == intra, green == direct, yellow == skip)

Blue/red/orange P-frame is before, the B-frame with lots of skips is after:

http://i34.tinypic.com/2vjo2f8.gif

Combined with weighted prediction, this should drastically decrease the bit cost of fades.

[Warpman]

It appears that this patch correctly detects fades!

Before and after (blue == inter, red/orange == intra, green == direct, yellow == skip)

Blue/red/orange P-frame is before, the B-frame with lots of skips is after:



Combined with weighted prediction, this should drastically decrease the bit cost of fades.
nice work!
i just tried one small sample (anime/not much motion/many fades)
and with a 500kbit bitrate... results are great ^^


--[NoImage] Job commandline: "C:\Programme\megui\tools\x264\x264.exe" --pass 2 --bitrate 500 --stats "G:\Anime\(DVDISO)Kanon
Vol.2\ff2.stats" --ref 10 --mixed-refs --bframes 16 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --partitions
p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --sar 1:1 --progress --output "G:\Anime\(DVDISO)Kanon
Vol.2\nobadapt2_2.mkv" "G:\Anime\(DVDISO)Kanon Vol.2\ff2.avs"
--[Information] [29.07.2008 21:13:08] Encoding started
--[NoImage] Standard output stream
--[NoImage] Standard error stream
---[NoImage] avis [info]: 720x480 @ 23.98 fps (3001 frames)
---[NoImage] x264 [info]: using SAR=1/1
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
---[NoImage] x264 [info]: slice I:32 Avg QP:15.34 size: 28103 PSNR Mean Y:50.16 U:50.59 V:50.92 Avg:50.34 Global:49.60
---[NoImage] x264 [info]: slice P:691 Avg QP:15.77 size: 7407 PSNR Mean Y:48.67 U:49.13 V:49.46 Avg:48.84 Global:48.23
---[NoImage] x264 [info]: slice B:2278 Avg QP:16.87 size: 812 PSNR Mean Y:47.88 U:48.67 V:49.08 Avg:48.15 Global:47.81
---[NoImage] x264 [info]: consecutive B-frames: 4.3% 7.3% 5.7% 14.4% 16.0% 20.4% 12.5% 1.6% 1.2% 0.7% 1.1% 0.4% 1.3% 0.5% 0.0% 0.0% 12.6%
---[NoImage] x264 [info]: mb I I16..4: 6.2% 58.8% 35.0%
---[NoImage] x264 [info]: mb P I16..4: 1.0% 6.1% 2.0% P16..4: 33.1% 14.7% 9.6% 0.0% 0.0% skip:33.5%
---[NoImage] x264 [info]: mb B I16..4: 0.0% 0.1% 0.0% B16..8: 18.5% 0.6% 0.7% direct: 0.9% skip:79.1% L0:46.9% L1:49.7% BI: 3.3%
---[NoImage] x264 [info]: 8x8 transform intra:64.2% inter:50.5%
---[NoImage] x264 [info]: direct mvs spatial:94.4% temporal:5.6%
---[NoImage] x264 [info]: ref P L0 56.0% 12.2% 8.4% 4.6% 4.1% 3.4% 3.6% 2.2% 2.7% 2.8%
---[NoImage] x264 [info]: ref B L0 73.3% 10.5% 5.2% 2.4% 2.5% 2.0% 1.6% 1.5% 1.0%
---[NoImage] x264 [info]: ref B L1 93.3% 6.7%
---[NoImage] x264 [info]: SSIM Mean Y:0.9943368
---[NoImage] x264 [info]: PSNR Mean Y:48.086 U:48.795 V:49.185 Avg:48.335 Global:47.920 kb/s:502.84
---[NoImage] encoded 3001 frames, 32.56 fps, 502.95 kb/s



--[NoImage] Job commandline: "C:\Programme\megui\tools\x264\x264.exe" --pass 2 --bitrate 500 --stats "G:\Anime\(DVDISO)Kanon
Vol.2\ff2.stats" --ref 10 --mixed-refs --bframes 16 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --partitions
p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --sar 1:1 --progress --output "G:\Anime\(DVDISO)Kanon
Vol.2\badapt2_2.mkv" "G:\Anime\(DVDISO)Kanon Vol.2\ff2.avs" --b-adapt 2
--[Information] [29.07.2008 21:07:51] Encoding started
--[NoImage] Standard output stream
--[NoImage] Standard error stream
---[NoImage] avis [info]: 720x480 @ 23.98 fps (3001 frames)
---[NoImage] x264 [info]: using SAR=1/1
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
---[NoImage] x264 [info]: slice I:30 Avg QP:15.55 size: 27491 PSNR Mean Y:50.08 U:50.51 V:50.88 Avg:50.26 Global:49.49
---[NoImage] x264 [info]: slice P:536 Avg QP:15.54 size: 7155 PSNR Mean Y:48.42 U:49.03 V:49.42 Avg:48.64 Global:48.22
---[NoImage] x264 [info]: slice B:2435 Avg QP:16.64 size: 1318 PSNR Mean Y:48.12 U:48.84 V:49.23 Avg:48.38 Global:47.99
---[NoImage] x264 [info]: consecutive B-frames: 0.6% 4.4% 10.3% 13.5% 7.6% 24.2% 3.3% 1.9% 0.0% 0.3% 0.0% 0.4% 1.8% 2.4% 0.0% 15.1% 14.3%
---[NoImage] x264 [info]: mb I I16..4: 6.7% 59.7% 33.7%
---[NoImage] x264 [info]: mb P I16..4: 0.9% 5.9% 2.3% P16..4: 30.9% 12.4% 8.9% 0.0% 0.0% skip:38.7%
---[NoImage] x264 [info]: mb B I16..4: 0.1% 0.4% 0.1% B16..8: 20.4% 1.0% 1.2% direct: 1.5% skip:75.4% L0:50.8% L1:44.8% BI: 4.4%
---[NoImage] x264 [info]: 8x8 transform intra:62.8% inter:51.0%
---[NoImage] x264 [info]: direct mvs spatial:93.8% temporal:6.2%
---[NoImage] x264 [info]: ref P L0 54.1% 11.8% 8.2% 5.1% 4.6% 3.8% 3.3% 2.7% 3.2% 3.2%
---[NoImage] x264 [info]: ref B L0 72.2% 10.3% 5.0% 3.3% 2.5% 1.7% 2.1% 1.6% 1.3%
---[NoImage] x264 [info]: ref B L1 92.6% 7.4%
---[NoImage] x264 [info]: SSIM Mean Y:0.9944345
---[NoImage] x264 [info]: PSNR Mean Y:48.197 U:48.895 V:49.277 Avg:48.442 Global:48.041 kb/s:503.00
---[NoImage] encoded 3001 frames, 31.80 fps, 503.11 kb/s


more SSIM and PSNR...
differences are really small but my eyes agree with the metrics here...

[Soichiro]

If the threading could be fixed with the new patch, this could be entirely usable. However, the test I'm running with the most recent version of the patch is only using 50% of the CPU, and going very slow, so until the threading issue is fixed, this isn't a very reasonable patch for everyday use.

I'll post stats/links when the encodes finish.

[Dark Shikari]

If the threading could be fixed with the new patch, this could be entirely usable. However, the test I'm running with the most recent version of the patch is only using 50% of the CPU, and going very slow, so until the threading issue is fixed, this isn't a very reasonable patch for everyday use.

I'll post stats/links when the encodes finish.I'm going to work on heuristics to prune the path tree of unlikely paths--this could drastically improve speed without much quality loss (and the faster slicetype decision is, the less of a threading issue there is).

It also probably helps a lot to use --bframes 2 or 3 instead of 16 ;)

[Warpman]

I'm going to work on heuristics to prune the path tree of unlikely paths--this could drastically improve speed without much quality loss (and the faster slicetype decision is, the less of a threading issue there is).

It also probably helps a lot to use --bframes 2 or 3 instead of 16 ;)
well i still get 15fps with --bframes 16 in the first pass so its stil fast enough(tm) for me ;)
2nd pass runs with 40fps tho xD

[Soichiro]

-[Information] Log for job1 (video, Pot 04.avs -> Pot 04 Old Bframes.mkv)
--[Information] [7/29/2008 6:14:59 PM] Started handling job
--[Information] [7/29/2008 6:14:59 PM] Preprocessing
--[NoImage] Job commandline: "C:\Documents and Settings\Soichiro\Desktop\x264.r920.bframepatch.exe" --bitrate 700 --keyint 400 --min-keyint 12 --ref 6 --mixed-refs --no-fast-pskip --bframes 16 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 6 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --merange 24 --threads auto --thread-input --sar 1:1 --progress --output "S:\Prince of Dumbness\04\Pot 04 Old Bframes.mkv" "S:\Prince of Dumbness\04\Pot 04.avs" --b-adapt 1
--[Information] [7/29/2008 6:15:01 PM] Encoding started
--[NoImage] Standard output stream
--[NoImage] Standard error stream
---[NoImage] avis [info]: 640x480 @ 23.98 fps (3001 frames)
---[NoImage] x264 [info]: using SAR=1/1
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Slow
---[NoImage] x264 [info]: slice I:20 Avg QP:17.55 size: 22405 PSNR Mean Y:49.86 U:51.03 V:51.57 Avg:48.99 Global:43.09
---[NoImage] x264 [info]: slice P:1438 Avg QP:23.26 size: 6879 PSNR Mean Y:41.01 U:44.26 V:44.42 Avg:41.74 Global:38.67
---[NoImage] x264 [info]: slice B:1543 Avg QP:21.86 size: 1486 PSNR Mean Y:43.15 U:45.80 V:45.78 Avg:43.77 Global:40.01
---[NoImage] x264 [info]: consecutive B-frames: 22.5% 32.7% 10.4% 8.3% 13.1% 1.8% 1.6% 0.0% 0.9% 0.0% 1.1% 0.4% 0.4% 0.0% 1.0% 0.0% 5.7%
---[NoImage] x264 [info]: mb I I16..4: 24.8% 44.2% 31.0%
---[NoImage] x264 [info]: mb P I16..4: 4.8% 10.9% 2.3% P16..4: 39.7% 11.7% 8.5% 0.0% 0.0% skip:22.0%
---[NoImage] x264 [info]: mb B I16..4: 0.2% 0.2% 0.0% B16..8: 27.7% 1.0% 1.5% direct: 4.1% skip:65.2% L0:38.9% L1:52.0% BI: 9.2%
---[NoImage] x264 [info]: final ratefactor: 23.01
---[NoImage] x264 [info]: 8x8 transform intra:59.3% inter:57.8%
---[NoImage] x264 [info]: direct mvs spatial:96.4% temporal:3.6%
---[NoImage] x264 [info]: ref P L0 71.4% 12.2% 7.7% 3.1% 2.8% 2.9%
---[NoImage] x264 [info]: ref B L0 83.0% 9.7% 3.8% 2.0% 1.4%
---[NoImage] x264 [info]: ref B L1 95.2% 4.8%
---[NoImage] x264 [info]: SSIM Mean Y:0.9872354
---[NoImage] x264 [info]: PSNR Mean Y:42.167 U:45.097 V:45.166 Avg:42.831 Global:39.330 kb/s:807.44
---[NoImage] encoded 3001 frames, 5.01 fps, 807.52 kb/s
-[Information] Log for job3 (video, Pot 04.avs -> Pot 04 New Bframes.mkv)
--[Information] [7/29/2008 6:25:03 PM] Started handling job
--[Information] [7/29/2008 6:25:03 PM] Preprocessing
--[NoImage] Job commandline: "C:\Documents and Settings\Soichiro\Desktop\x264.r920.bframepatch.exe" --bitrate 700 --keyint 400 --min-keyint 12 --ref 6 --mixed-refs --no-fast-pskip --bframes 16 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 6 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --merange 24 --threads auto --thread-input --sar 1:1 --progress --output "S:\Prince of Dumbness\04\Pot 04 New Bframes.mkv" "S:\Prince of Dumbness\04\Pot 04.avs" --b-adapt 2
--[Information] [7/29/2008 6:25:05 PM] Encoding started
--[NoImage] Standard output stream
--[NoImage] Standard error stream
---[NoImage] avis [info]: 640x480 @ 23.98 fps (3001 frames)
---[NoImage] x264 [info]: using SAR=1/1
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Slow
---[NoImage] x264 [info]: slice I:20 Avg QP:17.24 size: 23237 PSNR Mean Y:50.16 U:51.27 V:51.79 Avg:49.28 Global:43.40
---[NoImage] x264 [info]: slice P:1377 Avg QP:20.94 size: 6525 PSNR Mean Y:42.58 U:45.38 V:45.44 Avg:43.22 Global:39.87
---[NoImage] x264 [info]: slice B:1604 Avg QP:23.15 size: 1996 PSNR Mean Y:42.20 U:45.14 V:45.23 Avg:42.88 Global:39.55
---[NoImage] x264 [info]: consecutive B-frames: 15.0% 36.6% 19.7% 19.6% 2.5% 1.4% 3.1% 1.1% 0.3% 0.3% 0.4% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%
---[NoImage] x264 [info]: mb I I16..4: 23.7% 44.7% 31.7%
---[NoImage] x264 [info]: mb P I16..4: 3.8% 9.4% 2.2% P16..4: 35.8% 10.6% 8.2% 0.0% 0.0% skip:29.9%
---[NoImage] x264 [info]: mb B I16..4: 0.6% 0.9% 0.1% B16..8: 30.6% 1.4% 1.9% direct: 6.4% skip:58.1% L0:39.1% L1:51.1% BI: 9.8%
---[NoImage] x264 [info]: final ratefactor: 22.47
---[NoImage] x264 [info]: 8x8 transform intra:59.0% inter:57.5%
---[NoImage] x264 [info]: direct mvs spatial:96.0% temporal:4.0%
---[NoImage] x264 [info]: ref P L0 70.4% 12.5% 8.0% 3.3% 2.8% 2.9%
---[NoImage] x264 [info]: ref B L0 81.7% 9.6% 4.8% 2.2% 1.6%
---[NoImage] x264 [info]: ref B L1 95.4% 4.6%
---[NoImage] x264 [info]: SSIM Mean Y:0.9879179
---[NoImage] x264 [info]: PSNR Mean Y:42.427 U:45.291 V:45.369 Avg:43.083 Global:39.710 kb/s:808.61
---[NoImage] encoded 3001 frames, 1.68 fps, 808.70 kb/s

Top is old, bottom is new method. SSIM is much better on the new method, but wow, that's so much slower that I don't even know if it's worth it.

[LoRd_MuldeR]

Looking at your B-Frames stats, more than 6 B-Frames are used only in very rare cases.
So restricting the max number of B-Frames to 6 should give some good speed-up with the new method...

[Dark Shikari]

Top is old, bottom is new method. SSIM is much better on the new method, but wow, that's so much slower that I don't even know if it's worth it.Did you even read any of the posts in this thread... like the ones saying "don't use --bframes 16 with the new method if you're going to whine about its speed"? :p

[Soichiro]

Maybe I was just running a test. Sorry for whining about a slow test run. Geez. :p

I'm kind of surprised the patched version didn't use 16 bframes though, since the original did in some places (since this is animation with some static scenes).

[Audionut]

I'm kind of surprised the patched version didn't use 16 bframes though, since the original did in some places.

... and I found the bug that was causing long strings of 15/16 B-frames where there shouldn't be.

http://forum.doom9.org/showthread.php?p=1164133#post1164133

[bkman]

Builds with the latest patch?

Much obliged :)

[Sharktooth]

head over the x264 current patches thread.

[LoRd_MuldeR]

That "exception" report is utterly useless; I can't derive any useful information from it. How about a gdb backtrace on a build with --enable-debug?

Here we go:

LoRd_MuldeR@MULDER_NEU /d/Avidemux 2.4.3
$ gdb avidemux2_gtk.exe
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(gdb) run

[..]

Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 3096.0x528]
0x6fc9bcbd in block_residual_write_cabac (h=0x6526170, cb=0x177cd3b0,
i_ctxBlockCat=4, i_idx=21, l=0x6527ff2, i_count=15) at ./common/bs.h:228
228 return x264_ue_size_tab[(val+1)>>8] + 16;
(gdb) bt
#0 0x6fc9bcbd in block_residual_write_cabac (h=0x6526170, cb=0x177cd3b0,
i_ctxBlockCat=4, i_idx=21, l=0x6527ff2, i_count=15) at ./common/bs.h:228
#1 0x6fcae380 in x264_partition_size_cabac (h=0x6526170, cb=0x177cd3b0,
i8=<value optimized out>, i_pixel=3) at encoder/cabac.c:1089
#2 0x6fcae8ca in x264_rd_cost_part (h=0x6526170, i_lambda2=1462, i8=1,
i_pixel=3) at encoder/rdo.c:191
#3 0x6fcb95f6 in x264_me_refine_qpel_rd (h=0x6526170, m=0x177ce210,
i_lambda2=1462, i8=1) at encoder/me.c:955
#4 0x6fcb1ba1 in x264_macroblock_analyse (h=0x6526170)
at encoder/analyse.c:2370
#5 0x6fcd44e1 in x264_slice_write (h=0x6526170) at encoder/encoder.c:1160
#6 0x6fced884 in x264_stack_align () from d:\Avidemux 2.4.3\libx264.dll
#7 0x6fcd2afa in x264_slices_write (h=0x6526170) at encoder/encoder.c:1305
#8 0x611812fa in ptw32_threadStart@4 () from d:\Avidemux 2.4.3\pthreadGC2.dll
#9 0x77bcb530 in msvcrt!_endthreadex () from C:\WINDOWS\syswow64\msvcrt.dll
#10 0x7d4dfe21 in KERNEL32!GetConsoleOutputCP ()
from C:\WINDOWS\syswow64\kernel32.dll
#11 0x1177b358 in ?? ()
#12 0x00000000 in ?? ()
(gdb)


Are those the information you need? :confused:

[gav1577]

Sorry fo the noob question but is the --b-adapt 2 cmd only needed in the first pass of a 2 pass encode the reason i ask is because i read somewhere if i remember correctly all the b frame calculations are made in the first pass ? Thanks

[Dark Shikari]

That's... odd. That shouldn't happen.

Place assert( i_coeff > 0 ); on line 730 of encoder/cabac.c and see if the assert triggers.

Sorry fo the noob question but is the --b-adapt 2 cmd only needed in the first pass of a 2 pass encode the reason i ask is because i read somewhere if i remember correctly all the b frame calculations are made in the first pass ? Thankscorrect

[gav1577]

correct

Thanks :)

[LoRd_MuldeR]

That's... odd. That shouldn't happen.

Place assert( i_coeff > 0 ); on line 730 of encoder/cabac.c and see if the assert triggers.

correct

Okay. That's what I got during the compilation process. I used fprofiled.

avis [info]: 1280x720 @ 59.94 fps (200 frames)
x264 [warning]: psy RD is not compatible with trellis=1; use 0 or 2.
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
Assertion failed: i_coeff > 0, file encoder/cabac.c, line 731

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Well, it compiled anyway. But when encoding, I now see this:

http://img410.imageshack.us/img410/6701/gdbcrash3el0.th.png (http://img410.imageshack.us/my.php?image=gdbcrash3el0.png)

[Dark Shikari]

Hmm, this is very bizarre. Its crashing on a set of code that does have a CBP--the CBP check should ensure that a zero-set of coefficients never reaches the writing loop. I don't get a crash here either.

Do you have a sample that consistently generates the issue, and/or a set of encoding settings?

[LoRd_MuldeR]

Do you have a sample that consistently generates the issue, and/or a set of encoding settings?

Well, I run Avidemux with the newly compiled libx264.dll, load some MPEG-2 capture, load my usual x264 settings (from .js script) and save the video.

It will then hang for quite some time, which it didn't use to do, and then *boom*


[EDIT]

You can get Avidemux r4281 here: http://avidemux.razorbyte.com.au/#avidemux2.4
My x264 settings are here: http://pastebin.org/58864

Note: You'll need the Psy RDO patch or you must insert dummy fields for "i_psy_rd" and "f_psy_rd".
And if you want to use "b_adapt=2" with Avidmux, you'll need to hack the x264 defaults...

[Dark Shikari]

I need something that I can replicate with standalone x264, so x264 CLI settings would be more useful than a hexdump ;)

[LoRd_MuldeR]

I need something that I can replicate with standalone x264, so x264 CLI settings would be more useful than a hexdump ;)

Extracted from the file that crashed:
x264 - core 61 r0+922 4e7f5cb - H.264/MPEG-4 AVC codec - Copyleft 2003-2008 - http://www.videolan.org/x264.html - options: cabac=1 ref=8 deblock=1:0:0 analyse=0x3:0x133 me=umh subme=7 psy_rd=1,000000 brdo=1 mixed_ref=1 me_range=24 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 chroma_qp_offset=0 threads=6 nr=0 decimate=1 mbaff=0 bframes=15 b_pyramid=1 b_adapt=2 b_bias=0 direct=1 wpredb=1 bime=1 keyint=500 keyint_min=25 scenecut=40(pre) rc=crf crf=24,0 rceq='blurCplx^(1-qComp)' qcomp=1,00 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1,40 pb_ratio=1,30 aq=2:1,00

[LoRd_MuldeR]

http://www.soadfans.de/forum/images/armageddon/smilies/wand.gif

After re-compiling my libx264.dll for about 30 times today, I finally got a working build. No idea what I did wrong all the time :confused:

Sorry for bothering you, but I must conclude the the problem was on my side :o

[LoRd_MuldeR]

Back to the 2-Pass crash that happens exclusively when b_adapt=2 is used:

LoRd_MuldeR@MULDER_NEU /d/Avidemux 2.4.3
$ gdb avidemux2_gtk.exe
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(no debugging symbols found)
(gdb) run
Starting program: d:\Avidemux 2.4.3/avidemux2_gtk.exe
[New thread 4144.0x12f0]
[New thread 4144.0x1380]
[New thread 4144.0x62c]
[New thread 4144.0xdfc]
[New thread 4144.0xe9c]
[New thread 4144.0x1114]
[New thread 4144.0xdec]
[New thread 4144.0xf04]
[New thread 4144.0x520]

[....]

[New thread 4144.0x13f4]
[New thread 4144.0x1290]
[New thread 4144.0xe2c]
[New thread 4144.0x13c4]
[New thread 4144.0x1098]

Program received signal SIGTRAP, Trace/breakpoint trap.
0x77bc6b3f in msvcrt!_assert () from C:\WINDOWS\syswow64\msvcrt.dll
(gdb) bt
#0 0x77bc6b3f in msvcrt!_assert () from C:\WINDOWS\syswow64\msvcrt.dll
#1 0x6fc9fc55 in x264_slicetype_analyse (h=0x7ed9290)
at encoder/slicetype.c:477
Backtrace stopped: frame did not save the PC
(gdb)

It always crashes near to the end of the second pass. When I lower b_adapt=1 then all runs through fine...

[Dark Shikari]

????

Slicetype_analyse isn't run on the second pass.

[LoRd_MuldeR]

????

Slicetype_analyse isn't run on the second pass.

Well, that is what I see. There must be some reason. I can reproduce it, with shorter and longer samples. Any ideas? :scared:

[Dark Shikari]

if( h->param.rc.b_stat_read )
{
/* Use the frame types from the first pass */
for( i = 0; h->frames.next[i] != NULL; i++ )
h->frames.next[i]->i_type =
x264_ratecontrol_slice_type( h, h->frames.next[i]->i_frame );
}
else if( (h->param.i_bframe && h->param.i_bframe_adaptive)
|| h->param.b_pre_scenecut )
x264_slicetype_analyse( h );

It is physically impossible for slicetype_analyse to be run if b_stat_read is set. b_stat_read is set, GUARANTEED, if pass is 2 or 3. Might I suggest you make sure that you're actually running a second pass?

[LoRd_MuldeR]

Just for info: x264 r927 creates a working DLL with MingW GCC 4.3.1-tdm-1 and "fprofiled" enabled again. That didn't work with r922 and caused a lot of headache...

[Ranguvar]

4. Add --weightb code; use --weightb on your first pass now. In a quick test, this greatly improved x264's detection and reaction to fades.
IIRC, you previously advised against using --weightb (second pass) with anime/cartoons. Does this mean we should enable --weightb on the first pass, but not the second? Or both passes now, or do I just have a bad memory?

Thanks for the great work!

[Dark Shikari]

IIRC, you previously advised against using --weightb (second pass) with anime/cartoons. Does this mean we should enable --weightb on the first pass, but not the second? Or both passes now, or do I just have a bad memory?

Thanks for the great work!Weightb isn't recommended too much for cartoons, at least if there isn't significant fading. The reason is because it slightly reduces the effectiveness of multiref.

However, if there is any significant amount of fades, its probably worth using it either way.

I didn't recommend it before because x264 didn't properly detect fades.

[Soichiro]

http://forum.doom9.org/showthread.php?p=1164133#post1164133

I know there was a bug, and I'm not talking about the old version of the patch, I'm talking about the non-trellis bframe method giving strings of 16 bframes in still scenes (where it makes sense to have them) and the new version not having any. Maybe there's some fancy technical reason, but it seems odd IMO.

[akupenguin]

I know there was a bug, and I'm not talking about the old version of the patch, I'm talking about the non-trellis bframe method giving strings of 16 bframes in still scenes (where it makes sense to have them) and the new version not having any.
And what makes you think the scene actually deserved 16 B-frames?
In a perfectly still frame it doesn't matter what frame types you pick, and in a non-perfectly still frame there is going to be some optimal number short of infinity. Why would the old simple algorithm have got it right?

[Comatose]

Well, logically, in a still scene where the only difference between frames is noise, wouldn't it be most efficient to look both ways (B)?
Assume the scene lasts 2 seconds at 24 fps.

[TL0]

For the options --b-adapt 2 --weightb, does it matter if these options are enabled for both passes? or are they only needed for first pass and keeping them enabled for 2nd pass causes slowdown in encoding?

I read the other replies but am still not sure what is correct currently. This new b-frame decision gives nice bitrate saving for crf :D

[woah!]

For the options --b-adapt 2 --weightb, does it matter if these options are enabled for both passes? or are they only needed for first pass and keeping them enabled for 2nd pass causes slowdown in encoding?

I read the other replies but am still not sure what is correct currently. This new b-frame decision gives nice bitrate saving for crf :D

http://forum.doom9.org/showpost.php?p=1164712&postcount=116

[skystrife]

Just an update for the problem happening on my end. I just compiled a r928 version with psy+hrd+prog and the new bframe decision patch (the third one), and I no longer have any crashing being exhibited! Thank you DS! =D

[LoRd_MuldeR]

I still get the crash in 2-Pass mode. But this might be an Avidemux problem. Nevertheless it does not happen with b_adapt=1, only with b_adapt=2 :confused:

http://img211.imageshack.us/img211/4214/bframecrashij3.th.png (http://img211.imageshack.us/my.php?image=bframecrashij3.png)

[kemuri-_9]

Just for info: x264 r927 creates a working DLL with MingW GCC 4.3.1-tdm-1 and "fprofiled" enabled again. That didn't work with r922 and caused a lot of headache...

gcc 4.3.1 is not an official mingw distribution and is not fully supported, so i believe your problems could be lying there.
there's a reason tdm's site has got 'Experimental' plastered on the top...
try compiling in gcc 3.4.5 (the official mingw distribution on sourceforge) and see if you still have problems
https://sourceforge.net/project/showfiles.php?group_id=2435&package_id=82723&release_id=428244

[MythCreator]

Just a small test:Source is Macross Frontier EP01 1080 BDRip,
--cqmfile "M4G_High_Detail_V3.1.cfg" --no-fast-pskip --no-dct-decimate --mixed-refs --scenecut 40 -I 90 -i 25 --me umh --merange 32 --sar 1:1 --threads 3 -r 6 --nr 0 -f -2:-1 -b 16 --b-adapt 2 --direct "auto" --bime --b-bias 0 --b-pyramid -w --deadzone-inter 4 --deadzone-intra 6 --aq-mode 0 --chroma-qp-offset 0 --direct-8x8 1 --8x8dct -A p8x8,p4x4,b8x8,i8x8,i4x4 -m 7 --b-rdo --psy-rd 1.0 --qpmin 10 --qpmax 51 --qpstep 4 --qcomp 0.900000 --ipratio 1.400000 --pbratio 1.300000 --vbv-init 0.9


use CRF=20.


1st:using --b-adapt 1:
x264 [info]: slice I:9 Avg QP:17.78 size: 98476 PSNR Mean Y:53.46 U:52.12 V:51.32 Avg:52.61 Global:52.28
x264 [info]: slice P:144 Avg QP:19.66 size: 44595 PSNR Mean Y:51.32 U:52.34 V:51.64 Avg:51.47 Global:51.20
x264 [info]: slice B:348 Avg QP:21.53 size: 12453 PSNR Mean Y:50.47 U:52.05 V:51.49 Avg:50.82 Global:50.57
x264 [info]: consecutive B-frames: 6.1% 14.2% 6.7% 16.3% 16.3% 35.4% 2.8% 0.0% 0.0% 0.0% 2.2% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%
x264 [info]: mb I I16..4: 21.4% 73.8% 4.8%
x264 [info]: mb P I16..4: 7.2% 13.4% 0.5% P16..4: 50.4% 7.8% 5.1% 0.1% 0.0% skip:15.4%
x264 [info]: mb B I16..4: 0.5% 0.8% 0.0% B16..8: 31.0% 0.8% 0.8% direct: 1.4% skip:64.8% L0:46.3% L1:43.7% BI:10.0%
x264 [info]: 8x8 transform intra:65.2% inter:32.2%
x264 [info]: direct mvs spatial:96.6% temporal:3.4%
x264 [info]: ref P L0 73.7% 16.7% 5.4% 2.1% 1.2% 1.0%
x264 [info]: ref B L0 85.3% 10.3% 2.8% 1.2% 0.5%
x264 [info]: ref B L1 96.2% 3.8%
x264 [info]: SSIM Mean Y:0.9946263
x264 [info]: PSNR Mean Y:50.764 U:52.135 V:51.532 Avg:51.042 Global:50.771 kb/s:4457.01


encoded 501 frames, 0.86 fps, 4457.77 kb/s






2nd:using --b-adapt 2
x264 [info]: slice I:9 Avg QP:17.33 size:101944 PSNR Mean Y:53.71 U:52.34 V:51.52 Avg:52.84 Global:52.49
x264 [info]: slice P:221 Avg QP:19.40 size: 36761 PSNR Mean Y:51.69 U:52.93 V:52.23 Avg:51.92 Global:51.60
x264 [info]: slice B:271 Avg QP:21.22 size: 11365 PSNR Mean Y:51.07 U:52.67 V:52.12 Avg:51.43 Global:51.10
x264 [info]: consecutive B-frames: 7.5% 49.6% 26.2% 12.2% 2.0% 2.4% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%
x264 [info]: mb I I16..4: 19.9% 74.8% 5.2%
x264 [info]: mb P I16..4: 5.4% 9.1% 0.4% P16..4: 52.8% 6.8% 4.8% 0.1% 0.0% skip:20.5%
x264 [info]: mb B I16..4: 0.3% 0.6% 0.0% B16..8: 30.1% 0.7% 0.7% direct: 1.4% skip:66.0% L0:43.9% L1:45.5% BI:10.6%
x264 [info]: 8x8 transform intra:63.8% inter:30.1%
x264 [info]: direct mvs spatial:99.3% temporal:0.7%
x264 [info]: ref P L0 71.9% 15.6% 8.0% 2.2% 1.3% 0.9%
x264 [info]: ref B L0 87.2% 9.0% 2.3% 1.0% 0.5%
x264 [info]: ref B L1 96.5% 3.5%
x264 [info]: SSIM Mean Y:0.9951781
x264 [info]: PSNR Mean Y:51.390 U:52.781 V:52.156 Avg:51.668 Global:51.340 kb/s:4640.69


encoded 501 frames, 0.17 fps, 4641.44 kb/s

[Sagittaire]

You have a big quality gain with small higher bitrate. But like always for make good comparision you must strictly have the same bitrate. Make comparison with crf mode is useless.

[G_M_C]

OK read through this tread, and the "current patches" thread; So --weightb is best used on the first pass only, and --b-adapt can best be used on both passes ? Or did I misunderstand this ?

I also understand that --weightb is best used on clips that have fades in them; But how must i judge this ? Is it good to use on stuff like "Sin Sity" with a few fades (but also only few colors) ? Or must there be "more fades than average" and defenately not black&white ? So how do you judge when to use it ?

Now i have to fugure out how to get Megui to do a different commandline for the first pass than the second pass. I've only been using it for 1 week you know :p

[Soichiro]

--weightb should be used on both passes, whereas before it was only useful on the second pass. The --b-adapt setting must be the same on both passes or it won't work right. And yes, --weightb does give the most benefit on a clip with many fades, but it's probably not a bad idea to enable it on other clips, as it shouldn't hurt anything.

[G_M_C]

--weightb should be used on both passes, whereas before it was only useful on the second pass. The --b-adapt setting must be the same on both passes or it won't work right. And yes, --weightb does give the most benefit on a clip with many fades, but it's probably not a bad idea to enable it on other clips, as it shouldn't hurt anything.

Thx, i'm gonna try encoding a clip this weekend to see if i get it right :)

Anyway guess it is easy to use on megui (for me as a Megui n00b), since both passes/commandlines can be the same ;)

[Sagittaire]

--weightb should be used on both passes, whereas before it was only useful on the second pass. The --b-adapt setting must be the same on both passes or it won't work right. And yes, --weightb does give the most benefit on a clip with many fades, but it's probably not a bad idea to enable it on other clips, as it shouldn't hurt anything.

No I think that frame type decision is only for first pass.

[burfadel]

A forward predictor and statistics would be good for b-frame decision to become automatic. This would work by scanning ahead say, 6 frames and detecting whole scene changes in luminance. This would impact on performance very little, and by ramping up the b-frames when a change in luminance is detected (fades), you won't have the overall performance penalty of a high b-frame number throughout. The default b-frame decision number as base could be 3! This would also benefit other scenes where there are constant changes in luminance. On normal scenes where the luminance detector hasn't detected fades, statistics could be gathered to determine the optimum b-frame number. On very clean sources 3 may be ideal where there aren't any fades, and on more noisy sources 5 may be more beneficial. this would give the benefits of the better b-frame decision where needed, without the overall speed compromise of setting 16 b-frames. On clean video where there aren't fades, this may lead to a very fast encode without compromising quality/bitrate, and for scenes with grain or lots of fades, give the benefits of the higher b-frames, however with the slower speed. This would of course be an automatic feature when adaptive b-frames is enabled. However, for those that want an auto feature whilst encoding a video with lots of fades and noise, but don't want the speed penalty of a maximum of 16 b-frames, an option to set the maximum b-frames even on those scenes would be good. Maybe make the range of the maximum from say, 6 up to 16. For those that don't want the auto feautre, setting the adaptive b-frames to '2' could be used...

Just an idea, I don't know how practical it would be. Just since more b-frames is beneficial on fades though it would make sense to have a ramp up feature when fades are detected. Likewise, on normal scenes if 3 or 4 b-frames is the most common used, and since on scenes without fades are usually fairly consistent in terms of noise etc, then having a low b-frame decision number makes sense in those cases. In heavy motion scences, since this is already detected with the motion estimation etc and I believe in such cases less b-frames are used (mostly I and P frames?), even setting the b-frame decision level to 1 (if in high motion cases b-frames aren't used then maybe even 0!) in heavy scenes or 2 in less heavy scenes would promote a faster speed whilst again without the penalty of a higher decision level since its not needed.

Would this work at all? or is it just a fanciful idea? :)

[G_M_C]

I think that a forward predictor allready exsists; b-frame decicions are made on forward en backward (reference)frames (as far as i understand this whole encoding-thing ;) ).

I do not understand your post fully, but i get the idea that your method depends on fades not having much movement (classic fade-outs for instance). But what would happen on scenes that have same caractaristics as a fade, but have much movement; For instance a scene where "the bad guy" is chased by car, and drives into an unlit cave or tunnel. In a scene like that there is much movement, but overall-scene-luminance fades away gradually; It should not be detected as a fade.

I am not really knowledgable on things like this, but i've got the impression that luminance, chrominance and movement should all be considerated and weighed separately while encoding; Offcourse , in reality, you cant really see them separate from eachother, and i think that is whats making this whole thing complicated.

[burfadel]

Thats too true, I never though of it like that :) I guess that would be the benefit of setting a maximum b-frame decision limit of say 6 :) the main idea was to limit the thorough detection if the simple detection detects there is little change, since as pointed out by DS himself (I think it was him), 3 b-frames would be a good standard number. I was thinking that 3 would be good on normal scenes, but in the case of fade-outs more may be more beneficial. Even in the situation you pointed out, ramping it up to 6 or 7 just for that short time, even if its not used, would still be beneficial in an overall context as you would still have the benefit where needed of 6 or 7 b-frames, but without the penalty in static scenes where less are used and having the decision higher has a high penalty in terms of speed :) the statistics idea would still be good even if the other idea wasn't, as a ramp down feature instead of a ramp up!

I'm not entirely sure of how its done myself, the concept could be completely flawed :D!

[G_M_C]

Thats too true, I never though of it like that :) I guess that would be the benefit of setting a maximum b-frame decision limit of say 6 :) the main idea was to limit the thorough detection if the simple detection detects there is little change, since as pointed out by DS himself (I think it was him), 3 b-frames would be a good standard number. I was thinking that 3 would be good on normal scenes, but in the case of fade-outs more may be more beneficial. Even in the situation you pointed out, ramping it up to 6 or 7 just for that short time, even if its not used, would still be beneficial in an overall context as you would still have the benefit where needed of 6 or 7 b-frames, but without the penalty in static scenes where less are used and having the decision higher has a high penalty in terms of speed :) the statistics idea would still be good even if the other idea wasn't, as a ramp down feature instead of a ramp up!

I'm not entirely sure of how its done myself, the concept could be completely flawed :D!

In the situation I pointed out the max number of b-frames would never be reached, and in static scenes even more could be usefull (static scenes with fades are more or less just frame-repeats where only the avg-luminance changes).

But the max number of b-frames you can use also depends on your object; If you're encoding for blu-ray's, you can use less b-frames then when you make MKV's on level 5.1. So in many cases you are limited in what you can do.

The algorithm DS is trying to make has (more or less) be usefull for all cases, MKV and BR alike; So i have the feeling it's not that easy to develop. But i think luminance-weiging is indeed a part of it :)

[Dark Shikari]

Explicit fade-detection is not necessarily ideal; most fades are not linear so you can't just make them into a bunch of B-frames.

[gav1577]

--weightb should be used on both passes, whereas before it was only useful on the second pass. The --b-adapt setting must be the same on both passes or it won't work right. And yes, --weightb does give the most benefit on a clip with many fades, but it's probably not a bad idea to enable it on other clips, as it shouldn't hurt anything.

Sorry getting a little confused now so should --weightb be in both passes? and should --b-adapt 2 be in just the first pass or both? :)