pouët.net

Go to bottom

Simple and easy video codec to use in demos?

category: code [glöplog]
One that allows seeking, not sequential data :)
Ideas anyone?
added on the 2010-08-09 02:43:54 by xernobyl xernobyl
MJPEG has no inter-frame dependency, as far as I know.
added on the 2010-08-09 02:52:46 by trc_wm trc_wm
I don't think MJPEG has much more compression than a bunch of separated jpgs on a folder. I can be wrong.
added on the 2010-08-09 03:36:31 by xernobyl xernobyl
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.
added on the 2010-08-09 08:52:51 by ddeml ddeml
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).
added on the 2010-08-09 08:59:44 by ector ector
Xernobyl: correct. You asked for simple, easy to use and random access; you never mentioned efficiency :)
added on the 2010-08-09 09:10:11 by trc_wm trc_wm
Ector: Does that imply that VP8 and h.264 use more efficient static image compression techniques than JPEG?
added on the 2010-08-09 11:14:09 by doomdoom doomdoom
Not sure about VP8, but H.264 most definitely does. On some types of content, H.264 I-frame coding beats JPEG2000 as well.
added on the 2010-08-09 11:32:41 by ryg ryg
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.
added on the 2010-08-09 15:39:47 by KeyJ KeyJ
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.
added on the 2010-08-09 15:47:26 by KeyJ KeyJ
how about libraries?
added on the 2010-08-09 15:54:37 by xernobyl xernobyl
There used to be one in every village, but many of them closed because people don't read books anymore.
added on the 2010-08-09 17:27:42 by trc_wm trc_wm
lol :)
added on the 2010-08-09 17:31:50 by havoc havoc
@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.
added on the 2010-08-09 17:54:36 by texel texel
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.. :)
added on the 2010-08-09 18:26:43 by kbi kbi
best codec for demo use: mcw6
added on the 2010-08-09 19:39:20 by nosfe nosfe
Can't find any references to mcw6 -- links?
added on the 2010-08-10 03:39:09 by trixter trixter
what about if it is pure black and white?
added on the 2010-08-10 04:17:36 by xernobyl xernobyl
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.
added on the 2010-08-10 04:44:39 by trixter trixter
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
added on the 2010-08-10 13:20:41 by merkur merkur
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.
added on the 2010-08-11 05:43:41 by trixter trixter
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
added on the 2010-08-11 15:23:56 by merkur merkur
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).
added on the 2010-08-11 16:15:40 by ie ie
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.
added on the 2010-08-11 16:21:38 by trc_wm trc_wm
ZMBV is not that good for seeking. It is lossless though and compression is pretty high with low-bitdepth material.
added on the 2010-08-11 17:18:08 by raer raer

login

Go to top