SIF1 v1.20 was released

[lnatan25]

Forgive my OT, but why are Russians so afraid of Microsoft? Why is it that most of the usual anti-MS propaganda always comes from East Europeans, with a big percentage of that being from Russia?

[PatchWorKs]

Then I repeat the question.

What can protect me from Microsoft?

If I release a source code under the GPL licence I lose any rights to SIF-technology of compression.
And Microsoft can easily create the codec using SIF technology if will write the source code.

GPL and LGPL can protect you from anyone. You don't lose any rights (it's not Public Domain) by licensing with them, but you allow 3rd parties to change the source code under their rules.

Keep in consideration that if you choose GPL/LGPL you're not alone against any code-thieves: EFF, OSI, Xiph, etc. and the whole community will certainly help you.

[IgorC]

Forgive my OT, but why are Russians so afraid of Microsoft? Why is it that most of the usual anti-MS propaganda always comes from East Europeans, with a big percentage of that being from Russia?
:)
Windows is extremely popular in Eastern Europe while Mac gains the markets in other lands. Windows 7 was very well received http://marketshare.hitslink.com/report.aspx?qprid=12&qptimeframe=M&qpsp=129&qpmr=300&qpdt=1&qpct=101&qpcustomb=3211&qpob=MarketShare%20DESC&sample=5

But it's OT here.

[nakTT]

This is the first full-function version that realize open standard SIF1 Simple Profile.
The further modifications will take shape like addition to basic specification.

To download SIF1 it is possible from here (http://mysif.ru/SIF1_dd_Eng.htm).

The text of SIF-compression patent can be found here (http://mysif.ru/Patent.htm).

The Easy-to-understand description of features of SIF-compression technology can be found here (http://mysif.ru/O_SIF_En.htm).

Demonstration video fragments can be downloaded from there (http://mysif.ru/SIF1VidEn.htm).

Description of SIF1 settings can be found here (http://mysif.ru/WorkSif1_En.htm).

The source code of SIF1 decompressor can be downloaded from here (http://mysif.ru/SIF1_dd_Eng.htm).
From your site it is still version 1.00 of this software. Any updates or news?

[Neiromaster]

Definively a good codec and impressive start ... by far better than all the other 1.00 codec version. It's certainely possible to improve this codec ... !!?

Yes, I constantly develop and improve the codec.
But I usually do not distribute intermediate releases.
Usually I distribute release when enough of changes is made.
At present I adhere to semi-annual development cycle.

In the following version such primary tasks will be solved:

1)The restructuring a code of a motion-compensation engine will be made.

2)Multiprocessor optimisation of decompression library. Good decoding FullHD video on multicore processors

3)Support quarter-pixel movement compensations in motion-compensation engine

4)Some improvement of visual quality of compression

In more remote plans:

1) Motion-estimation engine will be improvement

2)The real time compression mode will be added

3)The quarter-pixel movement compensations will be added.

Only after these changes quarter-pixel movement compensations becomes completely efficient.

In general I expect for 20 % - 30 % increase of compression efficiency.
But it is necessary to understand that I do the codec during free time from the main work.
I need to maintain the wife and children. Therefore I most likely will make all these affairs only by next autumn.

Also I plan to release a source code of universal decoding library.
This library will have the portable code and it will be to use OpenGL ES 2.0 for the work. Thus will be an opportunity of the hardware decoding SIF1 on any platform supporting OpenGl ES 2.0

And it almost all modern platforms, such as Adroid, I-fone, Moemo and so on...

Also probably hardware decoding SIF1 by means of any videocard a supporting of DirectX 9.0. But it is not a priority.

I wish to mark that SIF1 it is unique modern technology of compression known to me which allows to receive hardware decoding on any platform supporting OpenGL ES 2.0. It does SIF1 best other alternative codecs for similar applications.

Here is actually plans for the future....

[Neiromaster]

Momentum and name recognition?

Well I don't know about others, but I want everything and I want it for free :) Has little to do with Microsoft though.

I don't consider that Microsoft is awful ;)
But I badly know English and have tried to formulate the thought in the elementary kind.


