is AVC really that good?

[CruNcher]

Sharktooth could you make a EDP version to please :)

[Sharktooth]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

It looks the same, just a bit darker coz showtime doesnt use VMR.

[JohnV]

Originally posted by Sharktooth
It looks the same, just a bit darker coz showtime doesnt use VMR. With 3 b-frame version too?

[Sharktooth]

Yep, x.264 is able to decode nero AVC with all the bells and whistles without problems.

[Gabriel_Bouvigne]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Heheheh no problems :D
Done.

[CruNcher]

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]

PM sent.

[skal]

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]

@Sharktooth


Edit: wrong vob d2ved oops sorry ;)

[calinb]

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]

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]

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]

Originally posted by LordRPI
Of course, I prefer the DVD source myself...

i like a raw or downsampled HD source, myself ^_^

[LordRPI]

Yes, I need access to some hdtv streams, an HDTV and a German Luxury Car.

[SeeMoreDigital]

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]

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]

@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]

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]

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]

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]

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]

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]

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]

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]

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