Schrodinger release the 1.0 version !

[jakor]

Originally Posted by MfA

In the case of 4K a couple of hundred of TB via 10 Gb/s fibre channel or ethernet (even that leaves you with rather small margins, probably need dual channel to be save) pushing nearly 2 GB/s of throughput with realtime editing ... that is getting pretty fussy even by professional standards

PS. wavelets aren't really ideal for near lossless coding either, no way to guarantee error bounds.

actually, there are different wavelets. Some of them provide 100% lossless processing of data. And some near lossless. And the latest is the worst case ;-)

[MfA]

I didn't say you couldn't do lossless coding. It's just that the only way to guarantee per pixel error bounds is by trial and error search through the quantizer range, which is not practical.

[Caroliano]

Schrödinger-1.0.1 Released
Sat, 03/15/2008 - 00:06 — ds

New Schrödinger release 1.0.1 out.

This is almost entirely a bugfixing release.

Also note that liboil-0.3.14 is out. It too is a bugfixing release,
but is not required to build schroedinger-1.0.1.

1.0.1
=====

- Add API reference documentation for SchroDecoder.
- Restructure API reference documentation, although coverage is very
low.
- Default GOP structure now uses 3 reference frames. This gives a
very slight improvement in quality.
- Fix encode/decode mismatch for low-delay syntax.
- Fix brokenness in CBR intra-only encoding
- Additional testing and code cleanups
- Eliminate artificial width limitation in encoder and decoder.
- Fix encoding/decoding of video offset and excursion.
- Fix granulepos calculation in GStreamer encoder element
- Set DELTA_UNIT correctly in GStreamer encoder element
- Update code path used when pthread is disabled.

There are also new versions of Dirac especification. The e-mail in the announce mailing list has an strange "confidentiality" disclamer, so I will not post it to avoid any unlikely problem... anyway, you can download the new especifications from the usual place: http://dirac.sourceforge.net/specification.html

And they are participating in the Google Summer of Code. See the project ideas here: http://www.diracvideo.org/wiki/GSoC2...as?action=show

[e-Pawel]

Sorry for digging up old threads, but...

what's about a win32 build?? The 1.0.3 realese is already out but there is still no win32 build...

[PatchWorKs]

MediaCoder is your friend !

[e-Pawel]

Originally Posted by PatchWorKs

MediaCoder is your friend !

Ok, but

Originally Posted by Caroliano

MediaCoder only has the 0.9.0 release, and seems that no-one informed them about this bug-fix release.

Or has MediaCoder already been updated and uses the latest 1.0.3 release?

[Shinigami-Sama]

Originally Posted by e-Pawel

Ok, but



Or has MediaCoder already been updated and uses the latest 1.0.3 release?

click the link and check yourself?

[Caroliano]

The last mediacoder build finaly include the Dirac 0.9.1 release. That is the lastest dirac version. As of now, I think that dirac encoder still have an higher quality than schrodinger, but is slower. Media coder don't include Schrodinger (version 1.0.3 now). In fact, I don't have any idea how to use it from windows.

[iwod]

How does Dirac compare to Snow?

[lucassp]

Is there any tool that uses Schroedinger+CUDA optimizations?

[Caroliano]

An simple - schrodinger cuda - search in google would get you to this: http://www.cs.rug.nl/~wladimir/sc-cuda/

However, this apear to be old, and in the google summer of code they are doing an OpenGL + GLSL implementation, to offer much broader compatibility: http://code.google.com/soc/2008/dirac/about.html

For recent status of dirac:http://www.schleef.org/blog/2008/07/15/dirac-news/

[lucassp]

I did that first but it didn't lead me to an actual working tool for windows or linux.

[valgor]

Schroedinger 1.0.9
==================

A new release of Schrödinger is available. Schrödinger (or “schro”
for short) is a cross-platform implementation of the Dirac video
compression specification as a C library. Many media frameworks
such as GStreamer and ffmpeg and applications such as VLC use schro
to encode and decode Dirac video.

Information: http://diracvideo.org/
Download: http://diracvideo.org/download/schro...r-1.0.9.tar.gz

