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