pouët.net

One that allows seeking, not sequential data :)
Ideas anyone?

MJPEG has no inter-frame dependency, as far as I know.

I don't think MJPEG has much more compression than a bunch of separated jpgs on a folder. I can be wrong.

all video codecs have "golden" frames where a full frame is encoded into it. You can encode such golden frames often enough, or especially at times where you actually need them later. Obviously, a golden frame reduces the compression rate. Also golden frames sometimes have a negative impact on the picture quality, especially on cbr encoded streams.

VP8 or h.264 configured to only output I-frames will beat MJPEG quite handily, if you think it's worth the trouble (MJPEG is nothing but sequential JPEGs so it's dead easy).

Xernobyl: correct. You asked for simple, easy to use and random access; you never mentioned efficiency :)

Ector: Does that imply that VP8 and h.264 use more efficient static image compression techniques than JPEG?

Not sure about VP8, but H.264 most definitely does. On some types of content, H.264 I-frame coding beats JPEG2000 as well.

VP8 should be better than JPEG, too. It uses a limited form of arithmetic coding (good) and borrows H.264's Intra Prediction (*very* good). I'd be very surprised to see it perform worse than Baseline JPEG with these features.

Then again, intraframe-only video with modern codecs might be problematic at low bitrates, because it introduces a new kind of coding artifact: intra prediction noise. This is a kind of temporal noise (i.e. invisible in still images, but visible when in motion) that results from the encoder choosing different intra prediction modes and hence generating different artifacts from frame to frame. I don't know to what extent x264 and libvpx are immune to this effect.

how about libraries?

There used to be one in every village, but many of them closed because people don't read books anymore.

lol :)

@Xernobyl:

The only time I've used video I did it with Microsoft Video for Windows. It allows to seek any frame you want and it is really easy to use. The problem is that it is very slow seeking. For the most common video formats, random frame seeking is slow. But, if speed is not a problem for you, since it is so easy to use and you don't need to install any lib, just use it.

By other hand, if you need fast seeking... How long is your video, and what is the resolution? At 640x480, one second of video occupy about 30 Mb... it is a lot, but maybe you can decode your video and store it in an array to randomly access frames later at the faster as possible speed.

If the video so big it doesn't enter in ram, maybe you can develop a cache system that gets, lets say, one full second of video on it each time there is a cache miss.

In "three fourh" I used DirectShow/VFW solution for mpeg-1 encoded content (the credits part) - it's relatively simple to use and handles seeking transparently. The process' performance is codec-dependent though. The bottom-line is that it's of course only available on windoze platforms, but you didn't say if it's a big problem for you, so.. :)

best codec for demo use: mcw6

Can't find any references to mcw6 -- links?

what about if it is pure black and white?

Pure B&W = Write your own. Write a simple RLE codec, even if it's as dumb as NM where N is the number of bytes to repeat and M is the byte value to use.

Cinepak is available on most platforms, included in (presumably) every Windows and Mac, given the age probably already patent-free. Decoding takes very little CPU. Wikipedia: Cinepak

Cinepak and MSV1 were finally removed from Windows 7 I think. Vista and prior have them.

If it's B&W only then just use 1-bit PNGs.

See current MS-Security-Bulletin:
KB982665 - Vulnerability in Cinepak codec could allow remote code execution
Windows 7 is mentioned

Edit: my Win7 also has iccvid.dll, the Cinepak Codec

Best solution is probably h264 with a large number of reference frames.

For lossless purposes and RGB colorspace: CamStudio codec (comes with the screen recorder, adjustable compression), Lagarith (has null frames), ZMBV (from DOSBox, most efficient, must use 16 or 32 bpp).

If it's B&W (not greyscale) and the frames contain lots of high frequency energy, e.g. line graphics, subband codecs (such as h264) will produce many artifacts.

A custom 1-bit PNG player doesn't sound like a bad idea.

ZMBV is not that good for seeking. It is lossless though and compression is pretty high with low-bitdepth material.