Again smearing...

[pastk]

First I've noticed these nasty trails in credits. So, the reading the forum, increasing of bitrate, setting B-frames to max 5 and BVOP sensitivity to 90, etc. almost eliminated that problem. Unfortunetly, I've watched the whole encoded movie only yesterday. "Trails" were also in normal scenes involving slow vertical movement.

Such as this..
http://temp.demogorgon.ru/kostya/trails.jpg

The movie is The Fellowship of the Ring (Extended Edition).
Average bitrate is 955 avg kbits/s (source is very compressible because of dark scenes)
Resolution is 640x268, resulting in 0.238 bits/pixel.
BVOPs 2/1.5/1
Trellis
Custom Matrix (HVS Better Picture)
Qpel

Will the increasing of bits/pixel value solve this problem or it's not only the matter of bitrate? (sorry, I can't check it, 'cause I don't have the source DVD for now)

[jimmy basushi]

obvious question first. what do you use to decode it?

[celtic_druid]

Above image is 640 x 360 pixels. Try using a mod16 resolution, although it was my understanding that non mod16 resolutions did work, it couldn't hurt to try. Plus the codec should be more efficient.

[sysKin]

non-mod16 did not work before 1.0 tree, although 1.0's decoder has a workaround to display them corrently - if it can only detect old xvid.
This is either a very old encode (it can't be detected) or new encode but old decoder.

[pastk]

Sorry, I really forgot to mention encoder/decoder configuration.

The movie was encoded with XviD 1.0 rc3 with settings mentioned earlier (so, this is not old encode).

I decoded it with latest ffdshow (postprocessing off) using both MPC and GraphEdit. BTW, those black borders causing 640x360 resolution were added by MPC ("save image..." feature).

But I did't try to decode it with native XviD decoder yet. I'll try and post the results tomorrow.

celtic_druid, what do you mean saying "the codec should be more efficient"?

[zulu]

Originally posted by pastk
celtic_druid, what do you mean saying "the codec should be more efficient"? [/B]

he means that the codec would be more efficient if you'd choose a resolution divisible by 16, because that's the size of a macroblock (16x16 pixels).

[Koepi]

When decoding with ffdshow don't forget to set IDCT (in "misc." tab) to XviD(walken) IDCT. Else you get smearing...

Regards
Koepi

[pastk]

Koepi:
setting IDCT to XVID had no effect (the smearing remained)

As i promised, I've tried it with DivX and XviD decoders.
Sorry, I can't include any test images, because my hosting is down :(

I'll try to explain the results by words.

1. DivX 5.1.1 decoder (postprocessing off, other options by default):
much less, but still noticeable smearing + strange color artefacts (trails of smeared colors (these colors should not be that frame) and sometimes color casts on edges).

2. XviD 1.0 rc3 DShow decoder
colors are natural; I'm not shure but it seems that a very small amount of smearing still exists at the very edges (top and bottom) of the frame. But maybe they are just a result of the compression smoothing.

[Soulhunter]

I could be wrong, but... The HVS Better matrix starts with a 19 in the upper left inter matrix, but ffdshow has problems to decode matrices that not start with a 16 in the upper left inter... :rolleyes:

Disable ffdshows XviD decoding, and try the original XviD decoder instead !!!

If you wanna use of ffdshows filtering, set it to "decode" raw video... ;)


Bye

[pastk]

I've alredy tried it with XviD and DivX decoders. Just reread my previous post :)

[redfordxx]

Hi,

I am continuing almost a year "sleeping" thread, but hope someone comes back and helps.

First: Do I understand correctly that smearing is that moving object is leaving trail on "one-color" background (e.g. sky)?

Now: I have source 704x416 compressible 0.400 b/(p*f) @Q2 using H.263.
Trying to compress it at 0.220 I have smearing. Is there general advise, what to change?
The filesize is given, so what else? Change matrix, settings, downsize....

I am asking again, coz here were some statements about SW, which aren't probably valid... and new experiance can be in place.

Using: XviD-1.1.0-Beta1-16012005...

[communist]

There is a difference between smearing due to 'overcompression' and buggy encoder / decoder setup.
You're not apparently getting smearing because your bitrate is too low?

[redfordxx]

Originally posted by communist
You're not apparently getting smearing because your bitrate is too low?
Well I thought I will to reduce the resolution... I wanted only to know whether there is not any specific thing which relates to smearing, like setting, matrix...

