Schrödinger One Point Zero Point Zero

Schroedinger-1.0.0 is now out. (download) The 1.0.0 means several things: One, early adopters can start using it for real work — it’s bitstream compliant and fairly well tested internally. Two, it’s API and ABI stable, so integrators can work at adding Dirac support to various frameworks and tools. Three, I’m going to be inundated with bug reports for the next few weeks.

Schro works best (right now) in combination with Ogg and GStreamer, and when compressing SD and HD720 video at constant bit rate. Integration with other projects is now a priority.

Encoded picture quality in CBR (constant bit rate) mode isn’t as good as I would have liked it for a release, but this is a good baseline to ensure progress. A week ago, picture quality was much better, but there was a bad bug that caused bit allocation for some pictures to be way too high, thus starving future pictures and causing the picture quality to drop to “unrecognizable”. The workaround for this release is to make the bit allocator less agressive, so average picture quality is lower, but worst-case is now tolerable.

6 Responses to “Schrödinger One Point Zero Point Zero”

  1. Francesco Romani Says:

    Hi there,
    I’d like to add support in transcode (http://www.transcoding.org) but I have some troubles finding helpful docs and/or code samples.
    Could you please point me to something helpful?
    I’m asking because I find the docs bundled into schro package sometimes lacking, and the gstreamer module source code isn’t so easy to grok.
    Thanks and congrats for great work!

  2. Ingo Says:

    So, where would you like bug-reports? ;-)

  3. Ben Schwartz Says:

    I’ve been working on video stuff for OLPC. We have assumed that Dirac would be far too CPU-intensive for the XO machine, but I don’t know that anyone has actually asked. What decode frame rate would be achievable on the XO at 320×240 with Schrodinger?

    The XO’s CPU is a Geode LX700 (433 MHz). It has relatively poor floating point performance using x86 FPU instructions, and somewhat better using 3DNow instructions. The GPU supports YUV overlays and scaling, but not general scaling or other OpenGL-related facilities.

  4. admin Says:

    Francesco: testsuite/encode and testsuite/decode are the best (only?) starting points for understanding how the API works. You might be able to convince me to do some of the porting work myself.

    Ingo: http://bugzilla.schleef.org/ (temporary, but there will be a redirect when it moves)

    Ben: When I ran the decoder on an XO a month or so ago, it had trouble keeping up with a SD (standard definition, i.e., DVD) stream, but there have been some speed improvements since then, and additional work targetted for the XO could still improve things more. 320×240 would not be a problem at all.

  5. Francesco Romani Says:

    admin: thanks, looks like an interesting starting point.
    I’ve still some perplexities (about stuff like headers handling and packing encoder output into container), but I’ll dig a bit more into test code/source code before asking again. ;)
    I could send to you the address of the experimental(bzr) repo with my code if you like.

  6. Ben Schwartz Says:

    admin: very interesting. I’ll have to try it out.

    The next question is real-time encoding…