Slashdot Mirror


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."

4 of 176 comments (clear)

  1. Probably not by autopr0n · · Score: 5, Insightful

    The benefit of this codec is it's ease of computation, not necessarily it's image quality/bandwidth ratio.

    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 :( It could be a cool way to put videos on my iPaq (Mpeg is still a little choppy)

    --
    autopr0n is like, down and stuff.
  2. Good enough for now? by standards · · Score: 4, Insightful

    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.

  3. Market wont accept... by macemoneta · · Score: 5, Insightful

    ...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.

  4. Simplistic compression by yabHuj · · Score: 4, Insightful
    ...if I my interpretation of the description is correct. They basically seem to break down each image into smaller bits and assemble them later - and only transmit the differences. So the textualized representation may read something like
    • 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.