Schrodinger release the 1.0 version !

[bratao]

Schroedinger is an implementation of the Dirac video codec
specification, written with speed, stability, and maintainability in
mind. Schroedinger provides a software library that implements both a
Dirac encoder and decoder. Also provided is a GStreamer plugin. No
end-user tools are included, since it is intended that users will use
existing tools written using a media framework such as GStreamer for
which a Schroedinger plugin is available.

The Dirac bitstream is now frozen, so video encoded today will be
decodable by future versions of Schroedinger and other Dirac-compliant
tools.


What's new?
-----------

This release is mainly intended for early adopters and integrators, in
order to work out many of the kinks that inevitably arise when a project
gains more wide usage.

Notable features:

- ABI and API stable
- Implements Dirac-1.0 and Dirac-2.1 bit streams
- Encoder is tested and tuned for SD and HD720
- Decodes HD720/25p in real-time on a Core Duo laptop


Where to get it
---------------

Schroedinger source code is available for download at:

http://diracvideo.schleef.org/download/schroedinger/

Information about Schroedinger and Dirac are scattered across several
web sites. We are working at consolidating this information into a
single web site, so changes may occur.

Project Web Site: http://schrodinger.sourceforge.net/
Bugzilla: http://bugzilla.schleef.org/
Git repository: git://diracvideo.schleef.org/git/schroedinger/


What is Dirac?
--------------

Dirac is a video codec specification created by the BBC R&D division
that provides state-of-the-art compression performance for a wide range
of video sizes and bitrates, encompassing low bit rate web video,
broadcast SD and HD television, nearly-lossless intra coding for studio
editing, and digital cinema. Dirac was created from the ground up to
be free from any patent claims. Dirac is also the name of the original
software implementation of the Dirac specification.

[neuron2]

Is this a Linux only thing?

Any binaries available?

[Caroliano]

By the way, Dirac 0.9.1 (http://sourceforge.net/forum/forum.php?forum_id=778600) was released a while ago. MediaCoder only has the 0.9.0 release (http://sourceforge.net/forum/forum.php?forum_id=777393), and seems that no-one informed them about this bug-fix release. Someone registered there can ask for the update? Then I can test in windows, because the other ways I know are too dificult for me.

:thanks:

And "encoded today will be decodable by future versions of Schroedinger and other Dirac-compliant tools", except in case of bugs... which is likely I think....

[Sharktooth]

"bugs" in the bitstream specs?

[Caroliano]

No, in the implementations, I think.

encoders and decoders are (more or less) cross compatible. We have successfully coded material with one and played back on the other. Over the coming weeks we will continue to work to rigorously ensure that both implementations conform to the spec.

[bratao]

BTW, you guys already noticed that in the Dirac blog says that Dirac will be the new VC-2 standart ?

[facialz]

That's DiracPro, not Dirac. DiracPro was meant for professional (low compression, high bitrate) work.

http://www.bbc.co.uk/rd/projects/dirac/diracpro.shtml

[dimzon]

Can anybody compile if for win32 with avisynth input support?

[Inventive Software]

Nice. So WMV9 is VC-1, DiracPro is VC-2, and DNxHD is VC-3! I'm taking bets as to what'll be VC-4! :D

[guada2]

Can anybody compile if for win32 with avisynth input support?
That can be interesting.

what'll be VC-4!
Super "I.S" :D

[guada2]

@dimzon

I i remenber, Kurtnoise with Damrod had developed a version under WIN32.
One could ask them (nicely) to revise this version.... alas is not succeeded yet.

[guada2]

Just a question.
Somebody can it tell me the difference between Rududu and Dirac?

Thanks

[Sharktooth]

rududu "info": http://forum.doom9.org/showthread.php?p=305958#post305958
diracpro specs: http://dirac.sourceforge.net/DiracSpec1.0.0-DiracPro.pdf
dirac specs: http://dirac.sourceforge.net/DiracSpec2.1.0.pdf

[Caroliano]

Just a question.
Somebody can it tell me the difference between Rududu and Dirac?
Your question is like asking the diference between Xvid and Theora or x264 or Mpeg1. They are very diferent codecs, although both are based in wavelets, as the Xvid and cia. are based in DCT.
That's DiracPro, not Dirac. DiracPro was meant for professional (low compression, high bitrate) work.
Yeah, that is right, but "If VC-2 is well-received we'll propose an extension so that it covers the whole of Dirac."
http://sonofid.blogspot.com/2008/01/on-road-to-dirac-standard-at-last.html

[Blue_MiSfit]

Looks interesting!

[bond]

Yeah, that is right, but "If VC-2 is well-received we'll propose an extension so that it covers the whole of Dirac."
http://sonofid.blogspot.com/2008/01/on-road-to-dirac-standard-at-last.htmlugh, who needs intra coding only :sly:

[IgorC]

Dirac. Schrodinger. Such names of scientists.

[CruNcher]

ugh, who needs intra coding only :sly:

Ehh me me :) especialy for intermediate Editing im really looking forward to Dirac as DxnHD (VC-3) seems weak :D
Dirac and AVC Intra seem to be the nicest options for the moment vs alot of non Standard stuff like Canapus HQ or Cineform (upto 120 mbit) :)
And Dirac even seems to get a self developed CUDA Decoder/Encoder implementation so it will be most likely even without big GFX support fast like H.264 (ah and ofcourse it's State of the Art Technology and most likely Patent Free so it would be a perfect replacement for Theora and yes even H.264) :). And there will be no barrier for Accelleration under LINUX like there is with H.264 and VC-1 currently (no Decoder core revealing by ATI nor Nvidia) :).
If you know the History of Wavelet codecs then you know that visually there are superior, they look HVS wise more right then Block based approaches Rududu really showed that nicely and even one of the i would say Main Researcher on H.264 in one of his papers admits that Wavelets could have been a better approach especialy for Grain/Noise Dr.Marpe (Cabac Patent Owner) :)

