Does SixOfNine-HVS produce artifacts with ffdshow?

[jk888]

Hi this message is for Didée, thx alot for providing us with the new SixOfNine-HVS custom matrices, it's really awesome. It seems to create sharper scenes than HVS-Best, and smooth out grain. But unfortunately it also produces artifacts in high contrast light and dark scenes.

http://randy.abstractstudios.ca/JK888/SixOfNine-HVS/Capture1.jpg

http://randy.abstractstudios.ca/JK888/SixOfNine-HVS/Capture2.jpg

http://randy.abstractstudios.ca/JK888/SixOfNine-HVS/Capture3.jpg

http://randy.abstractstudios.ca/JK888/SixOfNine-HVS/Capture4.jpg

[jk888]

Sorry I found out what was wrong, the one I downloaded was posted by ViCroié and he had ANOTHER typing error in the matrices. In the intra matrix, 3rd one from the bottom was another typing error, he had 118 and it was suppose to be 18. I'll re-encode with the fixed version and see what the results are.

[BoNz1]

Likely you will have the same problem. Please do a search next time you will find this has happened to others as well. It happens when there are numbers in the matrix smaller than a certain number I'm not sure what number it is but do a search and you will find out. ffdshow doesn't play it properly. Use the XviD decoder and you will not get these artifacts.
EDIT: Didee said it shouldn't produce artifacts with ffdshow. Try fixing that value and make sure that no others are wrong ;).

[jk888]

I think you misunderstood what I said. Read this thread:
http://forum.doom9.org/showthread.php?s=&threadid=71881&perpage=20&pagenumber=2

SixOfNine-HVS is a new one that Didée just recently released, but he didn't post the matricies, he just typed it out in his post. ViCroié later posted the matricies that he copied from what Didée typed, but he made a mistake and had a typing error which was way off (118 instead of 18).

[BoNz1]

No I didn't misunderstand; notice my EDIT :). I understand what happened I did read Didee's post. I would try it with the XviD decoder if you can't get it to work after you fix that value. If it works there and it doesn't work in ffdshow then someone needs to tell Didee that it still produces artifacts in ffdshow. Or someone could fix ffdshow so it doesn't have this problem any longer :rolleyes:

[Didée]

Oh-oh, what's that ...

From how those artefacts look, I cannot tell for sure if this is the "normal" ffdshow bug, or if it's caused by that wrong 118 component.

Most of those artefacts seem to appear in the bottom part of a frame. This could be caused by that wrong 118 value, since that value is located in the highest-vertical-frequency area of the matrix. So it's possible that the sharp transition between video and black border got coded by that particular component, thus created blocking, which then travelled its way into the frame.

OTOH, there are artefacts, like e.g. in the face of that guy, that seem to have no relation to that, and look just like the "normal" ffdshow bug.

It should be noted that the ffdshow bug seems to appear when the codec uses intra blocks within a P-frame. That's why the bug almost always appears in medium/high motion parts.

All I can tell is that personally, I did not experience any problems with SixOfNine-HVS & ffdshow so far.

Some questions, jk888:
(superfluid, if the artefacts disappear with the corrected matrix)

- do such artefacts appear in lo-mo parts also ?

- are there perhaps hidden scene changes just before these artefacts appear? (scenchanges that should have coded as I-frame, but actually got coded as P-frame)

- are these frames coded with quant=2, or does the artefacting start with a quant=2 frame?

- was adaptive quantization used? If yes, turn on "show quants" in ffdshow's "visualizations". What are the lowest numbers appearing then, resp. the numbers for the macroblocks where the artefacts get initially created?

- what happened with the corrected matrix?


jk888, I'm looking forward to your report after re-encoding with the corrected matrix, thanks.


- Didée

[ViCroié]

Hey,

I dont really understand, I know about that 118 typo
I corrected it the day after
If its not uploaded right or anything..
plz tell.
Works fine here...

