SIF1 v1.20 was released

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

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.


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.


1.00

1) All basic blocs of codec has been practically fully rewritten. Functionality of compression core has been considerably improved.

2) Quality of compression has been enormous increased.

3) Support of full set of compression mode has been added.

4) Psychovisual model has been debugged and improved.

5) Codec format has been fixed and will publish like the open specification.

6) Unfortunately this version is not compatible with all previous versions, but its the last considerable changing of format.

[Neiromaster]

Interestingly, it seems local inhabitants have lost speech power.
Or the new codec is so bad? :)

[Shinobu]

i've just downloaded the sample file and it's not bad at all, i'll test the encoder with my own source with week (i own some very grainy mpeg2 bluray and some japanese hight quality bluray).
realy impressed from the sample file, for a new codec it seems realy good (from the sample files).
thanks for releasing the decoder opensource, if the encoder could be opensource, it will great too ^^ (i realy don't have the prog level to play with it but i'm sure it will interest some people of the forum ^^)

[nakTT]

Interestingly, it seems local inhabitants have lost speech power.
Or the new codec is so bad? :)
Hi, do I need any special software/decoder to play the encoded file?

:thanks:

[Shinobu]

yes you need to download the codec of the official website, play fine in mpc et wmp.

[LoRd_MuldeR]

To my surprise MPlayer does handle it too ;)

[nakTT]

yes you need to download the codec of the official website, play fine in mpc et wmp.
Hi,

Can the codec integrate seamlessly with VLC, GOM and WMP11?

:thanks:

[Atak_Snajpera]

Source Blu-ray h264

SIF1 - 1024kbps - 2pass - DOWNLOAD (http://www.mediafire.com/file/vzmyzdmmgey/SIF1-1024kbps-2pass.avi)
http://img194.imageshack.us/img194/5513/sif11024kbps2passavisna.th.png (http://img194.imageshack.us/i/sif11024kbps2passavisna.png/)

SIF1 reduced resolution to SD :rolleyes:


x264 - 1024kbps - 2pass - DOWNLOAD (http://www.mediafire.com/file/zhmjojdngmj/x264-1024kbps-2pass.mkv)
http://img44.imageshack.us/img44/3606/x2641024kbps2passmkvsna.th.png (http://img44.imageshack.us/i/x2641024kbps2passmkvsna.png/)

x264 is still sharp :)

[LoRd_MuldeR]

Yes, after a quick test I can say that it cannot compete with x264. But it beats Theora clearly. May depend on the source of course...

Examples encoded at 333 kbps:

http://img7.imageshack.us/img7/1863/sif11.png

http://img197.imageshack.us/img197/5088/sif12.png

[nakTT]

Source Blu-ray h264

SIF1 - 1024kbps - 2pass - DOWNLOAD (http://www.mediafire.com/file/vzmyzdmmgey/SIF1-1024kbps-2pass.avi)
http://img194.imageshack.us/img194/5513/sif11024kbps2passavisna.th.png (http://img194.imageshack.us/i/sif11024kbps2passavisna.png/)

SIF1 reduced resolution to SD :rolleyes:


x264 - 1024kbps - 2pass - DOWNLOAD (http://www.mediafire.com/file/zhmjojdngmj/x264-1024kbps-2pass.mkv)
http://img44.imageshack.us/img44/3606/x2641024kbps2passmkvsna.th.png (http://img44.imageshack.us/i/x2641024kbps2passmkvsna.png/)

x264 is still sharp :)
Judging by your screenshots, I guess I will not going to test the encoder this time around. Hope the developer will work on it even more to increase quality.

[Neiromaster]

Source Blu-ray h264

SIF1 - 1024kbps - 2pass - DOWNLOAD (http://www.mediafire.com/file/vzmyzdmmgey/SIF1-1024kbps-2pass.avi)
http://img194.imageshack.us/img194/5513/sif11024kbps2passavisna.th.png (http://img194.imageshack.us/i/sif11024kbps2passavisna.png/)

SIF1 reduced resolution to SD :rolleyes:


x264 - 1024kbps - 2pass - DOWNLOAD (http://www.mediafire.com/file/zhmjojdngmj/x264-1024kbps-2pass.mkv)
http://img44.imageshack.us/img44/3606/x2641024kbps2passmkvsna.th.png (http://img44.imageshack.us/i/x2641024kbps2passmkvsna.png/)

x264 is still sharp :)

Choice of a correct screenshot this big art. :)
Two screenshots from the same example.

http://img15.imageshack.us/img15/7641/sifpr.th.png (http://img15.imageshack.us/i/sifpr.png/)

SIF1

http://img15.imageshack.us/img15/3553/x264pr.th.png (http://img15.imageshack.us/i/x264pr.png/)

x264

It is not enough 1 megabit for this example. And for X264 too.

For an example.

http://img40.imageshack.us/img40/393/x264pr1.th.png (http://img40.imageshack.us/i/x264pr1.png/)

x264 Shows HD quality :)

http://img40.imageshack.us/img40/7615/sifpr1.th.png (http://img40.imageshack.us/i/sifpr1.png/)

SIF1 Too

In any case the codec with quarter-pel motion compensation will always show the big sharpness, than the codec with half-pel motion compensation.

Therefore I suggest to use Spline64Resize which adds sharpnesses in a picture.

At compression with acceptable bitrate the difference not so is great especially on HD.

In any case, sooner or later in SIF1 too there will be quarter-pel motion compensation.

[Neiromaster]

By the way, quality of compression of this example could be improved.
If it is necessary to compress a strongly noisy source in the two-passes моде, on the first pass it was necessary to establish value V.D. Around 100 or above.
Otherwise occurs overcompression on dark scenes.

[Shinobu]

from my first quick tests i can say that on clear hd sources i found x264 better but on very grainy source, the sif1 done a better job on most samples at low, medium bitrates (lest washed out image)
i'm looking for it, but i think if sif1 encoder was opensource it would realy be great ^^
i need to test it more, these impressions was done on 7-15min bluray/dvd samples (need to test more x264 settings too).

[Dark Shikari]

Source Blu-ray h264

SIF1 - 1024kbps - 2pass - DOWNLOAD (http://www.mediafire.com/file/vzmyzdmmgey/SIF1-1024kbps-2pass.avi)
http://img194.imageshack.us/img194/5513/sif11024kbps2passavisna.th.png (http://img194.imageshack.us/i/sif11024kbps2passavisna.png/)

SIF1 reduced resolution to SD :rolleyes:


x264 - 1024kbps - 2pass - DOWNLOAD (http://www.mediafire.com/file/zhmjojdngmj/x264-1024kbps-2pass.mkv)
http://img44.imageshack.us/img44/3606/x2641024kbps2passmkvsna.th.png (http://img44.imageshack.us/i/x2641024kbps2passmkvsna.png/)

x264 is still sharp :)Looks like SIF is using transforms that are too large. The visual energy from high-complexity areas is overflowing into low-complexity areas because of this.In any case the codec with quarter-pel motion compensation will always show the big sharpness, than the codec with half-pel motion compensation.Completely wrong; at least with H.264, halfpel retains much more sharpness than qpel due to the 6-tap filter.

Either way, I don't consider grain retention to be that interesting a problem. If you're creating a custom video format, you can simply add grain in decoding as postprocessing; this doesn't say anything about good your encoder is in the general case.

The only reason to test grain retention is when dealing with a situation in which you can't add grain during decoding, such as when you want to encode video in an existing video format and decode it in situations in which you don't have control over the decoder. This is why people care about grain retention with x264: we can't simply modify our Blu-ray players to add grain on playback. But if you're starting from scratch with something custom, you can do whatever the hell you want.

This is why the standard test clips are so popular: they aren't lowpassed, grainy messes like most DVDs and Blu-rays and thus provide a perfect test of how efficient an encoder is, rather than how well a decoder can fake the grain.

Finally, note that extremely low bitrates inherently bias towards whatever encoder uses the largest transform size. Once your quantizers in H.264 are over ~35-40, you generally should just encode at a lower resolution by downscaling the video. The same thing happens with JPEG-2000 and JPEG; JPEG-2000 beats JPEG handily once the compression ratio is above about 50:1, but at such a high compression ratio you should been downscaling the image anyways. And when you do, JPEG often wins.

If you encode 720p film at 500kbps, x264 should lose to, for example, a good wavelet encoder. H.264 is not designed for the kind of spatial scalability necessary for such stupid encoding situations. Just downscale the video instead--from what I can tell, SIF is effectively doing the same internally anyways, given how heavily its low bitrate encodes are lowpassed.

[Neiromaster]

I apologise for machine translation, but such text too long to write on English.

Looks like SIF is using transforms that are too large. The visual energy from high-complexity areas is overflowing into low-complexity areas because of this.

No. And for many reasons.

1) SIF this adaptive transformation using many various ways of compression depending on local parametres of a signal. To compare it with wavlet transformations incorrectly.

2) Minimum from resampling patterns assumes direct quantization of pixels without any transformation. Like that mode that there will be as a variant in h265, only more flexible as operates with a pattern 2x2 pixel. By the way in a new kernel of compression after core-6 I will enter also patterns 2x1 for even more flexibility.

