[Tech Encoding] XviD Devapi4

[Sagittaire]

A new technique to encoding with XviD Devapi4 for weak bitrates consists in making the first pass in quant3, quant4 or quant5 to improve quality for second pass ...

Test with 500 kbps and 30% for compressibility ...

first Passe quant 2
GMC, No Qpel: 41.7754 dB

first Passe quant 4
GMC, No Qpel: 41.8205 dB

first Passe quant 5
GMC, No Qpel: 41.9125 dB

Quality is obviously better especially with regard to the blocking and one approaches the quality of DivX 5.1x which is superior for very weak bitrate ...

For encoding with 50% of compressibility first pass in quant3 will be a better solution than first pass in quant2 ...

[CruNcher]

A new technique to encoding with XviD Devapi4 for weak bitrates consists in making the first pass in quant3, quant4 or quant5 to improve quality for second pass ...


hmm my results tell another story


Quant 4:
Minimum Average Maximum
Y: PSNR: 24.0706 38.7933 43.1817
U: PSNR: 39.9186 42.9997 45.5551
V: PSNR: 40.0821 44.0895 49.3531
Sum: PSNR: 25.7764 39.8770 43.9477

New2pass Decission:
Minimum Average Maximum
Y: PSNR: 24.0766 38.8998 43.7253
U: PSNR: 38.7668 42.9468 46.1811
V: PSNR: 39.3697 44.1109 48.7220
Sum: PSNR: 25.7815 39.9649 44.4521

[Sagittaire]

Not it isn't the technique: it's necessary to make the encodings in 2 pass. For Xvid the first pass is always made in quant 2 (Iframe and Pframe) in default setting whereas my technique consists has to make the first pass with an inferior quant 3, 4 or 5 ...

The result will be better. The analysis is finer. the second pass is making with quant very superior from as quant 2 for low compressibility ...

Try with different quant for first pass ...

[Teegedeck]

Were these made with the new 2-pass code from 11-09, already?

[superdump]

Teegedeck: CruNcher will be using GomGom's newly submitted 2-Pass code, yes. :) He likes to keep up to date.

[Assault]

A possible reason for the different results Sagittaire and CruNcher got could be that they encoded with different bitrate settings. An encode with 30% compressibility as Sagittaire did seems to be a very low bitrate encode. The bitrate CruNcher used was PERHAPS higher. I don't know if that's true....I'm only gessing. :p

OT: With devapi4's directshow filter the message about b-frame decoder lag appears when you open a video in any media player. Does anyone of you know if that's normal? Koepi's devapi3 directshow filter didn't show that.

PS.: I hope asking that question is allowed although there isn't an official devapi4 build yet. But since we're discussing devapi4 things anyway it should be ok in my opinion. ;)

Assault

[springl]

@Sagittaire
would you kindly explain how to make a quant-N first pass encoding (N>2) with xvid dev4 ?
thank you

[Didée]

(Since the thread is still open ;) )

Hmmm...

since the last committed 2-pass code, B-frames are "out of control" in my tests: 2nd pass B'frames are somehow influenced by the multiplier&offset settings, but definetly not like they're supposed to. It gets a little better when using B-quant == P-quant for 1st-pass ...
Bug, WIP, or did I miss something?

@ springl:
Fixing the quant in the 'zones' box (in the very middle) for 1st-pass should do the trick. (Didn't try that myself yet, though.)

- Didée

[temporance]

Are we talking overall or average PSNRs here?

[RadicalEd]

Originally posted by Didée
since the last committed 2-pass code, B-frames are "out of control" in my tests: 2nd pass B'frames are somehow influenced by the multiplier&offset settings, but definetly not like they're supposed to. It gets a little better when using B-quant == P-quant for 1st-pass ...
Bug, WIP, or did I miss something?

Is that causing the nasty block-specific flickering effect? I've been wondering about that since last night, haven't had a chance yet
to check if Bframes are causing it.

Yep, B frames seem to be the problem here. I'll drop by on IRC and see what they've got.

[CruNcher]

try b-frames 1/1.50/0 still problems ?

[RadicalEd]

No go. Settings I've been using are Advanced Simple level 5 - VHQ4, chroma motion, cartoon mode (also tried without), trellis, and chroma optimizer. Everything else is default (well, except the B-frame suggestion).

Here's a segment of the clip with b-frames, without, and a corepng difference clip. I threw in a dev-api-3 encode as well (Koepi's 6/24/03 mod) and a difference clip between api-4 and api-3 both with B-frames.

