XviD-19062003-1

[Gaia]

Do you think that the quality of dark scenes(black blocks problem) got better with latest builds or did you simply mean that you don't use any filtering beside this lumafilter/unfilter combination?

I haven't seen black blocks since i switched to YV12 encoding...

[iago]

Do you think that the quality of dark scenes(black blocks problem) got better with latest builds or did you simply mean that you don't use any filtering beside this lumafilter/unfilter combination?Assault,

I don't know whether it's due to eliminating unnecessary colorspace conversions as a result of working in the native colorspace of YV12 (as Gaia also points out) or due to recent builds working better on that point now, but I think there has been improvements in that respect. Though I don't view often on TV lately, I have not noticed that problem for quite a while when viewing on my 17" CRT monitor. (You know I've always been pretty allergic to this black-blocks problem and when it exists it usually doesn't escape my eyes! ;) However, that problem might also depend on the source imho, but now at least we know how to deal with it when it occurs -> blockbuster, lumafilter/unfilter, etc.)

Back to your question, since I don't see/notice this problem any more, no, I don't use lumafilter/unfilter either unless I need them for some apparent purpose.

regards,
iago

[Assault]

@ iago

Thanks. :)
I think I'll try my next encodes without lumafilter then and I'll report it here if I see black blocks after all. ;)

Assault

[yaz]

dear devels (or any1)!

can u comment my note on 'max i-frame' neglection? sometimes it can be more serious than i expected.
i'm just trying to encode some home-video for my family. most of them consist of long slowly moving scenes, no scene changes in its strict meaning. imho, here it's essential to insert keyframes regularly. however, with vhq1/mbf0 i got 2x(3x!) of the max k-frame interval. of course, i could switch off vhq, but this way that some scene changes still existing are neglected. is there any other way to use the 'new' scd together with a stricktly kept max i-frame value?

thx
y

[Koepi]

Current Iframe insertation works best ever for me.

(Using usual content though.)

If you need more keyframes you have to set your limit to a shorter period - i would hate to see the final working iframe-decision which puts the keyframes on spot, even in dark scenes, broken again for inserting IMO useless keyframes.

Regards
Koepi

[yaz]

@koepi
ok ok ok ... scd is pretty good, i agree. my problem is why 'max i-frame interval' is neglected? imho, it's a different issue. or isn't it? however, if u say it's normal, i'll accept.

thx
y

[Koepi]

I'm trying to check this, but I always get iframes _before_ the max iframe interval is reached. Need a different source.

EDIT: sysKin just tested "max i frame interval" = 3 and it worked like charme... must be something special with your source i fear :( We can't reproduce that behaviour.

Regards
Koepi

[yaz]

Originally posted by Koepi
... must be something special with your source i fear :(
definitely. these videos were made as most of these home-made stuffs. somebody grabbed the camera & moved slowly round the crowd, slow zooms here & there. in general, all 'scenes' have the same character, no sudden changes, anything. (not an action movie but a sleepy afternoon in the garden, or so :-) so i'm not surprised that scd doesn't feel the need of k-f insertion. the only scene changes are the frames of camera on/off.
imho, the only way to avoid gradual degradation here is inserting keyframes regularly (i meant 5 sec). the problem is that scd overrules it somehow pushing k-fs away, up to ~15 sec sometimes.

just to make my point clear (& cut this long story short :-)
i don't think it's a seroius problem from the viewpoint of encoding quality. it's just a bug. it makes trouble only with some clips/scenes like mine. but with such 'special' sources i have there's no need to use a sophisticated scd at all.

EDIT:
- in the meantime i've made encodes quite acceptable by switching off vhq. 'old' scd worked perfectly.
- i checked some of my late encodes & i found the same 'shifting away'. ok, i just found it cus i knew what & where to look for :-) i checked 20min from a 'regular' movie & i found only 3 'displacement' out of hundreds. good rate, isn't it?

the bests
y

[kilg0r3]

@yaz - you did set the b-frame max value to >=0, right?

[yaz]

Originally posted by kilg0r3
@yaz - you did set the b-frame max value to >=0, right?
no, i don't. i've tried so far:
vhq off / mbf -1 : i-frames in place (but some is missing) max interval kept
vhq 1 / mbf -1 : i-frames only at max & nowhere else (practically, no scd!)
vhq 1 / mbf 0 : i-frames placed well, no one seems to be missing, max neglected

the bests
y

[sysKin]

Originally posted by yaz
vhq 1 / mbf -1 : i-frames only at max & nowhere else (practically, no scd!)Actually there is a thing I have to tell you all: when I created VHQ, I didn't care about max bf = -1. And I still don't :P
So assume "max bf = -1" as officially not supported by VHQ ;) which doesn't mean it won't work ;) but there might be problems with scene-change detection.
It all won't matter in version 1.0.
vhq 1 / mbf 0 : i-frames placed well, no one seems to be missing, max neglectedThat's really weird, I tried (as Koepi wrote) both my build and Koepi's build and it worked... Indeed, it's difficult to find a clip when max = 300 will be reached so I tried small numbers, like 3.

