Nancy Goes Head-to-Head With MPEG-4
Justin Rossi writes: "EE Times has an article about Nancy, 'the lightest video codec' which is taking Asia by storm and finally bringing streaming Video to handheld devices. What I wonder is how it shall fare against MPEG-4, Ogg Tarkin, and MC-10."
The benefit of this codec is it's ease of computation, not necessarily it's image quality/bandwidth ratio.
:( It could be a cool way to put videos on my iPaq (Mpeg is still a little choppy)
Anyway, since it's so quick to encode (you can do it real-time on a 50mips machine... so cell phone, pda, whatever) You'll probably be able to convert the files as fast as you can copy them to the device, or if you want to stream the videos to a cell phone you can have your computer decode them and then reencode them for broadcast.
Unfortunately this thing seems to be a lot more tied up legaly then MPEG
autopr0n is like, down and stuff.
I think Nancy is well-suited for devices that don't try to be video devices - like cell phones and PDAs.
In the relative scheme of things, non-video devices have low-resolution, low quality displays. And obviously the manufacturers of these devices are unwilling to spend significant CPU or board real estate for video purposes.
Devices that need to deliver high-quality video won't bother with Nancy - as anything that isn't a cell phone will have the power and capability to use a quality codec.
Nancy is just a stop-gap solution for delivering very low quality video to underpowered devices. As soon as the video demands increase, or as soon as the power of these devices rise, Nancy will be obsolete.
...video conferencing on the desktop, which has been available for years. Why does anyone think that they will want it in their cell phone?
Can You Say Linux? I Knew That You Could.
- first frame
- left up (pos 0,0) is a 16x32 block, near black (rgb #111111).
- next to it (pos 16,0) a 16x16 block, grayish (rgb #112211)
- below that a block (pos 16,16) with 16x8 green-grayish (rgb #115511)
- below that a block (pos 16,24) with 16x8 block, greenish (rgb #05BB05)
- next frame (Logo background appears in the middle)
- block change in middle (pos. 8,8), size 16x16, black (rgb #000000).
- next frame (Logo starting with bright expanding spot)
- block change in middle (pos. 16,16), size 1x1, white (rgb #ffffff).
- next frame (dito)
- block change in middle (pos. 14,14), size 4x4, white (rgb #ffffff).
...etc...
Something like a poor man's MJPG+MPEG. Maybe, if not using fix colors but linear gradients (4 values total = left-right and up-down) the quality can be a bit better.OTOH this compression is designed for mini-screens with waaaay sub-optimum quality anyway, so blockish compression is not an issue here? A close look at a demo and the algorithms would be interesting, agreed.