There is an ecology of projects for Open Source (in the OSI sense) which isn't present to the same extent for other licenses which would make it better for me to see it under such a license ... but that doesn't mean it's better for you of course.

There are open source licenses which explicitly exclude patent rights like this one (which would make the source code only useful for academic purposes) :

http://labs.metacarta.com/license-explanation.html

Concerning licensing of source code for the academic purposes.
Problem in that, in a current code there is a set of optimisation and improvements. The rights on which are not register officially in any way.

For an example. In the code of the decoder the original algorithm of motion compensation is applied. Also it is used original solutions of a problem effective realization an overlapped motion compensation with reference to a similar class of algorithms. Also original algorithms of high-speed optimisation for motion compensation engine and SIF synthesis are applied.

Thus only on this code it is possible to receive 5 patents of addition which will be already never received.

The same situation and with an encoder code.
If I had a separate academic version of a code without these optimisation, I without doubts would release it.

But at present I cannot make such version and I can not will decide so to release existing code.

Probably I will open a code in the future, but not now...

[MfA]

Thus only on this code it is possible to receive 5 patents of addition which will be already never received.
Never is right BTW. At least here in Europe, unless it's patent pending the binary release of SIF is prior art for any patents concerning techniques used in it even for your own patents. No grace period here (which I think is unfortunate, if we have to have patents I'd rather have them with a grace period ... although I'd prefer not to have algorithm patents at all).

Even in the countries with grace periods the clock is ticking.

[Dark Shikari]

Never is right BTW. At least here in Europe, unless it's patent pending the binary release of SIF is prior art for any patents concerning techniques used in it even for your own patents. No grace period here (which I think is unfortunate, if we have to have patents I'd rather have them with a grace period ... although I'd prefer not to have algorithm patents at all).

Even in the countries with grace periods the clock is ticking.Software patents in Europe are dubious to begin with.

[Neiromaster]

Never is right BTW. At least here in Europe, unless it's patent pending the binary release of SIF is prior art for any patents concerning techniques used in it even for your own patents.


1) I do not plan to receive any patents for the previously mentioned technologies. I'm not have any physical and financial possibilities for receive of such number of patents. If I possessed firm having corresponding financial possibilities I would fix the rights for this codec receive 10-15 patents. But as I could not make it I have decided to receive patent for key technology used in this codec. I have make other technologies to public property, having some as a know-how.

2) Practically in all blocks of this codec original, technical decisions not having analogues are used. Unlike other alternative codecs it is really original working out, instead of as usually a variant of the present codec with some changes.

3) To use binary release as prior art it is necessary to prove that the certain technology in it is used. If the submitting patent is the author of binary release it is difficult enough. ;)

4) Such things usually are not patented as algorithms or programs. Such things are patented as a method or the system. Legal receptions of recieve of such patents are well developed. Examples to find not difficult, it is enough to look patents for technologies used in H264.

[PatchWorKs]

