VSS Codec and H264

[ales19]

anyway i think the h264 project on sourceforge gives better results as for quality... maybe 'cos you actually have control over more settings and stuff...

[midiguy]

in-loop filtering is not post-processing (or pre-processing for that matter). "Normally", when you don't have enough bits to compensate for the sharpness/details in the picture, you get blocks and artifacts. with in-loop filtering, you get blur. RV9 uses in loop filtering, but the only trouible with that is that the realone player also POST-processes to hell, which gives the video a bad effect (but they say that they are planning to give us control over the PP soon!)

[molerus]

Hi!

I have done some further tests with the VSS and found out, that the most efficient and good looking encoding one can get using Normal speed. With the slowest+b-frames the video was couple % smaller but it looked shitty. Moreover the spped is fairly ok (only 7 times slower than XviD:p ).
As it was said it seems that smooth picture I have mentioned is due to preprocessing aided by the motion estimation.
Also I have read on the VSS codes web page, that it can acept variable parametrers during encode and it leads us to a software which could compress with two pass VBR!!!.

It seems that all I need to do now is to buy a new processor:sly:

[Sirber]

@molerus

Did you use H264 or VSS?

[molerus]

H264, VSS was giving me incredibly large files, like with uncompressed video:confused:

[molerus]

Hi!

New version Beta 2 on

http://www.vsofts.com/codec/h264_download.html

Have fun!!:p

[Selur]

Thx for the info :)

Cu Selur

[Sirber]

What's new in Beta2:

* Improved rate control
* Updated Codec Settings dialog

[gino25]

In my opinion it is faster.

[deXtoRious]

Could someone suggest which quantizer (h.264) should I use to get an equal to 800kbps xvid? Thanx :D

[Sirber]

I don't think so.

1) To have best quality, it's 1 frame per 3 seconds on a 2GHz
2) You need a 2GHz+ to decode a H264 stream at full speed
3) It's still alpha, uses XviD or RV9.

[haibane]

I just tried the VSS h264 to encode a clip about 35000 frames long...
with setting of slow, quant = 26, max keyframe interval=240
one problem I noticed is that eventhough the setting let me set the max KF interval, but it's actually the KF interval, i got a KF every 240 frames, it seems like the code still can't detect scene changes and insert KF acording to it. So, some times I will get a blocky picture before a scene change, especially when there is a big difference in luma between the two scenes.
But according to the description, this codec has scene change detection, and max keyframe interval implies the codec can automaticly insert KFs at scene change, or otherwise it would just say keyframe interval. I was wondering is this someting that is just still not implemented in the codec or it's just a bug......

[Sirber]

Use the defaults, a keyframe at each 30 frames. Also you can use the rate control. At 30 kf, there is no blocks.

[ales19]

Originally posted by Sirber
Use the defaults, a keyframe at each 30 frames. Also you can use the rate control. At 30 kf, there is no blocks.

well of course at 30kf theres no blocks, 30 frames is actually about 1 second and i seriously doubt you have scene changes less than every second.. besides even if the scene change is just after a keyframe there is just about a second before a new one is put in so you _allmost_ wont even notice blockiness... the issue (which i noticed too) is when you use a bigger length between the 2 kframes (which is btw 255), thus leaving you much more time (nearly 10 seconds and a lot of frames) to notice it :)

[Sirber]

VSS Codecs don't detect scene changes. Keep it at 30 and live a happy life :)

[ales19]

Originally posted by Sirber
VSS Codecs don't detect scene changes. Keep it at 30 and live a happy life :)

r u sure? i thought they did.. maybe i got mixed up with some other codec.. ill go read the codec specs on the site tomorrow... 'cos if youre right, 30 frame interval is the safest way to go :)

[slavickas]

Originally posted by ales19
r u sure? i thought they did.. maybe i got mixed up with some other codec.. ill go read the codec specs on the site tomorrow... 'cos if youre right, 30 frame interval is the safest way to go :)

i think they say that it supports, but actually it don't see in vdub

[Tommy Carrot]

I you're using quantizer mode instead of rate-control, there won't be such problems after scene-changes (although the codec doesn't identify the scene-changes indeed).

Setting keyframes so frequently is a huge waste of bitrate. Keyframes are much larger than the predicted ones.

[deXtoRious]

TO: Sirber

I'm asking this to you because our computer configurations are identical (except that my DDR RAM is 400Mhz, but I don't think it matters much). Can you decode h264 video normally? For me it jerks and is totaly unenjoyable :( So why encode in a format that you cannot watch (without multiprocessor parallel supercomputer systems, at least ;))?

