SIF1 v1.20 was released [Archive]

View Full Version : SIF1 v1.20 was released

Pages : [1] 2 3

Neiromaster

18th October 2009, 04:07

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

18th October 2009, 20:53

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

Shinobu

18th October 2009, 23:37

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

19th October 2009, 21:17

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

19th October 2009, 21:28

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

LoRd_MuldeR

19th October 2009, 21:34

To my surprise MPlayer does handle it too ;)

nakTT

19th October 2009, 22:09

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

19th October 2009, 23:10

LoRd_MuldeR

19th October 2009, 23:24

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

19th October 2009, 23:43

Neiromaster

20th October 2009, 05:13

Neiromaster

20th October 2009, 06:17

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

20th October 2009, 11:03

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

20th October 2009, 11:41

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

20th October 2009, 16:33

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

20th October 2009, 18:13

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

20th October 2009, 18:22

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

20th October 2009, 18:52

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

20th October 2009, 18:59

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

20th October 2009, 19:42

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

20th October 2009, 20:25

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

20th October 2009, 20:29

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

20th October 2009, 21:48

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

20th October 2009, 21:55

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

20th October 2009, 22:07

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

20th October 2009, 22:10

: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

20th October 2009, 22:14

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

20th October 2009, 22:35

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

20th October 2009, 22:38

But what about the encoder?

Neiromaster

20th October 2009, 22:41

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

Neiromaster

20th October 2009, 22:44

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

20th October 2009, 23:13

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

20th October 2009, 23:17

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

21st October 2009, 19:15

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

21st October 2009, 21:06

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

22nd October 2009, 20:15

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

22nd October 2009, 20:38

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

22nd October 2009, 20:54

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

22nd October 2009, 21:38

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

22nd October 2009, 21:50

Neiromaster

23rd October 2009, 09:30

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

23rd October 2009, 09:42

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

23rd October 2009, 10:32

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

23rd October 2009, 15:44

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

23rd October 2009, 16:07

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

23rd October 2009, 17:42

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

30th October 2009, 17:31

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

MfA

30th October 2009, 19:20

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

30th October 2009, 19:25

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

19th November 2009, 07:31

Any latest update?