1) I do not plan to receive any patents for the previously mentioned technologies. I'm not have any physical and financial possibilities for receive of such number of patents.
Then I believe that the best way is to keep in touch with Xiph.Org Foundation (http://www.xiph.org/): they are stong enough to protect your rights and - of course - can benefit from your work.

Once again: GPL (better if v3) is the most efficient way to keep Microsoft (and almost any other BIG players... rippers - aka bad peoples that steal open softwares and resells as own/closed - have short life if your work will become popular) away from your work. Avoid BSD/MIT and similar, trust me.

[Neiromaster]

Next version of SIF1 has been released.

To download SIF1 it is possible from here (http://mysif.ru/SIF1_dd_Eng.htm).

The text of SIF-compression patent can be found here (http://mysif.ru/Patent.htm).

The Easy-to-understand description of features of SIF-compression technology can be found here (http://mysif.ru/O_SIF_En.htm).

Demonstration video fragments can be downloaded from there (http://mysif.ru/SIF1VidEn.htm).

Description of SIF1 settings can be found here (http://mysif.ru/WorkSif1_En.htm).

Latest source code of SIF1 decompressor can be downloaded from here (http://mysif.ru/SIF1_dd_Eng.htm).

History of versions


1.10
1) The source code of the motion compensation engine was restructured.

2) All main DSP engines of the decoder has been optimized for multithreading execution. Up to 32 parallel threads are supported.

3) Internal parametres of SIF compression core has been optimized and simultaneously the psychovisual model is once again improved. Clearness and image detailing have very considerably increased as a result.

4) The error in a compression core has been corrected. This error has been to reveal itself in the codec if the vertical image size is not multiple of 32.

5) The error in a codec has been corrected. Because of this error the codec had fall on the old computers which did not supports of SSE instructions. Thanks for testing to Alexander Budchanin.

[MasterNobody]

2) All main DSP engines of the decoder has been optimized for multithreading execution. Up to 32 parallel threads are supported.
Multithreading is working and this is good. But I wouldn't say (as you write in Russian changelog):
В результате декодирование Full-HD теперь возможно на любом современном двухядерном процессоре с тактовой частотой не ниже 2 гигагерц.
Because realtime (50 fps) decoding of this sample (http://forum.doom9.org/showthread.php?p=1401568#post1401568) is still not possible on Core i7-860 system (no overclock/downclock. TB/HT both enabled).
Tests showed:
sif1 1.01 ~22 fps @ 12.5-13% CPU
sif1 1.10 ~40 fps @ 62-64% CPU
Seems to utilize 8 threads according to Process Explorer: 1-thread 12.5% + 7-threads about 7-7.5%).
For example, H264 sample of same size with placebo settings (so near maximum complexity) decoded by CoreAVC (software mode):
CoreAVC ~50 fps @ 13% CPU

[Neiromaster]

Multithreading is working and this is good. But I wouldn't say (as you write in Russian changelog):

Because realtime (50 fps) decoding of this sample (http://forum.doom9.org/showthread.php?p=1401568#post1401568) is still not possible on Core i7-860 system (no overclock/downclock. TB/HT both enabled).
Tests showed:
sif1 1.01 ~22 fps @ 12.5-13% CPU
sif1 1.10 ~40 fps @ 62-64% CPU
Seems to utilize 8 threads according to Process Explorer: 1-thread 12.5% + 7-threads about 7-7.5%).
For example, H264 sample of same size with placebo settings (so near maximum complexity) decoded by CoreAVC (software mode):
CoreAVC ~50 fps @ 13% CPU

Please turn off HT and test this again.
I'm not have i7 cpu, and not test it on him.
On Core2@2.5 cpu FullHD with 24 fps utilize 70-80% CPU.
FullHD with 50 fps is non standart FullHD move.
And in this code entropy codec is not parallelized. It will be parallelized in the future.
And before comparing with CoreAVC it is necessary to remember that it does not use now any SSE instructions.
It only twice more slowly CoreAVC now if to consider wrong calculation of loading CPU at if HT it is included.

[PatchWorKs]

Uhm... I believe that Google could be interested in your work.

Try to keep in touch with them: http://www.webmproject.org/about/discuss/ ;)

[Neiromaster]

Uhm... I believe that Google could be interested in your work.

Try to keep in touch with them: http://www.webmproject.org/about/discuss/ ;)

I have transmitted message in their mailing list - I will look that they will respond.

[Neiromaster]

As I thought, there have not become interested.
100 million paid for VP8 will not allow to them to make it. :)

[MasterNobody]

Please turn off HT and test this again.
Results with HT disabled:
sif1 1.10 ~40 fps @ 65-68% CPU
Seems to utilize 4 threads according to Process Explorer: 1-thread 25% + 3-threads about 13-14%). So near the same as with HT enabled.
And in this code entropy codec is not parallelized. It will be parallelized in the future.
Seems this is the issue because CPU use of one of the threads is maximized.
FullHD with 50 fps is non standart FullHD move.
May be it not standard at Blu-ray (currently) but it is standard in other places or at least will be in near future (read this: 1080p#Broadcasting_standards (http://en.wikipedia.org/wiki/1080p#Broadcasting_standards))

[Neiromaster]

Results with HT disabled:
sif1 1.10 ~40 fps @ 65-68% CPU
Seems to utilize 4 threads according to Process Explorer: 1-thread 25% + 3-threads about 13-14%). So near the same as with HT enabled.