[Sirber]

@deXtoRious

For encoding at Low, it 0-1FPS. At playback, the stream hang for 0.2 ms at keyframes ans uses 100% CPU.

H264 isn't for encoding real stuff, just for testing now. It's unoptimized and slow like hell (hell is slow?).

[sam_b]

@deXtoRious

If you RAM is running asynchronously to your FSB (133mhz) at 200mhz, then this will likely cause significant slowdown. 133 (DDR266) will be faster if you have an Nforce2 and 166(DDR333) is likely to be faster if you have a KT400.

Apologies if you have unlocked your multiplier and are in-fact running in sync, but if you havn't then this might make the difference.

[deXtoRious]

2 sam_b

My RAM is running syncronously with my FSB thanks to some advanced overclocking experiments during witch I almost burnt my CPU :D However, I didn't quite understand one thing: are you saying that 333Mhz RAM might actually be better than 400Mhz (with KT400)?

2 Sirber

Are any optimizations of the decoding (the encoding doesn't matter so much, I've got time) algorithm going to occur in a reasonable period of time or do we have to simply live with what we have and be happy (well, not very :()?

[ProfDrMorph]

Originally posted by deXtoRious
However, I didn't quite understand one thing: are you saying that 333Mhz RAM might actually be better than 400Mhz (with KT400)?
As sam_b said: when your RAM runs asynchronously to your FSB you will slow down your system ( due to added latency because your RAM can't transmit requested data since it's waiting for the CPU ( FSB ); systems with a CPU and RAM that run synchronously won't have that latency because the RAM will always try to transmit just in time when it's possible ).

[Sirber]

Originally posted by deXtoRious
2 sam_b
Are any optimizations of the decoding (the encoding doesn't matter so much, I've got time) algorithm going to occur in a reasonable period of time or do we have to simply live with what we have and be happy (well, not very :()?

I think VSS release new versions (I need water) at each 2 or 3 weeks. But, for what I know about VSS, all their codecs are made for demonstration and uses ~100% CPU for decoding. They want to sell their codecs for specialized hardware, so it's not well optimized now.

This is what I think and may be far from truth (vérité in french...)

[alexcyn]

slavickas is right - VSS H.264 Beta does not have scene changes detection, it is planned only for final release.
VSS Codec 1.3 does have this feature, but internally - i.e. when scene change is detected all macroblocks are compressed in "intra" mode, but it does not mark frame as a "key frame".
Do you think it is really needed to set frame type to I in this situation?

[ProfDrMorph]

Originally posted by alexcyn
slavickas is right - VSS H.264 Beta does not have scene changes detection, it is planned only for final release.
VSS Codec 1.3 does have this feature, but internally - i.e. when scene change is detected all macroblocks are compressed in "intra" mode, but it does not mark frame as a "key frame".
Do you think it is really needed to set frame type to I in this situation?
Yes because this information can be used to improve seeking speed.

[deXtoRious]

2 ProfDrMorph & sam_b

I am well aware of this, what I wanted to know was if this latency was big enough to make significant impact on the overall performance of the system.

2 Sirber

I do sincerely hope that you are wrong, for I am really looking forward to someday playing h.264 video normally, it could become the single best video codec yet with just a little bit of optimization...:rolleyes:

[ProfDrMorph]

Originally posted by deXtoRious
I am well aware of this, what I wanted to know was if this latency was big enough to make significant impact on the overall performance of the system.
The only numbers I have is that 400MHz (2x200) DDR RAM performs worse than 333MHz DDR RAM in current systems.

[Ramirez]

Originally posted by deXtoRious
[B]
My RAM is running syncronously with my FSB thanks to some advanced overclocking experiments during witch I almost burnt my CPU :D

Hmmm...Are you actually saying that you're running your system at 400 FSB?
And the whole thing running rock stable?,Very strange. Are you using Azot cooling or something?

[Sirber]

mine is at 266 MHz... maybe he has a Pentium 4. P4 are at 533 I think...

I also think I'm gonna get some sleep :D

[sam_b]

I apologise for dragging this slightly off-topic but...
Synchronous 200fsb is quite possible given a bit of luck and good ram. Fairly easy in some cases. NO VIA chipset supports DDR400 officially, KT400 included. Even when running synchronously, VIA chipsets often increase latencies to maintain stability at high FSBs, and so a 200FSB is not necessarily faster. Asynch is definately slower with DDR400. With your processor, a 200fsb will not make that big a difference over a 166fsb, so don't bust a gut to get it.

Hope this straightens some stuff out, and that some way of decoding this codec properly is found.

[Ramirez]

Ofcourse it's possible but still there is no way in hell you can run it stably.Even such an excellent overclockers group as guys at overclockers.ru couldn’t do it,IIRC The best result they've managed to achieve was something like 185x2-370 FSB and still they
couldn't get it to run smoothly w/t some add tweaks.

Nevermind,the whole story is most likely a fiction anyway, but hey I'd be the First to say congrats to this guy if I'm wrong though. Perhaps he'll find a way to post Some WCPUID screenshots?.
AND NO ADVANCED PICTURE EDITING EXPERIMENTS ON WCPUID'S SCREENSHOOTS PLEASE.:D

[deXtoRious]

Sorry for the fuss, I was wrong myself. My FSB is running at 332Mhz (2x166). I was using some weird information tool coded by a friend of mine, which for some reason reported my 400Mhz RAM instead of my FSB! Now I double-checked it in CPU-Z and the result is 332Mhz. I had to put to additional coolers to get it working stable and it was a lot of trouble so I don't really recommend anyone to try it (unless you're a real hardcore user with 50$ in you pocket and HUGE amounts of free time) ;)

