@ -h: JVT style pre-postprocessing in Sigma?

[tanksimpson]

In a post discussing the RealVideo codec, you said:

"I don't think they're doing anything radically different from MPEG traditions, they're just forcing post-processing to *always* be on, and having it affect reference frames during encoding, ala JVT:

- Encode frame with usual DCT/quantization
- Run post-processor over encoded frame to remove "mosquito noise"
- Use the post-processed frame as the reference frame for the next frame, so that we refer to a smooth, post-processed image (instead of the blocky image as in MPEG1/2/4)

It can do wonders for image quality, which is why the finalised MPEG4 video spec (which is what JVT is contributing to) will include it, as well as a whole heap of other nifty compression methods."

In my tests using the new Sigma MPEG4 codec, I've noticed what apppears to be evidence of post-processing by default. Wishing to see what the results looked like without postprocessing, I changed the FourCC to "DIVX", because I've got DivX 5.02 set up so that all post-processing is turned off. To my surprise, the Sigma encoded video still appears to be post-processed when played back in this manner! I'm curious - what do you think?

[TheXung]

I guess we're allowed to talk about this codec again since we haven't heard anything from the XviD crew on it for days.

From further testing, I'm pretty sure, sigma doesn't force any post-processing on you. It is straight up Xvid code. If there was post-processing, it wouldn't encode so fast.


My earlier belief that sigma has incorporated 1/4 pel is incorrect. The reason why my screenshots of the sigma codec were more detailed than xvid or divx is because virtual dub could only show the p-frames in a sigma clip, and for some reason, their p-frames were always larger than the other two codecs

[Koepi]

@TheXung:

You're still not helping when discussing sigma's codec. Please, don't behave childish - you'll notice when the situation about that clears up. Don't spread rumours!

*grmblfx*

@tanksimpson:

Well, your test is really *caugh* invalid.
You can't force DivX5.x to use _no_ postprocessing. It's always on.

Try e.g. XviD FourCC - there you can switch off the postprocessing. Or use ffdshow for playback.

Regards,
Koepi

[tanksimpson]

@Koepi: well, I searched the DivX.com website looking for information backing up your claim that you can't turn off postprocessing in DivX and this is what I found under the "Post-Processing" section of their guide.

"To cater to users' post-processing preferences, 6 different levels of post-processing have been defined. At the minimum (level 0), no post-processing algorithm is used;"

Look for yourself at http://www.divx.com/support/divx/guide.php

If you have documentation supporting your claim of hidden post-processing in the DivX codec, please show it to me so I can be enlightened :)

Furthermore, I would love to use XviD for my decoding, but I was under the impression that it didn't support B-frames. Doh! We're not supposed to talk about that either. I will give ffdshow a try, thanks for the tip.

Finally, am I to understand that there is no hope in discussing the technical issues surrounding the Sigma codec? Those are the issues that concern me, not political issues. If the XviD developers really think that there has been a GPL violation, they should simply post a submission to slashdot.org titled "Sigma Designs Inc rips GPL'd code from XviD project?" - believe me if somebody did that the issue would be cleared up VERY quickly. Then we could get back to discussing the codec on its own merits. All this sneaking around makes me wonder if the XviD developers have a secret agenda, like maybe they want to use the GPL to pressure Sigma into make some kind of monetary "compensation" to the XviD project.

[-h]

Just noticed this thread - I don't read other forum areas too regularly (or the forum at all lately, been a tad busy).

Technically, a simple-profile MPEG-4 video stream couldn't be using post-processing in the sense you mean (i.e. force it before compensation), so no that's not what's happening. Playing with ffdshow (or lowering the bitrate to expose blocks) should demonstrate this.

As for all this Sigma stuff, it's being kept low-key for a good reason - blowing everything open and throwing allegations around could do a lot of damage. If some wrong has been done (which is still being looked into, keep in mind), why not handle it quietly, tactfully and actually get it resolved? There's no need for a big glaring spotlight and loudspeaker, that should only be the last resort in any dispute.