Dev-Api-4 -128 with B-frames (http://digitalinsanity.ath.cx/~tab/api4B.avi)

Dev-Api-4 -128 without B-frames (http://digitalinsanity.ath.cx/~tab/api4.avi)

Difference (http://digitalinsanity.ath.cx/~tab/api4toapi4B.avi)

Dev-Api-3 (Koepi 6/24/03 - with B-frames) (http://digitalinsanity.ath.cx/~tab/api3B.avi)

Difference (http://digitalinsanity.ath.cx/~tab/api4Btoapi3B.avi)

edit - post reconstructed

[CruNcher]

geze the quant distro is negative thats not good gomgom is looking @ it

RadicalEd the problem should be fixed now just checkout :)

[RadicalEd]

At 11:30 CruNcher wrote

RadicalEd the problem should be fixed now just checkout :)

Off the ML:
2003-11-19 15:33:55 GMT patch-103

Summary:
Formula error in twopass code.
Revision:
xvidcore--devapi4--1.0--patch-103

The reversing bframe formula in 2pass 2 was not right. This was in fact
a test code i used when i was maintaining the code on its own branch.
I should not have commited it :\

Fixed :-)

modified files:
src/plugins/plugin_2pass2.c

:D cool. I'll run a test through.

edit- definitely works now, thanks for taking a look and forwarding to GomGom Cruncher :]
Also testing Sagittaire's method as I type.

[RadicalEd]

I really hate to say this, but it seems I spoke too soon :( For some reason it really wants to re-adjust stationary blocks. I'm not sure if this is just inevitable due to a bitrate shortage or what. Neither DevApi3, 4 without bframes, DivX, or 3ivX demonstrate the problem to the same extent. Hrm :\

I'm really not too sure what this is anymore, but here's another sample with B, without B, and the difference. It's most noticable from frames 61 - 71, because there's nothing else going on in the scene at that time.

B (http://digitalinsanity.ath.cx/~tab/hmmB.avi)

no B (http://digitalinsanity.ath.cx/~tab/hmm.avi)

diff (http://digitalinsanity.ath.cx/~tab/api4Btoapi4.avi)


I guess at this point it's possible that there's no real problem and I'm just nitpicking :| but the previous problem has made me super sensitive to these flickering blocks. Tomorrow I'll try to isolate the problem as relating to too high quants or whatever else it could be. First sleep.

[RadicalEd]

Alright, here's what I've got. The 'problem' occurs in all B-frames and consists of the contents of a block shifting by one pixel vertically or horizontally. This becomes noticable only when a block is compressed so much that the block's edges become well defined. The same shifting can occur to an extent in P frames, however P and B frames seem to make different decisions about these shifts and so when one or two B frames are succeeded by a P frame, the block seems to flicker back and forth, which isn't too pretty. I don't know if this is remediable, but I'm picking through the code trying to find what might cause it. Here's a single 16x16 block displaying the issue.

1x (http://digitalinsanity.ath.cx/~tab/1x_.gif)

4x (http://digitalinsanity.ath.cx/~tab/4x_.gif)

So essentially it's a problem with the part of the image being assigned to a P or B block. It also seems to happen more when ME and VHQ are 0, so I guess motion estimation is playing a part.


On another bughunting note, P frames don't listen to the min quant box or the quant setting in the ranges dialog. I'm getting a few at q20 when they should be 31. Most at 31, but a few stragglers staying at 20.

edit - interestingly, Qpel eliminated the problem for still frames, though it was still rampant in slightly moving ones.