Slashdot Mirror
Loki Software to Open Source SDL Motion JPEG Library
Loki Games has announced that they will be undertaking their 3rd Open Source project, the SDL Motion JPEG Library. SMJPEG creates and displays full motion video with a non-proprietary format created by Loki. It was developed while porting Railroad Tycoon II: Gold Edition. Check out their website for more details. Suffice to say that "among its many benefits, SMJPEG allows for arbitrary video sizes and frame-rates, user-tuneable compression levels,
and facilities for frame-skipping and time synchronization," according to Loki.
Is this similar to the motion jpeg codec (NOT the same as MPEG) used widely as a high quality high bitrate format for captured digital video?
If so, it's quite useful for local playback and editing, and provides very high quality, since each frame is basically just a jpeg. But without any attempt at delta compression, it results in stonking bitrates.
Very useful for editing though.
On further reading this looks more like an MPEG format, since it is based on MPEG 1 code. That would be a pity, since MPEG 1 fills its niche badly, while motion JPEG filss its niche well. However, I can see why a games company would want an MPEG (low bitrate/low quality) format more than a high bit rate high quality format.
-----
According to Linuxgames the source code has already been released.
SMJPEG documentation
SMJPEG source code
BlueSky
I've recently tried out Loki's latest Myth II demo , and it's one of the best games ever written for Linux. I was amazed and shocked, but the best thing about this game is not the game itself, but the fact how smooth and playable it is under Linux/XFree86. I never thought that such level of control and performance was possible in X. Myth II grabs the whole screen intelligently and goes into full screen mode without any flicker. Mouse movement cannot not move you out of focus, only exit brings you back to 'normal X'. Still the game has the performance of native SVGALib apps. I wish Loki good luck - both in their Open Source, and game-porting projects. They really have proved that Linux can be an excellent gaming platform.
--Coke
This falls squarely in the "rumor" catagory, but at NAB99 about a truly "crossplatform" version of QuickTime, and he very carefully worded it as "we would NOT see a Linux version of QuickTime before the OS X Consumer version was out".
I forget when OS X Consumer is out... Spring maybe?? That *doesn't* mean a Linux version will be out then, what I heard implied was we might get a clearer picture..
Basically the issue for those that don't know is, OS X Consumer is a UNIX BSD-based ("the other Linux" as someone put it, although it's technically innaccurate) implementation, and since OS X is commercial that will be "competing" for mindshare. Releasing a QuickTime for Linux before OS X would kind of steal Apple's thunder... QuickTime is one of the few world-class technologies they have left that can be sold, and great QT support IS still a basis for buying a Mac for some people.
I see both sides of this, and it is frustrating not to have a robust and well-supported video system in Linux. It's not *entirely* Apple's fault as some would state.. I don't see Red Hat and SuSE funding some GPL'd alternative (which without compatible codecs is moot anyhow). Apple doesn't "owe" the any platform a player - they owe their stockowners results. Anyways, It's fantastic to see some free good work out there.... thanks LOKI! I don't think a company should "own" a video delivery system any more than a phone (or cable...) company should have a monopoly .
The FIRST person I talked to at Apple's booth said "if I wanted QuickTime on UNIX I'd have to buy OS X". Great.. does OS X run Linux binaries? Oh, wait, they quietly smothered OS X for Intel (remember?). "Der...":-/
It looks like we're seeing a minor trend for companies that make their profits off OSS code and/or OSS users to "give a little back" in terms of open-sourcing some of their own creations. Let's hope these smallish companies can establish a new ethos for the profession, in opposition to the "can't let go" mentality of the established vendors.
Sheesh, evil *and* a jerk. -- Jade
QuickTime server was open sourced and possibly enough information to understand the file format. What hasn't been open sourced are CODECS (compressor/decompressors) such as Sorensen. So while you've got a system for net distributing already compressed image data you don't have an open sourced system for producing it.
As far as I know there are no open source initiatives to actually produce a CODEC for high quality and low bitrate image data.
Rumor has it that Sorensen has stated that Apple prohibits them from open sourcing their CODEC. I'm not sure how true it is. It may be closer to reality that Apple wouldn't be happy about it after paying large fees to make use of it. The other half of the equation might be that even if Apple didn't care one way or the other Sorensen still wouldn't. CODECs are expensive pieces of intellectual property to create, it may well be that Sorensen uses Apple as a convenient scape goat.
I don't know anything about quicktime being open source, but I know the codecs are not. What good is quicktime without the codecs? Developing the file format is quite simple, it's developing the codec that takes time. The description of the file format for SDMJPEG is maybe 50 lines. IMHO Loki did a good thing by creating their own format. I wouldn't trust Apple for a second when it comes to open source. IIRC Apple can still revoke the license on whatever parts of OS X that they released as "open source".
-matt
I just want applaud those commited to creating open source multimedia stuff for Linux.
Other stuff coming....
Though it won't be open source as far as I know, a company in Germany called Main Concepts is currently developing a low cost Video Editing system for both Windows and Linux. They are also developing(or already developed) a software only DV codec that should have generally higher quality than MJPEG with lower bit rate requirements (basically about 25Mb or 3MB per second throughput). DV, unlike MJPEG is lossless. The great thing will be the ability to encode/decode DV video without the requirement to be attached to a 1394 device. The company is very commited to the Linux platform.
Please no Flames, just putting out some info.
http://www.mainconcepts.com
Bigger yes, but not ten times bigger. I've done some experiments. A 600x400 image compresses down to 15k with some minor artifacts, and 24k with some almost-invisible artifacts. Reduce that to 300x200 and you are looking at 8 or 9k. My experience of watching compressed video is that the motion reduces the visual impact of the artifacts because they keep changing randomly, while the eye tends to track the image. So you should be able to get away with some 15k per frame. Maybe slightly less because these figures include picture headers that would be factored out of MJPEG.
At 15k per frame and 25 fps that is 375k/sec, or 1.35Gb/hour, which is about twice MPEG-1. Plus sound of course. But radio quality sound only needs about 8k/sec, so we can ignore that for now.
Has anyone tried doing this in real-time? It strikes me that we might have a DIY version of the TiVO here.
Paul.
You are lost in a twisty maze of little standards, all different.
OK, so Loki's games are non-free (but that's to be expected), but not only do they enable us to play top games (CivCTP is wonderful) ported professionally to Linux (the games feel like the "real thing"), but they keep on giving code to the Free Software Community. IMHO they are a good thing, and I'm happy to support them by bying games.
"At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org
Mostly because when we approached RAD Game Tools, they basically said: Sure, you can port smacker to Linux, and then you have to pay us to use it. The SMJPEG versions of the video files were about 60% of the size of the Smacker ones. There are obvious quality artifacts since we compressed the video down to 320x240 and then re-expand it to 640x480, but for the types of movies in RT2, it works just fine. SMJPEG is definitely not a replacement for MPEG or Smacker, but it is a good alternative. -- Sam Lantinga, Lead Programmer, Loki Entertainment Software
I got your QuickTime for Linux right here
No you haven't.
The QT4Linux libraries are development libraries, and do not posess hardly any of the features of the QT player as developed by Apple. And certainly, the most interesting codecs (Sorenson, Qdesign) are not included.
Although the libraries are great, and we're using them for a M-JPEG project right now, they're not to be confused by the player proper, so please don't pretend that they are.
Linux Media Labs offers MJPEG hardware for Linux and I want to comment on some widespread misconceptions about MJPEG vs. MPEG performance.
Full rate, broadcast quality signal (D1) at 720x480@30frames/sec with 4:2:2 color (2 bytes/pixel) has a data rate of 20 MByte/sec. Now, with 1:10 compression the image quality is very good, especially since there is 60 fields per second with noise caused by lossy compression averaged out. So, D1 quality requires 2 Mbyte/sec bandwidth. That is about 7 Gbyte/hour. DVD disks have 4.7 Mbyte of capacity and hold about 2 hours of video. Therefore with all hoops and patents MPEG-2 has 3 times better performance. I would argue though that D1 encoded with MJPEG at 1:10 compression is much better quality then DVD, and don't forget that it's a 4:2:2 color, not 4:2:0 one as in DVD.
Let up now go to VHS (MPEG1) qualiity and also reduce frame rate to 15 frames/sec. There would be no flicker since our video frame buffer still allows our CRT to be refreshed at 60 fields per second. 320x240@15frames/sec at 4:2:2 (2 bytes/pixel) gives us 2.2Gbyte/sec uncompressed and with 1:15 JPEG compression (certainly better then VHS) gives 150 Kbyte/sec. MPEG1 data rate is about 180Kbyte/sec - i.e. MPEG1 is no better then simular quality MJPEG.
Advantages of MJPEG:
Therefore maybe Linux should use MJPEG as a standard for handling video.
Speaking of codecs - nothing prevents Open Source community from creating a first class MJPEG codec. As a matter of fact we're working right now on a MJPEG viewing application, simular to xanim from the user prospective but optimized for MJPEG with the requirement to playback 720x480@30fps on resonable hardware and it's under GNU GPL of course. If anybody has some top performing (assembly language?) JPEG code (DCT/Huffman) or desire to work on such (under GNU GPL) I would like to talk very much.
Vassili Leonov vleo@linuxmedialabs.com
Vassili Leonov