Also, there is no connection between VHQ and scene change detection with bframes active. If there is, it must be some extremely nasty bug.

Regards,
Radek

[bugsan]

psnr-table updated (page 6) with various vhq+bf tests
vhq+bf0 gives a better psnr than vhq+bf-1 :)

[sungey]

wow this thread sure is long ... :P

so now it seems the smearing in QPel that we have a while ago is not because Walken idct being not as accurate as Simple idct .. but actually caused by different idct being used for encoding/decoding?

i do alot of xvid encoding and playback using DX50 for public ... i have yet to see/hear any prob with playback since Koepi 1405 and older version used Simple IDCT and DX50 filter uses Walken IDCT. (i didnt use qpel).

So now i wonder if we will get the same Qpel smearing when using this 24062003 build and play it back using DX50. Did anyone try this yet ?

[frodoontop]

You won't have the smearing since divx uses walken idct as well.

[BoNz1]

Originally posted by sungey
So now i wonder if we will get the same Qpel smearing when using this 24062003 build and play it back using DX50. Did anyone try this yet ?

You mean through ffdshow or the DXN DivX decoder? I assume you meant the later since the first wouldn't probably make any difference at all. The reason why you don't want to play qpel encoded movies in this decoder is because of a very very nasty effect, I suppose it is some sort of chroma shift much worse than any smearing. I can post some screenshots of it if you like.

[U977]

Hi all,

I did my second encode using Koepi's 24062003 build.
Movie: PAL progressive, 25 FPS, A.R. 16:9, about 1h40 long.

Quick settings summary:
2 passes
Motion search precision: Ultra
Qantization type: H.263
FourCC: XviD
VHQ = wide search
Max I-frame Interval: 250
Min I-frame Interval: 1

Checkboxes: Chroma motion enabled, all the others (Qpel too) disabled.

B-frames used, with settings 2/150/75/0.

DX50 B-VOP compatibility checked.

In the debug options: Chroma optimizer is used, Trellis R-D quant not used.

All the rest was left to default, except:
Below i-frame distance: 13 (accordingly to Snowbeach guide)
i-frame bitrade reduction: 25

Also, since I was going to a 2CD rip, with a res of 704x(something I forgot), and since I had a high bitrate, I've selected "playback with bias".


The resulting AVI was of very good quality (excelllent, as usual with XviD), except the last 15 minutes. At this point, I got a very surprising smearing, and many big blocks, like if I was viewing a movie encoded at res of 320 or probably even less, on a large monitor at full sceen. However, those occured in scenes with less light, but it wasn't dark, though. In scenes with a lot of light, the quality was quite OK, altough slightly less good than usual.

Playback was made with the native XviD decoding (I installed ffdshow, but I disable it for XviD 24062003 encoded movies playback).
Players: I tried with Windows media player 9, and BSPlayer.

