VSS Codec and H264

[Sirber]

About VSS Codec:
***********

VSS Video codec allows users to compress video data with highest compression ratio, sufficient coding speed, efficient rate control and flexibility. That makes VSS Video Codec very useful for a wide range of video coding tasks.
What's new in version 1.3
New wavelet technology makes compression much more faster
Two new compression modes for fast encoding
Improved rate control
New API functions (stream info, encoder/decoder settings)
Bug fixes
VSS Video Codec advantages
Very high compression efficiency and good compression speed
Flexibility and powerful fine-tuning capabilities
Rate control and quality control mechanisms
Platform independent coding engine and easy integration with various video-processing systems on different platforms
Video for Windows interface
Summary
The highest compression ratio, sufficient coding speed, efficient rate control and flexibility make VSS Video Codec very useful for a wide range of video coding tasks.

It is designed as a modular and platform independent software with simple and convenient SDK, allowing it to be easily integrated into various video streaming/recording/storing systems on different platforms. For an example, one of the testing procedures for the codec has been implemented within a Linux-based Internet videoconferencing system.

The codec has strong potential mechanisms for on-the-fly adjustment of speed/compression ratio (in addition to the rate control) to account for the changing bandwidth or other external conditions. This unique and important feature cannot be found in commonly used video compression SDKs.

About H264:
***********

ITU-T H.264 Codec
VSS has been working on the ITU-T H.264 (formerly H26L) codec implementation since the beginning of 2001.
Initially, our version was based on the reference software. However, the reference implementation, taken as is, is inefficient and has little practical value. Our implementation is highly optimized, and we continue working on the enhancements.
The optimization areas here can be split into the following three groups:
1. Optimizations affecting both encoder and decoder
2. Encoder-specific optimizations
3. Optional pre- and post processing, which by itself is not part of a standard but is still commonly used.

For the first group, it is mostly the code optimization for speed that has been done. We achieved about 2.5 times speed up just by pure C-code optimization.
Large part of the reference code was rewritten from scratch because:
- Its initial design did not allow for speed optimizing;
- It is not designed to work in multithreaded environment;
- Reference implementation is not designed in a modular way, making it very inflexible.
Our implementation addresses all these issues. We also performed custom optimization for the following target platforms: Trimedia DSP, TI and Intel Pentium. The work on further code optimization and flexibility is continuing.

Encoder-specific optimization includes several new efficient (patent-pending) algorithms. Among them:
- Optional noise reduction preprocessing (This is not just a preprocessing in a usual sense. This noise reduction filter is in fact a part of the encoding process as it uses the results of motion estimation)
- Very fast and precise Motion Estimation algorithms;
- Intelligent macroblock type and reference frame selection;
- Perception-based quant-parameter modulation;
- Several rate distortion algorithms;
- Original rate and time control;
- Scene change detection.

Preprocessing / postprocessing.
Here, we implemented a lot of optional procedures, which can be executed before encoding and after decoding. Among them:
- Separate noise reduction filter;
- Smoothing and sharpening filters;
- Clipping, downscaling, upscaling;
- Interlace, deinterlace, Telecine, Inverse Telecine;
These are very flexible procedures that can be used in various combinations.

Get them at:

VSS Codec: http://pluto.vss.spb.ru/vsscodec/download/
H264: http://www.vsofts.com/VideoDownloads/VSSH264Codec10beta.exe

[Sirber]

With H264, I'm encoding at ~2 FPS on a 2 GHz!!!! Playback is painfull, with 100% CPU utilisation. I'll post a preview shortly.

Mode:
Slow: ~2 FPS
Slowest + bframes: ~0 FPS

[Sirber]

I have no FTP so here the results:

Both codecs at 512kbps, slow encoding with wavelte intra-frames.

H264:
Good:
* Respect the rate control

Bad:
* Lots of blocks
* Encoding speed
* Require a ~2.4 GHz for playback

VSS Codec 1.3:
Good:
* Faster than 1.2
* Quality is nice at 512kbps
* No visible blocks

Bad:
* Don't respect the rate control
* Require a ~2 GHz for playback

================

Here's some preview:

http://pluto.vss.spb.ru/vsscodec/H.264/clips/Pepsi/pepsi-h264-300.avi
http://pluto.vss.spb.ru/vsscodec/H.264/clips/Pepsi/pepsi-h264-150.avi
http://pluto.vss.spb.ru/vsscodec/H.264/clips/TheMatrix/TheMatrix1-h264-300.avi
http://pluto.vss.spb.ru/vsscodec/H.264/clips/TheMatrix/TheMatrix2-h264-300.avi