It is good, as I seriously was afraid that the HT strongly spoils a overall performance of the decoder.
But you have not resulted processor loading when CoreAVC is running. At the switched off HT, load should be 25%.
Taking into account that by operation of the CoreAVC the TB is worked, and by operation of the SIF1 TB is not worked.

have
(65*2.80*40) /(25*3.46*50)~=1,68
Thus the SIF1 more slowly the CoreAVC only in 1,7 times.
It will well be co-ordinated with my data on the ffdshow-mt, which faster the SIF1 in less than in 1.6 times.



Seems this is the issue because CPU use of one of the threads is maximized.

It is natural, because multithreading is not using in the entropy codec.


May be it not standard at Blu-ray (currently) but it is standard in other places or at least will be in near future (read this: 1080p#Broadcasting_standards (http://en.wikipedia.org/wiki/1080p#Broadcasting_standards))

If you think that by then when it will be widely distributed the SIF it not be decode it fine , you are very naive. :)

[MasterNobody]

It is good, as I seriously was afraid that the HT strongly spoils a overall performance of the decoder.
But you have not resulted processor loading when CoreAVC is running. At the switched off HT, load should be 25%.
Yes. Without HT CoreAVC is about 28% (1-thread 8% + 4-threads about 5%).
Taking into account that by operation of the CoreAVC the TB is worked, and by operation of the SIF1 TB is not worked.

have
(65*2.80*40) /(25*3.46*50)~=1,68
Thus the SIF1 more slowly the CoreAVC only in 1,7 times.
Not correct. TB works with both. SIF1 @ ~3100 MHz, CoreAVC @ ~3200 MHz. Also you formula is incorrect. You need to divide on achived fps not multiply (because we count how much CPU power will need 50 fps so 50/<achived fps> but 50 is shorten from both sides). So here is result:
(65*3.1/40) / (28*3.2/50) =~ 2,8
If you think that by then when it will be widely distributed the SIF it not be decode it fine , you are very naive. :)
I will ignore this (I am not sure who is more naive among us :) ).

[Neiromaster]

Yes. Without HT CoreAVC is about 28% (1-thread 8% + 4-threads about 5%).

Last time I used the CoreAVC when it was the one-thread application. It was long ago..


Not correct. TB works with both. SIF1 @ ~3100 MHz, CoreAVC @ ~3200 MHz. Also you formula is incorrect. You need to divide on achived fps not multiply (because we count how much CPU power will need 50 fps so 50/<achived fps> but 50 is shorten from both sides). So here is result:
(65*3.1/40) / (28*3.2/50) =~ 2,8

Yes you are right it is necessary to divide.
Then it turns out that on the i7 it goes more slowly than on the Core2. It is necessary to buy probably the i7 to study it.

Whether you also will test the ffdshow-mt for a complete collection of speeds?



I will ignore this (I am not sure who is more naive among us :) ).

Time will tell :)

[MasterNobody]

Whether you also will test the ffdshow-mt for a complete collection of speeds?
No, I don't want to install ffdshow. But I can tell you that integrated H.264 decoder in MPC-HC (single threaded, based on ffmpeg) results in (HT disabled):
MPC-HC 50 fps @ 24% CPU @ 3300 MHz