3) All other used patterns have adaptive filters with the variable size. The size of the filter is dynamically switched for minimisation ringing artefacts around sharp transitions.

4) Therefore SIF practically does not give ringing artefacts without any postfiltration, and perfectly well compresses anime.

Completely wrong; at least with H.264, halfpel retains much more sharpness than qpel due to the 6-tap filter.

Too it is not absolutely true.
In the previous explanation I have very much simplified a situation not to go into detail.

In a reality, at weak movings of sharp borders half-pel compensation cannot adequately combine two pictures and residual energy of a signal gives increase in high-frequency components interframe differences. The codec should compress everyone frame much more the data, than at better motion compensation. It leads to overestimate of levels of quantization and accordingly to picture smoothing.
By working out of the experimental codec of the standard h26l the predecessor h264 experiments on various modes of indemnification of movement were made. By results of these experiments it has been established that half-pel motion compensation with long filters practically does not give to any increase to efficiency of compression. In h264 long half-pel the filter serves for creation of a good reference point, for the subsequent quarteri-pel to interpolation. Such scheme has been accepted for acceleration of calculation of vectors of movement and in h265 it will replace.

In especially hard cases, like uniform movement of a contrast caption in the end of a film, the difference between the codec with half-pel motion compensation and the codec with quarteri-pel can reach two times.

Either way, I don't consider grain retention to be that interesting a problem. If you're creating a custom video format, you can simply add grain in decoding as postprocessing; this doesn't say anything about good your encoder is in the general case.

Grain saving was not the purpose of the given development.
In this case this consequence of solution of other problem. In-loop filters in spoil low-frequency components on the picture leading to effect plastic face etc.
The it is better these filters, the this effect is less expressed. In H264 these filters the best, but all the same the effect is present.
And this basic weak place of all modern codecs.
Accordingly an overall objective of development SIF of compression was to make the modern codec well compressing without In-loop filters.


Finally, note that extremely low bitrates inherently bias towards whatever encoder uses the largest transform size. Once your quantizers in H.264 are over ~35-40, you generally should just encode at a lower resolution by downscaling the video. The same thing happens with JPEG-2000 and JPEG; JPEG-2000 beats JPEG handily once the compression ratio is above about 50:1, but at such a high compression ratio you should been downscaling the image anyways. And when you do, JPEG often wins.

The codec with in-loop the filter should encode the video with redundant quality that the effect from this filtering has not been observe. And than is worse in-loop the filter those above should lift up quality. For example PSNR for RV10 remarkable, and visual quality all bad.
If to measure PSNR for SIF and for H264 it will appear that for SIF PSNR awful, but it is not strongly mirrored in real visual quality. Thus if to improve all parts SIF to level x264 visually SIF will win at equal levels PSNR.
It is the task of the given project.

[Atak_Snajpera]

Choice of a correct screenshot this big art.

SIF
http://img18.imageshack.us/img18/5513/sif11024kbps2passavisna.th.png (http://img18.imageshack.us/i/sif11024kbps2passavisna.png/)

I really do not like this "chessboard effect". Letters lost sharpness as well.

x264
http://img30.imageshack.us/img30/3606/x2641024kbps2passmkvsna.th.png (http://img30.imageshack.us/i/x2641024kbps2passmkvsna.png/)

Somehow x264 managed to retain sharpness :)

[IgorC]

Yes, after a quick test I can say that it cannot compete with x264. But it beats Theora clearly. May depend on the source of course...

Comparing to Theora has no sense. Utterly old Divx3 is better than Theora.
Some people said that SIF1 is already better than Xvid,VC-1 and VP6.

[nakTT]

Comparing to Theora has no sense. Utterly old Divx3 is better than Theora.
Some people said that SIF1 is already better than Xvid,VC-1 and VP6.
Really looking forward for the latest update. Hope the developer will update it as frequent as x264. For me, in the world of advanced video encoder, the more the merrier.

:thanks:

[Neiromaster]

SIF
http://img18.imageshack.us/img18/5513/sif11024kbps2passavisna.th.png (http://img18.imageshack.us/i/sif11024kbps2passavisna.png/)

I really do not like this "chessboard effect". Letters lost sharpness as well.

x264
http://img30.imageshack.us/img30/3606/x2641024kbps2passmkvsna.th.png (http://img30.imageshack.us/i/x2641024kbps2passmkvsna.png/)

