Log in

View Full Version : The Coolness of B-Frames


Pages : [1] 2

DeathTheSheep
13th January 2005, 22:28
Yeah, I've heard all the hype. I see it written about in posts all the time. Never a day does pass without questions pertaining in some form or another to B-Frames ("When are B-Frames gunna be enabled for AVC?!!!!"). But now I must ask, what the heck is up with B-frames anyway?

I heard they are a form of bidirectional frame encoding/rendering. At this, I scratched my head long and hard and almost pulled a "pancake bunny." So what?!

B-Frames are complicated, they take long to encode, they are BLOCKY as HECK, and they increase filesize. Need I upload a sample with and without B-Frames fer y'all to see? Why don't people stick to the IPPPPPPPIPIPPPPPPPPPP... method? Complexity? If so, I don't see it.

So what is all this B-Frame craziness? What use to they serve? Or are they only useful at collosal bitrates (yeah, I'm livin the >56kbps road)? NeeheeharharharHAR.... No, seriously,
Inform Da Sheep Afore He A-Kills Hisself...BAAAa

Sirber
13th January 2005, 22:34
B-Frames are complicated, they take long to encode, they are BLOCKY as HECK, and they increase filesizeNot really. They aren't much slower to encode, they aren't much more blockier, and they decrease the filesize like hell!!! :D

DeathTheSheep
13th January 2005, 23:15
DE-crease? No way... Wierd... OK, I'll check it out... hei.....

Wat should I be a-puttin fer my max b-frame on anime (I like anime) at quant of 45 at around 7fps?

Or wat 'bout high br like 31 at 23.976fps?

Gabriel_Bouvigne
13th January 2005, 23:29
B frames decrease the overall size because:
*you can get better prediction using 2 refs
*often you can choose to quantize them more, as in mpeg-1 up to mpeg-4 asp they are not used as reference for other frames.


Btw, proper English is easier to understand.

Leak
13th January 2005, 23:47
Originally posted by Gabriel_Bouvigne
Btw, proper English is easier to understand.

Yeah, by the sound of it that has to be some seriously weird grass he's munching... :D

np: Yoko Kanno - Yakitori (Ghost In The Shell Stand Alone Complex OST 1)

bond
13th January 2005, 23:49
Originally posted by Leak
Yeah, by the sound of it that has to be some seriously weird grass he's munching... :Dlol ;)

akupenguin
14th January 2005, 00:59
I have to say that even though B-frames work in practice, I have a mild philosophical aversion to them. This is partly based on my experiences in implementing them (not too bad, but there's a zillion things to keep track of), and partly rubbed off of Michael Niedermayer. But I still think that 3D wavelets are so much more elegant, if only they could be reconciled with motion compensation. (And I am reading some papers that try to do so, but I haven't implemented any of them yet.)

DeathTheSheep
14th January 2005, 02:19
Yeah, by the sound of it that has to be some seriously weird grass he's munching...

Indeed, my grass happens to be a trifle tainted with a bit of "shwacker." Thus, I become mildly shwacked at periodic intervals. Perhaps a revision of my written language is in order.

Ah, I've been rather infatuated with the principle of "Wavelet" codecs, and hope some day a professional development group will shine such a codec onto the video market for public use. Needless to say, said codec must be fairly primed prior to evaluation.

I've also heard that VP7 utilizes some form of wavelet technology in its codec implementation. I don't quite recall, but I vaguely remember something to the effect of its utilization of "discrete cosine formation" or perhaps some other such wavelet-based technology...

Regardless, AVC B-Frames seem to decrease the overall quality of my encodes. This is especially conspicuous at lower bitrates (such as those attained by means of utilizing a quantizer of 45) at no significant decrease in filesize. At higher bitrates (those correlating to quantizers not exceeding 34, predominantly), the decrease in filesize makes up for the quality loss, for a quantizer of, say, 31 would produce the same filesize as 29 would with B-Frames.

akupenguin
14th January 2005, 02:44
Originally posted by DeathTheSheep
At higher bitrates (those correlating to quantizers not exceeding 34, predominantly)
Maybe it just depends on what you're encoding.
I consider QP=20 to be medium bitrate (1 mbit/s at dvd res with B-frames), and QP=30 to be low bitrate and untolerable quality (300 kbit/s). But then, I used MPEG-4 ASP at QP=1 too, because QP=2 just wasn't good enough for some scenes.

Didée
14th January 2005, 12:28
If I recall correctly from other threads, DeathTheSheep is aiming for crystal clear quality with 2-digit bitrates (<100) or something like that ...
Oh, how comes the "a man claims to store multiple movies on one floppy disk" thread springs to my mind.

Shinobu
14th January 2005, 15:54
But then, I used MPEG-4 ASP at QP=1 too, because QP=2 just wasn't good enough for some scenes.

if think avc is a very destructive codec, like the mpeg4.
the only no-loseless codecs witch give me realy good quality at hight bitrate and 720*576 resolutuion (>3500kbps) are mpeg2 (about 8Mbps) and snow iframes only (because of the strange green and violet temporal color degradation).

i think each codec is designed for different usage, that's why you'll never be able to make as good looking xvid thant mpeg2 at 8 mbps, yes you'll have some very close result with and xvid full ana @ 2500 or 3000 compared to a 8mbps mpeg2 full ana, but you'll never had as good quality than mpeg2@8mbps with xvid (full ana 720*576).

i got some hdtv sample in mpeg2 (don't remember the exact bitrate but probably about 15/20mbps and 1088p 16/9) and i've never be able to get as good looking movie with xvid, and i tried lots of custom matrix and even at quant 1 xvid was realy not as good as mpeg2...

sorry for the of topic, but it's true h264 is realy a great codec, and i'll use it a lot for some of my backup, but if a realy want a perfect quality at hight bitrate i'll use mpeg2 or maybe snow (when it'll become backward compatible).

++

Gabriel_Bouvigne
14th January 2005, 16:24
If your source is in mpeg-2@8Mbps, of course the mpeg-2 is the best, as it IS the source.

If you really want to compare let's say Xvid vs mpeg-2, you should decompress your source and recompress it in mpeg2, otherwise you are not really comparing mpeg-2 efficiency.

Didée
14th January 2005, 16:33
Shinobu:

Do I understand you correctly that you took an mpeg-2 source, and didn't get e.g. XviD to look as good as _the source_? If so, then my answer is "oh, c'mon!!".
Of course mpeg-2 must be coded again, too. AND: since really *raw* samples are not so common, and most testing is done with input that is already mpeg-2, the source *must* be *altered* before the comparison. At least, it must be cropped by a non-MOD8 amount. If not done so, then the source offers a block alignment (and block content as well) that clearly favours the mpeg-2 encoder over the mpeg-4 (ASP) encoder, since the characteristics are of the same type.
On top of that, one should add a rather small amount of noise, ideally on a subpixel level.

Analogy: take an MP3 as source, and then try running tests on that source in order to find out wether Vorbis or MP3 can compress that source with higher quality. Of course, that test is 100% b0rked.

Shinobu
14th January 2005, 16:35
of course i've done transcoding of mpeg2, i'm not stupid, i thought it was clear in my post.
and i've done lots of test too with dv source and analog loseless sources 720*576, and my conlusions remain the same.
but don't forgot that's my impression over my tests, i doesn't use psnr nor stuff like that, only some pairs of eyes and some blinded source ^^.
++

ObiKenobi
15th January 2005, 03:50
Originally posted by Shinobu
yes you'll have some very close result with and xvid full ana @ 2500 or 3000 compared to a 8mbps mpeg2 full ana, but you'll never had as good quality than mpeg2@8mbps with xvid (full ana 720*576).

Ummm...how is it fair to compare an XviD encode at 3 mbit to an Mpeg2 encode at 8mbit? The fact that it can look good with a bitrate 5mbit bigger isn't really some great feat, and if it in fact needs that much extra bitrate to look better is definitely not a good thing. I think it would be alot more fair to compare how good the Mpeg2 encode looks at 3mbit compared to an XviD at 3mbit (or any bitrate as long as they were equal) to get a more fair comparison, and I believe in many cases you'd see that XviD would give you as good if not sometimes better results.

This would be like saying that you could make an Nero AVC encode at 10 mbit look better then a DivX at 500kbit (which I think is pretty obvious), but is that really a fair comparison that provides any meaningful information considering the huge bitrate disparity? Not really.

Sergei_Esenin
15th January 2005, 06:59
Most "better quality" people think they see in MPEG-2 over MPEG-4 tends to be due to renderer or postprocessing differences. Widely used MPEG-2 playback software tends to turn on postprocessors like CLEV or NVPP by default, and if MPEG-2 playback takes place within a different application than the MPEG-4 playback or within different windows of the same application, it may use an altogether different renderer.

Then the quality and settings of the encoder are a third issue. With due respect to DivX, 3ivx, and NeroDigital ASP, they can't encode nearly as well as XviD with optimal settings. A fair comparison requires the optimal encoder with optimal settings.

Then the quality of playback filters is yet a fourth possible culprit, because ffdshow, XviD, DivX, Nero, and 3ivx can each produce subtle visual differences given the same MPEG-4 stream, even without postprocessing. People like to think of playback filters as largely interchangeable since they all attempt to conform to the same standards, but they each have minor variations. This has been acknowledged about MPEG-2 decoder filters for a long time, but is largely ignored in MPEG-4 decoder filters. And, any quality-robbing postprocessing options must be off, because deblocking and other features don't help at high bitrates, they diminish detail.

DeathTheSheep
15th January 2005, 18:33
a man claims to store multiple movies on one floppy disk

MWAHAHAAHAHAAA! You've figured me out!!! :devil: Actually, AVC at low bitrates is optimal for anime/cartoons. I ain't encodin' Matrix3 or nothin'.

Heh, I use junk at around 320*240 or less, not junk in the thousands of pixels range...

MPEG-2 sucks at low bitrates, no matter what the encoder or renderer happens to be, or so I've heard.

XVid can't even *reach* low bitrates (compare it to DivX Fusion at quants of 21+). And the closest it gets leave the most horrible trails of artifacts compared to any other ASP codec... Come now...

Certainly at the highest bitrates, 8mbps MPEG-2 or Quant 0/1 MPEG-4 or even emerging snow at 0 would give some good-a$$ picture....

But really, I'd like to see 8kbps encodes. Well, not really, but I doubt you can store much video on some trash like a 512MB memory card if yer usin' some old 8mbps MPEG-2.

A 45 quant on anime gives OK results with anime. The hardsubs are readable and everything at filesizes of UNDER (breakthrough) 2MB for a 20 minute episode. Of course, B-frames ruin this, rocketing the filesize. B-frames also wrecked MPEG-1 for exteremely low bitrates.

So, no, I don't really want to fit multiple movies on a floppy disk (one 512 MB memory card would suffice), but I most certainly don't want to stick on 8mbps MPEG-2 on.

ObiKenobi
15th January 2005, 21:47
Originally posted by DeathTheSheep
But really, I'd like to see 8kbps encodes. Well, not really, but I doubt you can store much video on some trash like a 512MB memory card if yer usin' some old 8mbps MPEG-2.

A 45 quant on anime gives OK results with anime. The hardsubs are readable and everything at filesizes of UNDER (breakthrough) 2MB for a 20 minute episode.

What size screen are you watching these on? Cause I've made encodes at this size and watched them on my PC, 17" LCD, and they look like absolute garbage. The quality reminded of the horrid 5meg DBZ fansubs that used to float around.

Originally posted by DeathTheSheep
Of course, B-frames ruin this, rocketing the filesize.

This still doesn't make any sense. A B-frame more compressed then a P or I frame and will always lead to smaller filesizes when used, as many frames that would have been lower quant P frames become higher quant B frames, unless you are just doing something absolutely wrong.

DeathTheSheep
15th January 2005, 22:56
IPPPPPPP sequences always increase quality over B-Frames in exteremely low bitrates. Bidirectional references are counter-productive when it comes to double-digit bitrates. I don't know why this is, but it absolutely destroys the hardsubs, wrecks movement, and increases filesize by a marginal degree.

Perhaps merely the sequence differentiation in itself is enough to boost the filesize just enough to overtake any possible benifit those destructive B-frames could offer... while reducing quality considerably.


Resolution: 320*240. ~7/8 fps. Deblocking 6/6. 30+ references (for best prediction). 45quant. Anime source.

ObiKenobi
15th January 2005, 23:13
Originally posted by DeathTheSheep
IPPPPPPP sequences always increase quality over B-Frames in exteremely low bitrates. Bidirectional references are counter-productive when it comes to double-digit bitrates.

In my experiences at lower bitrates B-frames are much better at increasing quality, but at the bitrates you encode at it looks like garbage with or without b-frames so to me encoding at such a low bitrate is worthless.

Originally posted by DeathTheSheep
Resolution: 320*240. ~7/8 fps. Deblocking 6/6. 30+ references (for best prediction). 45quant. Anime source.

Yes, but what is that being watched on was the question. Cause on any decent sized PC monitor that looks like complete garbage to me and even on a PDA that looks pretty bad. But I guess if it looks good to you that's all that matters.

RadicalEd
16th January 2005, 06:56
It is remotely possible for B frames to increase size indirectly, especially if they're not being overquantized with respect to the Ps. This is because a B frame essentially creates a void in prediction and the next P frame has to jump behind it and use the P (or I) frame before the B to predict from. Therefore P frames get bigger as a result of B frames. This is probably more prominent with anime as well, so maybe that's what sheep is experiencing. Still, there's no way encodes like that look good to anyone who doesn't have glaucoma.

DeathTheSheep
16th January 2005, 20:41
There's no way encodes like that look good to anyone who doesn't have glaucoma.

With B-frames, true. Otherwise, naa. (Or should I say, baa). Yeah, its on a PDA through an experimental AVC decoder. Also, I've shared some samples with people and they thought it was "easily watchable" but "prefered" original quality better. Wow.

Yeah, with B-frames, the in-loop filter (which is so relied on) is destroyed. Also, B-frames have a lower quant than I/P frames, and at 47, it looks one heck of a lot worse than at 45, so the quality is very inconsistent, and the subtitles are unreadable for a few ms and readable the next.

Yeah, it's the prediction reference gap. Solved with tons of refs (30+) and no B-frames.

I can make an average episode 1.8-2.1MB without B-frames, and 2.0-2.4MB without them, and with easily noticable decline in quality. Yep, it's anime, yep, it's probably the P-increase.

In my experiences at lower bitrates B-frames are much better at increasing quality

BAAAAA!! :sly: :p Well, well... anyone know where I could upload a couple of 1minute samples? You know how tiny the filesizes are... I'll just need lambchps--I mean, proof. MUHAHEEHEEAHHAHAR. Only with higher bitrates do B-frames help (Under 38q).

Thx ppl.

ObiKenobi
16th January 2005, 22:35
Originally posted by DeathTheSheep
With B-frames, true. Otherwise, naa. (Or should I say, baa). Yeah, its on a PDA through an experimental AVC decoder. Also, I've shared some samples with people and they thought it was "easily watchable" but "prefered" original quality better. Wow.

Which for me would mean it would again look like complete garbage.

Originally posted by DeathTheSheep
BAAAAA!! :sly: :p Well, well... anyone know where I could upload a couple of 1minute samples? You know how tiny the filesizes are... I'll just need lambchps--I mean, proof. MUHAHEEHEEAHHAHAR. Only with higher bitrates do B-frames help (Under 38q).

Except "low bitrate" for me is around the 500-800 kbit level, not the double digit bitrates you encode, because like I said before anything encoded at that level just looks like garbage to me.

dragongodz
17th January 2005, 00:38
the simple fact is that B frames do increase quality with lower bitrate encodes. look at mpeg2 and mpeg4ASP(xvid) and you will see they do.

however AVC is still very new and i remember akupenguin saying in another thread that B frames for x264 are not optimal yet. he even suggested only using 1 Bframe for the time being so that should tell you something.

DeathTheSheep
17th January 2005, 02:39
Originally posted by ObiKenobi
Which for me would mean it would again look like complete garbage.



Except "low bitrate" for me is around the 500-800 kbit level, not the double digit bitrates you encode, because like I said before anything encoded at that level just looks like garbage to me.

Here's to my defense (although sheep like me are really only meant for eating)
Mm... Imagine an anime source with strong, thick borders and high contrast. Now picture an episode at 320*240 on a Pocket PC. Readable, watchable, no prob.

However, a similar encode of Matrix3 with subtle borders and shading stretched to 1280*1024 on a plasma screen=death. And not for sheep, but for eyes. Yeah, I see what you mean.

So yeah. Samples are coming soon, with the most optimal B-frames yet--those included in the newest sEx264 (which actually DO increase compression, but reduce quality to an unbelievable extent...I liked the older ffdshow B-frames better, even though they DID make the file bigger)...lol

708145
17th January 2005, 03:40
Look here (http://www.funknmary.de/movie/) for the example that this grass munching sheep is talking about.


As it turns out, sEx264 does the best job with the B-frame
compression, so I used the newest version in these tests. And it
turns out there IS a filesize decrease... but once you see the
samples, you'll be surprised... Read sample.txt in the zip for info,
lol!


bis besser,
Tobias

ObiKenobi
17th January 2005, 03:56
Originally posted by DeathTheSheep
So yeah. Samples are coming soon, with the most optimal B-frames yet--those included in the newest sEx264 (which actually DO increase compression, but reduce quality to an unbelievable extent...I liked the older ffdshow B-frames better, even though they DID make the file bigger)...lol

All I see when watching these samples are complete blocky messes with barely readable subs. I see nothing to really differentiate the version without b-frames from the one with b-frames as they are both garbage. I see no pratical purpose for encoding something with such an extremely low bitrate unless you just wanna see how crappily something can come out.

skal
17th January 2005, 11:45
Hi all,

Originally posted by RadicalEd
It is remotely possible for B frames to increase size indirectly. This is because a B frame essentially creates a void in prediction and the next P frame has to jump behind it and use the P (or I) frame before the B to predict from. Therefore P frames get bigger as a result of B frames. This is probably more prominent with anime as well.

Thou speaketh wisdom, Radical Ed ;)
B-frame are good are inserting 'half-way' pictures between two close P-frames. You could even double the frame-rate at allmost no cost by systematically inserting a b-frame between each p-frame. But now, considering the frame rate (7/8 fps!) DeathTheSheep is using, the extremal P-frames are not temporarily close enough to permit a good temporal interpolation using a b-frame. Successive frames bear too few
resemblance to be bframe-friendly at such a framerate... Hence not only are b-frames bad at doing their job, but the p-frames are getting worse too, due to increased temporal distance. In fact, i think any content/resolution encoded at too low framerate (<10 Hz, say) is likely to be bframe-unfriendly as hell.
Just my 0.02euros.
-Skal

DeathTheSheep
18th January 2005, 22:05
And
Thou speaketh wisdom
as well, skal! 'Tis that which I had originally forseen... Frame discrepency gaps impede accurate B-frame estimation...

Now, however, a new question does arise, one that can be accurately summed up with the ensuing clever lines of prose:

Tell me why,
Pray tell,
The B-frames are blocky
As hell

For I
Don't see
Why oh why
That could be

A-Hem... So yeah.

[OT] skal... skal... Pardon me if I don't accurately recall, but...

Ain't you teh fella workin' on a sleek new AVC codec? I tried out yer ASP, and it sure works!

ObiKenobi
18th January 2005, 22:48
Originally posted by DeathTheSheep
Tell me why,
Pray tell,
The B-frames are blocky
As hell

For I
Don't see
Why oh why
That could be

It's cause you are quantizing them so high (the higher the quantizer the more data has to be eliminated from each macroblock which is causing that hideous blocking) and that's just a side effect. Considering that every frame in those encodes are nothing but a mass of blocks it's not that surprising that the b-frames would be blocky as well as they would be quantized even higher then the p-frames.

Tommy Carrot
18th January 2005, 23:01
Originally posted by ObiKenobi
It's cause you are quantizing them so high (the higher the quantizer the more data has to be eliminated from each macroblock which is this hideous blocking) and that's just a side effect. Yep, but another reason is: ffdshow cannot deblock AVC b-frames, that part of the deblocker filter is not completed yet.

DeathTheSheep
18th January 2005, 23:13
HAHHAHEHEHEHEHEHEHEHE

I think that this does the explaining all too well.

With B-frames:
http://img148.exs.cx/img148/8042/bframe5zz.jpg

Without:
http://img148.exs.cx/img148/8250/nobframe7lc.jpg


Get the picture? Heheh, get it?

B-frames increase quantization by ~2q. At these bitrates, my gosh... that's one heck of a quality decrease.

Windows media dynamically inserts B-frames into wmv content based on computer ability. Heh, I got an 8fps clip runnin smooth as heck at 120fps with this... it's exeedingly visually pleasing. Well, if not B-frames per say (must be integrated and conform to standards...GAA), they utilize the same principle: they stick in mid-frame estimates.

Is there a way to do this with non-wmv encoding? Or is it something specifically designed into the format? Or is MS just plain cheating with hack-like principles?

ObiKenobi
18th January 2005, 23:14
Originally posted by Tommy Carrot
Yep, but another reason is: ffdshow cannot deblock AVC b-frames, that part of the deblocker filter is not completed yet.

Though even with deblocking on for the other frames it still looks pretty bad... I can't imagine deblocking for b-frames helping out at all and in fact with deblocking enabled those clips looked even worse.

ObiKenobi
18th January 2005, 23:15
Originally posted by DeathTheSheep
HAHHAHEHEHEHEHEHEHEHE

I think that this does the explaining all too well.


Get the picture? Heheh, get it?

Except every single frame (regardless of b-frames are being used or not) look just as bad as the first picture.

DeathTheSheep
18th January 2005, 23:16
Um, why the heck does the IN-LOOP filtering not work? Eh... That's integrated into the encoding itself and ain't dependent on the decoder/renderer. It sure works on P and I frames.

DeathTheSheep
18th January 2005, 23:20
@ObiKenobi

Hey! <Snort, baa> that ain't so!! compare especially the second short samples. There are no "blocks" in the IPPPPPPP sequences; at most, all I can see is a tiny trace of an outline around areas of consistent color. B-frames give the true garbage.

I can see the quote:
But mista sheepy dude man dude fo wtf iss ALL "garbage" what choo talkin' bout...?

Remember, it's a tinseey weensey 320*240 screen. The blocks stick out like crazy man.

[edit man]
OK. Lookit quant 42 samples. up to 38. The blocking is astounding for B-frames!

Quote me on this: The results are a lot better with lower quant than those obtained with a higher B-framed quant at the same filesize in quants of 38-47. (In terms of blocking and overall quality)

ObiKenobi
18th January 2005, 23:25
Originally posted by DeathTheSheep
@ObiKenobi

Hey! <Snort, baa> that ain't so!! compare especially the second short samples. There are no "blocks" in the IPPPPPPP sequences; at most, all I can see is a tiny trace of an outline around areas of consistent color. B-frames give the true garbage.

I can see the quote:


Remember, it's a tinseey weensey 320*240 screen. The blocks stick out like crazy man.

Umm...you must be blind. I am watching the files at 320x240 and the blocking is apparent not only in the one with b-frames but the one without b-frames. Turning on deblocking in ffdshow doesn't help in the least bit it still looks like a non-detailed blocky mess with subs that are barely readable. Like Ed said the only person who could think this looks good must have glaucoma. I'll post some screenshots just to prove what I'm saying. Even at 1/2 and 1/4 resolution it still looks like crap.

DeathTheSheep
18th January 2005, 23:29
Ah, you mustn't be so hasty. 3*2.5 inch screen, and lack of detail=not important. Just blocks. I'm not tryin' to force my way of seeing (COUGHspreadtheglaucomaCOUGH)... I'm just tryin' to find out if there is a way to turn in-loop filtering/block prediction on B-frames. With that addition, B-framed clips rock (coughyeahsurecough).

:D oh, and check out the edit to the above post, heheh

Quote me on this: The results are a lot better with lower quant than those obtained with a higher B-framed quant at the same filesize in quants of 38-47. (In terms of blocking and overall quality)

Yeah, compare a 28.8kbps anime clip without b-frames to a 28.8kbps clip WITH b-frames... or a 56k clip ... or even a 92kbps clip... and you'll see the blocking. I can accept detail smearing. I hate blocks. (Although the BLOX codec is ok...it doesn't block! muhaha)