[Selur]

Another Codec too test, har har,.. ;)
(it's like christmas lately ;) )

Cu Selur

Ps: "version 1.3 is time-limited" :(

So feedback from first tests:

:( I only get about 50% CPU usage with the h264 beta, on my dual Athlon MP System, with Xvid&Co it's 805 :(

[midiguy]

I installed the VSS codec and I cannot playback TheMatrix2-h264-300.avi.. do I need the other h.264 codec? probably do....

[midiguy]

oohhhh.. the codec is called "h264".. I thought it was just a h.264 codec..

[midiguy]

argh... it works this tinme, but just plays a black screen. for sure this is purely because of how much my computer sucks (p3 600 mhz, 128 meg PC100 SDRAM):o :sly: can someone post some screenies for midiguy? thanks!

[Selur]

Hmm testing Vss codec atm and at low motion sceens (smith questioning Morpheus) Xvid and hdot264 beats it, vss uses to much smoothing. (tested them all kind of with the same file size; I only did high quality (Xvid quant 2 test), so can't say how it performs at low bitrates), but h264 Codec performes quite good,..

Cu Selur

Ps.: "but just plays a black screen." same problem here with the provided clip ;)

[Sirber]

About hdot264, will it have a GUI for configuration instead of .cfg?

About the "time limit", it's just words :)

[Selur]

"About hdot264, will it have a GUI for configuration instead of .cfg?" Don't know, maybe atm it's a one man show so progress takes it time.

Cu Selur

[gino25]

About the "time limit", it's just words

What?

[Sirber]

In the website, they say it's a 60-day limited version, but there is no limitation inside the codec, so it's just words.

[gino25]

ok thank you

[buba king]

testing now.. getting 15fps on the VSS 1.3 @ 640x320

VSS:
q=15

10mb

looks great. (no lag.. about 80% cpu usage, using ffdshow for postprocessing)

XviD:
q=15

4MB

Looks like crap.. Still trying to get the filesize on the VSS clip down.

[Mango Madness]

if i remember correctly, you can't compare quantizer for quantizer if this codec is remotely based off of h.264. They use completely different mathematical methods (linear and logarithmic?) for computing the quants.

[midiguy]

buba king: did you use the h.264 VSS codec or the VCC codec based on wavelet (one says h.264 and the other doesn't)?

[Tommy Carrot]

I did some tests.

Their h.264 gives slightly worse result, than the reference software and hdot264. And it doesn't matter which bitrate or quantizer you set, it always give the same length.

The vss codec is not wavelet, just the keyframes. The quality is not really better than xvid's with the ASP options, at higher bitrates it's worse imo. And much slower. Not worth to use it yet.

[netchris]

to Tommy Carrot : you have to have one vss codec installed at a time.If you have them both installed the 264 is broken giving the same low bitrate nomatter what bitrate or quantizer you choose.So uninstall them both,reboot and then install the vss264 and it works ok.
I Agree that the vss264 is worse than the reference one,and it has some
problems (due to immaturness). Such as everytime a scene changes the picture becomes blurry for a second even when there isn't too much motion and the colors of the walls and other surfaces are shaky.

[buba king]

Originally posted by midiguy
buba king: did you use the h.264 VSS codec or the VCC codec based on wavelet (one says h.264 and the other doesn't)?

I used the VCC codec (v.1.3). i got the filesize (q=22) down but i dont think it looks any better than a bad xvid encode at the same size :/ .. Maybe i fucked up something though ..

the size of the test clip i used: SHQ (mpeg2) 1280x1024 (1:30)

[netchris]

There is a new build of the h.264 available from vss(20/1/2003).
Although it has has the same version number the codec has definately been updated because the video quality in my tests has been greatly improved!
The bad thing is that the rate control is not working correctly so you have to play a lot to get a desired filesize(bitrate).
I dont see any speed improvements.

[Sirber]

Remember that H264 is beta and not avalible for download from VSS. I just found the link :)

*** New version from today ***

VSSH264Codec10beta.exe 20-Jan-2003 16:30 1.6M

What's new:

* Speed improvement
* Quality boost
* Bitrate control don't work (use quant)
* b-frames removed and other stuff, it's not VSS Codec VFW interface anymore.

[Sirber]

They removed H264 codec from their site. :(

[Selur]

Damn, the codec really rocks, I just encoded the first chaper of Lost in Space and the quality was amazing. (used quant 20)

Cu Selur

Ps.: the url just changed,.. atm one can find the codec under:
http://www.vsofts.com/codec/h264_download.html

[ales19]

the codec doesnt install (sends me to the control panel and there isnt anything there to do-click-check) i tryed to open it with winrar and i got a "archive corrupt" message...
any suggestions? :)

[easyfab]

Originally posted by ales19
the codec doesnt install (sends me to the control panel and there isnt anything there to do-click-check) i tryed to open it with winrar and i got a "archive corrupt" message...
any suggestions? :)

+1 and try installing install.msi in the temp directory but it tell me that data3.cab (h264.dll) is needed and i have not this *.cab

[Sirber]

I'll try to find where they keep it and get it.

[Tommy Carrot]

Originally posted by Sirber

*** New version from today ***

VSSH264Codec10beta.exe 20-Jan-2003 16:30 1.6M

What's new:

* Speed improvement
* Quality boost


Well, the quality is _identical_ to the older build at the same settings. I don't find the speed improvement also. Basically they only fixed the interface to the codec. Now the keyframe settings are working too, so the seeking is possible.

Choosing normal encoding speed will utilize some kind of ME/MC, so it's 5-6 times faster than 'slow' setting, but the image is not that clean (some artifacts appearing.

Slow setting uses the brute force motion searching, which can be familiar from hdot264.

I did some comparition to xvid with a part of LOTR. The settings was:
Xvid: mpeg quantizer 2, chroma on, bframes, qpel, GMC off.
h264: normal speed, quantizer 18.

Xvid gave 445 MB, h264 gave 328. (the encoding time was 38 min and 5h25m:D) To my surprise, h264 keeped slightly more details (for example, the difference can be seen on Gandalf's beard, skin pores, etc.) So it's really good at high quality encoding. I don't really understand the use of quantizers under 16, they are virtually lossless all, and the size differences are huge.

At medium quality (xvid mpeg quantizer 4, chroma, qpel on;h264 quantizer 22), the result is not so amazing, very often xvid is the better, which is surprising, because h.264's sweet spot is the lower bitrates. But maybe this is due to ummatureness/VSS's fault. More tuned versions of this standard(maybe xvid2:D) will be better i guess.

[Selur]

@ales19: Sounds like you should redownload the file ;)
@Tommy Carrot: about the medium quantizer, did you try to make a h264file that equals the quant 4 Xvid encode in size and then compare quality?

@all: How's playback working for you? (speedwise)

Cu Selur

/edit: to me it seems like: 'Max Keyframe Interval' should be renamed to 'Keyframe Interval' at least for me it seems liek there's no scenechangedetection,... edit/

[ffroms]

@ales19 - same here :( .

FFS

[ales19]

Originally posted by Selur
@ales19: Sounds like you should redownload the file ;)


well, i allready DLed it about 4 times and each time i get the same error... maybe i shouldnt use getright?

[Sirber]

Playback is almost realtime on a 2 GHz.

[gino25]

The installaer doesnt' work. I have "setup.exe error". But in temporary folder i have 2 cab and 1 file. I haven' t setup.exe.

Any suggestions?

[Selur]

Hmm,.. I used an ftp programm to download the file,.. (retry after 60sec if no data received for 30sec)

Cu Selur

[Tommy Carrot]

Originally posted by Selur

@Tommy Carrot: about the medium quantizer, did you try to make a h264file that equals the quant 4 Xvid encode in size and then compare quality?



Yes. The lenght is quite close. (176 and 182 mb)

[gino25]

@ selur

can you give me the file?

[killingspree]

well i just downloaded and gave it a first small test:
i took the faithhill - There you'll be vob, from my pearl harbor dvd to test. -vob files size: 133 MB, 10.4 MB ac3 sound
-> the clip is almost ideal for testing purposes: lots of motion
even more szene changes, dark szenes, bright szenes, close ups, basically almost everything you want
i first did a 2 - pass divx 5.02 rip @ 1500kbit (i know this isn't the best to compare, but that is what i use for normal movie encoding so i wanted it to) the video was approx 40MB
and then i did a vss h264 encode at the same bitrate
to my surprise the video file still came out half the size @ 21MB

i did the encoding @ approx 4 fps (with deintelacing switched on)
decoding in wmp9 works almost smooth, still there are enough jerks to make it disturbing -> so question: how do i benchmark the decoding fps?
processor is a PIV 2.0 with 512 DDr ram and winXP home

muxing with avimux and and the original ac3 file worked perfectly, also it somehow didn't make the video any more jerky.

what i've noticed at first is that the first 10 or 15 frames are blocky and some other fast szenes get some blocks to, not worse than any >1000kbit divx4 encode though.

regards
steVe

PS: these are only first impressions though.

[Sirber]

don't use bitrate with h264 yet, use quant instead. That's why you have blocky frames.

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

[easyfab]

Ok I've tested this version and the results are very good @quant17 , constante bitrate doesn't work.
But what a CPU usage, in encoding ~4fps (this doesn't matter if quality is there) against ~30fps for xvid and in decoding ~70 % of CPU usage on my XP 2.1ghz against ~10 % for ffdshow decoding.IMO the min CPU must be a 1.5ghz processor to have a proper decoding.

[Sirber]

can ffdshow decode H264? in Codecs, there is H263+, which is H264 right?

[Selur]

"can ffdshow decode H264?"
at least not on my machines,..

[easyfab]

Originally posted by Sirber
can ffdshow decode H264? in Codecs, there is H263+, which is H264 right?

No i don't think.
I only want to compare the CPU % usage for decoding.

h264 via h264 decoder -> 70%
xvid or divx via ffdshow -> 10%

[ales19]

Originally posted by Sirber
New link:
http://www.vsofts.com/codec/h264_download.html

for all the ppl who were having problems DLing this, i solved the problem by using explorer's DLer window instead of getright...

[rjamorim]

Originally posted by Sirber
there is H263+, which is H264 right?

No.

Although the "+" is misleading, H263+ has nothing to do with H264.

[Sirber]

This codec is still beta... my last test was yellow :)

[molerus]

Hello folks!

I don't know guys if you have noticed, that h264 behaves completly different from the present codecs. Namely when one increases quantization it doesn't cause blockiness (or just a little bit), but the codes loses more and more details, but the image looks still ok.
:p :p :p :p . Moreover when I did test with the noisy video the coded part looked better at first glance than the original. The noise was removed as with the median filter, while the details like tv-logo were preserved. Incredible!!!!!

I recon that excepting it's speed it is what we all were waiting for.

[ales19]

Originally posted by molerus
Hello folks!

I don't know guys if you have noticed, that h264 behaves completly different from the present codecs. Namely when one increases quantization it doesn't cause blockiness (or just a little bit), but the codes loses more and more details, but the image looks still ok.
:p :p :p :p . Moreover when I did test with the noisy video the coded part looked better at first glance than the original. The noise was removed as with the median filter, while the details like tv-logo were preserved. Incredible!!!!!

I recon that excepting it's speed it is what we all were waiting for.

yes i noticed that too... could that be due to some sort of "automatic" postprocessing like in wm9??? (which would go with the slowness in decoding)

[huangy]

Originally posted by molerus
Hello folks!

I don't know guys if you have noticed, that h264 behaves completly different from the present codecs. Namely when one increases quantization it doesn't cause blockiness (or just a little bit), but the codes loses more and more details, but the image looks still ok.
:p :p :p :p .


I think this is because H264 uses wavelet coding algorithms.

[Tommy Carrot]

Originally posted by huangy
I think this is because H264 uses wavelet coding algorithms.

No, it doesn't. It's because the in-loop filtering (not postfiltering).

[huangy]

Originally posted by Tommy Carrot
No, it doesn't. It's because the in-loop filtering (not postfiltering).
could you explain what the in-loop filtering is?

[Selur]

this little article vom M$research might help:
in-loop deblocking filter for block-based video coding (research.microsoft.com/~fengwu/ papers/deblocking_icsp_02.pdf) for the exact way this or something liek this is implemented in h264 you should read the jvt draft at Thomas Wiegand's page (http://bs.hhi.de/~wiegand/JVT.html).

Cu Selur

[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.

[gino25]

there is a new beta 3 preview here

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


who do test this ?

bye

[Ramirez]

Hey thx :), gonna test it ASAP; I hope they've fixed this "hang on key-frame insertion" thing.

[Sirber]

I just hope decoding is fast!

Ok.. it's not a codec. it's a console encoder like throea.

[stax76]

I would also be interested in a Microsoft vs Real comparison because Micosoft codec is VFW compatible

Edit: sorry wanted to post in the real vs xvid topic

[Ramirez]

Sirber what should we do with that stuff?,are these guys from Vanguard Soft joking or what?:devil: :p

[Sirber]

I think they want to slave us all. :scared:

lol

It's like a technology demo. It's still not in a VFW format. It will be soon. H264 bases changed so they have to recode it.

[deXtoRious]

Does anyone knows of a release date for the VFW version? Also, has anyone tried to compare the quality between h.264 and VSS H264?

[Sirber]

@deXtoRious

Usualy I receive a mail with a new beta from VSS is released. I havent for this one.

About VSS and h.264, I like more VSS, it's more lamer frendly ;)

[deXtoRious]

Agreed. I could freely encode clips with VSS (~1.5fps) and watch them. I couln't run h.264 at all and from what I heard, it's ~10 times slower... But is there a difference in quality?

[Sirber]

I don't know... it's based on the same code.

[deXtoRious]

Possibly VSS traded some part of quality for speed... It's just a theory, though, and I hope it's wrong.

[Sirber]

For speed vs quality, at slow it's like h.264. At normal and up, the motion estimation engine is tweaked for speed instead of quality.

[deXtoRious]

Understood, thanks. I'll test some clips with both settings to see if there is any visible difference.

[Sirber]

I don't use H264 yet, my 2000+ can't decompress it in realtime tor 720x and 640x rez at 24FPS. :(

[deXtoRious]

That's strange, my 2000+ can't either...:D Just convert it to HuffYuv and THEN watch it... So don't make clips long, 500 frames are more than enough.

[Sirber]

I made a test with a anime in 640x480, Vampire Princess Miyu, and at the same bitrate (350kbps), The one in H264, the rain was better but the ovreal quality was better in RV9.

That's why I'm a RV9 Nerd :D

[deXtoRious]

I made a test with Resident Evil trailer at 800kbps with XVID, 3IVX, VSS H264 and DIVX5. 3ivx and divx5 were quite similar, xvid was slightly better, but many artifacts still remained. H264 was true DVD quality.

[Sirber]

What about RV9?????

[deXtoRious]

I didn't use RV9 then. And now I don't have that trailer anymore. I'll do a new test as soon as I find a decent high motion trailer of some kind...

[alexcyn]

Originally posted by deXtoRious
Does anyone knows of a release date for the VFW version? Also, has anyone tried to compare the quality between h.264 and VSS H264?
We plan to release VFW & DirectShow for Beta3 next week. Beta3 has better compression and conforms to newest H.264 JM 6.1 verification model.

Regarding quality - our tests show that decoder is about 1.5-2 times faster than reference software. Encoder performance depends on compression mode:
- In slow mode (full conformance with JM) encoder is ~1.5 times faster than reference (same compression ratio);
- In normal mode (using some VSS patented algorithms) encoder is 3-4 times faster than reference (compression is 2-3% worse);
- In fast mode (normal mode plus some algorithms simplification) encoder is up to 7 times faster than reference (compression is ~5-8% worse);
= Alexei Doilnitsyn, VSS Inc. =

[gino25]

thank you to all developer.

bye

[Sirber]

@alexcyn

Hi

That's great news! I have a question: Will the decoder support 780x480 @24FPS on a 1 GHz machine?

[scorchED]

great news!

[Selur]

Cool, can't wait to test the new beta :)

"decoder is about 1.5-2 times faster than reference software"
So it should decode fine with my Athlon XP 2000+ :D

Cu Selur

[Sirber]

Now that we'll have a great video codec, I need to find a great audio codec that can encode at 32kbps and 64kbps with great quality. RealAudio is good but don't work with OGM/AVI.

[CompuKid101]

Originally posted by Sirber
Now that we'll have a great video codec, I need to find a great audio codec that can encode at 32kbps and 64kbps with great quality. RealAudio is good but don't work with OGM/AVI.

RealAudio is NOT good. OGG is the best out there... even more so with low bitrate audio. :)

Try encoding with a -1 quality for REALLY low bitrate! :D

[Sirber]

Encode a song at 64kbps with Vorbis. Encode the same song with Real Audio. The one in RealAudio will be better. Try at 32kbps too. Vorbis can't compete with RealAudio.

You don't trust me? Look here

http://ekei.com/audio/

Try things before posting :devil:

[Selur]

Okay, this is all going kind of offtopic, but:

"Vorbis can't compete with RealAudio."
at least with such low bitrates ;)

Sirber, did you try wma?
(As far as I remember it wasn't so bad at low datarates, but I can't remember to well,.. Normally I encode my DVD on 2 CDs ;) )

Has anyone tested how aac competes at low bitrates? (<64kBit)

Cu Selur

[fellip_nectar]

"Vorbis can't compete with RealAudio"

More correctly, Vorbis RC3 coudn't compete with Real Audio

Look at the date - March 2002 - These tests were conducted before Vorbis 1.0 came out, a release which IIRC included optimization for lower bitrates.

However IMHO Vorbis 1.0 sounds better than Real at 64kbps

[Sirber]

I tryed Vorbis 1.0 vs RealAudio (cook) and RealAudio sounds more natural with more high-freq.

WMA @64kbps sounds like Vorbis @64 some times, like for rain and wind.

[Assault]

Sorry this is going OT
@ Sirber
I want to try Real Audio with some songs but I don't know which program I could use for my test. Can you recommend anything?

Regards
Assault

[Sirber]

OT or not, here's the answer.

One day, God himself told me that I need Helix Producer to encode Real content. So the quest for the Helix Encoder began.

There is a movie about that:

Monty Python and the Helix Grail

:D

[unmei]

VSS is a nice codec but not exceptional. Contrary h dot 264 seems to be able to produce really ass-kicking results (i made a clip at 500kbit 720x576 that looks comparable to 1200kbit+ Xvid to me ) but it is faaaaaar from usable because of the speed and it seems to have the same motion detection problem as the VSS one, only less prominent.

a bit weird question :
is it possible h dot 264 gets slower the more frames you feed ? With 15 frames i get 1.5 frames a minute, with 50 frames i get a single frame every 5 minutes :s - could it bee that it tries to expand the search range over the entire clip for some weird reason (nevertheless i've set it to 8 frames) - hmm, not really important it's testing joy only, but would be interesting if anyone experienced the same anomaly (VSS is not affected, only h dot)

@selur
about AAC: im not into audio atm i just use cbr lame mp3, but a year ago i tried to figure out what is good in which bitrate range, and back then AAC seems only targeted at 160+ kbit, below 128 it produced results even worse than mp3 at the same bitrate - but well time passes and this results might really be outdated...

[Tommy Carrot]

Originally posted by unmei

a bit weird question :
is it possible h dot 264 gets slower the more frames you feed ? With 15 frames i get 1.5 frames a minute, with 50 frames i get a single frame every 5 minutes :s - could it bee that it tries to expand the search range over the entire clip for some weird reason (nevertheless i've set it to 8 frames) - hmm, not really important it's testing joy only, but would be interesting if anyone experienced the same anomaly (VSS is not affected, only h dot)


This can be because multiple reference frames, but 5 is the maximum, so the encoding can progressively slowing in the first 5 frames, but after that the speed remains constant.

BTW, h.264 is really superior to all alternatives, just a proper implementation is not exist yet. It needs some time.

[PerCIVaL]

In the new beta (jm61 spec), it seems the quantizer values have been changed. Using a quantizer of 30 for P-frames (31 for I) I'm getting an average bitrate of 19000 kbit/s.

Or am I doing something wrong?

[Sirber]

Do you like movies on 35 CDs? :p

[PerCIVaL]

Lol, maybe they're planning on inventing a 30gb cd-r along the final release ;-)

at quantizers I/P 31/30 this is what I get.

Frame Bit/pic QP SnrY SnrU SnrV Time(ms) Frm/Fld

0(I) 705672 31 31.7192 31.6530 31.6438 3047 FRM
1(P) 727840 30 31.5367 30.2833 30.3291 4547 FRM 432
2(P) 728296 30 31.5749 30.3381 30.3385 5156 FRM 432
3(P) 732968 30 31.5696 30.3234 30.3328 5750 FRM 432
4(P) 730872 30 31.5593 30.2697 30.2970 6359 FRM 432
5(P) 733160 30 31.5594 30.3364 30.2724 6985 FRM 432
6(P) 733400 30 31.5454 30.2739 30.3138 7015 FRM 432
7(P) 733624 30 31.5544 30.3065 30.2912 7344 FRM 432
8(P) 729664 30 31.5724 30.3238 30.3085 7219 FRM 432
9(P) 727928 30 31.5587 30.3097 30.2716 7172 FRM 432

notice the ~700000 bit/frame.

But I repeat it's very much possible that I'm doing something wrong/stupid here.

[Selur]

They propably just changed the scaling of the quantizers,.. ;)
Quantizer 1 in Xvid != Quantizer 1 in h264 != Quantizer 1 in hdot264 ....

They all use differend scaling e.g. choose a range from 1-32 or 1-250 ...

So don't look at the quantizers, look at the resulting size and quality. I know this makes comparing harder, but hey none of the codec is a final, so this is the way it is kind of ment to be :)

Cu Selur

[vinkes]

Originally posted by Sirber
I tryed Vorbis 1.0 vs RealAudio (cook) and RealAudio sounds more natural with more high-freq.

WMA @64kbps sounds like Vorbis @64 some times, like for rain and wind.

<offtopic>

Hi sirber,

I saw your discussion about ogg vorbis and aac, perhaps you should look at this:

http://forum.doom9.org/showthread.php?threadid=33110&highlight=ogg+vorbis


Regards

[Sirber]

I made LOTR:EE at 64kbps and it's DVD quality :) I made few films like the matrix at 64kbps with vorbis, and in the Bar, I can't hear the music, it's just plain, raw noise.

[gino25]

what day the new beta3 will be released?

[Sirber]

Originally posted by vinkes
<offtopic>

Hi sirber,

I saw your discussion about ogg vorbis and aac, perhaps you should look at this:

http://forum.doom9.org/showthread.php?threadid=33110&highlight=ogg+vorbis


Regards

By now I know where to find things :p. Read all the tread before posting sutch(?) things. What I said was kinda related to H264, whitch is a excellent low-bitrate video codec, because we need also a low-bitrate audio codec to use with. Don't tell me that MP3@32kps and Vorbis@32kbps are good... :devil:

@gino25

I don't know. Sometimes, they work fast, sometimes not. Beta3 seems the second choice.

[vinkes]

Hi Sirber,

I didn't mean to say that aac is a bad audio-codec, I'm just trying to say that I like vorbis more than aac. Just because you like aac and I like vorbis, that doesn't mean that any of us is right or wrong.
And please don't tell me to real all the threads, I did. My low post-count doesn't mean I'm a noob.


Regards,

[Sirber]

Originally posted by vinkes
Hi Sirber,

I didn't mean to say that aac is a bad audio-codec, I'm just trying to say that I like vorbis more than aac. Just because you like aac and I like vorbis, that doesn't mean that any of us is right or wrong.
And please don't tell me to real all the threads, I did. My low post-count doesn't mean I'm a noob.


Regards,

If you say that I like ACC, it because you didn't read THIS tread. I said I like Real Audio. BTW there is no aac codec...

[vinkes]

@ Sirber,

You're right, there is no aac codec. I mixed it up with ra audio.
Al the time I was talking about ra audio, not the aac.
(stupid me)


Regards,

[Sirber]

No prob :)

I have a question: Did you ever try RealAudio?

[Doom9]

I just got word from the developers.. beta3 won't be out this week.

[Sirber]

:(

That's bad news...

[gino25]

:( :( :( :( :(

[Selur]

No,....:(

[vinkes]

Originally posted by Sirber
No prob :)

I have a question: Did you ever try RealAudio?

Yes I did. Lately I've been experimenting somewhat with realvideo 9, It's a lot better than other codecs at lower bitrates. I usually use realaudio at either 64 or 96 kbits. It's not bad, but somehow on my soundcard (sb live 5.1) ogg vorbis sounds better.
And for some strange reason I can't get real audio with surround sound to work on my pc.


Regards,

[31 Flavas]

Originally posted by vinkes
And for some strange reason I can't get real audio with surround sound to work on my pc. Real Surround is DLP as far as I know. DLP (Dolby Pro Logic) is only 2 channels and I do not think a sound card will put out the extra channels even if it is a 5.1/6.1/7.1 card. You need something like the decoder box that comes with the Creative Labs DTT2500/3500 or Inspire 5700 speaker system or an external amplifier that has a pro-logic button.

Or maybe i'm just showing my ignorance....

[Sirber]

One of my friend (kind-of, he's a jerk really) have a 5.1, but the output sounds like stereo.

[Selur]

any news regarding h264?

[PerCIVaL]

I think not,

I played around with the jm61 spec console encoder. But it's too slow to be functional.

vsoft was going to release beta 3 on the new spec some time ago but didn't.

[Herculezz]

Whats Up With VSS They Promise a Beta 3 VFW Every Week And It's Been Something Like a Month :(

[Sirber]

2 month :)

Anyway H264 wont be ready for years :(

[Herculezz]

They Promisied Final Release next few months

Thank you for good words!
We plan to make final H.264 codec release in a few months. And we plan to provide H.264 Light version for free.
-- Alexei --
Posted: Mon Apr 14, 2003 5:03 pm

Also Said Full D1 Playback will only require a 1 GHZ Machine :)

[Sirber]

Few months will be in 3 years :)

In the meantime, we can use RV9 :D

[Herculezz]

I Would Use RV9 IF You Could Play With Other Player!! :)

[Sirber]

What about MPC?

[Herculezz]

I Just Did an Encode of a 1 min clip with RM 9 And It's Amazing Quality!! I Used AutoRV9 And was wondering if the AC3 File I Use When Encoded to 96KBPS Is it still dolby digital?

[Sirber]

It's Dolby Digital Surround only...

[Herculezz]

is it 5.1? no dts? Can You Merge a different audio file with the video?

[Sirber]

AC3, wav and vorbis I think, using the SMIL system.

Use search or browser this forum. :)

[Herculezz]

does any of them do dts?

[Sirber]

Nope.

Or... ask Karl :)

[nFury8]

originally posted by Herculezz
is it 5.1? no dts? Can You Merge a different audio file with the video?
If you have a 5.1 setup and want to maximize it, better stay away from RV9 for the moment, it only supports surround. Too restrictive, you can't mux a different audio format with its video.

[Sirber]

Originally posted by nFury8
Too restrictive, you can't mux a different audio format with its video.

You can, using a SMIL(E) :). It's an external muxing... For my 2 language rips, there is movie.rmvb, french.rm and english.rm, and 2 .smil to link the movie with the chosen language. You can use vorbis too or AC3 if you want...

[nFury8]

You can use vorbis too or AC3 if you want...
Really? IIRC, Karl Lillevold said its impossible to mux AC3 with RV9 in an earlier thread. Have you muxed AC3 with RV9 successfully? How did you do it with SMIL?

[Sirber]

For AC3 it was a guess, or a "wanted" feature ;) SOrry for that :D

[gino25]

Any news from hdot264 and vss?

[alexcyn]

Originally posted by gino25
Any news from hdot264 and vss?
VSS Status:
We present our apologies to all video compression gurus!
Beta3 codec was not very successfull due to a lot of bugs in reference software code (we were based on it). So we decided not to release it at all.
Instead we are finishing completely new clean H.264 codec, which will be several times faster at the same quality.
== Alexei ==

[gino25]

When will it be on-line?

[Selur]

"Instead we are finishing completely new clean H.264 codec, which will be several times faster at the same quality."

Cool :D

Thx for the info. :)

Cu Selur

[Sirber]

"Instead we are finishing completely new clean H.264 codec"

Based on what?

[Mango Madness]

How about several times the quality at the same speed? :)