Somehow x264 managed to retain sharpness :)

As I already spoke, this example is compressed so strongly that is outside of normal quality for any codec.

In addition, from for incorrectly exposed customisations of the first pass has occurred overcompressed on dark scenes.
For an example, I advise to compress that example in quality based mode - quality will increase.

SIF, as well as any codec without postfiltering has marginal level V.D. After which excess the picture starts to degrade fast. In this case blocks of motion compensation are visible. SIF-transformation of squares does not give.
And at normal levels of compression such does not occur.

With the same success I can disable the postfilter in x264 and show that it will turn out.;)

Do not frighten local people :)

[Atak_Snajpera]

Do not frighten local people
I'm just showing that SIF at current state is far behind x264.

SIF - 1024 kbps - 1280x720@50fps
http://www.mediafire.com/file/ojmk5dxgzjm/SIF-footbal.avi

x264 - 1024 kbps - 1280x720@50fps
http://www.mediafire.com/file/mw12jjrmomm/x264-football.mkv

This time without screenshots. You should judge yourself what looks better for you in movement.

If I had option to watch live match via internet I would definitely choose x264.

[Dark Shikari]

I apologise for machine translation, but such text too long to write on English.Your post is completely unreadable and I cannot understand more than about three words of it. Machine translation is useless; don't waste your time responding if you have to use machine translation. You have much better things you can do with your time, like improve SIF ;)3) All other used patterns have adaptive filters with the variable size. The size of the filter is dynamically switched for minimisation ringing artefacts around sharp transitions.

4) Therefore SIF practically does not give ringing artefacts without any postfiltration, and perfectly well compresses anime.Then why is every screenshot in this thread a ringy mess? SIF has worse ringing problems than any other codec I have ever seen. If you could fix these, it might do a lot better.In especially hard cases, like uniform movement of a contrast caption in the end of a film, the difference between the codec with half-pel motion compensation and the codec with quarteri-pel can reach two times.And yet x264 actually biases against the use of qpel despite how useful you claim it to be. Of course, this is because of H.264's flawed qpel algorithm, which relies too heavily on bilinear interpolation.

I'm not at all against research into better techniques--H.264 has many flaws and can surely be beaten--but there's no need to be overly defensive and try to pretend that problems don't exist.

Finally, you claim SIF1 to be "free", but if so, where is the source? It doesn't seem to have come with the download.

[Neiromaster]

I'm just showing that SIF at current state is far behind x264.

SIF - 1024 kbps - 1280x720@50fps
http://www.mediafire.com/file/ojmk5dxgzjm/SIF-footbal.avi

x264 - 1024 kbps - 1280x720@50fps
http://www.mediafire.com/file/mw12jjrmomm/x264-football.mkv

This time without screenshots. You should judge yourself what looks better for you in movement.

If I had option to watch live match via internet I would definitely chose x264.

And I also will not argue;)
I do not think that somebody will encode a football match in 1280x720x50 and with bitrate in one megabit.
In addition through the Internet it to transfer it will not turn out.
I think that it is encoded in VBR a mode and in two passes.
And such file cannot be transferred in live on a network.
Or I am not right?

[Dark Shikari]

Anyways, it's test time!

I don't at all expect SIF to get anywhere close to x264--it is certainly in early development while x264 is quite mature. But we can at least throw some tests at it. I've picked two random frames from it for comparison.

For comparison's sake, I've included "x264_hpel": a build of x264 that doesn't use qpel. As a result I had to disable a few other features that I couldn't easily adapt to avoid qpel (direct auto, bime), but it should be mostly fine. Obviously the purpose of this is to serve as a more fair comparison to SIF, which lacks qpel.

Source: LosslessKoishi.mkv (http://mirror05.x264.nl/Dark/LosslessKoishi.mkv)
Bitrate: 2000kbps
Output files (http://www.mediafire.com/?4ymnw2zm0dt)

Frame 86:

x264:
http://i35.tinypic.com/161j0yf.png

x264 hpel:
http://i35.tinypic.com/33ytgzr.png

sif1:
http://i33.tinypic.com/flbrqd.jpg

xvid:
http://i38.tinypic.com/2yzam4k.png

Frame 558:

x264:
http://i37.tinypic.com/2wn6ayp.png

x264 hpel:
http://i36.tinypic.com/zurz3s.png

sif:
http://i33.tinypic.com/2i1d5.png

xvid:
http://i36.tinypic.com/1yam11.png

Summary:

1) SIF isn't too bad--better than Xvid, but it primarily gets to its position by blurring everything. It seems like the "psy optimizations" in SIF are likely the standard CSF masking bullcrap which says that you should basically lowpass everything beyond the first couple frequency coefficients. I advise the developer of SIF to drop this immediately, as it looks terrible.

It's definitely a good start though.

2) I told you that hpel makes things sharper, not blurrier, than qpel ;)

[shark37]

This time without screenshots. You should judge yourself what looks better for you in movement.

If I had option to watch live match via internet I would definitely choose x264.

I would like to draw attention to the apparent problem of ghosting for SIF.

[Neiromaster]

Your post is completely unreadable and I cannot understand more than about three words of it. Machine translation is useless; don't waste your time responding if you have to use machine translation.
:confused:


Then why is every screenshot in this thread a ringy mess? SIF has worse ringing problems than any other codec I have ever seen.

I will try to explain on examples.
For an example, i took a small example with anime
Also has compressed it with two different bitrates.

The first example is compressed with bitrate lower than usually twice.
http://mysif.ru/Avi/Shangri-La1.avi

The second example is compressed with bitrate lower than usually three times.
http://mysif.ru/Avi/Shangri-La1.avi (http://mysif.ru/Avi/Shangri-La2.avi)

In the first case of a ring practically is not present

In the second it suddenly appears and becomes very strong.

It because at compression with normal bitrate the codec uses one set of functions.

And at very low bitrate it is necessary it will be switched to long filters, as causes a ring.

Actually it also uses Atak_Snajpera for misleading people.

In a reality on those bitrate which are really used for compression of a ring is not present.

If you could fix these, it might do a lot better.And yet x264 actually biases against the use of qpel despite how useful you claim it to be. Of course, this is because of H.264's flawed qpel algorithm, which relies too heavily on bilinear interpolation.

I will not use algorithm from H264.
I am going to use absolutely other algorithm for interpolation



I'm not at all against research into better techniques