and these screenshots where prolly not cuz of that 118... ive encoded allot of clips in that 118... (when i didnt notice mistake) all i saw was allot of blocks around edges and stuff...

JK888: "ViCroié and he had ANOTHER typing error"
what other 1 are you talking about here?
it was only the 118... as far as i know

[jk888]

Hi guys, sorry for the confusion, but yes bonzi you are correct, the artifacts still appear even after I fixed the 118 typo and re-encoded. The exact same artifacts appeared in the exact same manner on the same scenes, so I guess the 118 typo didn't really affect anything.

And yes I think it is related to ffdshow, cause when I watched the same scenes with the xvid decoder there are no artifacts. I used an older stable version of ffdshow that came with the Matroska driver pack, I think the build was 05/23/2003.

To answer Didée's questions:
-the artifacts appeared in lo-mo scenes, all the screen shots were relatively lo-mo.
-hidden scene changes? I have no idea what it is.

Here are the encoding settings I used:
QP
GMC
Max Consecutive B - 2
ratio - 1.5
offset - 1
Closed GOV
Motion Search Precision - 6
VHQ - 4
Chroma Motion
Min I-Frame Quantizer - 1
Max I-Frame Quantizer - 31
(same max and min for P and B frame)
Trellis Quantization
Rate Control Weight - 1

Adaptive Quantization wasn't used.

Hi ViCroié, sorry I didn't mean to make a big deal of the typo, I think there were 2 typos, 184 and 118 as mentioned in that other thread. Anyways the typo wasn't the cause of the artifacts

[P0l1m0rph1c]

Err...you really shouldn't use Trellis quantisation along with a custom matrix, you know...

[BoNz1]

Originally posted by P0l1m0rph1c
Err...you really shouldn't use Trellis quantisation along with a custom matrix, you know...

Why? There is nothing wrong with that. It is just that ffdshow bug that is causing this. Maybe someone should make a test file and upload to mplayer/incoming and then post to the ffmpeg mailing list about this problem, it really should be fixed. It is most annoying.

[jk888]

I tired the same movie with the latest version of ffdshow, build 03/04/2004, still same artifacts in the same areas.

I can use virtualdub to cut the scenes out and upload them for review. But who should I upload them to?

[sysKin]

jk888, are you sure you haven't used your own, buggy xvid build? GMC was broken for three days, and it looks like this GMC bug. If you're using custom, or Gamer's, build, make sure to update the buggy code - it's fixed now. It was also OK in RC3.

Radek

[ViCroié]

Hey

To JK888: nah it was only 118... :P

[jk888]

The one I used was RC3 build 02/29/2004. Should note that artifacts don't appear when using the Xvid decoder, only appears when ffdshow is used.

[Didée]

In the last hour, I tried to make some stress test encodings. I used 6of9-HVS along with quant2, quant1 (!), with/without adaptive quantisation, with/without GMC, all VHQ settings, with/without cartoon mode, on lo-mo and hi-mo ... just everything I could think of.

XviD was 1.0-RC3, ffdshow for playback was 25-03-03.

Result:

Not one single artefact *), just like in the some hundreds of enncodings I did before with it.

Me shrugs shoulders. Works perfect for me everytime, what else to say?

BTW, the thread title is a little disturbing, to my taste. Could perhaps the thread title be put as a *question* : "Does SixOfNine produce artefacts with ffdshow?"


- Didée


*) There is some block-flickering going on with quant-1, both in ffdshow and XviD-DS. Nothing like shown in above screenshots, more like the block-flickering XviD had when it initially learned to speak "B frame".

[jk888]

I uninstalled every single codec from my PC, then I install Xvid RC3, ffdshow 25032003, and then did some test re-encoding for the same movie. Results:

SixOfNine-HVS still produces artifacts when watching it in ffdshow, artifacts are gone when watching it with Xvid decoder.

I used the same settings but this time choose the HVS-Best matrices and no artifacts appeared regardless of decoder I used.

There is something going on here, if you want I can cut out some scenes and upload them to you (Didée) for review.