I will test playback using ffdshow tonight, to see what it produces.

Also, I'm at work right now, but when I will have more time, I can post stats. I kept all the files produced by GKnot and XviD after the encoding.

See you later! :-)

[Teegedeck]

Did you by any chance set the starting-frame for the credits too early?

[U977]

Now that you mention it....
Usually, I just strip credits, and don't even encode them.
But here, because I had plenty remaining space left on the second CD, I intended to keep them, without even encoding at lower quality...
Glad enough with that, I'm sure to remember that I simply forgot to put the slider at the very end of the movie, leaving it as it was for the previous movie...

Wow, I just earned the prize for the most stupid post of the week!
And I thought it may have been my first contribution in testing builds...
It's because of my wife disturbing me for taking dustbins out, because of the neightbourgs loudly listening at Celine Dion' songs, it's not my fault! Please believe me! :-)
Yet, I'll hide from here for a century or two, now! lol

Think twice about checking the most obvious, first.

Thanks, Teegedeck!

[kxy]

smearing with credit is still not acceptable.

[Danzel]

from one of my encodes, i found that if you use trellis and try do your credits at very low bitrates you get smearing, but the same settings without trellis gives nice looking credits.

anyone else seen this?

Danzel.

[sysKin]

Originally posted by kxy
smearing with credit is still not acceptable. Use many bframes (5?) and high bframe threshold (50? 100?) and you'll get rid of any smearing.

Radek

[U977]

(Can't hide for long...)

It's a bit off topic, but since I hear speaking about B frames: I've read contradictory statements, at different places.

Somewhere on this forum (don't remember where. I read too many things a day to remember where I've read something), I've read that a B frame takes more disk space than a P frame. I've also read that the quality obtained when viewing a B frame is less good than the quality we have when viewing a P frame, and that when we use more B frames, it allows to save bits that can then be used to improve the overall quality. This is why B frames help to improve quality.

So, there must be something I misunderstood. Either B frames are smaller than P frames, which would allow to save bits, either there is something I really did not catch. Can someone enlighten me about B frames, please?

Thanks!

[Selur]

As far as I remember b-frames are only larger than p-frames if they only refer to one frame (not two, like it should be).

Cu Selur

[Acaila]

B-frames are larger than P-frames when you compare both at the same quantizer. Also, I believe that a B-frame that is referenced by two frames is larger than one referenced by one frame.

However B-frames are never used at the same quantizer as P-frames, but always with a higher quantizer, so that is when they are smaller and help overal quality. The fact that B-frames don't cause error propagation (like P-frames do) allow you to get away with a higher quantizer.

[yingx2]

Originally posted by Acaila
B-frames are larger than P-frames when you compare both at the same quantizer.

Should be smaller.
Did you test it?

A clip encoded with bframe control 3/100/0/255 should be smaller than a clip encoded without bframes when using quantizer mode.

[sysKin]

Originally posted by Acaila
B-frames are larger than P-frames when you compare both at the same quantizer.
Actually Bframes are still smaller, but because Pframes are bigger when Bframes are present (because they describe picture change over larger distance), the whole video is larger (not much and not always, but still).

Also, I believe that a B-frame that is referenced by two frames is larger than one referenced by one frame.Bframes are designed to reference from two frames. This always happens, but if one of the reference frames is useless (because it belongs to diferent scene, for example) Bframe doesn't work as good as expected.

[Acaila]

Originally posted by yingx2
A clip encoded with bframe control 3/100/0/255 should be smaller than a clip encoded without bframes when using quantizer mode.On my tests they were either equal in size or the one without B-frames was smaller.

Originally posted by sysKin
Actually Bframes are still smaller, but because Pframes are bigger when Bframes are present (because they describe picture change over larger distance), the whole video is larger (not much and not always, but still).I thought the extra referencing info always makes B-frames larger unless you up the quantizer.

[kxy]

Originally posted by sysKin
Use many bframes (5?) and high bframe threshold (50? 100?) and you'll get rid of any smearing.

Radek

Can this be tuned in the codec level? Instead of doing 2 seperate encodes, we can let the codec handle it in the credit encoding part.

[symonjfox]

Originally posted by kxy
Can this be tuned in the codec level? Instead of doing 2 seperate encodes, we can let the codec handle it in the credit encoding part.
Good IDEA! For example calling it "Advanced Credits Treatement" (or ACT :D ).
My idea is that credits will be threated as special, just in the second pass. For example it will be possible to change B Frames thresolds, number of max B frames, Quantizers (min,max, fixed), and so on; but the features that MUST NOT be changed will remain unselectable.

Good idea, I really hope it will be developed in the future :)