R-D performance of 1/8-pel MCP on HD sequences (http://www.h265.net/2009/06/r-d-performance-of-18-pel-mcp-on-hd-sequences.html)

2-D non-separable adaptive interpolation filter (http://ftp3.itu.ch/av-arch/video-site/0610_Han/VCEG-AD08.zip)

directional AIF (http://ftp3.itu.ch/av-arch/video-site/0710_She/VCEG-AG21.zip)

For an example

Finally, you claim SIF1 to be "free", but if so, where is the source? It doesn't seem to have come with the download.

Source codes of that?
The codec?

The source code of the decoder is available a long time, but you apparently at all did not read it:
Easy-to-understand description of SIF (http://mysif.ru/O_SIF_En.htm)

оr it:

http://mysif.ru/Patent.htm

Otherwise would not ask questions concerning a ringing

[Dark Shikari]

:confused:Do I need to say it more simply? Machine translation is useless. It does not produce understandable output.I will not use algorithm from H264.
I am going to use absolutely other algorithm for interpolationI know; I was just explaining why in x264, qpel doesn't necessarily make things sharper.R-D performance of 1/8-pel MCP on HD sequences (http://www.h265.net/2009/06/r-d-performance-of-18-pel-mcp-on-hd-sequences.html)

2-D non-separable adaptive interpolation filter (http://ftp3.itu.ch/av-arch/video-site/0610_Han/VCEG-AD08.zip)

directional AIF (http://ftp3.itu.ch/av-arch/video-site/0710_She/VCEG-AG21.zip)

For an exampleYes, I read the JVT docs periodically in the hopes of them coming up with something not completely useless for once.Source codes of that?
The codec?

The source code of the decoder is available a long time, but you apparently at all did not read it:
Easy-to-understand description of SIF (http://mysif.ru/O_SIF_En.htm)

оr it:

http://mysif.ru/Patent.htm

Otherwise would not ask questions concerning a ringingI still don't see any source code. An english description is not source code. If you don't have source code available, your codec is not free software, it is proprietary.

[Atak_Snajpera]

I do not think that somebody will encode a football match in 1280x720x50 and with bitrate in one megabit.
Yes you are absolutely right! Nobody will encode football match with that settings using SIF1. It looks terrible compared to x264. It may not be detailed but at least it does not kill your eyes with this ghosting effect and weird analog distortion (on hd source it just looks odd). Also I don't like how some parts of grass move in SIF sample.

Actually it also uses Atak_Snajpera for misleading people.
What are you talking about? Codec must be efficient at all bitrates. (LOW - MED - HIGH).

[Neiromaster]

Do I need to say it more simply? Machine translation is useless. It does not produce understandable output.I know; I was just explaining why in x264, qpel doesn't necessarily make things sharper.Yes, I read the JVT docs periodically in the hopes of them coming up with something not completely useless for once.I still don't see any source code. An english description is not source code. If you don't have source code available, your codec is not free software, it is proprietary.

I have placed the reference to an source code in the first post.

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

Probably nobody has guessed to look at a page bottom. :)
Here a direct reference:

http://mysif.ru/Files/Sif1DecoderSource.zip

[Dark Shikari]

But what about the encoder?

[Neiromaster]

If somebody becomes interested in the codec, I can write the detailed documentation on a format

[Neiromaster]

But what about the encoder?

Encoder I can open in the future if there will be a real desire to help the project. While I do not see people who are ready to work over the project.

[LoRd_MuldeR]

Encoder I can open in the future if there will be a real desire to help the project. While I do not see people who are ready to work over the project.

I'm pretty sure FFmpeg would be very happy to include your Codec, iff the source code was published under a LGPL-compatible license ;)

This way your format would be directly supported by dozens of OpenSource video encoding and playback tools...

[Dark Shikari]

I'm pretty sure FFmpeg would be very happy to include your Codec, iff the source code was published under a GPL-compatible license ;)

This way your format would be directly supported by dozens of OpenSource video encoding/playback tools...LGPL, not GPL. It would be very difficult to convince Michael to include an entire GPL codec.

Also, let's just say the ffmpeg coding standards would require a rather significant rewrite of the SIF1 code ;).

[Neiromaster]

It seems like the "psy optimizations" in SIF are likely the standard CSF masking bullcrap which says that you should basically lowpass everything beyond the first couple frequency coefficients. I advise the developer of SIF to drop this immediately, as it looks terrible.

I'm not so stupid :)
SIF in itself as the algorithm, smoothes the image.
But the psychovisual model, on the contrary, adds details in the compressed image.

2) I told you that hpel makes things sharper, not blurrier, than qpel ;)

It because interpolation filter in H264 is given by such frequency characteristic:

http://img30.imageshack.us/img30/8030/interp.png

But it too is not so good.

SIF is very sensitive to quality of interpolation.
The choice of correct algorithm of interpolation gives a considerable increase to quality for SIF.

[Dark Shikari]

I'm not so stupid :)
SIF in itself as the algorithm, smoothes the image.
But the psychovisual model, on the contrary, adds details in the compressed image.It seems to add noise, which isn't too bad an idea (preserving energy is good), but it doesn't actually sharpen it at all.

[Neiromaster]

It seems to add noise, which isn't too bad an idea (preserving energy is good),

Any noise addition in the image is not make.
It is result of compression algorithm work.
But it is really similar to noise.
The psychovisual model has no relation to it.

The psychovisual model does other things, and really improves quality of the image.

but it doesn't actually sharpen it at all.

Transition to new, more effective compression engine would be the cardinal decision of a problem. But I wish to make qualitative all other blocks of the codec, first of all the block of motion compensation.

And only then when the codec platform will be improvement to the right degree I will be make the new SIF compression engine.

[Neiromaster]

LGPL, not GPL. It would be very difficult to convince Michael to include an entire GPL codec.

Also, let's just say the ffmpeg coding standards would require a rather significant rewrite of the SIF1 code ;).

I can release an source code of the decoder under several licences, up to BSD-similar licence.

Unique important conditions for me it:

no license may be granted to You by Contributor, under any intellectual property rights including patent rights, if: 1) Covered Code can’t decode data which are accepted by the Original Code; or 2) Covered Code uses the set of resampling patterns which differs from a set used in Original Code. These modifications are not permissible, and no license is granted for such Modification(s).

Set of resampling patterns is a term from the SIF patent.

If these conditions do not contradict to GPL licence there are no obstacles.

In addition, any person can make the codec which compatible with SIF1 and release it under any licence.

[Dark Shikari]

If these conditions do not contradict to GPL licence there are no obstacles.Official ffmpeg policy is to completely ignore all patent claims.

But regardless, such a condition is not GPL-compatible. Or for that matter, compatible with any free license.

[Neiromaster]

Official ffmpeg policy is to completely ignore all patent claims.

But regardless, such a condition is not GPL-compatible. Or for that matter, compatible with any free license.

:(

Otherwise nobody will protect me if Microsoft release a codec which will be based on SIF technologies.

[LoRd_MuldeR]

If you release your code under LPGL, then neither Microsoft nor any other company is allowed to incorporate your code into any proprietary product!

They'd be allowed to compile a library from your code and link their own (proprietary) applications against that library though.

But if they did modify/improve your code, they'd have to make those changed public under LGPL again. So with the LGPL you should be on the safe side.

[Neiromaster]

If you release your code under LPGL, then neither Microsoft nor any other company is allowed to incorporate your code into any proprietary product!

They'd be allowed to compile a library from your code and link their own (proprietary) applications against that library though.

But if they did modify/improve your code, they'd have to make those changed public under LGPL again. So with the LGPL you should be on the safe side.

In this case I am not excited on the rights to a source code.
I am excited on the rights to the patent.

To me it is not clear, whether I am compelled to transfer the rights to the patent if I release a source code under LGPL or GPL licences?

To me it is not acceptably, if GPL the licence forces me to refuse the patent rights.

If the GPL adheres to a policy of hush up for patents. And no rights are transferred, and I can theoretically bring an action concerning infringement of the patent rights, it is acceptably to me.

MPL licence allows to specify in the obvious form what permissions from the patent are transferred.

Therefore I took it for a basis.

Thus, if GPL and LGPL do not influence my rights concerning the patent I can release a source code simultaneously under SPL, GPL and LGPL.
But only SPL will transmit the rights to use of the patent.

It should be stated accurately for me.

[Dark Shikari]

In this case I am not excited on the rights to a source code.
I am excited on the rights to the patent.

To me it is not clear, whether I am compelled to transfer the rights to the patent if I release a source code under LGPL or GPL licences?

To me it is not acceptably, if GPL the licence forces me to refuse the patent rights.

If the GPL adheres to a policy of hush up for patents. And no rights are transferred, and I can theoretically bring an action concerning infringement of the patent rights, it is acceptably to me.

MPL licence allows to specify in the obvious form what permissions from the patent are transferred.

Therefore I took it for a basis.

Thus, if GPL and LGPL do not influence my rights concerning the patent I can release a source code simultaneously under SPL, GPL and LGPL.
But only SPL will transmit the rights to use of the patent.

It should be stated accurately for me.The GPL and LGPL both have a patent clause which is usually interpreted as follows:

If you own a patent on code that you are distributing under the GPL or LGPL, you must grant full rights to that patent to anyone who receives the code. In other words, if I own a patent on x264, and I give you a copy of x264, you automatically receive rights to use my patent. And you can go give x264 to someone else, and they automatically receive rights to use my patent, and so forth.

The reason for this is so that someone cannot patent technique X, sneak code that violates X into an open source project, and then come back 5 years later and sue everyone.

[Neiromaster]

The GPL and LGPL both have a patent clause which is usually interpreted as follows:

If you own a patent on code that you are distributing under the GPL or LGPL, you must grant full rights to that patent to anyone who receives the code. In other words, if I own a patent on x264, and I give you a copy of x264, you automatically receive rights to use my patent. And you can go give x264 to someone else, and they automatically receive rights to use my patent, and so forth.

The reason for this is so that someone cannot patent technique X, sneak code that violates X into an open source project, and then come back 5 years later and sue everyone.

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.

My possibilities and Microsot possibilities in this case are not comparable.

Now I can forbid to other companies to make codecs on the basis of SIF technologies as I hold a patent for it.

You want so as to I have refused all rights.
Thus it will not bring to you advantage, and will benefit only Microsoft.

[PatlaborForce]

The GPL and LGPL both have a patent clause which is usually interpreted as follows:

If you own a patent on code that you are distributing under the GPL or LGPL, you must grant full rights to that patent to anyone who receives the code. In other words, if I own a patent on x264, and I give you a copy of x264, you automatically receive rights to use my patent. And you can go give x264 to someone else, and they automatically receive rights to use my patent, and so forth.

The reason for this is so that someone cannot patent technique X, sneak code that violates X into an open source project, and then come back 5 years later and sue everyone.

That would only be applicable if he licensed his code under the GPLv3 or LGPLv3 which contains the patent indemnification terms. Nothing in the GPLv2 prevents anyone from retaining patent rights over code they've released. Now obviously the spirit of the GPL is to not release code that you hold patent to but it can't deny you from doing so.

[Sagittaire]

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 ... !!?

[Dark Shikari]

That would only be applicable if he licensed his code under the GPLv3 or LGPLv3 which contains the patent indemnification terms. Nothing in the GPLv2 prevents anyone from retaining patent rights over code they've released. Now obviously the spirit of the GPL is to not release code that you hold patent to but it can't deny you from doing so.I'm pretty sure the GPLv2 has similar patent rules, albeit not as strict as v3.

[nakTT]

Interestingly, it seems local inhabitants have lost speech power.
Or the new codec is so bad? :)
Any news on the development?

[MfA]

What can protect me from Microsoft?
Momentum and name recognition?
You want so as to I have refused all rights.
Well I don't know about others, but I want everything and I want it for free :) Has little to do with Microsoft though.

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

[MfA]

Nothing in the GPLv2 prevents anyone from retaining patent rights over code they've released.
You don't strictly promise to abide by your own license in distributing it with the GPLv2 ... but there is a very strong suggestion that you are doing so. Without making special note that no patent license is granted it would definitely weaken your case in court IMO.

Also it's just plain disingenuous to spread something seemingly under GPLv2 but make it impossible to do anything with it.

[nakTT]

Any latest update?

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

[Selur]

Seems like there's a problem with the DirectShowDecoder.

Encoded a small sample with sif v1.2 and when trying to playback it with WMP I get:
---------------------------
Error!
---------------------------
Not supported version of SIF stream!
---------------------------
OK
---------------------------
-> Playback through Virtual Dub (vfw) works fine,...

Cu Selur

[Neiromaster]

Seems like there's a problem with the DirectShowDecoder.

Encoded a small sample with sif v1.2 and when trying to playback it with WMP I get:
---------------------------
Error!
---------------------------
Not supported version of SIF stream!
---------------------------
OK
---------------------------
-> Playback through Virtual Dub (vfw) works fine,...

Cu Selur

The new version of the SIF1 hasn't been correctly installed on your computer.
The old version of the DirectShow decoder hasn't been replaced.
Try to uninstall the SIF1, to reboot your computer, install SIF1 and again reboot your computer.

[CruNcher]

Neiro http://mysif.ru/en/demo.html <- @ 2 megabits the grain preservation is crazy good on this demo but wouldn't it be better to show that of in a multiple frame compare so some previous frames and some next frames in a film strip like representation :) just a little criticism skeptics like me will never believe in 1 frame compares especially not if film grain is involved, the example download of course is for those the best way to judge.

[Neiromaster]

Neiro http://mysif.ru/en/demo.html <- @ 2 megabits the grain preservation is crazy good on this demo but wouldn't it be better to show that of in a multiple frame compare so some previous frames and some next frames in a film strip like representation :) just a little criticism skeptics like me will never believe in 1 frame compares especially not if film grain is involved, the example download of course is for those the best way to judge.

The English version of demonstration page at present is not ready.
You can load actual demonstration video from Russian (http://mysif.ru/SIF1Vid.htm) page.
Translation of this page will be completed in the near future and it will be updated to an actual condition.

[vivan]

Now it's ready ;) Sorry for delay.
http://mysif.ru/en/demo.html

[Selur]

The new version of the SIF1 hasn't been correctly installed on your computer.
The old version of the DirectShow decoder hasn't been replaced.
Try to uninstall the SIF1, to reboot your computer, install SIF1 and again reboot your computer.
didn't help :(
Anything else I can try?

[Neiromaster]

didn't help :(
Anything else I can try?

Interesting.
1) Send small size example on the file hosting service and place link here.

2) Find and remove all copies of Sif1Dec.ax from your computer.

[Selur]

uploaded file to: http://www.multiupload.com/VYKOH8AZFS
deinstalled SIF1_v_1_20, rebooted, searched for Sif1Dec.ax (found a single occurence in the mplayer codecs folder, which isn't on my system drive)
installed SIF1_v_1_20, tried to playback the file -> still the same problem
deintstalled SIF1_v_1_20 again, and searched for Sif* -> only the installer was found this time,..

Cu Selur

[Neiromaster]

uploaded file to: http://www.multiupload.com/VYKOH8AZFS

This file has been decoded by DirectShow decoder v1.20 without errors.


deinstalled SIF1_v_1_20, rebooted, searched for Sif1Dec.ax (found a single occurence in the mplayer codecs folder, which isn't on my system drive)

It is a root of problem. The position on a hard disk for DirectShow decoders is unimportant. Availability of the old version of the decoder somewhere on a hard disk is sole reason of error.


installed SIF1_v_1_20, tried to playback the file -> still the same problem
deintstalled SIF1_v_1_20 again, and searched for Sif* -> only the installer was found this time,..

Cu Selur

Probably it is a problem with mplayer - which uses old version of the DirectShow decoder.

[Neiromaster]

Find in regedit.exe CLSID ->

31666973-0000-0010-8000-00AA00389B71

Folder InprocServer32 contain path to the SIF1 DirectShow decoder used at present.

It can help to solve a problem.

[Selur]

With no SIF installed I checked the registry for "31666973-0000-0010-8000-00AA00389B71" and found no entry. (so far so good)
Then I installed SIF1 v.1.20 (to C:\Program Files (x86)\SIF1) and found InprocServer32 pointing to C:\Windows\SysWow64\Sif1Dec.ax (so far so good)
Then I tried to playback the file with WMPlayer and again got:
---------------------------
Error!
---------------------------
Not supported version of SIF stream!
---------------------------
OK
---------------------------

Here are all the entries from my registry when I search for "31666973-0000-0010-8000-00AA00389B71"

hit1:
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{083863F1-70DE-11D0-BD40-00A0C911CE86}\Instance\{31666973-0000-0010-8000-00AA00389B71}]
"FriendlyName"="SIF-1 Decoder Filter v.1.20"
"CLSID"="{31666973-0000-0010-8000-00AA00389B71}"
"FilterData"=hex:02,00,00,00,00,00,80,00,02,00,00,00,00,00,00,00,30,70,69,33,\
00,00,00,00,00,00,00,00,02,00,00,00,00,00,00,00,00,00,00,00,30,74,79,33,00,\
00,00,00,70,00,00,00,80,00,00,00,31,74,79,33,00,00,00,00,70,00,00,00,90,00,\
00,00,31,70,69,33,08,00,00,00,00,00,00,00,01,00,00,00,00,00,00,00,00,00,00,\
00,30,74,79,33,00,00,00,00,70,00,00,00,a0,00,00,00,76,69,64,73,00,00,10,00,\
80,00,00,aa,00,38,9b,71,73,69,66,31,00,00,10,00,80,00,00,aa,00,38,9b,71,53,\
49,46,31,00,00,10,00,80,00,00,aa,00,38,9b,71,00,00,00,00,00,00,00,00,00,00,\
00,00,00,00,00,00


hit2:
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{31666973-0000-0010-8000-00AA00389B71}]
@="SIF-1 Decoder Filter v.1.20"

[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{31666973-0000-0010-8000-00AA00389B71}\InprocServer32]
@="C:\\Windows\\SysWow64\\Sif1Dec.ax"
"ThreadingModel"="Both"



Trying to playback the file with MPC-HC I get:
D:\sifQuality.avi::Video

Media Type 0:
--------------------------
Video: SIF1 640x352 25.00fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {31464953-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo {05589F80-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 0
bTemporalCompression: 1
lSampleSize: 1
cbFormat: 92

VIDEOINFOHEADER:
rcSource: (0,0)-(640,352)
rcTarget: (0,0)-(640,352)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 400000

BITMAPINFOHEADER:
biSize: 44
biWidth: 640
biHeight: 352
biPlanes: 1
biBitCount: 0
biCompression: SIF1
biSizeImage: 0
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 80 02 00 00 60 01 00 00 ........€...`...
0010: 00 00 00 00 00 00 00 00 80 02 00 00 60 01 00 00 ........€...`...
0020: 00 00 00 00 00 00 00 00 80 1a 06 00 00 00 00 00 ........€.......
0030: 2c 00 00 00 80 02 00 00 60 01 00 00 01 00 00 00 ,...€...`.......
0040: 53 49 46 31 00 00 00 00 00 00 00 00 00 00 00 00 SIF1............
0050: 00 00 00 00 00 00 00 00|78 f6 92 2c ........xö’,

(tried with LAV Filters and MPC-HCs own .avi Source filter)

Cu Selur

[Neiromaster]

Here are all the entries from my registry when I search for "31666973-0000-0010-8000-00AA00389B71"

hit2:
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{31666973-0000-0010-8000-00AA00389B71}]
@="SIF-1 Decoder Filter v.1.20"

[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{31666973-0000-0010-8000-00AA00389B71}\InprocServer32]
@="C:\\Windows\\SysWow64\\Sif1Dec.ax"
"ThreadingModel"="Both"



Trying to playback the file with MPC-HC I get:

BITMAPINFOHEADER:
biSize: 44
biWidth: 640
biHeight: 352
biPlanes: 1
biBitCount: 0
biCompression: SIF1
biSizeImage: 0
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 80 02 00 00 60 01 00 00 ........€...`...
0010: 00 00 00 00 00 00 00 00 80 02 00 00 60 01 00 00 ........€...`...
0020: 00 00 00 00 00 00 00 00 80 1a 06 00 00 00 00 00 ........€.......
0030: 2c 00 00 00 80 02 00 00 60 01 00 00 01 00 00 00 ,...€...`.......
0040: 53 49 46 31 00 00 00 00 00 00 00 00 00 00 00 00 SIF1............
0050: 00 00 00 00 00 00 00 00|78 f6 92 2c ........xö’,

(tried with LAV Filters and MPC-HCs own .avi Source filter)

Cu Selur

This data means that the DirectShow decoder has been installed correctly, but input data are incorrect.

If biSizeImage = 0 the system doesn't allocate memory for the buffer of the compressed data.

For example, at playback the file with MPC-HC I get:

Filter : F:\Arhiv\sifQuality.avi - CLSID : {CEA8DEFF-0AF7-4DB9-9A38-FB3C3AEFC0DE}

- Connected to:

CLSID: {31666973-0000-0010-8000-00AA00389B71}
Filter: SIF-1 Decoder Filter v.1.20
Pin: XForm In

- Connection media type:

Video: SIF1 640x352 25.00fps 628kbps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {31464953-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo {05589F80-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 27723
cbFormat: 92

VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 628175
dwBitErrorRate: 0
AvgTimePerFrame: 400000

BITMAPINFOHEADER:
biSize: 40
biWidth: 640
biHeight: 352
biPlanes: 1
biBitCount: 0
biCompression: SIF1
biSizeImage: 675840
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0020: cf 95 09 00 00 00 00 00 80 1a 06 00 00 00 00 00 П•......Ђ.......
0030: 28 00 00 00 80 02 00 00 60 01 00 00 01 00 00 00 (...Ђ...`.......
0040: 53 49 46 31 00 50 0a 00 00 00 00 00 00 00 00 00 SIF1.P..........
0050: 00 00 00 00 00 00 00 00|78 f6 92 2c ........xц’,

- Enumerated media type 0:

Set as the current media type


biSizeImage = 675840 = 640 * 352 * 3

I can't obtain similar error on the my computer.
Probably incorrect DirectShow filter installed in the your system.

[Selur]

Aside from the Decoders that come with Win 7, I only installed ffdshow (3861), ffdshow 64bit (3861), LAV CUVID 0.9, LAV Filters 0.3 and SIF 1.2, I'll uninstall everything, install SIF anew and report.
DOH,... I know why it's not working in MPC-HC: I use a 64bit version of MPC-HC. (but I use the 32bit Version of WMPlayer)

uninstalled LAV Filters
-> tried Playback with WMPLayer (32bit)
=> Playback works!!! :D

(Strange think is this problem also occurs if I install LAV Filters and disable the .avi Support for the x86 Splitter, if I leave the Splitter out everything works,...)

Cu Selur

[Neiromaster]

Aside from the Decoders that come with Win 7, I only installed ffdshow (3861), ffdshow 64bit (3861), LAV CUVID 0.9, LAV Filters 0.3 and SIF 1.2, I'll uninstall everything, install SIF anew and report.
DOH,... I know why it's not working in MPC-HC: I use a 64bit version of MPC-HC. (but I use the 32bit Version of WMPlayer)

uninstalled LAV Filters
-> tried Playback with WMPLayer (32bit)
=> Playback works!!! :D

(Strange think is this problem also occurs if I install LAV Filters and disable the .avi Support for the x86 Splitter, if I leave the Splitter out everything works,...)

Cu Selur

Yes. It is error in the LAV Filters.
I have loaded it, installed it and obtained the same error.
Also i loaded LAV Filters source code, and immediately find error in LAVFVideoHelper.cpp.


VIDEOINFOHEADER *CLAVFVideoHelper::CreateVIH(const AVStream* avstream, ULONG *size)
{
VIDEOINFOHEADER *pvi = (VIDEOINFOHEADER*)CoTaskMemAlloc(ULONG(sizeof(VIDEOINFOHEADER) + avstream->codec->extradata_size));
memset(pvi, 0, sizeof(VIDEOINFOHEADER));
// Get the frame rate
REFERENCE_TIME r_avg = av_rescale(DSHOW_TIME_BASE, avstream->r_frame_rate.den, avstream->r_frame_rate.num);
if (avstream->r_frame_rate.den > 0 && avstream->r_frame_rate.num > 0 && (r_avg > MIN_TIME_PER_FRAME)) {
pvi->AvgTimePerFrame = r_avg;
} else if (avstream->avg_frame_rate.den > 0 && avstream->avg_frame_rate.num > 0) {
pvi->AvgTimePerFrame = av_rescale(DSHOW_TIME_BASE, avstream->avg_frame_rate.den, avstream->avg_frame_rate.num);
}
pvi->dwBitErrorRate = 0;
pvi->dwBitRate = avstream->codec->bit_rate;
RECT empty_tagrect = {0,0,0,0};
pvi->rcSource = empty_tagrect;//Some codecs like wmv are setting that value to the video current value
pvi->rcTarget = empty_tagrect;
pvi->rcTarget.right = pvi->rcSource.right = avstream->codec->width;
pvi->rcTarget.bottom = pvi->rcSource.bottom = avstream->codec->height;

memcpy((BYTE*)&pvi->bmiHeader + sizeof(BITMAPINFOHEADER), avstream->codec->extradata, avstream->codec->extradata_size);
pvi->bmiHeader.biSize = ULONG(sizeof(BITMAPINFOHEADER) + avstream->codec->extradata_size);

pvi->bmiHeader.biWidth = avstream->codec->width;
pvi->bmiHeader.biHeight = avstream->codec->height;
pvi->bmiHeader.biBitCount = avstream->codec->bits_per_coded_sample;
pvi->bmiHeader.biSizeImage = 0; // Calculating any value doesn't make sense, as we're dealing with compressed data, without constant frame sizes
pvi->bmiHeader.biCompression = avstream->codec->codec_tag;
//TOFIX The bitplanes is depending on the subtype
pvi->bmiHeader.biPlanes = 1;
pvi->bmiHeader.biClrUsed = 0;
pvi->bmiHeader.biClrImportant = 0;
pvi->bmiHeader.biYPelsPerMeter = 0;
pvi->bmiHeader.biXPelsPerMeter = 0;

if (avstream->codec->codec_id == CODEC_ID_RAWVIDEO) {
pvi->bmiHeader.biBitCount = av_get_bits_per_pixel2(avstream->codec->pix_fmt);
}

*size = sizeof(VIDEOINFOHEADER) + avstream->codec->extradata_size;
return pvi;
}


Here error:
pvi->bmiHeader.biSizeImage = 0; // Calculating any value doesn't make sense, as we're dealing with compressed data, without constant frame sizes

Correctly so:
pvi->bmiHeader.biSizeImage = avstream->codec->width * avstream->codec->height * 3;

Likely it's not sole error in the LAV Filters.
This error badly influences not only on the SIF decoder.
I don't recommend to use the LAV Filters while errors aren't corrected by the author.

[nevcairiel]

SIF1 is a compressed format, isn't it? Probably even variable frame size?
If it is, why would the image size be the same as a full uncompressed 24-bit RGB image, 3-byte per pixel?
Did you even read the comment that explaind why that value is being set to 0?

biSizeImage is *not* defined for compressed formats. 0 is a perfectly valid format. A decoder should not rely on that value in any way.
In fact, your decoder is the only one that fails with it set to 0. Alot of other splitters set this to 0. Not necessarily for AVI files, but do you want to be limited to that?

[mikinho]

biSizeImage should only be 0 for uncompressed RGB bitmaps.

I agree it shouldn't be relied on but it should be set

[nevcairiel]

biSizeImage should only be 0 for uncompressed RGB bitmaps.

I agree it shouldn't be relied on but it should be set

On a variable-size compressed format, to what exactly? :p

[mikinho]

On a variable-size compressed format, to what exactly? :p

The implied size of the uncompressed image

pvi->bmiHeader.biSizeImage = DIBSIZE(pvi->bmiHeader);

[nevcairiel]

I changed it to that, i however still do not see how a decoder can rely on that value. I would never trust it on a compressed format - i don't know which pixel format he wants to decode to, how many bits his destination has. Heck i don't even know what to make of this codec, how am i supposed to know how what colorspace was encoded here. :)

[mikinho]

I changed it to that, i however still do not see how a decoder can rely on that value. I would never trust it on a compressed format - i don't know which pixel format he wants to decode to, how many bits his destination has. Heck i don't even know what to make of this codec, how am i supposed to know how what colorspace was encoded here. :)

It is an area where the MSDN documentation should be updated and be more clear.

And while using a larger buffer than needed is a little wasteful it is generally faster than calculating the proper size and allocating it.

In MF the documentation is more clear that for compressed formats you should IMFMediaType->IsCompressedFormat and then use MFCalculateBitmapImageSize if needed. But then again there are still a few hacks you need to do for ASF and other headers.

[Neiromaster]

I changed it to that, i however still do not see how a decoder can rely on that value. I would never trust it on a compressed format - i don't know which pixel format he wants to decode to, how many bits his destination has. Heck i don't even know what to make of this codec, how am i supposed to know how what colorspace was encoded here. :)

The SIF1 decoder doesn't use this value, but it influences on buffer memory allocation for data packet.

Also probably the LAV Filters doesn't reset SyncPoint after seeking.
SIF1 DirectShow decoder can't work correctly if IsSyncPoint() return wrong status.

[nevcairiel]

All samples with a valid timestamp and a valid duration are sync points to LAV Splitter. It cannot detect key-frames for every of the hundreds of video formats out there, its the decoders responsibility to properly recover after a seek.

[Neiromaster]

All samples with a valid timestamp and a valid duration are sync points to LAV Splitter. It cannot detect key-frames for every of the hundreds of video formats out there, its the decoders responsibility to properly recover after a seek.

The SIF1 data format doesn't contain key frames information as this information doubles the data containing in the container.

SIF1 decoder can't work if the splitter discards information containing in the exterior container.

Many other decoders too won't work with the LAV Splitter.

It is probably fundamental reason of incompatibility of SIF1 decoder and LAV Splitter.

[nevcairiel]

Many other decoders too won't work with the LAV Splitter.


Apparently you're the only one with that wisdom. I have had no reports of any decoder not working, short of yours.

[Neiromaster]

All samples with a valid timestamp and a valid duration are sync points to LAV Splitter. It cannot detect key-frames for every of the hundreds of video formats out there, its the decoders responsibility to properly recover after a seek.

To know information on hundreds formats is not necessary - enough to process correctly information containing in the AVI container.

[Neiromaster]

Apparently you're the only one with that wisdom.

I doubt. Inter alia it is your choice - to write the correct or incorrect code.

[CruNcher]

Apparently you're the only one with that wisdom. I have had no reports of any decoder not working, short of yours.

I wouldn't see that as a fact that lav splitter is doing it correct seeing the margin of AVI based codecs and numbers of vendors that somehow use AVI for sure you gonna find both ways ;). With Neiro their might be a chance that he adepts to you or you to his way of doing it but with all the other vendors their might be only the way to adept to them or don't support them @ all :)

[khagaroth]

^^
THERE not their. I know you are not a native English speaker, but I'm neither and it's still bugging me, LOL.

[Selur]

btw. any news/progress on a command line version ?

[Neiromaster]

btw. any news/progress on a command line version ?

My opportunities of codec development are limited. That's why my development plan is optimized for maximum speed of codec development with the available resources.
Now I have two priorities:
First is the completion of main algorithms to be used in the codec.
Second is integration into the existing streaming video systems.

In each of the last codec versions code structure was modified with improvement of each block of code. The purpose of this changes is the possibility of further easy porting of all the codec code to pure C and removing of all assembler code.

Now only one code block left, where such restructuring was not done - the engine of direct SIF-transform.
Thus plan is such:
1) Restructurization and improvement of SIF transform engine.
2) Adding support for quarter-pixel motion compensation.
3) Porting codec code to the pure C and removal of assembler functions. Achieving code compilation with GCC + Yasm. And writing a portable SIF1 encoding-decoding library for Linux.
4) SSE2 code optimization and writing in C analogues of the functions which are written only in assembler.
5) ARM NEON optimization and writing decoder with GPU acceleration support.

Upon reaching stage 3, I plan to integrate codec library with existing console code. This can either be part of the WebM code, or part of project TEORA code. I hope that by that time the process of obtaining U.S. patents will be completed, and I would be able to change current decoder license. I plan to use freeBSD license together with a separate license for a patent, such as Google did with WebM.
Thus, compatibility with GPL and code portability will be achieved at the same time, together with its integration into the existing streaming systems.

Of course I can not get SIF1 embedded into existing browsers (like Google did) - it is up to you.

Before reaching stage 3 I do not plan to make the console versions of the codec, since it will require extra resources which I do not have. In addition this can greatly slow the development of the codec.
With the opportunities I have now I plan to reach stage 3 in 1.5 - 2 years.

All development os SIF1 is an initiative of one person. I have no personal wealth and no one is funding the development. Therefore, I'm developing SIF in my own free time while earning money to support my family. Unfortunately, obtaining financial support of such project in Russia is almost impossible.

That's why the development of SIF1 lasts so long and it's not possible to say exact dates - because all depends on my free time and opportunities of further project development.

Thanks for Valiulin Ivan for the help over translation it into English.

[Selur]

Thanks for explaining. :)