[Dark-Cracker]

any news ?

[Selur]

- bump -
and again:

Any news from hdot264 and vss?

[Sgt_Strider]

I just check the download portion of the site and beta 3 preview of the software is available for download. I'm not sure if this is signifigant news or even old news. Just check ;)

[Sirber]

It's old news. Sorry :(

[gino25]

In my opinion these codec are dead.

[unmei]

don't call them dead for some months without release. AAC was drifting for years and now everyone seems to jump on it ;D

AAC is mpeg-4 and H.264 is mpeg-4 too. Mpeg seems to like slow projects :0
(of course xvid is mepg-4 too and not slow at all)

[Sirber]

LOL!!!! A good one :D

[gino25]

Any news?

[Sirber]

Nope.

You can check theur website...

[gino25]

:( :( :( :( :mad:

[Sirber]

6 months later, still no news...

[Bandung]

Are you sure? I thought they did release it already?

[Tommy Carrot]

Yea, but the codec in its current form is totally useless (too slow, bad interface - configurable via a .cfg file, etc), and the development stopped almost a year ago. And it wasn't even a serious development, just an avi wrapper on the reference software.

I think VSS progressed further, but they said their codec wont be free.

[Doom9]

their base level h.264 codec was released at the international broadcast fair a few months back. It does real-time encoding if your computer is fast enough (don't ask me about the res). Now they're working on a main level codec. Both codecs won't be free but there's hope that the base level codec might show up in a future codec comparison ;)

[Selur]

@doom9: Thanks for the info. :)

Do you know if there will be or is a way for a private person to buy their h.264 codec. ;)

Especially the "main level codec" would be interesting. ;)

Cu Selur

[Doom9]

Do you know if there will be or is a way for a private person to buy their h.264 codec.You'd have to ask them. But I'd suppose they'd advertise if it they wanted to sell it to non corporate customers.

[gino25]

See here

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

It appears that final version was released, but doesnt seem to be free

:(

[Sirber]

VSS H.264 Beta2 JM 4.2 Video for Windows
VSS H.264 Beta3 Preview JM 6.1 Console

nothing has been released :)