PS: Maybe extend this idea not only to credits, but to several frame selections.
PS2: Maybe an external program that join all files togheter in one shot should be nice. For example, I create 10 AVS scripts, each one will give 1 scene of a stuff I want to encode. I open VDubMod and I create 10 jobs (one for each part, one with its own settings). I let VDMod encode them separately. Then a simple program would be nice to rejoin everything togheter (ex. part01.avi, part02.avi ... partxx.avi ---> Alltogheter.avi)

[drebel]

Quote PS2:Never heard of GordianKnot's special credits treatment through trim function ? :D
Nice idea about credits.Somewhere in IRC I saw a credits part encoded by Syskin which was simply amazing!Please ,do share the knowledge with us, or ,even better ,keep it as an option somewhere in debug tab (only available space IIRC) or as a special gift with dev-api-4 ,if possible ;)

[symonjfox]

Originally posted by drebel
[B]Quote PS2:Never heard of GordianKnot's special credits treatment through trim function ? :D

I never used GKnot :D ... I always do it by myself ... manual scripting, manual encoding and so on ...

[wannabe]

Hi

I read trough the thread. I can confirm the same problem that Didée and Prettz stated about 24062003's Qpel's decode smearing. I understood that this shouldnt be a bug, just different idct: Walken and Simple.

BUT: as you advised if i playback a 24062003-Qarterpel-encoded clip in FFDSHOW (20030523 or 20030927) with "xvid iDCT" set in, it still has the same smearing problem. Yes. It only plays back flawlessly if i use 24062003 for playback. But this cant be a solution, because as yaz pointed out, i cant tell from other encodes that they made with what specific codec, so in the future these encodes would be useless if there would be no decoder that could automatically decide which iDCT to use.

And i repeat, i set IDCT to "XviD" in the Latest ffdshow, restarted the application, rebooted my machine etc, and its still bad, still has the smearing effect, altough maybe not that much as with other idct but still it looks pretty bad. And no, autoselect does not help either.

So it seems that the Walken iDCT that 24062003 uses is not compatible with ffdshow's xvid idct to me... Any ideas ?


Greetings

[wannabe]

http://www.geocities.com/werrew23/24062003_with_Simple.JPG
http://www.geocities.com/werrew23/24062003_with_XviD.JPG
http://www.geocities.com/werrew23/24062003_with_24062003.JPG


I made some still image captures on 24062003 quarterpel encoded videos playbacking with 20030927-FFDSHOW and 24062003 as decoder. I tried both Simple and XviD iDCT in FFDSHOW.

The results:

It looks like that FFDSHOW is unable to playback 24062003's quarterpel properly with any of its iDCTs. "Simple iDCT" looks very bad, "XviD iDCT" is a little bit better, but still not as good as 24062003 with 24062003.


Conclusion: FFDSHOW's XviD iDCT is not compatible with 24062003 iDCT.


PS: Pls see for yourself, but dont open the pages too many times because geocities transfer is limited for every hour, and i couldnt attach the pictures to the message because its not allowed anymore.

If the .jpgs wouldnt load first, hit CTRL+F5 a few times, geocities is slow...