View Full Version : [HD 1080p Challenge: Low bitrate!]
drbuzz0
28th August 2007, 02:56
Um... the bit torrent link for the source doesn't work for me. I tried it with uTorrent, which should be Bittorrent version 4.x compatible. It gives an error on the torrent file.
the current bittorrent official client is version 6.0. Do I need to track down the old version 4.0?
Or is there actually a problem with the torrent?
Dark Shikari
28th August 2007, 03:07
Um... the bit torrent link for the source doesn't work for me. I tried it with uTorrent, which should be Bittorrent version 4.x compatible. It gives an error on the torrent file.
the current bittorrent official client is version 6.0. Do I need to track down the old version 4.0?
Or is there actually a problem with the torrent?
You don't need to use the torrent--there's an FTP link there, I believe.
CruNcher
28th August 2007, 10:07
here is an example of x264 not so perfect p frame block decission compared vs Ateme useing the prestige matrix it was useing only i and p prediction
X264 p-frame --deadzone-inter 21 --subme 1 --me dia --no-deblock --no-dct-decimate --partitions "p8x8" --8x8dct (--no-fast-pskip plays no big difference here)
http://s3.directupload.net/images/070828/pDx5eAq4.png
X264 p-frame --deadzone-inter 0 (impacts rc imidiatly compression loss) --subme 1 --me dia --no-deblock --no-dct-decimate --partitions "p8x8" --8x8dct (--no-fast-pskip plays no big difference here)
http://s1.directupload.net/images/070828/CZr9Q4BW.png[/URL]
X264 p-frame --deadzone-inter 0 (impacts rc imidiatly compression loss) --subme 1 --me dia --no-deblock --no-dct-decimate --partitions "all" --8x8dct (--no-fast-pskip plays no big difference here)
http://s3.directupload.net/images/070828/cWIEIDyk.png
Ateme p-frame --qual fastest ,part,hpel,qpel,xf8x8
http://s1.directupload.net/images/070828/FB93RWt8.png
times
X264 7:10
Ateme 7:30
target bitrate 3000 kbps
Ateme = 2990 kbps
X264 = 2983 kbps
X264 = 2981 kbps (--deadzone-inter 0)
X264 = 2975 kbps (--partitions "all")
even with a little deblocking applied Ateme would still preserve more details, where in X264 all the details are lost allready, and if the marketing of Microsoft is correct the detail preservation for this and VC-1 should be even much better ;)
another Ateme this is so great they achived with H.264 what i never could have achived with XviD EDP it's really the XviD of H.264 :)
this is how Low Bitrate HD H.264 has to Look & Feel :) (no blurring sharp edges fantastic)
[see post #60]
akupenguin
28th August 2007, 14:22
here is an example of x264 not so perfect p frame block decission compared vs Ateme useing the prestige matrix it was useing only i and p prediction
A picture doesn't illustrate the block decisions. And do you have the same frame with flat matrix?
even with a little deblocking applied Ateme would still preserve more details, where in X264 all the details are lost allready, and if the marketing of Microsoft is correct the detail preservation for this and VC-1 should be even much better ;)
Do you see any details? I only see noise, turned into blocky noise. (For the first frame, that is. The second frame looks great.)
chickenmonger
29th August 2007, 04:32
Um... the bit torrent link for the source doesn't work for me. I tried it with uTorrent, which should be Bittorrent version 4.x compatible. It gives an error on the torrent file.
the current bittorrent official client is version 6.0. Do I need to track down the old version 4.0?
Or is there actually a problem with the torrent?
I had trouble with the torrent file, too. I tried using Azureus, and it seemed to at least start the torrent, but it took a -long- time. I think it creates all the files at once. As you may imagine, there's a -lot- of files in that torrent. The following website has the files up for http download. It's how I got the first 2000 frames. I wouldn't use it for the entire movie, though.
http://media.xiph.org/
zambelli
31st August 2007, 08:01
I had trouble with the torrent file, too. I tried using Azureus, and it seemed to at least start the torrent, but it took a -long- time. I think it creates all the files at once. As you may imagine, there's a -lot- of files in that torrent. The following website has the files up for http download. It's how I got the first 2000 frames. I wouldn't use it for the entire movie, though.
http://media.xiph.org/
Download a the Wget client (http://users.ugent.be/~bpuype/wget/#download) and run this:
wget -r -l 1 -A png http://media.xiph.org/ED/ED-1080-png/
zambelli
31st August 2007, 08:03
Do you see any details? I only see noise, turned into blocky noise. (For the first frame, that is. The second frame looks great.)
The second x264 frame? All 3 x264 frames look pretty bad to me compared to the Ateme frame. The skin details are nearly entirely gone in all 3 x264 frames.
akupenguin
31st August 2007, 11:38
"second frame" = the one that Cruncher only showed one version of.
For the first frame with 3 versions of x264 and 1 of Ateme, I don't see any details in any of the 4 versions. Just that Ateme preserved some noise which x264 smoothed out.
Golgot13
31st August 2007, 11:43
The second x264 frame? All 3 x264 frames look pretty bad to me compared to the Ateme frame. The skin details are nearly entirely gone in all 3 x264 frames.
You're right because Ateme is a professional encoder (not yet compliant with BD and HDDVD but sure soon...).
I listen some project to include "grain" optimization in X264....
And we will see after :devil:
and if the marketing of Microsoft is correct the detail preservation for this and VC-1 should be even much better ;)
Like St Thomas, I agree when I see. May be Zambelli can make a test with PEP at 3000Kbps but...
CruNcher can you give a little sequence at Zambelli?
A picture doesn't illustrate the block decisions.
Agree. It's much better to watch a small video encoded sequence to judge the picture quality.
CruNcher
31st August 2007, 11:55
"second frame" = the one that Cruncher only showed one version of.
For the first frame with 3 versions of x264 and 1 of Ateme, I don't see any details in any of the 4 versions. Just that Ateme preserved some noise which x264 smoothed out.
you right im gonna post the x264 version of that frame later today, but i doub't that x264 gonna look better (in detail preservation terms) im almost sure it will smooth out details, especialy with the standard deadzone settings. Im also prepareing a much more complex stream with different scenes to better be able to rate the decission and quality differences those are fairly short test sequences wich don't resamble a full source that precise this was just to see the general Look & Feel of both not how good they are @ compression.
Im not their yet to rate RDO of both also im no fan of to heavy compression and the Look & Feel this results in, im starting from the lowest point possible going the way up and this takes time.
The second x264 frame? All 3 x264 frames look pretty bad to me compared to the Ateme frame. The skin details are nearly entirely gone in all 3 x264 frames.
This is also very interesting you rate the quality based on what you see but you didn't saw the source yet as i didn't post that, aku looks @ it very different not from a user point of view but more from a tech guy pov :) "the power of visuall (p)(d)e(r)ception :D" best example to see why HVS is so important in lossy codecs.
Here are the dark sequence results
Ateme p-frame --qual fastest ,part,hpel,qpel,xf8x8
http://s1.directupload.net/images/070828/ABhGEu97.png
X264 p-frame --deadzone-inter 0 --subme 1 --me dia --no-deblock --no-dct-decimate --partitions "p8x8" --8x8dct
http://s2.directupload.net/images/070901/C4HoYsAB.png
X264 p-frame --deadzone-inter 21 --subme 1 --me dia --no-deblock --no-dct-decimate --partitions "p8x8" --8x8dct
http://s3.directupload.net/images/070901/qweWgNf7.png
X264 p-frame --deadzone-inter 21 --subme 1 --me dia --no-deblock --no-dct-decimate --partitions "all" --8x8dct
http://s3.directupload.net/images/070901/AY4FfFHA.png
CruNcher
5th September 2007, 00:48
VC-1 (consumer encoder WMP11) results
http://s4.directupload.net/images/070905/Jthcj885.png
http://s5.directupload.net/images/070905/iYfjmhUc.png
cscript WMCmd.vbs -input full.avs -output test.wmv -v_codec WVC1 -v_mode 0 -v_bitrate 3000000 -videoonly -v_dquantoption 0 -v_bframedist 0 -v_loopfilter 0 -v_complexity 0 -v_lookahead 0 -v_mbmodecost 0 -v_mmatch 1 -v_mslevel 0 -v_msrange 1 -v_mvcost 0 -v_percopt 0 -v_preset fast
this settings can be speedwise compared with the x264 and Ateme ones i used, only difference for the VC-1 encode is old ASP problems like smearing texture trails with this speed settings.
@zambelli wich option i have to increase to get rid only of those smearing trails ?
Sharktooth
5th September 2007, 02:56
ateme and VC-1 SS look sharper than x264 and pretty similar but VC-1 shows some blocking (and x264 too).
x264 seems to kill the small details and with deadzone set at 0 it seems to lack bitrate.
maybe subme 2 or more (maybe 4 or 5 but not higher) will do better in conjunction with deatzone-intra about 6. i would also use all partitions except p4x4, maybe umh and obvioulsy 8x8dct... im unsure about dct decimation too but i would remove it.
cruncher, could you post a screenshot encoded with those parameters?
CruNcher
5th September 2007, 11:29
yep gonna try that later (but i feel that highering the ME in anyway is gonna kill the grain even with a low deadzone) deadzone-intra 6 shouldn't really improve anything -deadzone-inter 6 you mean ? -deadzone-intra can be very high without any bad effect on the p-frame decission, if im correct intra frames only get a little more blurry then (this doesn't have any effect on p-frames except that they get more bits that where taken from the intra frames, i think) but they are so far away (in an unconstrained encode) from each other that this shouldn't get realy visible.
(in the first VC-1 frame you can really see how it preserved the grain almost completly, the second frame lacks from dquant i think so better balanced settings should improve that with hopefully don't destroy the grain that much as H.264 does, but a more important visually problem in the VC-1 encode are those smearing texture trails we know from ASP times @ the moment)
CruNcher
6th September 2007, 01:05
here are the results sharktooth (it got even more bad then i expected, im heading into unreality (source wise not real life) tough for sure nice for Anime/Comic or Digital Cinema :P )
--partitions "i4x4,i8x8,p8x8" --8x8dct --bframe 0 --no-deblock --me umh --subme 2 --deadzone-intra 32 --deadzone-inter 6
http://s4.directupload.net/images/070906/hchExq2o.png
http://s5.directupload.net/images/070906/vYq6TxX9.png
Sharktooth
6th September 2007, 02:42
yeah. looks smeared... but why deazone-intra 32?!?!? that's the source of smearing :p
use deadzone-intra 6 or something...
benwaggoner
7th September 2007, 12:28
@Cruncher
Those are pretty non-quality optimized settings! You'd likely get a lot better results for this test with the below (just general starting settings - I haven't seen the source yet):
cscript WMCmd.vbs -input full.avs -output test.wmv -v_codec WVC1 -v_mode 3 -v_bitrate 2000000 -videoonly -v_dquantoption 2 -v_bframedist 1 -v_loopfilter 1 -v_complexity 4 -v_mmatch 0 -v_mslevel 2 -v_msrange 0 -v_percopt 2
Why did you turn lookahead off in your settings? It's a nice help with all 1-pass encodes. Of course, 2-pass does better yet.
Of course, our new VC-1 Encoder SDK would be quite a bit faster and higher quality:
http://www.microsoft.com/presspass/press/2007/sep07/09-06VC1EncoderToolsPR.mspx
CruNcher
7th September 2007, 19:53
Of course, our new VC-1 Encoder SDK would be quite a bit faster and higher quality:
For sure as it isn't 1 Year old *rofl*
And to answer your lookahead question because i wan't to find out how advanced the encoders are and Grain and Low Bitrate are perfect to find out (without useing a workarround like FGT) how advanced the visual quality is and i test @ wich speed this target can be hit by the encoders, first without any additional extras so lowest speed settings possible and then i go slowly higher and look again and again and again and again very time consumeing process that is especialy for a full 3h HD source @ this low bitrate, your settings are still far away and sound very slow btw.
Lookahead is indeed a nice thing, because it doesn't take much speed and gives a nice precission boost (just a little more ram usage) but it doesn't change much of how the encoder handles different scenes visualy just the precission is enhanced and it wouldn't also get rid of those smearing trails i talked about most probably higher ME does but then the question is if VC-1 will keep the grain.
And sure Grain is bad and an old analog recording problem that most of Hollywood Directors sell nowdays as an "Artistic" thing that people get used to or better "druged" from it over the years especialy the older Generation (people that don't know anything else old Hollywood Lab workers for example), that's also why i doubt it will vanish in the coming Digital Cinema era completly it won't for sure and so more advanced codecs need to handle Grain (they shouldn't tough, because Grain is still an artifact) in the future for sure, todays Video Codecs arent advanced enough to preserve the grain @ those low bitrates (that's why FGT is exisiting, a simple workarround) but the way they handle a Grainy source nowdays is interesting for example the smearing trails of VC-1 at this bitrate aren't noticeable with H.264 at the same speed settings and this shows at least for me that current H.264 implementations are more advanced handling grainy sources (at low bitrates) for sure not optimal but good enough to give good results without any extra user interaction as degrain/noising or setting extra parameters (but as you said H.264 wise im testing with the newest from the newest and VC-1 wise im testing with 1 Year old technology, so im almost sure that i could spare my time and just throw VC-1 out of my tests :P (as the results would be allready outdated), and im sorry but i can't understand Microsofts consumer politics in that way this is only marketing for sure you gonna provide the average users with the new Encoder Core with WMP 12 that comes maybe next year or whatnot so you hold this advances back from the general public and i have no idea what this brings for Microsoft why do you hide your advances from the average users i can't understand it and seeing your press release this software is far away from the average users budget, and don't say it would take to much time doing a Encoder update for WMP11 VC-1 that you wan't to wait till WMP 12, if that's really the case it's no wonder that Microsoft can't keep up with the pace and sooner or later is gonna fall like the Roman Empire did ;) .
Sharktooth
8th September 2007, 03:32
you still havent tried my settings with a lower deadzone-intra... :p
benwaggoner
9th September 2007, 10:46
@CruNcher
Sorry, I've got too much jet lag to mentally figure out where to stick all the punctuation.
But if your challenge is to try and preserve film grain with FSDK 11, I recommend you try these settings:
DQuant: I+P frames only
DQuant Method: Regular
Perceptal Option: Adaptive Dead-Zone 1
I-Loop Filter: On
Overlap Filter: On
Motion Search Level: Fixed True Chroma
Motion Match Method: Adaptive
B-Frame Number:1
As for the commercial license, we're not saying there won't be future updates to the free codec. But the Format SDK 11 is a Windows Component, and it's up to Windows to release those updates on their schedule. We're doing the VC-1 Encoder program as a way to provide additional improvements to commercial compresion products and processes on a more rapid schedule than tying to a Windows release schedule and release requirements would allow.
I realize that isn't a big help to this specific community, but certainly will address the needs of most professional compression service providers, and the viewers of commecial compressed media. But I hope we can find a good way to provide improvements to the user-generated content market as well.
I keep hoping someone is going to start a robust open-source "xvc1" effort to compete with our VC-1 implementation...
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.