[Sirber]

Can we talk more about H264 now? ;)

[deXtoRious]

Yes, sir! :D

Any news about H264?

[jonny]

ICSetState - ICGetState seems to not work in both codecs.
Someone know if this is going to be fixed?

[Sirber]

ICSetState - ICGetState...

What's that?

[jonny]

To make this simple:

If you save processing settings with vdub (in a .vcf file) and you try to reload the settings, no codec settings will be restored.
(and probably putting multiple jobs in vdub will not work)

[Sirber]

Ok... I see... maybe we should contact VSS about that.

[jonny]

I've posted a message in the VSS forum...
Let's see what happen ;)

[molerus]

Is there another forum or thread considering VSS codec, exept for this??

[jonny]

The official forum is at VSS site:

http://www.vsofts.com

Seems REALLY young (8 registered users)... i hope someone read my message :rolleyes:

[deXtoRious]

I tried a test using a 2 minute DVD trailer from Resident Evil using the following codecs: VSS Codec, VSS H.264, XVID (with all advanced options), XVID (without advanced options), DivX 4.12 (found it accidently on my computer) and 3ivx (new version). I used a constant bitrate of 800kbps for all the codecs. I'm surprised about some posts in this thread earlier stating that one could not use constrained bitrate with h.264 and get a normal filesize. The VOB was 88mb and the encoded files were: 3ivx - 13,2 mb, DivX4 - 12,6mb, VSS H.264 - 13,4mb, VSS - 10,6mb (!), XVID (with all options) - 13,4mb, XVID (without options) - 13,3mb. Now about the quality: H264 and VSS were both simply staggering, true "near DVD quality", I noticed only minor artifacts and they were really hard to spot with human eyes. Xvid with the advanced options turned on was about equal to 3ivx, while the ordinary Xvid was a bit worse. DivX4 had surprisingly good quality, only missing a little from Xvid. I have a big question: what is the difference between VSS and VSS H264??? I noticed no quality difference while H264 was encoded with 1,5-2,5 FPS and VSS with 25-35 FPS (!) :confused: Other than that, I found no surprises, I'll try Sorenson as soon as I get it :rolleyes:

[deXtoRious]

Tomorrow I'll try a dvdrip in VSS on 1cd :D

[drebel]

deXtoRious,
when comparing xvid full advanced options enabled,please dont use GMC.I's a waste of bits with VHQ enabled...:)
regards,
george

[deXtoRious]

So that' were the 100kb came from! BTW, does using GMC with VHQ slow down the encoding a lot and does it decrease quality?

[Sirber]

VSS and H264 uses 110% CPU at DVD rez. VSS may be good for anime or series...

[drebel]

BTW, does using GMC with VHQ slow down the encoding a lot and does it decrease quality?
...By wasting bits yes.You 're lucky your cpu didnt crash

[Defiler]

Originally posted by deXtoRious
advanced overclocking experiments during witch I almost burnt my CPU :DWe've boosted the antimass spectrometer to 105 percent. Bit of a gamble, but we need the extra resolution.

They're waiting for you Gordon... In the Test Chamber!

:D

[jonny]

for those interested on this:

If you save processing settings with vdub (in a .vcf file) and you try to reload the settings, no codec settings will be restored.
(and probably putting multiple jobs in vdub will not work)

One of the guy at VSS have answered and the problem will be probably resolved in the next versions.