Video Capture Enhancements

[revelator]

Ok read the legal papers and there are two versions.

One the non commercial version which anyone can use but its illegal to sell media encoded with it.
Two the commercial version where you can sell media encoded with it but will have to pay a royalty.

The GPL version is free to use as long as you dont charge money for media encoded with it.
Firefox uses it internally allready to play internet video streams.

So its perfectly safe to use for say quake videos unless someone tries to get a fee for doing it.

[taniwha]

The GPL version is free to use as long as you dont charge money for media encoded with it.

That is incompatible with the GPL. Now, if you fully own the code, it might be a gray area, but for any Quake engine (as none of us fully own the code), it means it would be a violation of Quake's GPL to use such code as it would place on the engine a restriction (non-commercial encoding) which did not previously exist. This is why QuakeForge does not and will not (for now, anyway) support mp3 audio.

[revelator]

mp3 i can understand as they newer opensourced it though some encoders like lame does support it its somewhat of a grayzone though and i wouldnt use it unless i was 100 certain.
on2 (h.264 patent owners) themselfes support the GPL version so i would not be as scared to use it unless i broke the rules put in the GPL license.

if in doubt one could use theora (ogg video codec) or dirac (though many mediaplayers dont support it yet).

Or to get really cocky one could just call the dll and thereby avoiding including any of the code (joequake does so with fmod) bit like we call opengl32 or in directq case d3d39.dll etc.
Might even be a better approach as we could support multiple codecs depending on what we have installed without being in doubt if we broke some law.

[Baker]

Let's just all agree it isn't really GPL but open source of some type and the idea is to let you use the code and if you do something cool, buy a license. And that is nice of them, even if the description of "GPL" is being inaccurately used.

License agreement discussions never end and never entertain. This one has been "ok" so far but let's quit while we're ahead!

[revelator]

Agree can be a bit taxing (phun intentional).

[taniwha]

Ah, good to end with a chuckle

[Spike]

gpl2 is more lax than that. if your codec is part of the system or compiler then chunks of the gpl do not apply. 'part of the compiler' is too hard to argue, but windows does come with mp3 decoders, licensed as part of the cost of your windows license.
gpl2 has nothing against patents specifically. using that windows componant allows you to avoid implementing the patented algorithm in your code, while avoiding the gplv2's contageous nature.
(system component allowances are separate from the 'mere amalgomation' terms of the gpl which avoids the issues of linking to questionably-non-separate-work dlls)

of course, linux users are utterly %£*$ed.

then again, as the gplv2 has nothing against patents specifically, those linux users could move to a sane country that doesn't impose patents on software and there would be no restrictions. for them. but now I'm getting in to politics so I'll end this post here.

[revelator]

Allready in one of those countries but i feel the pain for those who are not.

[mh]

The GPL version is free to use as long as you dont charge money for media encoded with it.

That is incompatible with the GPL. Now, if you fully own the code, it might be a gray area, but for any Quake engine (as none of us fully own the code), it means it would be a violation of Quake's GPL to use such code as it would place on the engine a restriction (non-commercial encoding) which did not previously exist. This is why QuakeForge does not and will not (for now, anyway) support mp3 audio.

Actually it remains compatible; please see: http://www.gnu.org/licenses/gpl-faq.htm ... sOutputGPL - the output of a GPL program is only covered by the GPL "when the program copies part of itself into the output". See also http://www.gnu.org/licenses/gpl-faq.html#GPLOutput for further discussion. So the authors of this codec are perfectly entitled to stipulate their own terms on what's done with the output from it.

[Spirit]

Things to consider:

Span recording over re-loads/changelevels in a demo. Do not screw up audio sync there.

Add options to seriously embiggen hud elements and texts.

Make sure gamma levels are used properly to the output even in window mode.

Save the video with the same basename as the demo file.

Be able to write avi bigger than 4GB. Indexed if possible.

Have the option to both skip over pauses/console-moments as well as allow capture of the console too (for tutorials etc).

I capture in lossless avi and then simply use ffmpeg to encode to H264 (libx264 using the slow preset) and mp3 (libmp3lame using 192kbps fixed). This gives great quality and is fast enough and small enough for me: http://www.youtube.com/user/quaddicted

As much as I am against patents and stuff, this is simply the only viable option if you plan to upload your videos to youtube or other hosts that will reencode it. For years I tried with Theora and Webm, thinking that it would be good enough but frankly x264 kicks any encoders ass and since I already made a pact with the devil now (Youtube/Google, Facebook) why bother.

I'd completely drop Xvid/Divx. Surely H264 on a fast profile would be better in any case.

[Baker]

Make sure gamma levels are used properly to the output even in window mode.

I've thought about that one. And screen shots. That is something FitzQuake doesn't do (apply gamma to screenshots saved). At the same time, I think doing that in realtime for a video is going to be slow.

Save the video with the same basename as the demo file.

I did that. Actually it overwrites it for the reason that is writes to the gamedir folder and a demoname is going to be unique in there. But the ad-hoc bind doesn't.

For years I tried with Theora and Webm, thinking that it would be good enough but frankly x264 kicks any encoders ass and since I already made a pact with the devil now (Youtube/Google, Facebook) why bother.

My goal with the super-easy video capture is to make it accessible to anyone without a lot of trouble.

Most videos someone makes are going to be unserious YouTube fodder. Someone really wanting to do stuff "pro" isn't even going to be using capturedemo but selectively picking segments, using video editing softrware etc. For example, and I don't know first hand, but I bet fraps isn't using super-slow glReadPixels but at least on Windows reading from whatever method Windows provides via API [Probably true for Linux as well, no doubt]

[In fact, I'm kind of wondering if maybe to get the gamma for a video ... may better to grab from Windows than glReadPixels anyway ... I haven't used Fraps in a while, but I think it is fast enough to actually play and record for many purposes ...]

[qbism]

Many ways to skin a cat...

I set Xvid quality settings high and record to that rather than lossless. On my machine this is actually faster when doing HD, possibly because hard drive is slow. Xvid file size is much larger to get similar quality of h.264, but Xvid encodes much faster and is easier to edit.

I would prefer not to encode with the gamma, but wouldn't mind this as a feature because it can be set to 1.0 during vid record. I say without gamma because I always remix in a video editor anyway. Avidemux is good for quick cut-and-paste. Have to crank up the contrast and perhaps do some sharpening to keep Youtube from turning Quake vids into blurry mush.

[Spirit]

It probably would not be a blurry mess if you used H264.

Capturing with a brighter gamma is lightyears better than changing colors in the video afterwards. This might also contribute to your blurriness.

Not to mention that if you edit the video later on and re-encode it, you seriously lose quality. Even more so with XviD.

[Baker]

I would prefer not to encode with the gamma, but wouldn't mind this as a feature because it can be set to 1.0 during vid record. I say without gamma because I always remix in a video editor anyway

I just want to point out that I mentioned gamma + glReadPixels because most of the Quake engines use hardware gamma to control brightness.

WinQuake bakes your brightness settings into the 256 color palette so your screenshots reflect your in-game settings, but an OpenGL engine using glReadPixels but using hardware gamma the buffer you pixels you get isn't modified (often somewhat dark).

[qbism]

The blurriness I'm talking about occurs after upload to youtube in Quake's "native" darkishness, when youtube's recompression removes detail from dark areas. But the video quality of Spirit's Quake movies are the best I've seen on Youtube. So it's time to join the dark side although I despise facebook

What codec packs are people using? I've been using klite because it plays just about anything with the included media player, but I notice that not all the fourcc codes are available to Quake.