P.S. So even faster than CoreAVC if use your formula (but it doesn't count many other aspects)

[Neiromaster]

No, I don't want to install ffdshow. But I can tell you that integrated H.264 decoder in MPC-HC (single threaded, based on ffmpeg) results in (HT disabled):
MPC-HC 50 fps @ 24% CPU @ 3300 MHz

P.S. So even faster than CoreAVC if use your formula (but it doesn't count many other aspects)

I precisely know MPC-HC uses the hardware acceleration.
And I precisely know that it there cannot be disabled.
Most likely the CoreAVC too used a hardware acceleration.
But I precisely know that the ffmpeg-mt does not use a hardware acceleration. Having compared digits it is possible to instal true easily. After that I am not inclined to trust your measurements result of the CoreAVC.

[MasterNobody]

I precisely know MPC-HC uses the hardware acceleration.
And I precisely know that it there cannot be disabled.
Most likely the CoreAVC too used a hardware acceleration.
I precisely know that you incorrect because DXVA *can be disabled* in MPC-HC (also it not work for this H.264 sample due the DXVA limits). And CoreAVC+CUDA use only 12% CPU.

[mariush]

^ But that's basically cheating. Instead of using the CPU you're using the video card's cpu - you want the cpu to be used less to save power mainly and with coreavc + cuda you just move the processing to video card which probably uses more power and does more heat.

I guess this way I could also make up a filter that takes the compressed frames, sends them to another pc for decompression and then gets them uncompressed from the other pc and wow, the player uses 2-5% cpu in network interrupts and memory copies.

Get one of those Kill a watt (http://www.p3international.com/products/special/P4400/P4400-CE.html) meters and compare power usage between cpu only, dxva and cuda decodings - though the difference will probably be just a few watts.

DXVA is really cheap on my 4850 - about 5-8% cpu to decode 1080p with 5.1 dts audio track on a Q6600 slightly overclocked to 2.5 ghz. With DXVA disabled it tops at about 15% with the built in ffmpeg codec.

[Neiromaster]

I precisely know that you incorrect because DXVA *can be disabled* in MPC-HC (also it not work for this H.264 sample due the DXVA limits). And CoreAVC+CUDA use only 12% CPU.

It is easy for checking up - it is necessary to select the Haali Renderer as output. In such conditions my MPC-HC v1.2.1008 cannot use the built in decoder at all. It occurs because the Haali Renderer does not allow to use a hardware acceleration. There can be you use other version of the MPC-HC, but for me so. In too time speed of all program decoders considerably increases from Haali Renderer as output. Probably the EVR Renderer very strongly decelerates program decoders, or it is feature of a MPC-HC. So to always check up in correct conditions it possible.

[Neiromaster]

Has now checked up - inclusion of the EVR Renderer instead of a Haali Renderer decelerates a ffmpeg-mt on ~20 %.
To the SIF1 occurs too most.

[MasterNobody]

It is easy for checking up - it is necessary to select the Haali Renderer as output.
All this test numbers was with "Haali Renderer" (because I always use it). I used "VMR-9 (windowed)" only once to check could DXVA decode this sample or not (not EVR Renderer because I am on WinXP so DXVA only works in Overlay Mixer, VMR-7, VMR-9) and the answer was no.

P.S. And don't take position "You are idiot, you can't correctly test" only because you don't like results. Result are fair because I know how to correctly compare such things. If you don't trust anyone (who had his free time to test your codec) then say so but not suppose that others are stupid.

[Neiromaster]

All this test numbers was with "Haali Renderer" (because I always use it). I used "VMR-9 (windowed)" only once to check could DXVA decode this sample or not (not EVR Renderer because I am on WinXP so DXVA only works in Overlay Mixer, VMR-7, VMR-9) and the answer was no.

Well, thanks for testing. I will work further over codec improvement.


P.S. And don't take position "You are idiot, you can't correctly test" only because you don't like results. Result are fair because I know how to correctly compare such things. If you don't trust anyone (who had his free time to test your codec) then say so but not suppose that others are stupid.

I did not tell it, but it is natural reaction recognising that I knew about the MPC-HC.

[nakTT]

Next version of SIF1 has been released.

To download SIF1 it is possible from here (http://mysif.ru/SIF1_dd_Eng.htm).

The text of SIF-compression patent can be found here (http://mysif.ru/Patent.htm).

The Easy-to-understand description of features of SIF-compression technology can be found here (http://mysif.ru/O_SIF_En.htm).

Demonstration video fragments can be downloaded from there (http://mysif.ru/SIF1VidEn.htm).

Description of SIF1 settings can be found here (http://mysif.ru/WorkSif1_En.htm).

Latest source code of SIF1 decompressor can be downloaded from here (http://mysif.ru/SIF1_dd_Eng.htm).

History of versions


1.10
1) The source code of the motion compensation engine was restructured.

2) All main DSP engines of the decoder has been optimized for multithreading execution. Up to 32 parallel threads are supported.

3) Internal parametres of SIF compression core has been optimized and simultaneously the psychovisual model is once again improved. Clearness and image detailing have very considerably increased as a result.

4) The error in a compression core has been corrected. This error has been to reveal itself in the codec if the vertical image size is not multiple of 32.

5) The error in a codec has been corrected. Because of this error the codec had fall on the old computers which did not supports of SSE instructions. Thanks for testing to Alexander Budchanin.

Glad that finally this alternative encoder has been updated. Keep up the good work.

[DarkNite]

I did not see any mention of height or width restrictions on your settings page. A single sentence added to your initial advice paragraph would be sufficient.

The best way to resize the original video is to use interpolation functions of maximum quality from those available. To obtain the best result, I recommend using Spline64Resize function from AviSynth package instead of LanczosResize function.

Perhaps it could be changed to:

The best way to resize the original video is to use interpolation functions of maximum quality from those available. To obtain the best result, I recommend using Spline64Resize function from AviSynth package instead of LanczosResize function. The resulting horizontal image size should be a multiple of 32, and the vertical image size should be a multiple of 16.

[Neiromaster]

I did not see any mention of height or width restrictions on your settings page. A single sentence added to your initial advice paragraph would be sufficient.

Well, I will add it. In current version of the codec horizontal and vertical image size should be a multiple of 16. But I will make in the future version of the codec that the vertical image size should be a multiple of 4.

[buzzqw]

Hi Neiromaster

i tested your codec, and i like it :)

good performance and good quality, for a starting codec is well done

would be possible to have a command line executable with avs input support and avi output (or mkv) ?
with all features of vfw..

i will like to add support in my gui

thanks

BHH

[DarkNite]

Thank you Neiromaster. I am sure that will save a few people from the frustrations of trial and error. Keep up the good work.

[Neiromaster]

would be possible to have a command line executable with avs input support and avi output (or mkv) ?


I will add it in the my plans.
In current plans. I'm going to released SIF1 encode/decode library with documentations for API. It will allow to use SIF1 encoding/decoding in other programs. Also I am going to make such library under Linux. I reflect under what licence to release the library, but I think it will be royalty free.

Open source code of the encoder is not meaningful at the given stage for following reasons:

1) It very much a complex code for which there is no normal documentation.
2) It uses the same style of programming, as a source code of the decoder.

Thus nobody will help the project, until encoder will not be have a good documentation and a source code of the encoder will not be restructured in a canonical form. I will work for it, but for given time it is more important to release a source code of the decoder in a canonical form and to write documentation on a format.

Current priorities in work are that:

1) Improve motion estimation engine and make quarter-pel motion compensation.
2) Multi-threaded entropy codec.
3) Release a source code of the decoder in a canonical form and write documentation on a format.
4) Release SIF1 encode/decode library with documentations for API.

