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 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 4th August 2009, 20:56   #61  |  Link
moviefan
Registered User
 
Join Date: Jul 2005
Posts: 438
@Chengbin: What DS (as I understood) is saying is that CRF most probably hasn't shifted by a constant value but it has entirely changed and this change cannot easily be described on basis of one encoding sample. You simply need to find a new CRF that meets your demands, but I think you always have to if you don't want to waste bitrate or lack quality in the end.
moviefan is offline   Reply With Quote
Old 4th August 2009, 22:20   #62  |  Link
Firethe1
Registered User
 
Join Date: Apr 2009
Posts: 2
Hi,
its sad that this is my first post, but x264_mbtree keeps crashing with one input file ...
The crash occurs around frame 2-20 ...
Already tried to reduce lookahead to 0.

commandline:
Code:
C:\Dokumente und Einstellungen\Fire>"D:\$Test\temp\x264_mbtree11.exe" --lookahea
d 0 --pass 1 --mbtree --ref 2 --bitrate 500 --qcomp 0.95 --bframes 3 --b-adapt 2
 --mixed-refs --no-fast-pskip --weightb --direct auto --subme 10 --trellis 2 --p
artitions all --8x8dct --me umh --merange 32 --nr 50 --stats "D:\$Test\temp\test
2.avs.mbtree.stats" --threads 1 --thread-input -o "D:\$Test\temp\test2.avs.mbtre
e.mkv" "D:\$Test\temp\test2.avs"
avis [info]: 1280x720 @ 23.98 fps (1750 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile Main, level 3.1
[0.2%] 4/1750 frames, 43.01 fps, 0.00 kb/s, eta 0:00:40
even this cmd crashes: (works with latest x264.exe from x264.nl 32 Bit)
Code:
C:\Dokumente und Einstellungen\Fire>"D:\$Test\temp\x264_mbtree11.exe" -o D:\$Tes
t\temp\test2.avs.mkv D:\$Test\temp\test2.avs
avis [info]: 1280x720 @ 23.98 fps (1750 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 3.1
[0.1%] 2/1750 frames, 32.26 fps, 0.00 kb/s, eta 0:00:54
gdb: (hopefully i did it right ... but i dont think so xD)
Code:
D:\$Test\temp>gdb.exe D:\$Test\temp\x264_mbtree11_debug.exe
GNU gdb (GDB) 6.8.50.20090804
Copyright (C) 2009 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 "i386-pc-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
This binary was built by Equation Solution <http://www.Equation.com>...
(gdb) run  -o a.mkv test2.avs
Starting program: D:\$Test\temp\x264_mbtree11_debug.exe -o a.mkv test2.avs
[New Thread 4472.0x12e4]
warning: Can not parse XML library list; XML support was disabled at compile tim
e
[New Thread 4472.0x1248]
[New Thread 4472.0x1208]
[New Thread 4472.0x264]
[New Thread 4472.0x858]
[New Thread 4472.0xf90]
warning: HEAP[x264_mbtree11_debug.exe]:
warning: Invalid Address specified to RtlFreeHeap( 00240000, 00FAF174 )


Program received signal SIGTRAP, Trace/breakpoint trap.
0x7c91120f in ?? ()
(gdb) bt
#0  0x7c91120f in ?? ()
#1  0x7c97c201 in ?? ()
#2  0x0022ebe8 in ?? ()
#3  0x7c97c63e in ?? ()
#4  0x00faf16c in ?? ()
#5  0x00240000 in ?? ()
#6  0x00faf174 in ?? ()
#7  0x0022ec5c in ?? ()
#8  0x7c97d826 in ?? ()
#9  0x00240000 in ?? ()
#10 0x00faf16c in ?? ()
#11 0x7c97d9dc in ?? ()
#12 0x00240000 in ?? ()
#13 0x00faf174 in ?? ()
#14 0x40000060 in ?? ()
#15 0x00000040 in ?? ()
#16 0x00f37e48 in ?? ()
#17 0x003e0000 in ?? ()
#18 0x003e0000 in ?? ()
#19 0x007d0037 in ?? ()
#20 0x0101ecec in ?? ()
#21 0x0022ebd8 in ?? ()
#22 0x0022ebdc in ?? ()
#23 0x0022ed10 in ?? ()
#24 0x00014320 in ?? ()
#25 0x00faf16c in ?? ()
#26 0x00240000 in ?? ()
#27 0x7c97d994 in ?? ()
#28 0x7c959e1c in ?? ()
#29 0x00010000 in ?? ()
#30 0x0022ebfc in ?? ()
#31 0x7c937764 in ?? ()
#32 0x0022ed34 in ?? ()
#33 0x7c91e900 in ?? ()
#34 0x7c97d9b8 in ?? ()
#35 0x00000001 in ?? ()
#36 0x0022ed44 in ?? ()
#37 0x7c959e1c in ?? ()
#38 0x00240000 in ?? ()
#39 0x50000061 in ?? ()
#40 0x00faf174 in ?? ()
#41 0x00240000 in ?? ()
#42 0x00faf174 in ?? ()
#43 0x40000060 in ?? ()
#44 0x40000060 in ?? ()
#45 0x7c92003d in ?? ()
#46 0x00efa744 in ?? ()
#47 0x00efa740 in ?? ()
#48 0x00240000 in ?? ()
#49 0x0022ed60 in ?? ()
#50 0x7c91e900 in ?? ()
#51 0x7c937768 in ?? ()
#52 0xffffffff in ?? ()
#53 0x7c937764 in ?? ()
#54 0x7c007553 in ?? ()
#55 0x003e0000 in ?? ()
#56 0x0022ebf0 in ?? ()
#57 0x7c92003d in ?? ()
#58 0x0022ed84 in ?? ()
#59 0x7c91e900 in ?? ()
#60 0x7c937768 in ?? ()
#61 0xffffffff in ?? ()
#62 0x7c937764 in ?? ()
#63 0x7c937553 in ?? ()
#64 0x00240000 in ?? ()
#65 0x40000060 in ?? ()
#66 0x7c92003d in ?? ()
#67 0x00e98f4c in ?? ()
#68 0x0022edd8 in ?? ()
#69 0x00e95038 in ?? ()
#70 0x0022ec40 in ?? ()
#71 0x003e0000 in ?? ()
#72 0x003e0000 in ?? ()
#73 0x7c91e900 in ?? ()
#74 0x7c920040 in ?? ()
#75 0xffffffff in ?? ()
#76 0x7c92003d in ?? ()
#77 0x7c001432 in ?? ()
#78 0x7c001463 in ?? ()
#79 0x0022ec4c in ?? ()
#80 0x00240000 in ?? ()
#81 0x0022ede0 in ?? ()
#82 0x7c91e900 in ?? ()
#83 0x7c937768 in ?? ()
#84 0xffffffff in ?? ()
#85 0x7c937764 in ?? ()
#86 0x7c007553 in ?? ()
#87 0x003e0000 in ?? ()
#88 0x0022ec70 in ?? ()
#89 0x7c92003d in ?? ()
#90 0x0022ee04 in ?? ()
#91 0x7c91e900 in ?? ()
#92 0x7c937768 in ?? ()
#93 0xffffffff in ?? ()
#94 0x0022ee14 in ?? ()
#95 0x7c937553 in ?? ()
#96 0x00240000 in ?? ()
#97 0x40000060 in ?? ()
#98 0x00faf174 in ?? ()
#99 0x0022eea8 in ?? ()
#100 0x00f37e90 in ?? ()
#101 0x00f08ca8 in ?? ()
#102 0x0022ed44 in ?? ()
#103 0x0022f218 in ?? ()
#104 0x0022f218 in ?? ()
#105 0x0022ed54 in ?? ()
#106 0x000113d8 in ?? ()
#107 0x0022f218 in ?? ()
#108 0x0022ecd8 in ?? ()
#109 0x77be2070 in ?? ()
#110 0x0022f218 in ?? ()
#111 0x7c91e900 in ?? ()
#112 0x7c920040 in ?? ()
#113 0xffffffff in ?? ()
#114 0x7c92003d in ?? ()
#115 0x774cd01c in ?? ()
#116 0x00240000 in ?? ()
#117 0x00000000 in ?? ()
AVS:
Code:
DirectShowSource("X:\test.mp4",audio=false)
LoadPlugin("D:\***\UnDot.dll")
UnDot()
ConvertToYV12()
SelectRangeEvery(5000,250)
AVS plays fine in mpc ... and this is the first file which crashes ...

If you need more information/i should try something then tell me ^^
Firethe1 is offline   Reply With Quote
Old 4th August 2009, 22:26   #63  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
Don't use Avisynth input during debugging; use raw YUV input only.
Dark Shikari is offline   Reply With Quote
Old 4th August 2009, 22:32   #64  |  Link
Firethe1
Registered User
 
Join Date: Apr 2009
Posts: 2
thx for the quick response ... could you also tell me how i get my avs input to a raw yuv file? thx

found avs2yuv.exe .. tried like this: avs2yuv.exe test2.avs -raw -o test2.yuv
put also crashes ... maybe its avisynth ...
Code:
AppName: avs2yuv.exe	 AppVer: 0.0.0.0	 ModName: avisynth.dll
ModVer: 2.5.7.0	 Offset: 000168f0
Updated to Avisynth 2.5.8 with directshowsource plugin patch and it works ... sry

Last edited by Firethe1; 4th August 2009 at 23:08.
Firethe1 is offline   Reply With Quote
Old 4th August 2009, 22:47   #65  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
Quote:
Originally Posted by Firethe1 View Post
thx for the quick response ... could you also tell me how i get my avs input to a raw yuv file? thx

found avs2yuv.exe .. tried like this: avs2yuv.exe test2.avs -raw -o test2.yuv
put also crashes ... maybe its avisynth ...
It probably is Avisynth
Dark Shikari is offline   Reply With Quote
Old 4th August 2009, 23:42   #66  |  Link
Yoshiyuki Blade
Novice x264 User
 
Yoshiyuki Blade's Avatar
 
Join Date: Dec 2006
Location: California
Posts: 169
Tests on some anime I have are looking good so far!

Even at lower bitrates, an aq and psy-rd value of 1.0 doesn't create as much horrible artifacts as before.

Testing with --tune animation now.
__________________
"I'll take a potato chip... and eat it!"

Last edited by Yoshiyuki Blade; 4th August 2009 at 23:49.
Yoshiyuki Blade is offline   Reply With Quote
Old 5th August 2009, 00:16   #67  |  Link
Chengbin
Registered User
 
Join Date: Oct 2007
Posts: 1,060
Quote:
Originally Posted by Dark Shikari View Post
Please stop responding to my posts without reading them.
Quote:
Originally Posted by moviefan View Post
@Chengbin: What DS (as I understood) is saying is that CRF most probably hasn't shifted by a constant value but it has entirely changed and this change cannot easily be described on basis of one encoding sample. You simply need to find a new CRF that meets your demands, but I think you always have to if you don't want to waste bitrate or lack quality in the end.
I understood him well.

If one encoding says with the same CRF value an encoding dropped 35% in bitrate than the unpatched, that means the same CRF value gives lower bitrate encodes. Of course with different sources the percentage will differ, but I seriously doubt it will vary much, let alone 35%.

How about as a suggestion, when CRF changes, can you tell us what is the new "CRF 18"?
Chengbin is offline   Reply With Quote
Old 5th August 2009, 00:30   #68  |  Link
Sagekilla
x264aholic
 
Join Date: Jul 2007
Location: New York
Posts: 1,752
Why don't you do some testing? Go pick out a bunch of clips, test them with and without mbtree.

Find what the average change in crf is, then you'll know. I know you think that it might not vary much, but the only way you can really prove that is by testing more than one source.

Otherwise, I could pull out a source and say "Hey, I think this changes the crf upwards by 5" which could be completely wrong.

I'd do testing myself, but I don't have the time for it at the moment (Going away on vacation soon). If anyone is willing to do the testing, you or otherwise, it would be useful for everyone.
__________________
You can't call your encoding speed slow until you start measuring in seconds per frame.
Sagekilla is offline   Reply With Quote
Old 5th August 2009, 00:30   #69  |  Link
nm
Registered User
 
Join Date: Mar 2005
Location: Finland
Posts: 2,641
Quote:
Originally Posted by Chengbin View Post
If one encoding says with the same CRF value an encoding dropped 35% in bitrate than the unpatched, that means the same CRF value gives lower bitrate encodes. Of course with different sources the percentage will differ, but I seriously doubt it will vary much, let alone 35%.
From the first post (emphasis mine):
Quote:
Originally Posted by Dark Shikari
Also, note that CRF is redefined again by this patch--I set it so that it kept the same bitrate on Blackpearl as before, but it may vary for different videos.
nm is offline   Reply With Quote
Old 5th August 2009, 00:58   #70  |  Link
Chengbin
Registered User
 
Join Date: Oct 2007
Posts: 1,060
Quote:
Originally Posted by Sagekilla View Post
Why don't you do some testing? Go pick out a bunch of clips, test them with and without mbtree.

Find what the average change in crf is, then you'll know. I know you think that it might not vary much, but the only way you can really prove that is by testing more than one source.

Otherwise, I could pull out a source and say "Hey, I think this changes the crf upwards by 5" which could be completely wrong.

I'd do testing myself, but I don't have the time for it at the moment (Going away on vacation soon). If anyone is willing to do the testing, you or otherwise, it would be useful for everyone.
CRF has been changed twice in I think 2 months (AutoVAQ (from the time it officially been adopted in x264, I didn't take it seriously before), and mbtree).

If I did testing (which I did for AutoVAQ with all kinds of sources), by the time I finished with AutoVAQ testing (which is a few weeks ago), my data is obsolete because of mbtree. Who knows when another change could happen. Maybe an update to mbtree will change CRF again. I think you can understand why I'm asking.

Just to keep the thread on topic, are there any compression improvements with this patch? Or is it visuals only?

Last edited by Chengbin; 5th August 2009 at 01:02.
Chengbin is offline   Reply With Quote
Old 5th August 2009, 01:53   #71  |  Link
wyti
Insane Encoder
 
wyti's Avatar
 
Join Date: Feb 2008
Location: Lausanne (Switzerland)
Posts: 142
plz learn to read...
if metrics increase it means that's a compression improvement.
metrics almost always go down when it's visually (aq PSNR goes down, psyrd / trellis both go down...)

And the change at the crf value may happend until the commit of this patch, this is a TEST patch, and everything that is true today may be wrong tomorow. It's not for real encoding, but to see what it does, where it fails, where it does great and improve this path before he got commited
__________________
Only two things are infinite, the universe and human stupidity, and I’m not sure about the former.
wyti is offline   Reply With Quote
Old 5th August 2009, 05:16   #72  |  Link
Sagekilla
x264aholic
 
Join Date: Jul 2007
Location: New York
Posts: 1,752
Yes, mbtree should improve quality, visually and metrically speaking.

It might not be as easy to judge in crf mode given the wide fluctuations we've seen, but it should be optimal when it comes out of testing.
__________________
You can't call your encoding speed slow until you start measuring in seconds per frame.
Sagekilla is offline   Reply With Quote
Old 5th August 2009, 06:14   #73  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
Original post updated with v0.13.
Dark Shikari is offline   Reply With Quote
Old 5th August 2009, 07:05   #74  |  Link
Zachs
Suptitle, MediaPlayer.NET
 
Join Date: Nov 2001
Posts: 1,721
@DS

In your OP, you said that mb-tree is on by default. And --preset fast and faster also turns it on. That means, other presets have it turned off?
Zachs is offline   Reply With Quote
Old 5th August 2009, 07:09   #75  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
Quote:
Originally Posted by Zachs View Post
@DS

In your OP, you said that mb-tree is on by default. And --preset fast and faster also turns it on. That means, other presets have it turned off?
Yes, "faster", "veryfast", and "ultrafast" have it off.

Fast and above (medium, slow, etc) have it on.
Dark Shikari is offline   Reply With Quote
Old 5th August 2009, 07:16   #76  |  Link
Zachs
Suptitle, MediaPlayer.NET
 
Join Date: Nov 2001
Posts: 1,721
@DS

Thanks.

BTW, is mb-tree with b-pyramid any closer for testing?
How much does b-pyramid add to encodes anyway?
Zachs is offline   Reply With Quote
Old 5th August 2009, 07:21   #77  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
Quote:
Originally Posted by Zachs View Post
@DS

Thanks.

BTW, is mb-tree with b-pyramid any closer for testing?
How much does b-pyramid add to encodes anyway?
I probably will commit without pyramid support, then add pyramid support when Trahald finishes MMCO-related stuff.

Currently I don't think MB-tree with pyramid is a good idea as long as we allow referenced B-frames to end up in the reference list.
Dark Shikari is offline   Reply With Quote
Old 5th August 2009, 07:45   #78  |  Link
G_M_C
Registered User
 
Join Date: Feb 2006
Posts: 1,076
Quote:
Originally Posted by G_M_C View Post
Well my first test is allmost done. Made a 20 minutes reencode of a docu i capped from BBCHD. Will put it on BD9, so i've used juGGaKNot build with HRD.

For testing purposes i've enabled 2-pass mode with both --ssim and --psnr. Will paste results tomorrow, after i've done test no2 (the one without --mbtree (which will be the only difference in the commandline/source etc. used).

This test will also test if --mbtree is accepted by STD's like my Panasonic BD30 (and incidentily if the mbtree patch coincides with the other patches juGGaKNot used, like the hrd-patch).
As promised. I give the log of pass 2 of both encodes. Used same commandline on both encodes, only removed/added --mbtree.

Commandline used:
Quote:
<<x264>> --threads auto --thread-input --psnr --ssim "%IN_TITLE%.avs" --stats "%IN_TITLE%.stats" --output "%OUT_TITLE%.264" --pass 2 --bitrate 4450 --vbv-bufsize 30000 --vbv-maxrate 24000 --level 4.1 --deblock -1:-1 --keyint 25 --min-keyint 1 --nal-hrd --fps 25 --aud --sar 1:1 --bframes 3 --b-adapt 2 --ref 6 --no-fast-pskip --ipratio 1.3 --pbratio 1.2 --direct auto --subme 10 --trellis 2 --psy-rd 1.0:0.2 --partitions all --me umh --merange 24 --mvrange 511 --aq-strength 1.0 --aq-mode 1 --mbtree
Encode without --mbtree
Code:
avis [info]: 1280x720 @ 25.00 fps (35001 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cach
e64
x264 [info]: profile High, level 4.1
x264 [info]: slice I:2212  Avg QP:19.00  size: 73712  PSNR Mean Y:46.71 U:50.33
V:50.92 Avg:47.62 Global:46.51
x264 [info]: slice P:12247 Avg QP:21.08  size: 32098  PSNR Mean Y:43.76 U:47.87
V:48.92 Avg:44.78 Global:43.59
x264 [info]: slice B:20542 Avg QP:22.86  size: 10825  PSNR Mean Y:43.02 U:47.50
V:48.58 Avg:44.09 Global:43.19
x264 [info]: consecutive B-frames:  4.1% 18.0% 57.1% 20.8%
x264 [info]: mb I  I16..4:  8.2% 84.8%  7.0%
x264 [info]: mb P  I16..4:  1.8% 14.8%  0.6%  P16..4: 44.0% 20.5% 13.5%  0.2%  0
.2%    skip: 4.5%
x264 [info]: mb B  I16..4:  0.5%  1.9%  0.1%  B16..8: 42.1%  1.6%  2.4%  direct:
 9.2%  skip:42.3%  L0:35.6% L1:48.1% BI:16.3%
x264 [info]: 8x8 transform  intra:84.6%  inter:74.8%
x264 [info]: direct mvs  spatial:76.3%  temporal:23.7%
x264 [info]: coded y,uvDC,uvAC intra:80.9% 80.7% 46.4% inter:30.4% 32.1% 3.9%
x264 [info]: ref P L0  78.9% 11.5%  5.4%  2.2%  1.3%  0.7%
x264 [info]: ref B L0  85.2%  8.9%  3.6%  1.5%  0.9%
x264 [info]: SSIM Mean Y:0.9784036
x264 [info]: PSNR Mean Y:43.516 U:47.805 V:48.844 Avg:44.553 Global:43.481 kb/s:
4448.60

encoded 35001 frames, 4.39 fps, 4448.63 kb/s
]

Encode with --mbtree
Code:
avis [info]: 1280x720 @ 25.00 fps (35001 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cach
e64
x264 [info]: profile High, level 4.1
x264 [info]: slice I:2211  Avg QP:18.28  size: 89332  PSNR Mean Y:47.28 U:50.78
V:51.30 Avg:48.17 Global:47.36
x264 [info]: slice P:12255 Avg QP:21.25  size: 32438  PSNR Mean Y:43.83 U:47.96
V:48.98 Avg:44.85 Global:43.92
x264 [info]: slice B:20535 Avg QP:24.79  size:  8944  PSNR Mean Y:43.01 U:47.53
V:48.62 Avg:44.07 Global:43.39
x264 [info]: consecutive B-frames:  4.2% 17.4% 59.0% 19.5%
x264 [info]: mb I  I16..4: 10.8% 79.8%  9.4%
x264 [info]: mb P  I16..4:  1.9% 15.0%  0.6%  P16..4: 43.2% 19.4% 13.4%  0.2%  0
.3%    skip: 6.0%
x264 [info]: mb B  I16..4:  0.4%  1.8%  0.1%  B16..8: 40.3%  1.4%  1.8%  direct:
 6.0%  skip:48.2%  L0:37.7% L1:47.7% BI:14.6%
x264 [info]: 8x8 transform  intra:82.3%  inter:74.7%
x264 [info]: direct mvs  spatial:72.8%  temporal:27.2%
x264 [info]: coded y,uvDC,uvAC intra:80.6% 80.1% 48.2% inter:26.1% 26.6% 3.5%
x264 [info]: ref P L0  78.7% 11.7%  5.5%  2.2%  1.3%  0.7%
x264 [info]: ref B L0  86.5%  8.1%  3.3%  1.3%  0.8%
x264 [info]: SSIM Mean Y:0.9790297
x264 [info]: PSNR Mean Y:43.564 U:47.884 V:48.917 Avg:44.603 Global:43.742 kb/s:
4449.59

encoded 35001 frames, 4.41 fps, 4449.62 kb/s
I saw a rise in both SSIM and PSNR, but not shockingly high percentages. But i did notice a difference of 2 points in the avg QP used for b-frames. At the same time I-frames got a slightly lower QP, and the QP for P stayed about the same.

But other than that, all went as if nothing changed. My STD ran these files as usual (no change noticed), and visual quality was about the same (with a slight plus on the --mbtree side).

Will run another encode with some different parameters while i'm at work (with/without VAQ). I'll post about those when i get back from work.

Last edited by G_M_C; 5th August 2009 at 10:05.
G_M_C is offline   Reply With Quote
Old 5th August 2009, 08:29   #79  |  Link
tetsuo55
MPC-HC Project Manager
 
Join Date: Mar 2007
Posts: 2,317
Quote:
Originally Posted by Dark Shikari View Post
Currently I don't think MB-tree with pyramid is a good idea as long as we allow referenced B-frames to end up in the reference list.
Do you mean the that with that other patch b-frames will be freed from reference frames?

This might raise b-frame and b-pyramid compatibility with standalone devices! (or break them)
__________________
MPC-HC, an open source project everyone can improve. Want to help? Test Nightly Builds, submit patches or bugs and chat on IRC
tetsuo55 is offline   Reply With Quote
Old 5th August 2009, 10:47   #80  |  Link
juGGaKNot
Registered User
 
juGGaKNot's Avatar
 
Join Date: Feb 2008
Posts: 733
x264_x86_r1195_juGGaKNot
GCC 4.4.0, modified, fprofiled, patched
Code:
Source: GIT

Applied patches :

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.15_interlace.diff
x264_Macroblock_Tree_Ratecontrol_013.diff
x264_juGGaKNot_preset_01.diff ( This just adds a preset, juggaknot, download it to see the settings )

It is fprofiled on a uncompressed 300 frames source with very high motion

Please check Doom9.org patches thread, Doom9.org Macroblock tree Ratecontrol thread and GIT shortlog for more info.

Compiled by juGGaKNot with GCC 4.4.0 on Windows XP SP-2 32-bit.

Platform:   X86
System:     MINGW
asm:        yes
avis input: yes
mp4 output: yes
pthread:    yes
debug:      no
gprof:      no
PIC:        no
shared:     no
visualize:  no

Last edited by juGGaKNot; 5th August 2009 at 13:38.
juGGaKNot is offline   Reply With Quote
Reply

Tags
development, testing, x264

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 08:27.


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