ObiKenobi
18th January 2005, 23:33
Here's pictures from each of the encodes:

With B-frames
http://img153.exs.cx/img153/8096/withbf9gt.png

No B-frames
http://img153.exs.cx/img153/8227/nobf9uy.png

There is little to no difference between these encodes as they are both just a blocky mess, though at this frame the one with b-frames looks slightly more detailed. I'm sorry, but to say that either one of these looks "good" means you must seriously get your eyes checked cause there is a problem.

ObiKenobi
18th January 2005, 23:35
Originally posted by DeathTheSheep
Ah, you mustn't be so hasty. 3*2.5 inch screen, and lack of detail=not important. Just blocks. I'm not tryin' to force my way of seeing (COUGHspreadtheglaucomaCOUGH)... I'm just tryin' to find out if there is a way to turn in-loop filtering/block prediction on B-frames. With that addition, B-framed clips rock (coughyeahsurecough).

Except I'm not watching it at the full resolution of my monitor. At 1/2 and 1/4 the resolution of the file that would easily mimic what it would look like on your PDA and it still looks like crap.

DeathTheSheep
18th January 2005, 23:41
You got em on a P-frame, man, when the blocks have already been washed out, probably, or one where there is low motion taking place. I'm talking about blocking while there is movement. Also, the second screenshot is working off a slightly lowered entropy rate, so the data was more easily predictable and the encoder didn't bother to apply detail to that specific frame.