[buzzqw]

thanks for your hard work Neiromaster!

i will wait, thanks

BHH

[Selur]

I second that a command line version would be fine. (but I would prefer yv12 input via pipe which would allow the use of mencoder and ffmpeg for decoding)

[Dreadwock]

As I thought, there have not become interested.
100 million paid for VP8 will not allow to them to make it. :)

Maybe you could collaborate with Xiph.org? It shouldn't be a problem to open source the codec but still have a patent on it, like On2 Tech. did with their VP3 codec when founding Theora. There are a lot types of licences and maybe someone from Xiph could help you with this?

And one more thing - you say on your website that SIF1 is the only one codec that support ABR encoding and that's not true - the new ffmpeg2theora has such an encoding model, enabling even the minimum desired quality with target bitrte. And it is also possible with 2-pass encoding. Altough the video qualirty is far worse then SIF1, but ther's a constant developing progress.

By the way it's nice to see some new ideas in video coding.
Cheers

[Neiromaster]

Maybe you could collaborate with Xiph.org?

I am ready to co-operate with any company having interest to it. But in this case I'm not understand to whom from Xiph.org necessary to apply with this question. In addition, I have certain interests in the given project and all depends on that are ready to consider them in Xiph.org.



And one more thing - you say on your website that SIF1 is the only one codec that support ABR encoding and that's not true - the new ffmpeg2theora has such an encoding model, enabling even the minimum desired quality with target bitrte.