-h

[tanksimpson]

"Lowering the bitrate to expose blocks" produced the results you predicted - the it did not appear that any attempt had been made to "smooth" the blocks. I could not really tell a big difference when using the ffdshow w/postprocessing disabled and the DivX decoder, either. Ffdshow does have lots of *sweet* options BTW, thanks! There must be something about Sigma codec's design that makes for a blurry, "post-processed" look even at the high bitrates I usually use (1500-3000 kbps). At *really* high bitrates (4000+ kbps), Sigma crashes(!) VDub, hopefully Sigma will come out with an improved version after this mess gets sorted out.

[Koepi]

Originally posted by -h

As for all this Sigma stuff, it's being kept low-key for a good reason - blowing everything open and throwing allegations around could do a lot of damage. If some wrong has been done (which is still being looked into, keep in mind), why not handle it quietly, tactfully and actually get it resolved? There's no need for a big glaring spotlight and loudspeaker, that should only be the last resort in any dispute.

-h

tanksimpsons, do you actually READ what's in those posts?

Thanks for respecting this in future.

Regards,
Koepi

[tanksimpson]

@Koepi: although your comments have absolutely *nothing* to with the visual quality issues I asked -h about, since you asked me a question "do you actually READ what's in those posts?", I will be happy to answer you. Yes, I have read the posts, including all the posts regarding this codec where the thread was locked and the poster was redirected to other threads... which are also locked! Has it occurred to you that people might have something to say about this codec that has *nothing* to do with the XviD licensing issue? How does discussing obscure technical issues about this codec have ANY effect whatsoever on the issue with the XviD developers? If I had wanted to talk about XviD, I would have posted in the XviD forum, but this is the New A/V Formats forum, isn't it? As far as I can tell, YOU are the person having the threads locked and making a big deal about this, otherwise I doubt anyone would care to discuss this issue at all! Did you actually READ my post? - I believe my point is already made.

[avih]

Originally posted by tanksimpson
@Koepi: although your comments have absolutely *nothing* to with the visual quality issues I asked -h about, since you asked me a question "do you actually READ what's in those posts?", I will be happy to answer you. Yes, I have read the posts, including all the posts regarding this codec where the thread was locked and the poster was redirected to other threads... which are also locked! Has it occurred to you that people might have something to say about this codec that has *nothing* to do with the XviD licensing issue? How does discussing obscure technical issues about this codec have ANY effect whatsoever on the issue with the XviD developers? If I had wanted to talk about XviD, I would have posted in the XviD forum, but this is the New A/V Formats forum, isn't it? As far as I can tell, YOU are the person having the threads locked and making a big deal about this, otherwise I doubt anyone would care to discuss this issue at all! Did you actually READ my post? - I believe my point is already made.

@tanksimpson and everyone else:

tanksimeon, you are right, the referenced threads are closed. i was not aware of that point, but atm of writing they were open, and they were referenced to show that the subject has been discussed, after a claim it wasn't.

now, we have a gentle situation here. as pointed by -h (an xvid developer) and other xvid developers, the issue of this codec is beening handled gracefully. eventhough some of the discussions on this subject are of strict technical nature, NON xvid related, we (the forum team) think that such discussions would make a hype of this codec that will essentially lead to xvid questions as well, if not by you, then by others. since we would like to respect the xvid team and keep this issue quiet for a while, we just want to kindly request the members of this board to 'forget' about this codec for a while. we WILL post any new information that we have. we're probably talking about few weeks here.

now, i'm NOT closing this thread, since i don't think that stopping ppl from expressing their oppinion is the way to go. however, i DO request that you to try and keep a low profile with this subject.

your oppinions/thoughts on this matter are very welcome. and there's NO need to get angry, ok ppl? ;)

cheers
avi

[tanksimpson]

Thank you, avih, for being forthcoming with a logical explanation for the policy regarding the Sigma codec. I still don't agree with it, but I promise not to post any new threads on the doom9 forums regarding this codec until the "coast is clear", so to speak.