[Didée]

*** browser went crazy ***

[Didée]

If you manage to cut out something of reasonable size, I'll inspect it, no problem. I'm still behind a 56k modem, see ... a sniplet in the range of 1~2 MB is okay, and up to 4 MB, I might perhaps still bite into that apple.

For the time being, try to set the "12" in the upper-left corner of the inter matrix (the matrix on the right side) to "16".

That should be sufficient to circumvent that bug of libavcodec. However, I don't like that setting too much, as it may produce sub-optimal results on flat-colored surfaces, or in scenes with very little contrast (dark scenes, scenes playing in fog, underwater scenes, etc.)

- Didée


P.S.

Is anyone else getting artefacts with 6of9-HVS ??

[iago]

Originally posted by Didée
Is anyone else getting artefacts with 6of9-HVS ?? No! And I like it a lot. ;)

[jk888]

Ok I got some clips down real small, around 1-3mb, if anyone wants to check them out you can find them here:
http://randy.abstractstudios.ca/JK888/SixOfNine-HVS/

The clips I encoded with SixOfNine all have examples of the artifacts, the exact same scene equalivent I encoded with HVS-best are included as well. You can compare the 2 matrices with these small clips using ffdshow decoder and Xvid decoder. The first 2 clips are the best examples of the artifacts.

The clips were from Hong Kong movie Infernal Affairs 3 original DVD.

[Didée]

iago:

:)

Oh, and, ... MILLENIUM POST !!!

We are awaitening the invitation to the big party! :D


jk888:

Am Downloading. Let's see if something springs into eye.


- Didée

[iago]

Can it be the weird mod 2 height? 672*378 !!!

[Didée]

Yep, that could be part of the puzzle. MOD2 heights seem always intriguous.

However:

- HVS-best *does* play fine with ffdshow
- 6of9 *does* play fine with XviD DS

So it seems that 6of9 <--> ffdshow don't play nicely here.

Observations:

- The artefacting seems always to be initiated by GMC frames!

jk888, could you please try the following, each seperately, on one of those scenes:

1. Resize to MOD4 vertically
1a dito to MOD8
2. Disable GMC
3. Crop away the black borders at top&bottom

There were some little changes to GMC code recently, perhaps something can be adressed there, particularly in relation to the MOD2 height.

Quick notes, encoding-wise:

- The codec's overall efficiency drops with resolutions of MOD4 & MOD2. Try to not go below MOD8 if anyhow possible!

- I suppose that the efficiency of GMC drops very noticeably if you leave those black borders. The codec trys to transform the picture geometrically, but those static black borders will most likely screw most senseful decisions.


If syskin is reading this, perhaps he should have a look into it?


- Didée

[jk888]

You'll have to give me a few days worth of time for the re-encoding. Also can you please explain what you mean by MOD2 MOD8 etc... I don't know what it means, I usually enter in a resolution like 672x378 (16:9 widescreen) for my avs script. I'm gonna need time to learn how to crop stuff as well...

[Teegedeck]

MOD4, 8, 16 etc. mean that your horizontal and vertical resolution can be divided by 4, 8 or 16. Your chosen horizontal resolution (378) cannot even be divided by 4 and this triggers the problem. It's got to do with the size of macroblocks in XviD. AFAIK XviD can work around odd-resolution problems but it's better not to do it anyway. Generally MOD16 also yields marginally better compressiblity, so you should perhaps try to reach that if possible. You can configure GKnot to output only MOD16 resolutions and keep aspect-ratio error at a minimum at the same time.

[Chainmax]

Will the SixOfNine-HVS matrix be included in the next codec release?

[malkion]

6of9-hvs works fine for me without artifacts. I use dctfilter() with all my encodes so stick with mod 16. for 1.78:1 I stretch to 1.85:1 and encode at 640x352 which isn't quite 1.85:1 nor 1.78:1. funny. I also do 2.35:1 at 640x272, again safely mod16 and no artifacts. I'm pretty positive mod means divisible by. mod16 is as low as I safely play with, avoiding mod8,4,2. Good luck with your settings, jk888, hopefully the artifacts will disappear