It has been written for a long time and at that point in time it was the truth. If to you it very much disturbs, I will remove it. But it is not enough to make ABR mode. It will not be good to work without qualitative psychovisual model. In the SIF1 psychovisual model the best from this that is in the market.

[tuqueque]

Hello Neiromaster.

If you want to get in contact with the Xiph people, you can write to their mailing list:

http://lists.xiph.org/pipermail/theora/

(To write to their mailing list you just have to write an email to theora at xiph.org . It can take some days to get a response though, so be patient).

You can contact directly one of this Xiph developers/maintainers:

xiphmont at xiph.org

gmaxwell at gmail.com

'Hope this helps... Good luck!

[nakTT]

Hi Neiromaster

i tested your codec, and i like it :)

good performance and good quality, for a starting codec is well done

would be possible to have a command line executable with avs input support and avi output (or mkv) ?
with all features of vfw..

i will like to add support in my gui

thanks

BHH
Glad to hear that. Looking forward to it. Keep up the good work.

:thanks:

[ckmox]

ah i found the latest thread, lol i was replying on this old thread -> http://forum.doom9.org/showthread.php?p=1496252#post1496252

anyway is their any status/update for this codec? please make this open source lol, it looks great it does not have blocking artifacts at 260kbps and in action scenes like this -> http://www.mysif.ru/Avi/Matrix_tr.avi the compression artifacts looks like psy-rd effects to my eyes so its not that bad it looks very good imo

[Neiromaster]

Аnyway is their any status/update for this codec?

SIF project isn't dead because undead can't die ;)

The SIF have been intensively developed in underground all this time.
Release of the new version of the SIF is already close.

Currently have done:
1) The motion estimation engine have been restructured and optimized for multi-threading execution (up to 32 threads.)
2) Due to the significant improvement in motion estimation engine in the famous test park_joy visual quality close to a x264 in a Simple Profile with placebo preset.
3) The entropy codec have been optimized for multi-threading execution (up to 8 threads.) Thus the decoder is now fully parallelized and can decode hi-bitrate video streams up to 80 megabit or more.
4) Added support for video with vertical resolution is not multiple of 16.
5) Have been made different presets in terms of speed & quality in motion estimation engine.
6)The correctness control of input data have been made. Now decoder does not fall when decoding the broken files.
7)The preset have been made for a fast first pass compression - It is two times faster than the base preset for two pass compression.

This will be done:
1) New RD extrapolation engine for the motion estimation engine + support new higher-quality presets in motion estimation engine.


When all of the planned tasks will be made - new version of the codec will be released.

[CruNcher]

SIF project isn't dead because undead can't die ;)

The SIF have been intensively developed in underground all this time.
Release of the new version of the SIF is already close.

Currently have done:
1) The motion estimation engine have been restructured and optimized for multi-threading execution (up to 32 threads.)
2) Due to the significant improvement in motion estimation engine in the famous test park_joy visual quality close to a x264 in a Simple Profile with placebo preset.
3) The entropy codec have been optimized for multi-threading execution (up to 8 threads.) Thus the decoder is now fully parallelized and can decode hi-bitrate video streams up to 80 megabit or more.
4) Added support for video with vertical resolution is not multiple of 16.
5) Have been made different presets in terms of speed & quality in motion estimation engine.
6)The correctness control of input data have been made. Now decoder does not fall when decoding the broken files.
7)The preset have been made for a fast first pass compression - It is two times faster than the base preset for two pass compression.

This will be done:
1) New RD extrapolation engine for the motion estimation engine + support new higher-quality presets in motion estimation engine.


When all of the planned tasks will be made - new version of the codec will be released.

Hehe who knows maybe in the future VP9 will be based on SIF eh ;) ?
and what are you referring to by "Simple Profile" ? that as you know doesn't exist in H.264 specs, i guess you referring to a simple complexity but what comparable complexity exactly or do you mean compared to SIF Simple Profile complexity ? ;)
So SIF Simple Profile comes close to X264 High Profile placebo now ? that would be indeed a marvelous achievement especially if you reach that @ the same or lower encoding speed :)

[ckmox]

@Neiromaster

thats good news, thanks for the effort, will the next version of SIF1 be ready for real encoding then? i mean will their be a CLI encoder for SIF1?