Otherwise, the movie is quite nice, sharp in scenes they need it, few blocks. The smearing is the ugliest thing.

EDIT:
With 704x336-->0.260 b/(p*f) no visible difference
With lower res maybe less, but still annoyingly present.

I am checking it on the beginning of LOTR TTT, where the camera is flying over the mountains for some time. I guess even for the specific scene zone setting won't help...?

[lordadmira]

Originally posted by Koepi
When decoding with ffdshow don't forget to set IDCT (in "misc." tab) to XviD(walken) IDCT. Else you get smearing...
The current ffdshow (3/12/05) has "libmpeg2(Xvid)" for this value.

LA

[redfordxx]

Originally posted by lordadmira
The current ffdshow (3/12/05) has "libmpeg2(Xvid)" for this value.
Tnx, useful info. I'll try...

Then, I wonder what is the advantage of not having this option. why it is not default or the only option (except disabled).

[akupenguin]

XviD's iDCT is non-default because libavcodec's is default. As for why there are multiple versions of iDCT, blame MPEG for not specifying the transform exactly.

[lordadmira]

If the exact iDCT is that important, why isn't in the video stream? Instead u have to specify it externally? That makes no sense.

LA

[redfordxx]

When I recently looked at the DCT in vob source (I mean dgdecode option iDCT), the floating point(iDCT=3) and simple (iDCT=7) looked better than the reference (iDCT=4)...
Originally posted by akupenguin
blame MPEG for not specifying the transform exactly. Does it mean, that in other source could iDCT=4 look better than others?

[Manao]

> If the exact iDCT is that important, why isn't in the video stream?

Because that wouldn't solve anything :

* only ffmpeg / dgdecode lets you the choice of the iDCT, normal decoders ( and especially hardware one ) don't let you the choice, so that information would be of no use to them.

* since the iDCT is not strictly defined, an infinity of iDCT methods can be created and used, so how could you write in the bitstream which one was used ?

[temporance]

To be fair on MPEG, xvid users are using much longer GOVs (longer key frame interval) than they recommend. Drift causes by iDCT implementation variations becomes more obvious a long time after a keyframe.

IIRC they recommend a max keyframe interval of 60 frames.

[akupenguin]

Originally posted by temporance
To be fair on MPEG, xvid users are using much longer GOVs than they recommend.
IIRC they recommend a max keyframe interval of 60 frames.
No mercy. That just means they recognized the problem and still didn't fix it until H.264.
(And is that 60 frames with 2 consecutive B? DCT drift should depend only on the number of P-frames in a GOP.)

[Manao]

Actually, in the Annex A of the reference document, they require a macroblock not to be coded more than 132 times consecutively as inter P, without taking into account skip & b's.

But i must admit that "the precision shall be sufficient so that significant errors do not occur in the final integer values" is not a sentence that should be found in a normative document.

[lordadmira]

Originally posted by Manao
Actually, in the Annex A of the reference document, they require a macroblock not to be coded more than 132 times consecutively as inter P, without taking into account skip & b's.
Uh-oh! Looks like I'm off-spec. :D


LA

[Isibaar]

We have thoroughly discussed and analyzed the idct mismatch problem at XviD already long ago and had also implemented the 132 intra-refresh rule. However, all additional rules in the standard (like the 132 MB intra-refresh) do not help to reduce the (very) visible artifacts caused by idct mismatch.

In fact, I've tested with sequences where there was a visible mismatch between simple and XviD idct even when a keyframe interval of 16 (!!) was used. I can just back up what akupenguin said: this is a major problem of the standard and MPEG is to blame for this. So in order to be sure there won't be mismatch problems, you should decode your videos with the same idct that was originally used by the encoder to create the stream. This however will severely limit interoperability with third-party decoders.

BTW: ffdshow should be able to autodetect whether to use simple or XviD idct for a stream. At least, libavcodec has such a feature and it works reasonably well.

[redfordxx]

Originally posted by communist
There is a difference between smearing due to 'overcompression' and buggy encoder / decoder setup.
You're not apparently getting smearing because your bitrate is too low? Well, I made tests with firstpass file 6of9 Q1:
Then, overcompression is definitely not the case.
I captured one frame with Xvid,FFD(XviD),FFD(libavcodec).The difference was noticable only when quickly switching captured pictures having enhanced contrast. Differrence FFD(XviD) vs. FFD(libavcodec) was bigger than Xvid vs. FFD(XviD), but still nothing compared to the strength of the smearing artifact.