Quote from micha1980de :

@filur

The more important point might be there are other lossless codecs with proper standards available, and a good balance between quality and recording speed? using a codec that eats cpu whilst recording from lfs which also eats cpu into something that's not lossless is none of those things.

well, I still use lossess video capture. The reason is because it will look terrible if I compress it twice. It kind of works out that for the average video that I caputure, MB = 10 * Seconds. So, an hour of footage at 1024x768 for me would be about 36GB. Now, if a 250GB hard drive can be bought for $80, that means it costs about $0.32 per gigabyte. So, an hour of 1024x768 uncompressed video would cost me only $11. Too expensive? I don't think so.... For me, this is not expensive. It may be different for everyone else though.

Ultra-ATA100: $80, not sure on the speed, but pretty slower than SATA
http://www.newegg.com/Product/ ... .asp?Item=N82E16822144309

S-ATA150: $80, 1.5Gbps
http://www.newegg.com/Product/ ... .asp?Item=N82E16822144235

S-ATA3: $80, 3Gbps
http://www.newegg.com/Product/ ... .asp?Item=N82E16822152025

Quote from filur :

The more important point might be there are other lossless codecs with proper standards available, and a good balance between quality and recording speed? using a codec that eats cpu whilst recording from lfs which also eats cpu into something that's not lossless is none of those things.

huh?
sorry but i don't don't understand that last sentence, sorry.
can you rephrase please?

Quote from micha1980de :

can you rephrase please?

Using a codec heavy on CPU to record from a game heavy on CPU does not equal speed.

but it doesn't need to be equal, as far as im remembering correctly, the processors these days are superscalar, meaning they dedicate all cpu load to a task until it's striped off the cpu, to make room (time) for another task...

so in this scenario you have a codec using "more" load than lfs, thsu lfs can't render further until the codec has finished its work for the latest frame, and still you get acceptabe filesizes.

or am i wrong?

regards

Quote from micha1980de :

or am i wrong?

You're talking of something completely different.

The basic math concerning capture speed would include how many cpu cycles LFS needs to draw a frame, and how many cycles for the codec to save the frame. Choosing a fast codec would seem like a good idea here, since LFS tends to use quite alot of cycles.

MJPEG isn't a fast codec for reading either, which doesn't exactly help the process of editing captured video.

Quote from wikipedia :

.. most M-JPEG implementations are designed for interlaced video, M-JPEG is not well suited for movies that are smaller than television resolution. Movies designed to be viewed on progressive scan computer monitors (like web movies or CD-ROM videogames) are ill suited for these implementations of M-JPEG.

.. did i mention it's pretty damn slow, too?

ok, your point.

but what would be the solution?
uncompressed all the way?
Or do you have a better codec in mind?

Quote from micha1980de :

ok, your point. but what would be the solution? uncompressed all the way? Or do you have a better codec in mind?

A good choice might be a windows popup asking for which codec i'd want to use, from which i'd probably pick uncompressed most of the time. Simplest and fastest would probably be to just offer uncompressed output for both audio and video.

acceptable...

at least we'd all have the choice, or to experiment.

regards

Quote from micha1980de :

acceptable...
at least we'd all have the choice, or to experiment.

From the user's point of view, the choice would be great. However, I would hate to be the one who has to support all the weird codecs and debug arising problems.

The problem is, there are lots of flaky, bugged, crashing codecs out there, and some people even have their whole DirectShow infrastructure seriously broken. When this stuff is running in the context of your process it may not only crash your program, but induce strange, hard to reproduce, hard to debug problems. It may corrupt your heap memory, leak your process resources, leave running threads behind, and you as a programmer don't have any control over it.

As a programmer, I would probably choice ffmpeg libraries with a few carefully selected codecs and few encoding settings. I would bundle all the dlls with the app and no user installed crap could break it. To satisfy advanced users there could be an option to just write raw audio and video data to a socket and let an external app handle it, similar to In/OutSim/OutGauge.

good point, i'd prefer a standard "frame-out" if sth. like this exists.
after that you could easily convert it to any format you like...

maybee the programmer of V-dub (orig) has the same problems with "broken" codecs...


regards