Any suggestions for an open source video encoder?

Moderator
Posts: 3,570
Joined: 2003.06
Post: #1
I was just looking at updating my old in-game movie recorder but since Quicktime is going through yet another change and I'm just plain tired of digging through QT docs, the thought occurred to me that since all I'm doing is encoding video, maybe there was a reliable, light-weight, open-source (maybe bsd-ish?) video encoder I could use instead?

Any thoughts about Theora perhaps?

I know this isn't exactly a popular topic in the game dev community, so I am skeptical I'll get many, if any, replies but I figured it was worth asking.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
The problem with Theora is that nobody can then *play* your videos Wink

The QTKit APIs for recording a movie are very simple, though possibly *too* simple. There's also FFmpeg: http://ffmpeg.org/legal.html
Quote this message in a reply
Moderator
Posts: 3,570
Joined: 2003.06
Post: #3
Yeah, I was wondering if Theora was even playable on the Mac.

I might fiddle around with QTKit some more and see what I can do. I'm just so sick of QT. Sad ... but maybe I'll get over that.

I'm not happy with the licensing of FFmpeg, but I suppose it's worth considering. I wouldn't mind it so much by linking dynamically, but the requirement of re-distributing the source, even if you don't touch it, strikes me as annoyingly "leftist" (for lack of a better term). I mean, I completely understand getting credit for it, and that any modifications must be redistributed, but redistributing untouched source just so that it's redistributed doesn't make any sense. .. not to mention the tone that seems like if you so much as forget to cross a "t" in the thank you that you mention on your box, they're going to hunt you down and stab your eyeballs out with rusty nails, then kill you, then burn the body, and then pour salt on it... or is it salt the body, then burn?
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #4
It's LGPL, so satisfying the requirements is not onerous. Just dynamically link it, put the required text in your about box, and link to the official site for the source redistribution part. On Mac OS X, the dylib will be inside the app bundle, so it's no inconvenience to anyone. Everyone using SDL already deals with this. With FFmpeg you do have to take care to avoid the GPLed bits, though.
Quote this message in a reply
Moderator
Posts: 3,570
Joined: 2003.06
Post: #5
OneSadCookie Wrote:It's LGPL, so satisfying the requirements is not onerous. Just dynamically link it, put the required text in your about box, and link to the official site for the source redistribution part.

Geez, their "checklist" which they think is the "easiest" way to comply with the LGPL for FFmpeg definitely comes off as onerous. But the way you're putting it makes it much more palatable. Dynamic linking and distributing it in the bundle is absolutely no problem whatsoever in my book. Credit in the about box and a link to the official site is absolutely no problem either.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #6
Well, IANAL Wink

But the *intent* of the LGPL is that anyone receiving the program should be able to replace the LGPL'd components with compatible, or bug-fixed, or newer, or whatever (as well as ensuring that modifications to the source of the LGPL'd bit are also LGPL'd).

http://www.libsdl.org/license-lgpl.php provides a different perspective on how to comply with the LGPL.
Quote this message in a reply
Moderator
Posts: 3,570
Joined: 2003.06
Post: #7
I see. That makes sense. Shouldn't be a problem then. Maybe I'll dig some more into FFmpeg and see how it goes after all. Thanks. Smile
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #8
IIRC, QTKit is indeed a bit too dumb for this. However, using the C API wasn't all that bad, either. I don't remember if it's 64bit-safe, though.
Quote this message in a reply
Moderator
Posts: 3,570
Joined: 2003.06
Post: #9
I lucked out and managed to get it working again with QTKit. I had already been using as much QTKit as I could previously. The only thing I needed to update this time was setting up the empty movie file. I wound up replacing about 40 lines of old Quicktime junk with the newer QTKit's initToWritableFile. Looking at it now, there is a surprisingly minimal amount of actual QT calls needed to do this. Most of the remaining code is general setup and thread synch stuff. The Cliff's notes of the QT part of it appear to be something like:

Code:
// setup (not sure it needs *all* of these codec attribs but I didn't fiddle with them to find out)
NSDictionary *codecAttributes = [[NSDictionary dictionaryWithObjectsAndKeys:
            [NSNumber numberWithBool:YES], QTMovieExport,
            [NSNumber numberWithLong:kMPEG4VisualCodecType], QTMovieExportType,
            @"mp4v", QTAddImageCodecType, // <-- use rle for no compression at all
            codecNormalQuality, QTAddImageCodecQuality, // <-- change quality to whatever
            [NSNumber numberWithBool:YES], QTMovieFlatten,
            nil] retain];
