Log in

View Full Version : The Horror of B-Frames


Asrial
18th May 2004, 07:17
Pre-Motion Estimation.png (http://home.sprynet.com/~asrial/temp/Pre-Motion Estimation.png)

Post-Motion Estimation.png (http://home.sprynet.com/~asrial/temp/Post-Motion Estimation.png)

Post-Motion Estimation Zoomed.png (http://home.sprynet.com/~asrial/temp/Post-Motion Estimation Zoomed.png)

.

This issue is caused by setting Motion Estimation above 0. It's not corrected by qpel or gmc. It's not a filter issue.

Doubt there's much that can be done to correct it but just an heads up so that people are aware of it (for those that aren't, anyways).

[EDIT: this occurs on RC3 and with the final]

[EDIT2 -- 6/9/04 -- after much research, it appears that b-frames are what's causing this]

Koepi
18th May 2004, 07:20
Did you use adaptive quantisation or trellis quantisation (or both)?

Is that an i-frame, p-frame or b-frame?

Let's put it simple: post all your settings, maybe we can find something that can be done to avoid that.

Koepi

Asrial
18th May 2004, 07:31
Trellis: yes
Adaptive: no
I/P/B: dunno

I actually first noticed it on a different segment (movement caused by the frame being moved up and down to simulate the character's moving) where it occured through a number of frames so it's not limited to just only one frame.

How do I find out what frame type this specific one is?

.

If it's not noted, it's not running.

Unrestricted, H.263, B-VOPs (2, 1.5, 1.0), Closed GOV, Pixel Aspect Ratio = Square

Twopass - 1st Pass (happens in both 1st and 2nd pass), Full Quality First Pass

Frame 0 -> end, weight 1.0, bvop sensitivity = 0

Motion Search Precision = 6 (happens @ 1 as well), VHQ = 1, Use Chroma Motion (happens with this off as well), Frame Drop Ratio = 0, I-Frame Interval = 300, Quants 1/31, 1/31, 1/31, Trellis Quantization, automatically detect optimizations, fourcc = xvid

.

..and let me go change the name of the topic, I'm talking about Motion Search Precision.. not Motion Estimation (which is a term I made up because I made an error).

Nibor
18th May 2004, 07:42
Originally posted by Asrial
How do I find out what frame type this specific one is?
You can use ffdshow, go into the configuration and switch the onscreen display ( OSD ) on.
Then you can play your file and go to the frame you want to know what frame type it is :)

I hope this problem gets fixed as I think I saw it too some time.
But in 'real' films it isn't that disturbing, therefore I'm not sure if it was really an artefact or already in the source.

Regards,
nibor

AS
18th May 2004, 08:10
The way it occurs on a border between two colour and the shape reminds me of trellis blocks.

BoNz1
18th May 2004, 08:25
Some guy posted a little while ago about a similar problem. The problem was trellis apparently, try deactivating it and see if it goes away.

Asrial
18th May 2004, 08:30
Originally posted by AS

The way it occurs on a border between two colour and the shape reminds me of trellis blocks. Still there, albeit not as pronounced it looks like, with trellis quant off.

A friend of mine taking a look at it said he discovered these results:

2 b-frames + chroma optimizer ON = error
2 b-frames + chroma optimizer OFF = error
1 b-frame + chroma optimizer ON = error
1 b-frame + chroma optimizer OFF = no error
0 b-frame + chroma optimizer ON = no error

.

Investigating for myself now.

[EDIT: still there, disregard this post for the moment -- leaving info because it may be relevant since Motion Search Precision 0 is the same as 0 b-frames]

[EDIT 2: each of the steps listed above (above meaning above in this post and above in the posts by others) seems to lessen it, but so far these are the only two ways to remove their presence -> set Motion Search Precision to 0 OR disable BVOPs]

Leak
18th May 2004, 08:53
Originally posted by Asrial
2 b-frames + chroma optimizer ON = error
2 b-frames + chroma optimizer OFF = error
1 b-frame + chroma optimizer ON = error
1 b-frame + chroma optimizer OFF = no error
0 b-frame + chroma optimizer ON = no error

Well, I noticed and IIRC reported this myself some time ago, but I believe this is what sysKin means with

1.1 bugs I invented so far:
- better SKIP decisions make walls move less and prevent some rare b-frame artifacts

in his sig - sometimes XviD will choose B-frames that produce these artifacts because they have a higher PSNR for the whole frame even though they look icky in a few places.

np: Turner - My PC (A Pack Of Lies)

MfA
18th May 2004, 09:55
Dont be so sure it is an error, could just be an artifact.

gamr
18th May 2004, 10:09
im pretty sure leak is right, try getting the latest build from the url in my signature and see if that helps.

Teegedeck
18th May 2004, 12:24
As far as I remember it is exactly the problem Leak describes.

Asrial
18th May 2004, 18:54
Leak, thanks for the info!

GaM3R, yeah MG had told me your builds have some really awesome motion precision so was going to give it a shot but haven't gotten around to it yet.

Teegedeck, thanks for the confirmation of what Leak said.

Asrial
9th June 2004, 10:44
I'm using the latest XviD with these 'non-default' settings: qpel, 1 bframe, packed bitstream OFF, trellis quantization.

The issue is still present.

Also, I've been using a LCD lately and I made an interesting discovery.. which I enhanced in this image..

The enhancement was made just by using the 'fill' feature of MSPAINT.

You can also see these 'major blocks' in the zoomed up image I posted in the beginning of the thread.

http://home.sprynet.com/~asrial/temp/blocks2.png

Omni
9th June 2004, 12:58
I noticed the same thing in various cases. sometimes little squares are totally wrong. i posted some screenshots where b-frames lead to pre-ghosting. seems to be the same problem. in my case it looked like xvid b-frames interpolated between two frames in some really rare cases.
correct me if i'm wrong but b-frames are bidirectional so maybe they use information from the next p-frame where they shouldn't. i made some tests and noticed that the pre-ghosting visbility increased with rising max. consec. b-frames.
(by the way, divx sometimes shows the same behavior....but a lot less compared to xvid...anyway i don't like divx5. if i notice some b-frame ghosting/artifacts i just reduce them to a good value)

Sharro
9th June 2004, 13:17
I wonder if the previous and next frame have the same problem.

All the best,


Sharro

amango
9th June 2004, 16:35
I posted this pictures two weeks ago, but no one answered. It's the same problem. (flashing squares)

Sample 1 (http://people.freenet.de/amango1/pixel-xvid1-sample.JPG)
Sample 2 (http://people.freenet.de/amango1/pixel-xvid2-sample.JPG)

Caspar
9th June 2004, 23:10
Did the new bugfix release of 1.0.1 fix this problem? I notice that there are core fixes, but did any of it actually address this problem? I would test it myself if I had sometime...

sysKin
10th June 2004, 04:21
No, this problem will not be addressed in xvid 1.0. This is not actually a programming error (aka a "bug") but an encoding artifact. With a different design of motion estimation this can be, and should be, reduced to invisible level.

It was already addressed in xvid 1.1. Not many tests were done, but go and check, you might find the effect (nearly) gone.

More will be done when I finish my exams (end of June). Stay tuned.

Radek

@amango: oh, you meant this bug. I have no idea what this is, you might give me a video sample instead of the picture. Never seen that before (except for your previous post of course)

[edit]I am stupid and I confuse people. Sorry. The question above ("no idea what this is") was to amango. The main answer ("look at 1.1") was to Asrial...

Caspar
10th June 2004, 04:57
@sysKin
Sorry for any confusion caused, the problem I am referring to is the problem displayed by this picture as posted by Asrial:
http://home.sprynet.com/~asrial/temp/Post-Motion%20Estimation.png

I was wondering if any of the corefixes implemented on the 1.0.1 release actually addressed this.

Asrial
10th June 2004, 05:50
Originally posted by Caspar

Did the new bugfix release of 1.0.1 fix this problem? I notice that there are core fixes, but did any of it actually address this problem? I would test it myself if I had sometime... No. The post I made that re-opened this thread (where I blacked in the blocks) is using XviD-1.0.1-05062004.exe.

sysKin, I don't have enough room on my website to host a VOB example. Is there a location I can upload it to?

sysKin
10th June 2004, 08:02
Originally posted by Asrial
sysKin, I don't have enough room on my website to host a VOB example. Is there a location I can upload it to? Oh, not a vob - just an avi that has the problem. Cut it to be as short as possible, I don't need many frames at all. Just one keyframe and as many frames as needed.

Asrial
10th June 2004, 12:16
http://home.sprynet.com/~asrial/temp/testsample.avi

dragongodz
10th June 2004, 13:42
just wondering if you get the same if you dont use trellis or if you dont use qpel ?

sysKin
10th June 2004, 13:58
Okay sorry guys, it's all my fault, I am stupid and I confuse people...

When I said "no idea what this is" I meant amango's problem.
When I said "look at 1.1", I meant Asrial's problem.

So, one more time:

Asrial: it's an encoding artifact, it was already targetted in 1.1's branch, but VHQ for b-frames (planned later) should help even more.

amango: I've never seen such thing before, could you upload a clip somewhere.

Apologies again,
Radek

Asrial
10th June 2004, 20:17
No worries Radek :)

Any idea when Koepi will be releasing a 1.1 compile?