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