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."
I just can say: cool a new codec, which will perhaps allow me to watch some extra pr0n on this slow computer....but then I'm running Linux and this thing is proprietary, so implementation probability is about 10%. However the chinese got their hands in it, so not all is lost.
"Nancy"? Was it named after some coders girlfriend or something?
:P
From a CPU (and therefore an electrical) standpoint the algorithm is better because it uses much simpler mathematics. But I wonder what the video quality would look like. Is it comparable to Mpeg4 based codecs like DivX? This is great for handheld devices, but I doubt it'll make much of a dent on the desktop unless the image quality is a lot better. We already have way more CPU power then we know what to do with
autopr0n is like, down and stuff.
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.
Two formats I can't play in my favorite player (which happens to be just the mediaplayer, but it's the same thing if you are using other players). Will this be the same thing all over again? I don't mind new formats, especially if they are good, but if I can't watch them where I want to, who cares? If the big companies has to buy licenses to get them in their devices, and then force all publishers to use their special software... you know the drill.
I don't care if the software is closed source as long as protocols, codecs, formats, etc are open so anyone can implement and use them.
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.
Sharp was one of the early adopters of MPEG-4, introducing an MPEG-4 video recorder and a Zaurus with an MPEG-4 player in December 2000.
Interesting, yes, but used where? The article does not say.
They also talk about "block noise" which you can see in DivX quite readily if you have a large piece of video recorded at too low a bitrate.
It is like watching a movie with a 1/4inch chicken wire overlay.
One of the problems with DivX that I have noticed is that it does not handle low light secenes very well...and it seems there are algorithms that compensate, because now some encoders complain about bright/outdoor scenes "going white"...heh.
oh, and this caught my eye...
The company has demonstrated video transmission to a notebook PC at 512 kbits/second, to a PDA at 256 kbits/s and to a cell phone at 28.8 to 32 kbits/s.
...and to charter pipeline (aka charter "sipping straw") at (drum roll please) a max of 12Kbytes a second... Road kill on the information highway.
People are going to ask which Mpeg4 codec is best, and, well that is an issue we will have to treat "Ginger"ly...hehehee
Have you read the moderator guidelines? Well, have you, PUNK? (and I want a Karma: Gnarly option)
I don't seem to find anywhere how well this "nancy" compares in the compression rate arena. How much does it compress with the same amount of lossiness? This is very important for this, because if yu don't care about the rate I could simply use gzip to compress my movies and have no loss at all.
[]'s Victor Bogado da Silva Lins
^[:wq
Just imagine the possiblities for live phone sex shows. The porn industry will love this. And why have phone sex with your wife with only words? Soon she will be able to strip for you whereever you are in the world.
It's a low power (power=not much cpu required) designed for mobile devices.
The codec will run "even if CPU power is not high," said Kato. "A 50-Mips CPU can compress and decompress video at 30 frames per second with QCIF [176 x 144-pixel] resolution [using Nancy].
QCIF is a postage stamp, don't get excited... my freakin webcam can do that type of compression right now, this acheives a smaller size I'm guessing. As far as quality is concerned, I don't think thats the main focus.
Their goal is real-time, and low power cpu, and perhaps low bitrate... not highest quality, lowest overall size (MPEG4/DivX, etc)..
I've been waiting for the 1.0 release of Ogg Vorbis for a few years now. Yes, it's a nice CODEC, but the development timeline has been less than ideal for commercial adoption. Ogg Tarkin is still in extremely early development, without even alpha code to show for the effort. While most new audio CODECs have just been proprietary hacks of standard stuff to avoid patent royalties or optimize for streaming, video CODECs are making advances by leaps and bounds. MPEG-4 has the best compression ratio out there, though that may be at the cost of quality. I think that for handhelds and such things, processor requirements may be just as important as compression ratios, and those formats that keep this in mind will flourish.
WARNING: there is a trojan on your
- 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.
>I've been waiting for the 1.0 release of Ogg >Vorbis for a few years now
:-)
Really? Development only began in 1998, and nothing was even announced to the world until 2000 (right here in slashdot, a few months before we'd have liked word to leak out). No one has even known about it 'for a few years'.
>Yes, it's a nice CODEC, but the development >timeline has been less than ideal for commercial >adoption.
MPEG required ~10 years. Our code has been production grade since beta1, and every bitstream make since May 8th, 2000 will work forever. That's less than two years from beginning to frozen. The '1.0' label is just waiting on a paper list of features that has grown over time.
Hrumf. We should have just called 'rc1' 1.0 and no one would have known the difference.
> Ogg Tarkin is still in
> extremely early development,
very true.
> without even alpha code to show for the effort.
Running Tarkin code exists; we actually have three competing implementations, two in CVS, and the 'w3d' module at cvs.xiph.org is the current frontrunner (and the one we're actively developing).
But this is not release grade code.
Monty