View Full Version : is AVC really that good?
Sharktooth
26th January 2005, 15:39
Ok, i did a small test on the usual spiderman 2 trailer.
Encoding was done thru: AVS + recode and AVS + virtualdubmod.
The AVS script is 3 lines long:
# VIDEO SOURCE
Mpeg2Source("sp2tr.d2v", idct=2)
# CROPPING
Crop(0,14,720,548)
# RESIZING
LanczosResize(720,384)
Codec settings:
AVC maximum definition profile:
2 passes, everything (including chroma optimization) enabled. Reference frames set to 5 (old default), GOP size set to 250 (25fps...), vector range set to -256/+256, bframes set to 1 (default) and inloop deblocking set to deblocking strenght = 1.
VP6.4.2 heightened sharpness profile:
default settings except sharpness 8.
(dowload the codec here: http://ebola.gamersrevolt.it/vp6/VP6.4.2.rar and ensure the post processing is set to best quality. A large advantage VP6 has over other codecs is it's postprocessing and the ability to reconstruct the lost data during playback. so postprocessing should be always activated.)
bitrate is about 900kbit for both codecs. Download the clips and post your impressions.
Clip1: Nerodigital (http://www.aziendeassociate.com/sp2.tr.Nero.AVC.mp4) (updated - again - and again...)
Clip2: VP6.4.2 (http://ebola.gamersrevolt.it/temp/sp2.tr.VP6.4.2.avi)
Clip3: x.264 (http://www.aziendeassociate.com/sp2.tr.x.264.avi) (updated to rev. 111)
Clip4: x.264 no b-frames (http://www.aziendeassociate.com/sp2.tr.x.264.noB.avi)
Clip5: Xvid 1.1b1 (http://www.aziendeassociate.com/sp2.tr.xvid.1.1.b1.avi)
Clip6: Xvid 1.1EDP (http://www.aziendeassociate.com/sp2.tr.xvid.1.1.edp.avi)
Clip7: NeroDigital (unreleased encoder) (http://www.aziendeassociate.com/sp2.tr.b3.dbl2_johnv.mp4)
Edit: The ND clip was encoded several times and it seems B-Frames were generating blocks everywhere. 1 b-frame encode was the best result i could obtain (without disabling b-frames...).
Edit2: x.264 clip was added. Settings are default except 1-bframe, 5 reference, deblocking 1/1, no fast first pass and of course 2-passes @ 907 kbits. x.264 w/out b-frames was also added (thanks len0x)
Edit3: Added a xvid and a xvid EDP encode (thanks cruncher) at the same bitrate of 907kbps.
Edit4: Added a new nero digital clip encoded by JohnV with the newest nerodigital filters, deblocking st = -2, 3 b-frames and all encoder options activated.
Leo 69
26th January 2005, 16:07
Originally posted by Sharktooth
ensure the post processing is set to best quality. A large advantage VP6 has over other codecs is it's postprocessing and the ability to reconstruct the lost data during playback. so postprocessing should be always activated.)
This is already not fair , mate. :D We'd better test the raw encoder perfomance,without any decoder postprocessing.Although I'm very sad I can't download your clips because of my slow modem :(
JohnV
26th January 2005, 16:16
My very subjective personal opinion (as you can guess.. :D). ND AVC has a bit more blocking (which can be fixed with different inloop settings), but looks much more detailed and sharper than VP 6.4.2.
Of course my opinion doesn't count, but anyway.. :)
Sirber
26th January 2005, 16:16
VP6 strength is mostly based on it's postprocessing filter. You should always have it on.
G-Slide
26th January 2005, 16:17
i prefer AVC
Sharktooth
26th January 2005, 16:19
AVC is "generally" more detailed but there are artifacts everywhere...
Ok, what settings you suggest for deblocking?
@ Leo69: so VP6 has no B-Frames and no inloop deblocking etc... should i disable those in AVC? Your comment has no sense at all. VP6 relays on PP since it is part of the codec... It is a COder-DECoder...
Leo 69
26th January 2005, 16:26
In my opinion, AVC is a fantastic codec.It does miracles, really.
For the last week I've encoded the three(!) parts of Lord of the Rings onto 1(!) CD(700mb).That's over 9 hours of video & audio (HE AAC @ 32kbps).No other codec is capable of what the AVC has done for me
:cool: This is pretty amazing ! Check out the short clip which shows the OVERALL quality of those encodes.I'm VERY delighted with the result.He-he:D It's a good fun to compress the video so much.
Check it out,it's only @ 130kbps :p
http://cp.people.overclockers.ru/cgi-bin/dl.pl?id=4585&filename=X264.rar
JohnV
26th January 2005, 16:26
Originally posted by Sharktooth
AVC is "generally" more detailed but there are artifacts everywhere...
Ok, what settings you suggest for deblocking? But VP 6.4.2 looks very "post-prosessed" and has unstable grainyness.
For AVC, try deblocking 3-4 for this for example, especially if you use that much post-processing for VP6.4.2, then give AVC inloop also more strength.. Maybe automatic smooth is good also, but if you prefer that much post prosessing for VP, then use higher fixed deblocking here for AVC.
Sharktooth
26th January 2005, 16:29
It's how vp6 works. PP is adaptive.
I already tried with auto smooth... no good...
Trying with deblocking strength = 4.
Leo 69
26th January 2005, 16:37
@ Leo69: so VP6 has no B-Frames and no inloop deblocking etc... should i disable those in AVC? Your comment has no sense at all. VP6 relays on PP since it is part of the codec... It is a COder-DECoder...
Sharktooth
Well maybe it makes no sense.But I never rely on decoder personally.
Xvid is too COder-DECoder,but I prefer not to use postprocessing in it
because,well, it seems to be unfair to me, I don't know why.VP6 doesn't impress me either.What impresses me much is AVC :rolleyes:
Sharktooth
26th January 2005, 16:41
ok, let's explain a couple of things:
PP in xvid removes details by removing blocks and ringing effects... PP in VP6 adds quality reconstructing missing data, removing blocks and ringing effects.
Even if AVC has some more details than VP6, what i hate are visible artifacts and AVC clip is full of them...
I'm re-encoding the AVC clip with more deblocking strength to see if it gets better.
SeeMoreDigital
26th January 2005, 16:43
Originally posted by Sharktooth
Is AVC really that good? I think so... But it's important to remember that it's very early days for AVC ;)
Cheers
yaz
26th January 2005, 16:47
what if full auto pp would be used also in nero decoder ? :-)
anyway, i haven't found vp6 so impressive, but w/pp it's a bit better. however pp-ing the avc in ffdshow gave much better output too. who can tell this ? :-))
the bests
y
JohnV
26th January 2005, 16:48
Originally posted by Sharktooth
ok, let's explain a couple of things:
PP in xvid removes details by removing blocks and ringing effects... PP in VP6 adds quality reconstructing missing data, removing blocks and ringing effects.
Even if AVC has some more details than VP6, what i hate are visible artifacts and AVC clip is full of them...
What is an artifact exactly.. Blocking, ringing etc only? Or is generally degraded quality low detailed unstable picture as here in VP's case (in my opinion) not "artifacted" in your opinion? Maybe you just notice the artifacts easier with AVC..?
You should probably use the maximum deblocking for AVC if you prefer VP video here..
Sharktooth
26th January 2005, 16:55
well, i didn't say i prefer the VP6 video.
I already said AVC has more details, but what's the cost of those details?
Is AVC really that good at keeping picture quality or some compromises are needed at certain "levels"?
We already saw AVC is not able to reproduce film grain (like xvid for example) even at high bitrates.
Now i'm looking again at the two encodes on my TV (low def) and i can see the same details in both encodes but i see blocks in AVC...
If i rise the deblocking filter AVC looses details and VP6 looks better...
Edit: at deblocking strength = 4 there are still blocks everywhere... trying with maximum deblocking strength. But at 4 facial details were already lost...
temporance
26th January 2005, 17:04
For the record, I'm with Sharktooth here. My experience is that ASP and AVC really are not very different in terms of quality/bitrate performance. I would agree though, that each has its own distinctive flavor.
People who think AVC is so much better than ASP, must have their ASP postprocessing permanently disabled. MHO.
JohnV
26th January 2005, 17:07
Originally posted by Sharktooth
well, i didn't say i prefer the VP6 video.
I already said AVC has more details, but what's the cost of those details?
Is AVC really that good at keeping picture quality or some compromises are needed at certain "levels"?
We already saw AVC is not able to reproduce film grain (like xvid for example) even at high bitrates. Well, we need to add then better PP as in VP's case.
I don't understand how can you claim that "we already saw AVC is not able..". Things are in constant state of improvement and all AVC implementations are still quite young, so saying something like this doesn't make any sense.
Sharktooth
26th January 2005, 17:12
Ok, you're right, i will correct my statement: "We saw the current AVC implementation isn't able to...".
I'm not trying to bash AVC. I just want to understand what are the limits of this codec and where it can be improved.
(actually i add artificial noise thru FFDShow to make it look more like the original... maybe adding some PP to AVC decoder won't hurt?)
JohnV
26th January 2005, 17:19
Originally posted by Sharktooth
Ok, you're right, i will correct my statement: "We saw the current AVC implementation isn't able to...".
I'm not trying to bash AVC. I just want to understand what are the limits of this codec and where it can be improved.
(actually i add artificial noise thru FFDShow to make it look more like the original... maybe adding some PP to AVC decoder won't hurt?) BTW, why don't you use chroma optimization? No difference for you?
Sharktooth
26th January 2005, 17:21
Isn't chroma optimization intended for cartoons/anime?
I've also noticed that the "Cartoon mode" option under Source Material seems to have been changed to "Chroma optimization".
Does this mean I should check "Chroma optimization" if I want the encoder to use chroma ME?
Yea, that is correct. And only the name has changed.
JohnV
26th January 2005, 17:22
Originally posted by Sharktooth
Isn't chroma optimization intended for cartoons/anime? It can improve non-cartoons as well. That's why the name was changed..
Also maybe just use the ME vector range -256 to 255. Max value may not be always optimal..
Sirber
26th January 2005, 17:26
VP6 tryes to improve quality by filtering and by using adaptive grain, but "real details" aren't there much. The picture is much more washed than XviD or RV10. Maybe VP7 will be better with details...
Sharktooth
26th January 2005, 17:31
I'm updating the nero digital clip with one with deblocking strength set at 6. There are still some visible blocks (!!!) and details are a bit washed but finally it looks good on my TV.
Looking at it on my PC monitor now i dont know what one is better... VP6 or ND.
edit: update finished.
JohnV
26th January 2005, 17:37
Originally posted by Sharktooth
I'm updating the nero digital clip with one with deblocking strength set at 6. There are still some visible blocks (!!!) and details are a bit washed but finally it looks good on my TV.
Looking at it on my PC monitor now i dont know what one is better... VP6 or ND. Well deblocking 6 is quite high value, and I think most people here don't prefer that, even if you think it's better.
My guess is that something like ME vectors -256 255, chroma opt and deblock 3-4 changed to your current settings would create video which most people here like the best, but not having the source, difficult to say exactly..
Sharktooth
26th January 2005, 17:38
Ok, re-encoding again:)
PM me how to directly contact you and i will send you the source.
Edit: update completed.
len0x
26th January 2005, 18:43
I wanna have the source as well :)
Sharktooth
26th January 2005, 18:46
ok, i'm uploading it just wait until i finish and i will PM you the URL.
EDIT: Done. Sending PMs.
EDIT2: The trailer source has a LOT of "added" noise btw... that's a b&%$h to encode... :D
JohnV
26th January 2005, 19:25
Originally posted by Sharktooth
Ok, re-encoding again:)
PM me how to directly contact you and i will send you the source.
Edit: update completed. Hmm fixed deblock 4 is too strong for my taste. If smaller me vector range and chroma decrease blocking, I'd go for 1-2.
I'll see later what I can produce with latest filters and my preferred settings.
Sharktooth
26th January 2005, 19:27
re-encoding...
btw i think 128 or 256 is the optimal value for bitrates under 1000kbps.
512 maybe is good for high bitrates or for HD content.
Andrey
26th January 2005, 19:44
>>The picture is much more washed than XviD or RV10.
That's the common problem with VP codecs in my expirience...
But on extremely low (for selected stream) bitrates such a behaviour can help much - it is better to have "washed" picture that a simple crap :)
Sharktooth
26th January 2005, 20:02
ok, i updated the nerodigital clip for the nth time.
there are still flashing blocks.
time to eat something...
len0x
26th January 2005, 21:40
What is the exact bitrate or target size used?
LordRPI
27th January 2005, 03:55
Hmmm, maybe some thoughts from an outsider...
I've done several encodes with the VP6 heightened sharpness mode and have a few mixed impressions. I definately do like this codec, but there are certain things about it that are unsettling to my eyes such as moving textures and odd noise that I can't put my finger on. Sometimes it may look washed out but others it looks really sharp. Visually, it's less disturbing on my eyes when the film grain effect is turned off. In some cases it has retained more detail to my eyes than ASP, but not so in other times. I've seen some really nice looking (didn't look for detail though) in some low bitrate animated encodes that ASP can't touch but AVC seems to do insanely well on. Regardless I'm proud to see a codec so well developed by an office of 25 of which some share my alma mater.
As for AVC, I've already tested out at least 3 different flavors made available to me: Nero Digital (through recode), x264/sex264, Apple's among others. I've been really impressed with the offerings on the quality of a standard so young. Our good old part-2 friend seemed to have a much greater time to come to fruition. On the screens that I've used to watch it on, blocking seemed to be little of an issue, even though there were some annoying effects surrounding blocking. I've reduced bitrates to obscene levels and have seen clips almost lacking blocks but at the expense of looking washed out. ASP would have blocked strongly, VP6 would have given a decent picture, but IMHO not as good as AVC.
While not going into much depth about either of the two codecs, I think part of the reason of seeing these codecs as *not always as good* has to deal with the fact that our eyes are just so used to looking at the tried and true ASP and when something looks different, then it doesn't feel right.
Of course, I prefer the DVD source myself...
Teegedeck
27th January 2005, 10:13
Originally posted by Sharktooth
ok, i updated the nerodigital clip for the nth time.
there are still flashing blocks.
time to eat something...
Care to throw in other codecs, like RV10 or Snow (still only fixed quantizer mode available, I believe)? :)
temporance
27th January 2005, 12:41
Originally posted by LordRPI
While not going into much depth about either of the two codecs, I think part of the reason of seeing these codecs as *not always as good* has to deal with the fact that our eyes are just so used to looking at the tried and true ASP and when something looks different, then it doesn't feel right.You're definitely onto something here, LordRPI. But I think the psychology works the other way around. Seasoned video experts, so called "golden eyes", or many of the citizens of these fora are very well tuned into the artifacts generated by MPEG-2 and MPEG-4 pt2. Years of nose-against-screen watching 3.11, DivX and xvid have sensitized us to 8x8 blocking and ringing artifacts to such an extent that we are less sensitive to the annoyances of the newer standards.
When I first see an AVC encode for the first time I'm looking carefully for the artifacts that I'm accustomed to: 8x8 blocking and ringing. My eyes, which are painfully sensitive to such effects, are pleased with what they see. Other artifacts (e.g. unstable, blurry features) go unnoticed.
Given time, we'll all be painfully sensitive to the artifacts of the newer codecs. Examples from AVC include:
- contouring of flat backgrounds,
- details "moving in-and-out of focus" over several frames
- loss of fine textures and film grain
After using AVC for several years, we may even become detuned from ASP's characteristic artifacts. Revisit xvid 1.1 or DivX 6.0 in 3 years time, when you're all tuned into AVC artifacts, and you might be delighted with what you see!
Sirber
27th January 2005, 13:12
always the same, new codecs, new artefacts, old encodes look like sh*t :)
Sharktooth
27th January 2005, 13:27
Originally posted by len0x
What is the exact bitrate or target size used?
907 kbits (i couldn't set 900 coz recode doesnt permit to set a precise bitrate).
Originally posted by Teegedeck
Care to throw in other codecs, like RV10 or Snow (still only fixed quantizer mode available, I believe)? :)
I have not the needed experience with those codecs so i think im not able to squeeze the best from them.
I feel AVC can be improved a lot since it's not mature at all, just look at the x.264 improvements in the last months...
However i think AVC has some sort of limits when talking about picture quality and i hope those limits will be heightened with future development.
This trailer is the example that some sources may need more than 1000kbits to be encoded at good quality (the same bitrate needed by old ASP codecs...) and AVC isn't doing miracles here...
So, back to the subject of this thread: Is AVC really that good?
len0x
27th January 2005, 13:32
Quick question: how can I play that Recode mp4 file without having anything from Nero installed? I have 3ivx splitter and ffdshow combo that crashes on me...
Sharktooth
27th January 2005, 13:39
moonlight mp4 splitter and latest ffdshow with h.264 support checked (i dont know if it works, but it should...)
len0x
27th January 2005, 13:44
it really does. 10x :)
len0x
27th January 2005, 14:06
I just compared x264 vs ND AVC and x264 wins easily if you look at P-frames (B-frames can be broken often in x264 atm). ND introduces very large number of artifacts in high motion scenes: look at broken glass when the car hits the window - ND encode has twice as many white pieces as original source! (frame ~980)
Sharktooth
27th January 2005, 14:08
interesting.
len0x can you pls send me the x.264 encode?
len0x
27th January 2005, 14:15
Sure I'll make another encode with presize bitrate 907 (I used 900 before) and without b-frames and I'll put them both somewhere and PM you.
Sharktooth
27th January 2005, 14:16
ok, i'm patiently awaiting... :D
... i also started a x.264 (b107) encode with 1 b-frame.
edit: i've finished encoding and the x.264 clip with deblocking strength = 1 is much more "deblocked" and kept more details than the ND one...
len0x
27th January 2005, 15:02
Better try no bframes first :) (Actually that encode is up already)
There are too many broken b-frames in my b-frames encode.
P.S. my settings were all defaults, but 5 reference frames.
len0x
27th January 2005, 15:07
Now that I think of it - ND AVC vs x264 very much reminds me DivX vs XviD situation when first encoder washes out too much details comparing to the second one...
Sharktooth
27th January 2005, 15:09
ok i'm uploading the new sample clips.
What i've noticed is ND generates far more blocks than x264. then deblocking is needed to remove them ... and details "go away"...
Edit: btw my encode seems to have correct b-frames... the download link is in the first post but wait until i finish uploading it. *OK i finished*
len0x
27th January 2005, 15:18
Originally posted by Sharktooth
Edit: btw my encode seems to have correct b-frames...
May be its decoder. I'm opening it with VDubMod via DShowSource. Seeking is a bitch there :(
P.S. Try more reference frames - the more the better :)
Sharktooth
27th January 2005, 15:22
I'm going for 5 reference frames and 3 b-frames (the same settings i used for ND).
BTW, donwload the clip and look at b-frames. Are they corrupted on your side?
EDIT: 3 b-frames is causing BLOCKING as in ND encode. So i suppose all the mess in ND comes from b-frames too.
Re-encoding...
EDIT2: I was right, less b-frames, less blocking in both x.264 and ND. Encodes are updated with 1 b-brame.
EDIT3: x.264 has been re-uploaded due to a x.264 update (rev 108).
Sharktooth
27th January 2005, 19:03
I added a xvid encode too.
The settings are default + VHQ4 + B-VHQ + CQM=EQM V3ULRr2 + I Frame int. 250 + Chroma OPT. + AQ.
Try watching it with PP enabled too.
CruNcher
27th January 2005, 19:34
Sharktooth could you make a EDP version to please :)
Sharktooth
27th January 2005, 19:35
Originally posted by CruNcher
Sharktooth could you make a EDP version to please :)
Please #define "EDP" :D
Edit: ok, the Extra Details Profile... it's on the way:)
Sharktooth
27th January 2005, 21:01
Ok, i think my PC will have some hard times...
18 encodes scheduled with 5 different codecs... (ND encode is already good)...
cya tomorrow...
ChronoReverse
27th January 2005, 22:31
I don't know if you're going to redo the x64 encode, but the ND encode seems to retain quite a bit more details (check out the difference in the face at about 58 seconds in).
In fact, the current xvid encode is comparable in some places. Maybe I'm just looking for the wrong things? :confused:
DeathTheSheep
27th January 2005, 22:32
I just compared x264 vs ND AVC and x264 wins easily if you look at P-frames (B-frames can be broken often in x264 atm). ND introduces very large number of artifacts in high motion scenes: look at broken glass when the car hits the window - ND encode has twice as many white pieces as original source! (frame ~980) I was right, less b-frames, less blocking in both x.264 and ND.
There are too many broken b-frames in my b-frames encode. ND generates far more blocks than x264. then deblocking is needed to remove them ... and details "go away"...
There is a thread on this forum called "The Coolness of B-frames" in which I attempt to outline the fact that B-frames are crap. However, that thread turned into a battlefield of my word vs. theirs, and the point wasn't made, me being execrated.
You see, B-frames in H264 currently:
1. Add tons of blocks
2. Screw up high-motion scenes
3. Cause high detail washing
4. Cause innacurate motion prediction (a half-way scene--which h264 creates between 2 P-frames--is terrible, especially when lined up with others).
5. Cause added need for high postprocessing levels while reducing their own quantizers.
6. Cannot be deblocked by in-loop filtering OR postprocessing with ffdshow.
Now that you've all started to see this for yourselves... Try encodes with 1 or 0 B-frames. Especially 0. You'll be pleasantly surprized.
Moral: JUST AVOID B-FRAMES!! THEY ARENT THE SAME AS IN XVID!! (Actually, they are exactly the same, which is the problem when using AVC... but this decreases quality rather than increasing it).
Please consider this, at least. There is no need to bash anything now, folks. Just a friendly little explanatory post.
JohnV
27th January 2005, 22:41
Originally posted by DeathTheSheep
6. Cannot be deblocked by in-loop filtering OR postprocessing with ffdshow. What player/decoder you are using Sharktooth? I hope ffdshow supports inloop deblock nowadays? IIRC some earlier versions didn't.
708145
27th January 2005, 22:42
Originally posted by DeathTheSheep
Moral: JUST AVOID B-FRAMES!! THEY ARENT THE SAME AS IN XVID!! (Actually, they are exactly the same, which is the problem when using AVC... but this decreases quality rather than increasing it).
Two very important things are missing with B-frames right now:
1) in-loop de-blocking
2) adaptiveness
Please do not judge the potential of B-frames from current implementation (which is pre-alpha, btw)
edit: P.S. I agree that in its *current* state they are not helping in most cases!
bis besser,
Tobias
Prettz
27th January 2005, 22:54
Originally posted by Sharktooth
However i think AVC has some sort of limits when talking about picture quality and i hope those limits will be heightened with future development.
People said the same thing about quality limits for ASP vs. MPEG-2 and it was untrue for that, so why would it be true for this? Other than using a different style of b-frame, ASP is ridiculously similar to MPEG-2 to be drawing conclusions like that. AVC isn't that much different from ASP either, the codec just has more tools. According to AVC's technical specs, it should by all accounts be capable of better quality at any bitrate than ASP (things like a large linear quant scale, adaptable blocks, more frame references, and CABAC). There are some tools which too me seem like they could put an upper limit on quality (maybe weighted prediction), but they certainly don't have to be used all the time. It's up to the encoder to decide when and how to use the features provided, which depends not only on how good the encoder's decision-making is but what the encoder was tuned for (there's no better example of this than Xvid vs Divx5).
It all comes down to the encoder, how complex it is, what it was tuned for, etc. AVC encoders are still so immature that in my opinion it's still too early to even be speculating on whether the codec itself has upper limits on quality.
*.mp4 guy
27th January 2005, 22:59
Sharktooth i would also like to make some encodings of this file, plz pm me the source. I think its on one of my dvds, but i have no idea witch one and i have a lot of dvds:D .
Sharktooth
27th January 2005, 23:12
Originally posted by JohnV
What player/decoder you are using Sharktooth? I hope ffdshow supports inloop deblock nowadays? IIRC some earlier versions didn't.
I use latest FFDShow build made by celtic_druid.
Originally posted by *.mp4 guy
Sharktooth i would also like to make some encodings of this file, plz pm me the source. I think its on one of my dvds, but i have no idea witch one and i have a lot of dvds:D .
I've sent you a PM with the URL.
@pretzz: i agree with you. the AVC encoders are "immature". I was just observing the limits of actual encoders.
@Death the sheep: From the experience i gathered encoding with both Nero Recode and x.264, 1 b-frame is the best choice. For what concerns xvid 2 b-frames (the actual defaults) is the best for "everyday" encodings.
JohnV
27th January 2005, 23:18
Originally posted by Sharktooth
I use latest FFDShow build made by celtic_druid.
Just out of interest.. Can you try with ShowTime and tell if it looks different?
Sharktooth
27th January 2005, 23:30
It looks the same, just a bit darker coz showtime doesnt use VMR.
JohnV
27th January 2005, 23:33
Originally posted by Sharktooth
It looks the same, just a bit darker coz showtime doesnt use VMR. With 3 b-frame version too?
Sharktooth
27th January 2005, 23:35
Yep, x.264 is able to decode nero AVC with all the bells and whistles without problems.
Gabriel_Bouvigne
27th January 2005, 23:35
Just out of interest.. Can you try with ShowTime and tell if it looks different?
To me it looks different, but I am not sure if my ffdshow version is really the latest one (it is from mid-january)
Sharktooth
27th January 2005, 23:40
If there are differences they are so small i dont even notice them.
BTW, i tried with both decoders and the blocks with 2+ bframes are there.
DeathTheSheep
28th January 2005, 00:11
Yep, so it's fully the fault of the pre-alpha B-frames.
Did anyone try 0 b-frames yet? What about insane references to beef it up (15)?
skal
28th January 2005, 09:04
Hi, sorry for this late reply, but:
Originally posted by Leo 69
Check it out,it's only @ 130kbps :p
http://cp.people.overclockers.ru/cgi-bin/dl.pl?id=4585&filename=X264.rar
it appears to me this bitstream isn't AVC compliant: it uses
level 2.1 (profile 77 -Main-), but needs to store 16 references
frames. However, only 13 such are permitted at this level. Some
picky decoder (or hardware player) will choke on it. At least,
JM9.3 ref software can't decode it. So, the question is: what
encoder did you use to produce it? Avoiding the non-compliancy
within the new-born AVC format seems very important to me, looking
at the MPEG4 mess around "certifications" hmm...
-Skal
len0x
28th January 2005, 11:20
Originally posted by DeathTheSheep
Did anyone try 0 b-frames yet?
It was the first thing I tried with x264 and it looks to me so much better! (comparing to 1-bframe version).
Sharktooth
28th January 2005, 12:44
ok, i'm uploading the 0 b-frames encode too.
EDIT: http://www.aziendeassociate.com/sp2.tr.x.264.noB.avi
Notes: While a frame to frame comparison shows that the "no bframes" encode has better frames (B looks bad coz the higher quant), using ffdshow OSD to look at the frame quantizer reveals that P and I Frames have lower quant on the 1 bframe encode.
The theory behind b-frames says that given a sufficient frame rate, the eye cant distinguish, while in motion, a sequence of "good frame/less good frame/good frame".
So having 1 bframe between two P that looks not so "globally" different is an advantage for the final quality, since bitrate is spared to lower the pframes quant.
netchris
28th January 2005, 13:14
Hm.. so far i like Nero avc very much, I am using it at bitrates of about 500kbps.
But i had bad experience with one option. I would strongly suggest to disable the adaptive deblocking option, cause it was creating blocks in many cases.
Sharktooth adaptive might be the culprit of the blockiness you notice, so trying to encode without it wouldnt harm. It might even be an incompatibility with adaptive and b-frames, because I always used 3 b-frames, never tried to use less.
There was a case of a videoclip, that adaptive deblock. added lots of blocks and artifacts, while without it the video looked 2x times better and alot cleaner.
Also i have to thank those who found that using smaller "maximum vector range" for small bitrates is better, because I always used the maximum possible : -512to512 .
X264 just doesnt work good enough for me at these bitrates, but i believe it might truly be strong at 1000+kbps.
len0x
28th January 2005, 13:17
Originally posted by Sharktooth
Notes: While a frame to frame comparison shows that the "no bframes" encode has better frames (B looks bad coz the higher quant), using ffdshow OSD to look at the frame quantizer reveals that P and I Frames have lower quant on the 1 bframe encode.
Yes, but real question is: can you see the difference in quality for those I/P frames?
Sharktooth
28th January 2005, 13:36
Originally posted by netchris
Hm.. so far i like Nero avc very much, I am using it at bitrates of about 500kbps.
But i had bad experience with one option. I would strongly suggest to disable the adaptive deblocking option, cause it was creating blocks in many cases.
Sharktooth adaptive might be the culprit of the blockiness you notice, so trying to encode without it wouldnt harm. It might even be an incompatibility with adaptive and b-frames, because I always used 3 b-frames, never tried to use less.
There was a case of a videoclip, that adaptive deblock. added lots of blocks and artifacts, while without it the video looked 2x times better and alot cleaner.
Also i have to thank those who found that using smaller "maximum vector range" for small bitrates is better, because I always used the maximum possible : -512to512 .
X264 just doesnt work good enough for me at these bitrates, but i believe it might truly be strong at 1000+kbps.
I used deblocking strength 1 and no adaptive deblocking.
Originally posted by len0x
Yes, but real question is: can you see the difference in quality for those I/P frames?
Well, not always, but definatly, yes, i can perceive it.
JohnV
28th January 2005, 13:39
Maybe the b-frame allocation should be made smarter, like max 1 consequtive b-frame in high motion scenes, or something..
Have to ask from Ateme devs that they improve this.
Sharktooth
28th January 2005, 13:40
Originally posted by JohnV
Maybe the b-frame allocation should be made smarter, like max 1 consequtive b-frame in high motion scenes..
Have to ask from Ateme devs that they improve this.
Not in high motion... but in low motion.
Blocking is more visible in low motion scenes coz everything is "static" and the eye spots those "flashing" blocks easier.
yaz
28th January 2005, 13:49
sharky! would u, pls, do some trickin ? i'm forbidden to down(up)load mm contents. so, pls, make some trickin the filenames (extra dots, spaces, etc.) or zip them! imho, i'm not the only one restricted such a stupid way.
thx
y
Sharktooth
28th January 2005, 13:53
suggestions? (zipping is out of discussion, i should reupload all the files and, sincerely, i did it so many times i could have an heart attack if i should re-up the files...)
akupenguin
28th January 2005, 14:52
Originally posted by skal
it appears to me this bitstream isn't AVC compliant: it uses
level 2.1 (profile 77 -Main-), but needs to store 16 references
frames. However, only 13 such are permitted at this level.
As fas as I can tell from the spec, levels limit the amount of memory used for buffered pictures, not the actual number of pictures. Level 2.1 allows 1782 KiB for DecodedPictureBuffer. This video is 480x208 = 146 KiB, so would be allowed 12 reference frames.
Currently, x264 always says level 2.1, no matter what resolution / settings you select. Yes, this is broken. I just changed it to 4.0, but it's still broken.
If there were a level for "I make no guarantees about decoding requirements", I would use that. But there isn't, so there are some combinations of settings that don't fit in any level. All the levels with a decent size DPB also restrict max number of MVs for 2 consecutive macroblocks, which p4x4 and bdirect easily violate. And while x264's MVs probably won't exceed 512 pixels, theres no strict limit. And neither 2pass nor constant quant enforce a max bitrate. etc.
yaz
28th January 2005, 15:05
Originally posted by Sharktooth
suggestions? use dot instead of underscore/underline. many many dots cheats the 'watchdog' here :-)
anyway, if it burdens ur heart so much, pls, stay away, i don't want to risk we loose u :-))
thx
y
Sharktooth
28th January 2005, 15:22
Heheheh no problems :D
Done.
CruNcher
28th January 2005, 17:06
Sharktooth the EDP version finished ?
could you also pm me where i can find that trailer i have one on the DVD but it is not the same :( and i dont want to downsize the HDTV version of the one you used
Sharktooth
28th January 2005, 17:11
PM sent.
skal
28th January 2005, 18:30
Hi Akupenguin
Originally posted by akupenguin
As fas as I can tell from the spec, levels limit the amount of memory used for buffered pictures, not the actual number of pictures. Level 2.1 allows 1782 KiB for DecodedPictureBuffer. This video is 480x208 = 146 KiB, so would be allowed 12 reference frames.
You're right, 12 refs. Wrong rounding of mine...
If there were a level for "I make no guarantees about decoding requirements", I would use that.
I wish too, but it would be something the hardware manufacturers wouldn't like. Being able to put bounds on resources requirements is important for them.
All the levels with a decent size DPB also restrict max number of MVs for 2 consecutive macroblocks, which p4x4 and bdirect easily violate. And while x264's MVs probably won't exceed 512 pixels, theres no strict limit.
Agreed, there are a lot of restrictions for each levels, most of which will be hard to abide to. Even using a global "max peak rate" limitation or something a-la VBV. But i'm inlcined to think memory limits are the most important one. Afterward, MV range limits are of some uses too (for sliced /multithread encode , most probably).
Note that the DPBSize is of another importance: it describes the latency time of a picture, telling how long will a frame spend in the DPB before being displayable ("bumping" process in C.4.5.2). Hence, using an inaccurate DPBSize may result in a (faint) A/V de-sync.
-Skal
CruNcher
28th January 2005, 19:08
@Sharktooth
Edit: wrong vob d2ved oops sorry ;)
calinb
28th January 2005, 19:46
Originally posted by Sharktooth
Edit: at deblocking strength = 4 there are still blocks everywhere... trying with maximum deblocking strength. But at 4 facial details were already lost... Sharktooth, JohnV: Using my 50" Sammy DLP and the DVI input, I must use adaptive deblocking strength=6, or the blocks drive me nuts. Whether or not the downside to such an extreme setting is more offensive than the blocks, seems to greatly depend on the playback device, but I feel your pain, Sharktooth :(
JohnV
28th January 2005, 20:24
Originally posted by calinb
Sharktooth, JohnV: Using my 50" Sammy DLP and the DVI input, I must use adaptive deblocking strength=6, or the blocks drive me nuts. Whether or not the downside to such an extreme setting is more offensive than the blocks, seems to greatly depend on the playback device, but I feel your pain, Sharktooth :( Try using 1 or 0 b-frames. I'm interested if that makes a big difference for you with your 50" screen.
G-Slide
28th January 2005, 20:47
i have this problem on my thomson TV (72cm), it blocks a lot...
do you think next version of recode will change this problem ? with a new version of atem encoder ?
plonk420
28th January 2005, 21:01
Originally posted by LordRPI
Of course, I prefer the DVD source myself...
i like a raw or downsampled HD source, myself ^_^
LordRPI
28th January 2005, 21:04
Yes, I need access to some hdtv streams, an HDTV and a German Luxury Car.
SeeMoreDigital
28th January 2005, 21:41
Originally posted by calinb
Sharktooth, JohnV: Using my 50" Sammy DLP and the DVI input, I must use adaptive deblocking strength=6, or the blocks drive me nuts. As a matter of interest... how many pixels can your Samsung display?
Cheers
708145
28th January 2005, 22:41
Originally posted by LordRPI
Yes, I need access to some hdtv streams, an HDTV and a German Luxury Car.
There are some HD streams here:
ftp://ftp.ldv.e-technik.tu-muenchen.de/pub/test_sequences/
bis besser,
Tobias
calinb
28th January 2005, 23:21
@JohnV, Okay, I'll try some 1280x720x24 video with 0 and 1 b-frames. I normally disable CABAC and partitions because they chew up too much cpu at HD res.
@SeeMoreDigital, The Samusungs (and all the Ti DLP-based HDTVs) natively support the 720p format (1280x720x60fps progressive) Thank you ABC and Fox :) http://alvyray.com/DigitalTV/Naming_Proposal.htm (off topic link)
708145
28th January 2005, 23:32
Originally posted by calinb
@SeeMoreDigital, The Samusungs (and all the Ti DLP-based HDTVs) natively support the 720p format (1280x720x60fps progressive) Thank you ABC and Fox :) http://alvyray.com/DigitalTV/Naming_Proposal.htm (off topic link)
Do you happen to know how much CPU is needed to play 720p@60 in software?
Or maybe someone knows a CPU/GPU combo that's fast enough?
edit: Aehm, to avoid confusion: I'm asking about AVC main profile.
bis besser,
Tobias
calinb
28th January 2005, 23:46
Originally posted by 708145
Do you happen to know how much CPU is needed to play 720p@60 in software?720p with AVC is tough without a GPU and hardware acceleration. The Nero H/W acceleration doesn't seem to work on my ATI 9800 pro or Nvidia FX 5200 yet. Bottom line: I can't do it with a 2.1 GHz XP-3000+ Barton (512L2/200/400FSB) or 3.2 GHz Prescott (512L2/400/800 FSB). They can barely handle 24-30 fps without partitions / CABAC. (Tell me what constitutes the main profile, again :))
For comparison: 720p mpeg2 plays fine on my old 1.5GHz Willamette and an ATI or Nvidia DxVA decoder (Dvico, Moonlight, ATI). A 1.8GHz T-bred can do it with non-DxVA decoder.
708145
29th January 2005, 00:33
Originally posted by calinb
720p with AVC is tough without a GPU and hardware acceleration. The Nero H/W acceleration doesn't seem to work on my ATI 9800 pro or Nvidia FX 5200 yet. Bottom line: I can't do it with a 2.1 GHz XP-3000+ Barton (512L2/200/400FSB) or 3.2 GHz Prescott (512L2/400/800 FSB). They can barely handle 24-30 fps without partitions / CABAC. (Tell me what constitutes the main profile, again :))
For comparison: 720p mpeg2 plays fine on my old 1.5GHz Willamette and an ATI or Nvidia DxVA decoder (Dvico, Moonlight, ATI). A 1.8GHz T-bred can do it with non-DxVA decoder.
I'll just continue saving money then :p
I own a 1800+ and MPEG2 720p works fine, that's why I edited my previous post and added the AVC hint.
bis besser,
Tobias
calinb
29th January 2005, 00:50
Originally posted by 708145
I'll just continue saving money then :p
I own a 1800+ and MPEG2 720p works fine, that's why I edited my previous post and added the AVC hint.
bis besser,
Tobias Tobias, yes--understood! I just put some mpeg2 examples in my post for comparison. Of course, maybe Nero could get hardware acceleration working and enable slower CPUs for free. :D Does Nero hardware acceleration currently work under any conditions? I check the box but nothing happens and it doesn't stay checked.
thegeby
29th January 2005, 08:56
720p with AVC is tough without a GPU and hardware acceleration. The Nero H/W acceleration doesn't seem to work on my ATI 9800 pro or Nvidia FX 5200 yet. Bottom line: I can't do it with a 2.1 GHz XP-3000+ Barton (512L2/200/400FSB) or 3.2 GHz Prescott (512L2/400/800 FSB)
I am a bit confused here. Admittedly I have not done any 720p encodes on the released Nero, but the beta worked just fine on my lowly 2.4 celeron laptop. I did a few tests blown up on a beamer and everything was fine. We are talking INTEL INTEGRATED GRAPHICS:scared:
calinb
29th January 2005, 10:36
thegeby, you sure you were using Nero AVC rather than ASP? If I turn off everything but B-frames and in-loop deblocking, I can usually playback using Nero/CoreAAC 1280x720 @ 24 fps or maybe even 30 fps plus the HE-AAC audio on my 3.2GHz P4 or Athlon XP3000+ as described above. True 720p is 60fps! No way on those cpus! I've never run any tests without the deblocking 'cause it looks terrible on my DLP. Maybe it could run on a 2.4GHz Celeron--I dunno :confused:
len0x
29th January 2005, 12:20
Originally posted by calinb
True 720p is 60fps!
There is no such thing as "true" 720p :)
Standard defines it as having 60p or 30p or 24p.
Blue_MiSfit
29th January 2005, 12:37
Would it be possible to interlace these 60p sources thereby making older machines capible of decoding HD (admitedly at the cost of interlacing)?
I know this wouldn't really look good as interlacing tends to especially look bad on progressive displays like PC monitors.
Just an idea though, what do you all think?
~misfit
nexx
29th January 2005, 12:47
Originally posted by Blue_MiSfit
Would it be possible to interlace these 60p sources thereby making older machines capible of decoding HD (admitedly at the cost of interlacing)?
I'm no expert, but it is entirely possible to take a progressive image and create interlaced output (at half the frame rate). I've used MEncoder for this exact thing, I'm sure it's possible with other tools. So you'd get 720i. I dont see how it being interlaced will help, but there is half the amount of video data to be decoded. You could just half the frame rate?
SeeMoreDigital
29th January 2005, 13:11
Originally posted by nexx
I'm no expert, but it is entirely possible to take a progressive image and create interlaced output (at half the frame rate). I've used MEncoder for this exact thing, I'm sure it's possible with other tools. So you'd get 720i. I dont see how it being interlaced will help, but there is half the amount of video data to be decoded. You could just half the frame rate? Agreed....
I find it a bit odd as to why 60fps is being used to broadcast HD content anyway... unless it's to provide a "half arsed" solution for owner/users with non progressive displays!
I had originally got it into my head that maybe each one of the 60No "fields" had been turned into a full frame. But, apparently this is not the case, each successive frame is slightly different.
That said, when the whole world goes completely digital, with everybody owning a progressive digitally connected display, all video could be displayed at 24fps :D
Cheers
Sharktooth
29th January 2005, 13:14
i'm uploading a new clip made with xvid1.1EDP (thanks cruncher).
Sharktooth
29th January 2005, 13:24
Originally posted by JohnV
Try using 1 or 0 b-frames. I'm interested if that makes a big difference for you with your 50" screen.
I made several encodes with different settings.
It seems 2+ b-frames is the major cause of blocking. With 1 b-frame you can safely keep the deblocking strength to a lower value and gain more details.
I suggest you to set 1 (or max 2 bframes) as the default recode setting.
len0x
29th January 2005, 23:18
Btw, you should all realize that this test is actually really flawed as if you do a comp test on the source you'll see that for XviD its ~32% for x264 it's ~26%(1 bframe), so basically no sane person should encode the above sample at the given bitrate and resolution (at least 1800kbps is needed for the width of 720).
CruNcher
30th January 2005, 11:49
len0x ehh i wouldn't say so this hits for 1 Cd bitrates ok 896 kbps is a little over 1 cd wich would be in the region of 7xx sure for the content thats used here i would not go that low (trailer) but that's the thing we need to test @ wich bitrate does it still looks visualy pleasant (and compares against others) also in those extreme samples you and Gknot can't adapt as fast as the codecs feature change and compression get's improved i personaly never use any compression test to set my settings if i have a original i know how much ASP/AVC is capable off (at the moment) and set the factor by that not doing any compression test on the sources it's like alot of things a expirience question.
len0x
30th January 2005, 12:28
Its true that comp test for AVC is not really defined yet, but it certainly is for ASP codecs. So this test is like saying "I know its gonna look really really bad with ASP codec, but I wonder how bad its gonna look with AVC?". AVC codecs never promised us to deliver the same quality as ASP with bitrates lower than 50% of the latter. So you know you're not gonna be satisfied with results of any encoding at that bitrate and resolution even before you start...
P.S. Is it just me or everyone else finds it difficult to read CruNcher's post above without any punctuation? :)
SeeMoreDigital
30th January 2005, 12:33
Originally posted by len0x
Its true that comp test for AVC is not really defined yet, but it certainly is for ASP codecs. Personally speaking, I think there's a need to generate more Mpeg4 "comp tests" using SP and ASP modes. And at DVD pixel frame sizes. :eek:
Cheers
dragongodz
30th January 2005, 12:49
P.S. Is it just me or everyone else finds it difficult to read CruNcher's post above without any punctuation? :)
read it really fast while holding your breath, its not that hard. :)
no punctuation ? he has a fullstop at the end so what are you nitpicking about ? :D
Sharktooth
30th January 2005, 15:23
Anyone watched the xvid1.1edp clip?
IMHO it looks really good in terms of details. Sure, it has some blocking and ringing artifacts but it definatly has more details than any other encode...
JohnV
30th January 2005, 15:36
Originally posted by Sharktooth
Anyone watched the xvid1.1edp clip?
IMHO it looks really good in terms of details. Sure, it has some blocking and ringing artifacts Ah, now it's only "some".. :D
Sorry but in EDP's case I'd call it horrible blocking.. Details are nice though.
Sharktooth
30th January 2005, 15:42
well, i cant expect that an ASP codec doesnt block at that res/bitrate.
AVC has in-loop filter that should prevent it to block even at the lowest bitrates...
Anyways have you tried different b-frames settings while encoding the trailer source with recode?
scharfis_brain
30th January 2005, 15:44
where do I get a small sized working avc-playback filter from?
the mpegable avc doesn't work (MPC refuses playing)
ffdshow crashes
and nero's codec is really huge in file size.
Sharktooth
30th January 2005, 15:47
ffdshow shouldnt crash. try downloading the latest celtic_druid build.
Tommy Carrot
30th January 2005, 16:37
Originally posted by Sharktooth
Anyone watched the xvid1.1edp clip?
IMHO it looks really good in terms of details. Sure, it has some blocking and ringing artifacts but it definatly has more details than any other encode...
This edp encode apparently favors the low-motion scenes very strongly. Didn't you encode it in 1-pass cbr mode?
JohnV
30th January 2005, 16:45
Originally posted by Sharktooth
well, i cant expect that an ASP codec doesnt block at that res/bitrate.
Well, if we are talking about video quality, imo we should talk about what we actually see, and not what we expect to see..
If the point of this thread is to compare different codecs with this trailer, why not discuss without any expectations what we actually see.
It gets soon very hard to interpret this discussion if EDP only has "some" blocking and ringing only because "we can't expect more from ASP"..
SeeMoreDigital
30th January 2005, 17:25
Hi Sharktooth,
Have you thought about generating these encodes again at 1:1 and raising the bitrate accordingly!
I'm wondering whether some of the blocking and ringing effects might reduce if the encodes are generated without resizing...
Cheers
JohnV
31st January 2005, 04:01
Here's a clip with a bit newer filters using 3-bframes and fixed deblocking -2 with extra quality and all tools enabled.
http://morbo.org/nero/sp2tr_b3_deblock-2.mp4
Don't know if it's better or not than the one Sharktooth provides, you decide.
I should get today (monday) again new filters with hopefully even better quality.
kurt
31st January 2005, 18:02
sharktooth, nice little codec comparison! especially the x264 AVC file (with b-frames) is IMHO impressive. The last one from JohnV too - wich filters do you mean, johnV? new version from ateme?
BTW, wouldn't it be better to encode without resizing?
Sharktooth
31st January 2005, 18:16
Originally posted by JohnV
Here's a clip with a bit newer filters using 3-bframes and fixed deblocking -2 with extra quality and all tools enabled.
http://morbo.org/nero/sp2tr_b3_deblock-2.mp4
Don't know if it's better or not than the one Sharktooth provides, you decide.
I should get today (monday) again new filters with hopefully even better quality.
Well it's much better then the actual filter with the same settings.
However there are still some blocks but comparing with the "actual" encoder and the deblock strength you used it is much much better!
The facial details are also improved and the high-motion scenese are less "motion-blurred" and definatly better looking.
There's still some work to do with the "flashing" blocks but i'm glad to see that 3 b-frames is a choosable option now.
Originally posted by SeeMoreDigital
Hi Sharktooth,
Have you thought about generating these encodes again at 1:1 and raising the bitrate accordingly!
I'm wondering whether some of the blocking and ringing effects might reduce if the encodes are generated without resizing...
You mean anamorphic encode? No. I choosen a mid-high res and a medium bitrate (the usual settings for a 1 CD backup with newer codecs) to see how much AVC is better than other codecs for making 1DVD->1CD backup.
JohnV
31st January 2005, 23:16
Originally posted by kurt
sharktooth, nice little codec comparison! especially the x264 AVC file (with b-frames) is IMHO impressive. The last one from JohnV too - wich filters do you mean, johnV? new version from ateme?
It was our newer filters than in the current Recode release. These will be available in the next update. And there's speed improvement too.
plonk420
4th February 2005, 18:54
Originally posted by calinb
720p with AVC is tough without a GPU and hardware acceleration. The Nero H/W acceleration doesn't seem to work on my ATI 9800 pro or Nvidia FX 5200 yet. Bottom line: I can't do it with a 2.1 GHz XP-3000+ Barton (512L2/200/400FSB) or 3.2 GHz Prescott (512L2/400/800 FSB). They can barely handle 24-30 fps without partitions / CABAC. (Tell me what constitutes the main profile, again :))
For comparison: 720p mpeg2 plays fine on my old 1.5GHz Willamette and an ATI or Nvidia DxVA decoder (Dvico, Moonlight, ATI). A 1.8GHz T-bred can do it with non-DxVA decoder.
well, mpeg-2 and wmv9 accelleration is supposedly working already with geforce 6600/6600GTs and WMP10/nvDVD. can it be harnessed by MPEG-4 AVC/ASP decoders perchance? my 2400+ can't even keep up with some of the ASP encodes i've done...
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.