It's been a long time since the last release, and there have been a
*lot* of changes. This is an exciting release: most of the encoding
tools in dirac-research have been ported over to Schrödinger, so now
schro has the same or better compression efficiency as dirac-research.
Second, we've switched over to using Orc instead of liboil for signal
processing code. Dirac is a very configurable format, and normally
would require thousands of lines of assembly code -- Orc generates
this at runtime from simple rules. (Hey, it was easier to write Orc
than write all that assembly!)

Third, we now have an encoder quality testing system in place to check
how well new encoding tools work and to make sure bugs that affect
quality are quickly fixed.

New in 1.0.9
============

- Orc: Complete conversion to Orc and removal of liboil dependency.
- Added a lot of orc code to make things faster. A lot faster.
- New motion vector generation, enabled by default.
- New CBR rate control, enabled by default.
- New scene change detection, enabled by default.
- Encoder went through several rounds of tuning, improving quality
greatly.
- New encoder setting "force-profile". Allows easy access to one of
three VC-2 profiles (vc2_low_delay, vc2_simple, vc2_main) for
intermediate coding. Default is same as before: long-GOP Dirac.
- Improved lossless encoding. Works in concert with force-profile.

[Caroliano]

Still no easy to use binary for windows with avisynth input or VFW suport? Also, the link for download is wrong at the diracvideo.org's post. Anyway, good that the project isn't dead.

[roozhou]

Originally Posted by Caroliano

Still no easy to use binary for windows with avisynth input or VFW suport? Also, the link for download is wrong at the diracvideo.org's post. Anyway, good that the project isn't dead.

Why don't you use ffmpeg?

[Caroliano]