Hey Rududu is OS now too totaly missed that :D http://rududu.berlios.de/

[Mug Funky]

i-frame only = good for editing

the idea behind DNxHD, ProRes and the like is you have a high-bitrate, online quality ("online" being in the editing sense - broadcast quality and greater) codec that is reasonably lightweight. editing anything that has delta frames is a stupid idea if hard disk space is so fast and cheap. these codecs are like a bridge between uncompressed and offline codecs (DV, mjpg, etc).

this may seem unnecessary if computers are able to edit HD in uncompressed without too much fuss (just a couple of terabytes of very fast RAID via fibre channel), but considering the next generation of cameras are shooting up to 4k (!!!), a high quality compressed, and FAST codec is very appealing. check out redcode for a good example, if not a bleeding-edge one that's not fully proven yet (i'll be finding out next week how well it really works :))

i'd love to see a patent free codec in an opensource editing program... say cinelerra on a linux box with native diracpro support. you could cut in whatever you want and conform in HD on a linux box :), or go tapeless like what the BBC do with Ingex.

[MfA]

just a couple of terabytes of very fast RAID via fibre channel
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.

[jakor]

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/GSoC2008Ideas?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 (http://mediacoder.sourceforge.net/) is your friend ! :helpful:

[e-Pawel]

MediaCoder (http://mediacoder.sourceforge.net/) is your friend ! :helpful:

Ok, but

MediaCoder only has the 0.9.0 release (http://sourceforge.net/forum/forum.php?forum_id=777393), 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]

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/schroedinger/schroedinger-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]

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 (http://diracvideo.org/wiki/index.php/Schroedinger_and_FFmpeg), 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:
http://img715.imageshack.us/img715/6977/originali.th.png (http://img715.imageshack.us/i/originali.png/)

Theora:
http://img682.imageshack.us/img682/3374/theora.th.png (http://img682.imageshack.us/i/theora.png/)

Schroedinger:
http://img682.imageshack.us/img682/7056/schroedinger.th.png (http://img682.imageshack.us/i/schroedinger.png/)

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

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.

[yuri69]

Still no easy to use binary for windows with avisynth input or VFW suport?

First of all, I'm sorry for bumping this elder thread.

Any progress with that? I would love to have AviSynth input support for Dirac/Schroedinger.

I've been struggling with FFMS AviSynth plugin with libschroedinger included for more than a month. It seems that libschroedinger or dependent liborc have some serious issue, because FFMS always crashes on a schroedinger encoded vid.

Is it possible to measure SSIM and PSNR somehow w/o this support? I mean, is there an utility or something?

[valgor]

tiny_ssim source is in this post:

http://lists.mplayerhq.hu/pipermail/mencoder-users/2006-August/003801.html

[yuri69]

tiny_ssim source is in this post:

http://lists.mplayerhq.hu/pipermail/mencoder-users/2006-August/003801.htmlAh, thanks.

All my FFMPEG builds (the latest from the git+libschroedinger 1.0.10 and plenty of various binaries) crash when I try to decode a libschroedinger video file. The decoding process freezes approx 2-4 frames before the ending.

I'd say it's exactly the same problem as previously described by user 'Caroliano' in this thread:
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.

I really don't know any other method of creating YUV files of some schroedinger encoded video files.

//OK. It seems I figured it out. The problem seems to be with the 1.0.10 schroedinger lib. FFMPEG + libschroedinger 1.0.8 from ubuntu repository works flawlessly.