QTMovie *movie = [[QTMovie alloc] initToWritableFile:tempMovieFilePath error:NULL];
[movie setAttribute:[NSNumber numberWithBool:YES] forKey:QTMovieEditableAttribute];


// adding each frame
NSImage *image = [[NSImage alloc] init];
[image addRepresentation:rep];
[rep release];
if (previousTimeStamp == 0.0)
    duration = 0.0;
else
    duration = currTimeStamp - previousTimeStamp;
previousTimeStamp = currTimeStamp;
timeValue = lrintf(duration * timeScale);
frameTime = QTMakeTime(timeValue, timeScale);
[movie addImage:image forDuration:frameTime withAttributes:codecAttributes];
[image release];

// finish
successful = [movie writeToFile:finalFilePath withAttributes:codecAttributes];

Basically that's all the QT stuff. The rest is just thread synch using a condition lock and grabbing each GL frame via glReadPixels using a pbo and copying it into the rep's bitMapData.

I'm still going to dig into FFmpeg when I get a chance, so I can see if that might be worth it for cross-platform compatibility. But admittedly, the QTKit way of doing it is actually about as simple as I could ask for.
Quote this message in a reply
⌘-R in Chief
Posts: 1,237
Joined: 2002.05
Post: #10
Using addImage: is going to be slooooooooooowwwwwwww.........

Just use the same image compression session C path. It's still the only way to get high performance if you're supplying the data.
Quote this message in a reply
Moderator
Posts: 3,570
Joined: 2003.06
Post: #11
Really? Blink I was completely unaware of that. Thanks for the tip FreakSoftware!
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #12
That's not 64-bit safe, since the QuickTime C API is all gone.

Since 7.2 you can get frames out of QTKit (horrendously slowly) as various more efficient data types than NSImage, but it looks like you can still only get frames in as NSImages. Urgh.

When I was writing http://ourspace.tepapa.com/home/wall the worst design decision I made was using QuickTime. It was pretty much an unmitigated disaster.
Quote this message in a reply
Moderator
Posts: 3,570
Joined: 2003.06
Post: #13
OneSadCookie Wrote:Since 7.2 you can get frames out of QTKit (horrendously slowly) as various more efficient data types than NSImage, but it looks like you can still only get frames in as NSImages. Urgh.

Which wouldn't be so bad if it were a fast path, but geez, you'd think with such a major push onwards they'd at least *have* a fast path! Annoyed

For me, it's just a cutsey bonus and not a core feature, so I can live with addImage for now. It does actually work quite well, but the lingering thought that I now know there is a faster way to do it sure is a bugger. Well, that's tempered by the fact that the rest of my stuff is 64-bit compatible, and it's hard to justify giving that up just for the movie recording side-feature.
Quote this message in a reply
⌘-R in Chief
Posts: 1,237
Joined: 2002.05
Post: #14
It's not like you'll have a major advantage being 64-bit yet. Rolleyes
Quote this message in a reply
Moderator
Posts: 3,570
Joined: 2003.06
Post: #15
Actually I do get a little better performance with 64-bit, depending on what I'm doing. Anecdotally, measuring my custom audio engine performance by looking at Activity Monitor, 32-bit might be in the area of 30% CPU usage, while at 64-bit it might be only 15-20% for roughly the same loading. Why that is, I don't know, but that's *very* roughly the best case improvement I've measured so far. So 64-bit can indeed offer some performance advantage.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  [split] CocoaBASIC released as open source Carlos Camacho 0 3,739 Jan 28, 2011 04:13 PM
Last Post: Carlos Camacho
  Open source Fallout engine coming to Mac (with your help) mvBarracuda 75 52,704 Jan 22, 2009 08:52 AM
Last Post: mvBarracuda
  Port of an open source game engine iarwain 4 4,362 Aug 28, 2008 02:16 PM
Last Post: iarwain
  Spiderweb's Blades of Exile is now open source JeroMiya 3 4,663 Jun 12, 2007 02:35 PM
Last Post: stevejohnson
  Open source alternatives ootoovak 9 5,208 Dec 15, 2006 07:56 AM
Last Post: bronxbomber92