Ok, now I tried to use ffmpeg (today build, but I don't know if it has this lastest schrodinger). One encode aparently went fine, with only some errors... but the decoder stoped responding. The second seems to have had problems at some point of the encoding, and the decoder also stopped responding.

first encoding log:

D:\Programas\E-F\FFmpeg\avanti-045\ffmpeg>ffmpeg -s 450x360 -i fail.mp4 -qscale
70 default_output.drc
FFmpeg version SVN-r22221, Copyright (c) 2000-2010 the FFmpeg developers
  built on Mar  5 2010 06:09:29 with gcc 4.4.2
  configuration: --enable-memalign-hack --cross-prefix=i686-mingw32- --cc=ccache
-i686-mingw32-gcc --arch=i686 --target-os=mingw32 --enable-runtime-cpudetect --e
nable-avisynth --enable-gpl --enable-version3 --enable-bzlib --enable-libgsm --e
nable-libfaad --enable-pthreads --enable-libvorbis --enable-libtheora --enable-l
ibspeex --enable-libmp3lame --enable-libopenjpeg --enable-libxvid --enable-libsc
hroedinger --enable-libx264 --enable-libopencore_amrwb --enable-libopencore_amrn
b
  libavutil     50.10. 0 / 50.10. 0
  libavcodec    52.55. 0 / 52.55. 0
  libavformat   52.54. 0 / 52.54. 0
  libavdevice   52. 2. 0 / 52. 2. 0
  libswscale     0.10. 0 /  0.10. 0

Seems stream 1 codec frame rate differs from container frame rate: 50.00 (50/1)
-> 25.00 (25/1)
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'fail.mp4':
  Metadata:
    major_brand     : mp42
    minor_version   : 0
    compatible_brands: isomavc1mp42
  Duration: 00:00:25.92, start: 0.000000, bitrate: 537 kb/s
    Stream #0.0(und): Audio: aac, 44100 Hz, stereo, s16, 93 kb/s
    Stream #0.1(und): Video: h264, yuv420p, 450x360 [PAR 1:1 DAR 5:4], 441 kb/s,
 25 fps, 25 tbr, 25k tbn, 50 tbc
SCHRO: ERROR: schrovideoformat.c(35): schro_video_format_validate: 10.3.7: horiz
ontal clean area is not legal (clean_width + left_offset > width)
SCHRO: ERROR: schrovideoformat.c(39): schro_video_format_validate: 10.3.7: verti
cal clean area is not legal (clean_height + top_offset > height)
SCHRO: ERROR: schrovideoformat.c(43): schro_video_format_validate: resetting cle
an area to frame size
Output #0, dirac, to 'default_output.drc':
  Metadata:
    encoder         : Lavf52.54.0
    Stream #0.0(und): Video: libschroedinger, yuv420p, 450x360 [PAR 1:1 DAR 5:4]
, q=2-31, 200 kb/s, 90k tbn, 25 tbc
Stream mapping:
  Stream #0.1 -> #0.0
Press [q] to stop encoding
frame=  648 fps= 77 q=0.0 Lsize=   34236kB time=25.88 bitrate=10837.1kbits/s

video:34236kB audio:0kB global headers:0kB muxing overhead 0.000000%

D:\Programas\E-F\FFmpeg\avanti-045\ffmpeg>pause
Pressione qualquer tecla para continuar. . .

The second encode was more or less like that, but from an certain point started outputing this:

Press [q] to stop encoding
frame= 1495 fps= 10 q=0.0 size=   54646kB time=61.46 bitrate=7284.0kbits/s dup=1
frame= 1501 fps= 10 q=0.0 size=   54904kB time=61.71 bitrate=7288.7kbits/s dup=1
frame= 1507 fps= 10 q=0.0 size=   55079kB time=61.96 bitrate=7282.4kbits/s dup=1
frame= 1513 fps= 10 q=0.0 size=   55315kB time=62.21 bitrate=7284.2kbits/s dup=1
frame= 1520 fps= 10 q=0.0 size=   55571kB time=62.50 bitrate=7283.8kbits/s dup=1

[...]

And on the decode...

E:\Testes>ffmpeg -i gundam.drc gundam.yuv
FFmpeg version SVN-r22221, Copyright (c) 2000-2010 the FFmpeg developers
  built on Mar  5 2010 06:09:29 with gcc 4.4.2
  configuration: --enable-memalign-hack --cross-prefix=i686-mingw32- --cc=ccache
-i686-mingw32-gcc --arch=i686 --target-os=mingw32 --enable-runtime-cpudetect --e
nable-avisynth --enable-gpl --enable-version3 --enable-bzlib --enable-libgsm --e
nable-libfaad --enable-pthreads --enable-libvorbis --enable-libtheora --enable-l
ibspeex --enable-libmp3lame --enable-libopenjpeg --enable-libxvid --enable-libsc
hroedinger --enable-libx264 --enable-libopencore_amrwb --enable-libopencore_amrn
b
  libavutil     50.10. 0 / 50.10. 0
  libavcodec    52.55. 0 / 52.55. 0
  libavformat   52.54. 0 / 52.54. 0
  libavdevice   52. 2. 0 / 52. 2. 0
  libswscale     0.10. 0 /  0.10. 0
[dirac @ 0003bbb0]Estimating duration from bitrate, this may be inaccurate
Input #0, dirac, from 'gundam.drc':
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0.0: Video: libschroedinger, yuv420p, 1920x1080, 24 tbr, 1200k tbn,
24 tbc
Output #0, rawvideo, to 'gundam.yuv':
  Metadata:
    encoder         : Lavf52.54.0
    Stream #0.0: Video: rawvideo, yuv420p, 1920x1080, q=2-31, 200 kb/s, 90k tbn,
 24 tbc
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop encoding
frame=    2 fps=  0 q=0.0 size=    6075kB time=0.08 bitrate=597196.8kbits/s dup=
frame=    3 fps=  3 q=0.0 size=    9112kB time=0.12 bitrate=597196.8kbits/s dup=
frame=    3 fps=  2 q=0.0 size=    9112kB time=0.12 bitrate=597196.8kbits/s dup=
frame=    3 fps=  1 q=0.0 size=    9112kB time=0.12 bitrate=597196.8kbits/s dup=
frame=    3 fps=  1 q=0.0 size=    9112kB time=0.12 bitrate=597196.8kbits/s dup=
frame=    3 fps=  1 q=0.0 size=    9112kB time=0.12 bitrate=597196.8kbits/s dup=
frame=    3 fps=  1 q=0.0 size=    9112kB time=0.12 bitrate=597196.8kbits/s dup=
frame=    3 fps=  1 q=0.0 size=    9112kB time=0.12 bitrate=597196.8kbits/s dup=
frame=    3 fps=  1 q=0.0 size=    9112kB time=0.12 bitrate=597196.8kbits/s dup=
frame=    3 fps=  1 q=0.0 size=    9112kB time=0.12 bitrate=597196.8kbits/s dup=
frame=    3 fps=  1 q=0.0 size=    9112kB time=0.12 bitrate=597196.8kbits/s dup=
frame=    3 fps=  0 q=0.0 size=    9112kB time=0.12 bitrate=597196.8kbits/s dup=

[...]

I used the instructions at this page, that seems outdated, and are not very good... I don't even know if I really used schrodinger, or how to select it, or how to select an better container like .mkv, and so on. FFmpeg2dirac seems dead.

Also, comand-line aplications are never intuitive... you aways need to waste some time only to learn to operate them. Besides, I'm not used to them, and find them ankward and dificult to use, at least on windows. And I don't know if the errors are because I don't know how to use ffmpeg.

It don't seem to be easy to encode to schrodinger at the moment. I coundn't. :/

[valgor]

Here a quick comparison, Schroedinger-1.0.9 vs Theora-1.1.1

3000 first frames of Elephants_Dream_HD.avi (http://www.elephantsdream.org/download/), resized to 640x368:
(ffmpeg -i /home/video/Elephants_Dream_HD.avi -s 640x368 -vframes 3000 ed640x368.yuv)

ed640_Schro.drc (schro_encode -w 640 -h 368 --quality 6 --8bitvid --rate_control constant_quality):
video rate: 1018 kbit/s
http://www.mediafire.com/download.php?lntnjdwiwxy
PSNR Y:36.699 U:43.045 V:42.701 All:37.965
SSIM Y:0.95105 U:0.96794 V:0.96571 All:0.95631

ed640_Theora.ogv (encoder_example -v 6):
video rate: 1085 kbit/s
http://www.mediafire.com/download.php?myyzrz2wwui
PSNR Y:37.072 U:46.791 V:46.076 All:38.588
SSIM Y:0.94890 U:0.98393 V:0.98175 All:0.96021

In spite of Theora's metrics are higher, Schroedinger looks much detailed.
Original:


Theora:


Schroedinger:

[Dark Shikari]

Should probably test with Theora 1.2 (ptalabvorm); 1.1.1 doesn't have adaptive lambda, which should greatly improve SSIM and visual quality (poor man's version of x264's VAQ).

[valgor]

Theora 1.2 (encoder_example -v 5.7):
video rate: 1014 kbit/s
(Quality parameter is decreased from 6 to 5.7 to match the Schro file size, "-v 6" produced 1130 kbit/s)

PSNR Y:36.141 U:46.555 V:45.800 All:37.691
SSIM Y:0.95469 U:0.98331 V:0.98089 All:0.96382

Visual difference between 1.1 and 1.2 is really negligible, so no necessary to produce samples.

As I said before, Schro preserve much more detailed video anyway.
But its problem in the colors. They are worse than in Theora.

[jethro]

Originally Posted by valgor

But its problem in the colors. They are worse than in Theora.

Exactly. I noticed it too in this multiformat comparison
that Dirac despite having terrible metrics (totally off in the SSIM graph), its output looks fairly detailed.
http://keyj.s2000.ws/?p=356

Clearly the colors problem is common to Dirac and Schoedinger alike and its disheartening to see that despite all this time working on this and supposed improvements in this release, a BIG bug like this gets unnoticed (or just ignored?) by the devs.
If you look at the 'star trek' frame in dirac you can instantly see its too violet. Similar in your ED frames but here the green ones also show up clearly.
Maybe its the decoder that screws the chroma, and the devs having a correct one, don't see it? Anyway its still bad, like they couldn't check this.