[jk888]

I was pretty busy lately, but I did a quick test encode with no resize. The results? No artifacts!!! You were right guys, it was related to the resize! I'll do some more tests on the weekends and update this thread with the results. But I'm pretty sure we got it figured out.

[jk888]

I did alot of extensive testing and found that changing the resolution so that it's mod 4, 8 or 16 does not solve the artifacts problem. Nor does cropping the video fix anything. So we're back to square one.

Here's my script for Video 1 (cropped):
LoadPlugin("F:\AviSynth 2.5\plugins\mpeg2dec3dg.dll")
LoadPlugin("F:\AviSynth 2.5\plugins\Decomb511.dll")
mpeg2source("F:\DVD2\test.d2v")
FieldDeinterlace(blend=false)
Crop(4,8,-4,-8)
LanczosResize(624,416)

Here's my script for Video 2 (non-crop):
LoadPlugin("F:\AviSynth 2.5\plugins\mpeg2dec3dg.dll")
LoadPlugin("F:\AviSynth 2.5\plugins\Decomb511.dll")
mpeg2source("F:\DVD2\test.d2v")
FieldDeinterlace(blend=false)
LanczosResize(624,416)

Pictures of Video 1 (cropped):
A small clip of the picture (2.7mb) cropped1-clip (http://randy.abstractstudios.ca/JK888/SixOfNine-HVS/cropped1.avi)
http://randy.abstractstudios.ca/JK888/SixOfNine-HVS/cropped1.jpg


2nd Picture from Video 1 (cropped):
A small clip of the picture (2.0mb) cropped2-clip (http://randy.abstractstudios.ca/JK888/SixOfNine-HVS/cropped2.avi)
http://randy.abstractstudios.ca/JK888/SixOfNine-HVS/cropped2.jpg


**************************************************************************
Pictures from Video 2 (non-crop):
A small clip of the picture (2.8mb) non-crop1-clip (http://randy.abstractstudios.ca/JK888/SixOfNine-HVS/non-crop1.avi)
http://randy.abstractstudios.ca/JK888/SixOfNine-HVS/non-crop1.jpg


2nd Picture from Video 2 (non-crop):
A small clip of the picture (2.4mb) non-crop2-clip (http://randy.abstractstudios.ca/JK888/SixOfNine-HVS/non-crop2.avi)
http://randy.abstractstudios.ca/JK888/SixOfNine-HVS/non-crop2.jpg


Just like last time artifacts will only appear when played using ffdshow, when played using the Xvid decoder everything is fine. I am at a complete loss at why this happens, and can only conclude that SixOfNine-HVS still produces artifacts with ffdshow. Which is to blame? I am not sure but I am guessing that it could very well be ffdshow's fault because the Xvid decoder plays everything fine.

If everyone agrees with the results then I will post a message in the ffdshow thread to let them know about it.

also here is a link to the SixOfNine-HVS matrices I am using SixOfNine-HVS (http://randy.abstractstudios.ca/JK888/SixOfNine-HVS/6of9-hvs.txt)

[Didée]

Hello.

In the meantime, I found something interesting, too ... but first:
Which is to blame? I am not sure but I am guessing that it could very well be ffdshow's fault because the Xvid decoder plays everything fine.
That was clear from the very start. There is nothing wrong with SixOfNine, because ... there simply is nothing wrong with it. Everything within it is perfectly correct and allowed.
The only question is, and ever was, *if* *ffdshow* can handle that matrix, or not. So, in any case:If everyone agrees with the results then I will post a message in the ffdshow thread to let them know about it.
You would only bring old news. This very problem is known for a very long time now, for a year or two ... (however, a reminder really could not hurt ;) )

Then, I was tempted to say: "No, I do NOT agree with the results." Because, as already mentioned, I did hundreds and hundreds of encodings with SixOfNine, without get one single of these specific artefacts ...
... until yesterday. Yesterday I DID get such artefacts, in one specific scene.

And now, please follow me closely!

Of course, I do always crop my videos properly. There are never any black borders in it, perhaps a pixel or two in _very_ seldom cases. And I _never_ did get artefacts.

Yesterday, I got these artefacts for the very first time. They appeared directly after a scenechance (which correctly got an I-frame, btw.).
And it just turned out, that the source was badly mastered, because after the scenechange the video was misaligned and had an additional border of ca. 16 pixels at the top!, which of course then was in my video also, because I didn't notice the misaligning beforehand.

And in exactly this place I got these artefacts for the very first time!

Therefore, jk888:
If you want to safely use SixOfNine with ffdshow, then you must *completely* crop away *all* of the black borders. Your "little cropping" anyways was so useless as anything ... either one crops away the black bars, or leaves them (which is generally a bad idea for mpeg-4). Just cropping "a little" into black borders is like cutting away a minor part of a tumor ... it doesn't help anything ...


However, here I stand, greatly astounded about this "border-related ffdshow/QuantMatrix" bug ... :confused:


- Didée

[jk888]

Hi Didée, glad that you still helping me with this issue, support and feedback is great. As for the cropping, I swear I cut out all the black borders, I used AVSedit and it shows the cropping of the movie on screen. My source was good too, they're all from retail DVDs I bought, all imports and special editions too, unless it's a problem with Asian DVDs. Well I'll do more testing in the future as well, maybe I'll discover more things in the long run.

[Kurosu]

Check my post here (http://forum.doom9.org/showthread.php?s=&threadid=48511&perpage=20&pagenumber=37#post460557) for maybe an idea where the so-called 'bug' comes from. Beyond that, it's all a matter whether Michael Niedermayer and co followed that annex(was: want to closely follow specs), or not. But knowing they tend to support on-the-fly detection of known bugs, at least they would (was: will) more likely accept to add support for that "XviD bug" than fix a "ffmpeg bug" (was: "ffmpeg bug yet to proove"). :)

[jk888]

I'm not if this means anything, but I did some more testing, I used a different resolution and also change my target file size by 10mb. My new script looks like this now:

LoadPlugin("F:\AviSynth 2.5\plugins\mpeg2dec3dg.dll")
LoadPlugin("F:\AviSynth 2.5\plugins\Decomb511.dll")
mpeg2source("F:\DVD2\test.d2v").ConvertToYV12()
FieldDeinterlace(blend=false)
Crop(4,8,-4,-8)
LanczosResize(648,352)

What I found out for the first time ever is that the artifacts will appear in different scenes than with my original encode. Areas in the original encode that are full of artifacts now don't have any, and scenes that were fine are bad now. I think it means that the problem isn't related to particular frames.

[Soulhunter]

Originally posted by jk888
What I found out for the first time ever is that the artifacts will appear in different scenes than with my original encode. Areas in the original encode that are full of artifacts now don't have any, and scenes that were fine are bad now. I think it means that the problem isn't related to particular frames. You have used 2Pass encoding... :rolleyes:

So, your changed resolution n' target filesize changed the quantization also !!!


Bye

[jk888]

Seems the guys at ffmpeg finally fixed the artifacts bug with 6of9-hvs. I received an email today saying the bug report I submitted had the status changed to "fixed". Look here for the details:

https://sourceforge.net/tracker/?func=detail&atid=116082&aid=918736&group_id=16082

The only details I got was from this line: "Last Updated By:
michaelni - Settings changed".

Nothing else was said, so is it safe to assume that the bug is fixed? Shall we start the celebrations and notify the ffdshow team?

[jk888]

This issue is now fixed! The latest version of ffdshow (ffdshow-20040501) plays all of the sample encodes without any artifacts at all. Hurray! Now I can finally do all my encodes with 6of9-hvs!

[Didée]

... or with any other high-BR matrix holding an inter DC cell < 16.

AMEN!

;)