Remember, a screenshot of a specific frame can prove just about anything, and in any direction. I'll come back with proof supporting motion blocking (come on, its a known fact baaaaaAA that B-frames stuck between P frames that far away from each other leads to heavily decreased motion accuracy, especially in anime, where short jolts of motion are depended on to convey an image.

So yeah! :D I rule :D I drool :D (Please don't make me into p-p-poisonous lambchops...or worse yet, lamB-framechops. (see how that b-frame caused a choppier word and ruined its consistency and understandiblity? Not to mention innacurately predicting the word)

So, anything to my previous questions?

1. In-loop filter possible on B-frames?
2. Dynamic B-frame insertion like wmv's?

DeathTheSheep
18th January 2005, 23:42
Eh, and some people think Xvid at quant=2 looks like trash, too, not to mention my favorite...31...

[]Edit, oh man... B-frames trash up ASP codecs pretty bad, man. DivX fusion, set to adaptive multiple consecutive, gives you a tremendous filesize in my preliminary tests...

Tommy Carrot
18th January 2005, 23:42
Originally posted by DeathTheSheep
Um, why the heck does the IN-LOOP filtering not work? Eh... That's integrated into the encoding itself and ain't dependent on the decoder/renderer.
Ahh, it's not so simple. The deblocking on the encoder side simply helps in better predictions, but for actual deblocking, you have to support it on the decoder side too.
I can accept detail smearing. I hate blocks.
If you hate blocks so much, you should use Snow codec instead of x264. True, it has even worse quality at those ultra-low bitrates, but guaranteed no blocks. :D
1. In-loop filter possible on B-frames?
2. Dynamic B-frame insertion like wmv's?
Sure, both possible, just not implemented yet.

DeathTheSheep
18th January 2005, 23:47
Yeah!! Wavelet forever man!! Go rududu!!! :D

(wavelet decoding isn't supported on PPC, even in theory, but i suppose someone could try it...:D)

DeathTheSheep
18th January 2005, 23:51
Originally posted by Tommy Carrot
Sure, both possible, just not implemented yet.

yet. yet. yet. ever hear of yeti3d? man... it rocks

GAAAAAAA!!! ASP had fifty years to get it done!! (heheh, who the heck wants dynamic B-frames? And in already-complex AVC? Besides maybe some sheep that is, quite frankly, very close to death, AHAH, no.)

But in-loop filtering is a huge plus....

DeathTheSheep
19th January 2005, 00:08
Eheh, I think I'll pass. Let me work one up for you, man! And at a lower quant. Baa! :p

Ah, here goes.

Bframes: (not same frame according to VDub, because B-frames through off frame count, another example of B-frame coolness hehe)

As you can see, b-frames give terrible blocking while movement is taking place, and I can't tell what the heck is going on. How many characters do you see? Maybe no the best example, but you get the point. Sample 1, frame 58 (B) or 55 (P):
http://img49.exs.cx/img49/1268/bf0jl.jpg

NO BF
While still pretty blurry (as i said, not the best example), it's a heck of a lot worse. I'll try higher br later. How many characters are there? Fundemental estimation difficulties with low framerate.
http://img49.exs.cx/img49/6277/nobf6bb.jpg

Convinced?

stephanV
19th January 2005, 00:17
uhm

what the hell is supposed to be on those 2 pictures??? i only see crap, b-frame or not.

Gabriel_Bouvigne
19th January 2005, 00:28
How many characters do you see?
Zero. There is some signal, but I am totally unable to see what it could be.

RadicalEd
19th January 2005, 01:45
The problem with your comparison is that you're using constant quants to encode. The idea of B-frames is that they reduce size so that more can go to other parts of the video. Of course a B-frame encode is going to look somehow worse than a P-frame encode at the same quant (with offsets), it's the difference between same-size files that matters.
Not that I think you'll get much better results that way, it's pretty clear that b-frames are not good under these (very rare) conditions.

Sirber
19th January 2005, 02:15
Originally posted by stephanV
uhm

what the hell is supposed to be on those 2 pictures??? i only see crap, b-frame or not. +1.

Is that a video? Who enjoy watching that? :o