[Neiromaster]

Hehe who knows maybe in the future VP9 will be based on SIF eh ;) ?

Maybe. Time will tell.
The big work it is necessary to make in the future.
I think it is required not less than three years of a hard work that it was ready for commercial use.



and what are you referring to by "Simple Profile" ?

Yes I meant the Baseline profile. Sorry.
I'm talking about this file: http://doom10.org/compare/x264baseline.mkv


SIF now looks approximately so. At the same size certainly.
SIF is close to x264@Baseline at coding HD video.
On low resolution x264@Baseline look slightly better.



So SIF Simple Profile comes close to X264 High Profile placebo now ? that would be indeed a marvelous achievement especially if you reach that @ the same or lower encoding speed :)

No. The big hard work should be made, before the SIF1 speed and quality will be comparable to x264 @ High Profile.

[Neiromaster]

@Neiromaster

thats good news, thanks for the effort, will the next version of SIF1 be ready for real encoding then? i mean will their be a CLI encoder for SIF1?

No. It is necessary to make one more intermediate version before the SIF1 CLI will be ready.

Still there is a big block of the code which is necessary a restructuring. Only then I can make the portable code under Linux. Also now some things necessary for real encoding aren't made. But I assiduously work over it.

[ckmox]

@Neiromaster

looks like your the only one working on this codec, good luck with it, it looks very promising :)

[vivan]

Neiromaster started writing the specification, and I'm translating it into English.
And it would be very nice if someone helped us with editing, since my knowledge of English is far from ideal... So if you want to help - please contact me via pm.

UPD: first part (General decoder structure and description of used algorithms) is published here: http://mysif.ru/en/specification.html
If there is something unclear - feel free to contact us...

[Neiromaster]

Next version of SIF1 has been released.

To download SIF1 it is possible from here (http://mysif.ru/en/codec.html).

The text of SIF-compression patent can be found here (http://mysif.ru/en/sif_patent.html).

The text of SIF1 video compression format specification can be found here (http://mysif.ru/en/specification.html).

The Easy-to-understand description of features of SIF-compression technology can be found here (http://mysif.ru/en/about_sif.html).

Demonstration video fragments can be downloaded from there (http://mysif.ru/en/demo.html).

Description of SIF1 settings can be found here (http://mysif.ru/en/sif1_settings.html).

Latest source code of SIF1 decompressor can be downloaded from here (http://mysif.ru/en/decoder_source_code.html).

Further plans

1) SIF transform core code restructurization and multithreaded optimization.

2) Adding a new higher-quality SIF transform modes through the use of PsyRD optimization.

3) Adding support for quarter-pixel motion compensation.

4) Writing a portable SIF1 encoding-decoding library for Linux.

5) Performing SSE2 and multiprocessor optimization of the current code.

6) Further development of new algorithms based on SIF-technology.


History of version

1.20

1) Motion detection engine was restructured and optimized for multithreaded operation (up to 32 threads). In current code multithreaded optimization is done using a temporal scheme since the core of SIF transform is the last big unit of code that is not working in multithreaded mode.

2) Added multithreaded modes of an entropy codec operation (up to 8 threads). Thus, the decoder now have full multithreading support and supports decoding of streams with 80+ mbits bitrate.

3) Codec now supports vertical resolution that is not a multiple of 16.

4) Implemented different (in terms of speed & quality) motion detection engine presets.

5) Added checking for correct input. Now the decoder doesn't crash on corrupt or invalid files.

6) Added turbo first pass mode - about two times faster than second in two-pass mode.

7) New PsyRD extrapolation engine, used in the motion detection engine, is written. Due to this, another significant improvement in sharpness and detail of compressed image was achieved.

[Neiromaster]

You can download (http://mysif.ru/Avi/ParkJoySif_1_20.avi) famous test Park joy encoded by the new version of the codec for demonstration of improvement in sharpness and detail in the new version.

For example, here it is possible to download (http://doom10.org/compare/x264baseline.mkv) Park joy, encoded x264 with Baseline&Placebo presets.

And here it is possible to download (http://doom10.org/compare/x264.mkv) Park joy, encoded x264 with pure Placebo presets.