Will there ever be a successor to huffYUV or MJPEG?

[Chainmax]

I'm not really complaining, but I wonder why is it that no new codecs have emerged (something like MotionPNG, for instance).

[superdump]

I believe such a thing as MNG exists. Also FFV1 in the latest ffvfw builds compresses much better than huffyuv but is also a lot slower. VBLE is a good fairly fast YV12 lossless codec. Look around a bit, you'll find plenty to play with.

[Chainmax]

Will do. Thanks for the info :).
Why has none of these alternatives hit "mainstream" appeal like huffYUV or MJPEG?

[Tommy Carrot]

Originally posted by Chainmax
Will do. Thanks for the info :).
Why has none of these alternatives hit "mainstream" appeal like huffYUV or MJPEG?

Mjpeg still has no alternative, because the lossless codecs give much higher bitrates, and better keyframe-based lossy codecs still not exist.

FFV1 is really amazing, gives almost half the bitrate of huffyuv, while still lossless. But sadly it is not optimized at all, so it's so slow it's not usable (except on athlonFX i suppose :D).

Well, why is VBLE relative unknown? I don't know, it's better than huffyuv, and still fast enough to be usable. Bad marketing? :)

[Owen]

There is an alternative to Mjpeg.
Try ffvfw's Mpeg4 encoder. Excellent quality at modest bit rates.
You can use more key frames if you need accurate editing.

Regards,

Owen

[General Lee D. Mented]

http://www.morgan-multimedia.com has an mjpeg2000 codec with lossy and lossless modes.

[Neo Neko]

I don't think Mjpeg2000 is gonna be an easy codec to do better with IRT than MJPEG. Perhaps MPNG. MNG I am not sure would be apropriate. It supports GIF style animation with PNG and JPEG compressed images. But it's real power comes from its use of scripts and sprites. Theoretically it could work though. My kudos to the first that implements either one though.

[Tommy Carrot]

Originally posted by General Lee D. Mented
http://www.morgan-multimedia.com has an mjpeg2000 codec with lossy and lossless modes.

Well, i don't find jp2k to be clearly superior to the good old jpeg. It has different artifacts (blurring instead of blocking), but that's it. The detail preservation is not better imo. Not to mention mjpeg2k is too slow.

[Chainmax]

Wait a second, does MotionPNG exist or are you guys just mentioning its theoretical advantages if it existed?

FFV1 sounds very interesting. In fact, I'm going to google for their website and check them out. You guys say it's not optimized, why is that? Is it a newly released codec?

[superdump]

FFV1 is indeed new. It's only in the latest ffvfw compiles though. See here. (http://athos.leffe.dnsalias.com)

MNG does exist because firebird supports it. :) I think its intention is more towards small animated GIF style sequences than full framerate (say 25 fps) videos.

[outlyer]

yeah, MNG exists (http://libpng.org/pub/mng/) and as superdump mentioned it's more directed towards gif style animations (but with png features).

IIRC MNG and PNG are internally quite different but for the time being MNG is the reference when talking about "motion PNG".

About motion png keep in mind png uses a tweaked zlib for compression (http://www.gzip.org/zlib/) and it's very cpu intensive. Try that AVIZlib codec out there and you'll know what I mean :P.

[Atamido]

First, MNG stands for "Multiple-image Network Graphics" and it is not really a "motion PNG" type of format like animated GIFs. It is more of a Flash type of format that supports PNGs internally. It can handle a few different image formats and some simple interactive scripts.

If you wanted to save a stream using PNG images, it would be quite simple to drop the libpng into a directshow filter that compressed/decompressed each frame to/from PNG.

[Tommy Carrot]

FFV1 has clearly higher compression ratio, than PNG, for a given frame, so i think, for capture purposes, MPNG or MNG is not so useful.

[MfA]

Just curious ... whereabouts is FFV1 compression? On level with JPEG-LS?

[Tommy Carrot]

Originally posted by MfA
Just curious ... whereabouts is FFV1 compression? On level with JPEG-LS?

I don't know, i've never tried it. But if this helps, it gives usually 50-70% filesize compared to huffyuv.

[outlyer]

Originally posted by Tommy Carrot
FFV1 has clearly higher compression ratio, than PNG, for a given frame, so i think, for capture purposes, MPNG or MNG is not so useful.
it's not strange, PNG is lossless after all.

[Tommy Carrot]

Originally posted by outlyer
it's not strange, PNG is lossless after all.

FFV1 too.

[outlyer]

Originally posted by Tommy Carrot
FFV1 too.
True, and huffyuv too, forgot what i said :rolleyes:

[Atamido]

But does FFV1 or Huffyuv have an 8-bit transparency layer? This is where PNG would shine, allowing for quite the fancy subtitling.

The problem is that PNG is RGB only. YUV can take up much less space because it can leave out lots of data. (Data that your eye has a harder time noticing) This makes not as well suited for video streams, but it may still do okay with subtitles.

The amazing jcsston threw together a DS filter that could encode/decode video frames to PNG in a few hours. (Isn't he amazing folks?) I encoded a 720x432 video clip and it decoded at about 15fps on my Athlon 2100+. Pretty much unusable for large video sizes. But, it MAY still be useable for static hard-subs on fast systems...

Compression varies with the source. It may be a little bigger than huffyuv, or it may be only 30% of the size. I compressed a 320x240 simple rendered scene that I had made. The Huffyuv had the file at 14,903KB and PNG had it at 3,757KB. That is around 20% of the size of what Huffyuv did. Also, that video decoded realtime 24fps video taking 15% of the CPU for PNG, while Huffyuv took 16-17% of the CPU to decode.

So, scenes with larger/solid color areas will decode faster and be smaller with PNG than Huffyuv. But, other sources will offer little benefit. Given this, subtitles should be very possible with PNG.

[Chainmax]

Pamel: did he release it? If not, why?

What about MJPEG? Are there really no suitable alternatives to it?

[Atamido]

He hadn't said anything, and I don't like to just put links to someone else's test code. But, he just told me I could, and it isn't buggy enough to hold back so here it is:

CorePNG (http://corecodec.org/download.php/70/CorePNG-v0.4-DShow-VFW.7z)

You will need 7-Zip (http://www.7-zip.org/download.html) to decompress the file. Put the file in your windows\system32 folder and register it. In GraphEdit when you go to the filter list, it is under DirectShow Filter with the names CorePNG Decoder and Encoder.

Edit: Changed download link to new build.

[jcsston]

I did some tests with an actual subtitle video stream.
Using VirtualDub and the Subtitler filter with the included demo.ssa and gray.avi to create a black 640x480 3min 10fps clip with the rendered subs.

The RGB24 HuffYuv compressed output from VDub was 571MB.

I then rencoded the clip with CorePNG in GraphEdit muxing to a 14MB MKV. (I've added very basic frame dropping to CorePNG so the output is VFR)
Recompressing the frame-dropped MKV to Huffyuv resulted in 63MB.

On playback of the PNG clip the cpu was between 1%-10%. Once the scolling text came on the cpu went up to 50%. (On my 650mhz T-Bird)

So PNG does get better compression with large areas of solid color and requires less cpu than HuffYuv for playback (the HuffYuv clip used 85%-90%). But it may use too much cpu to be used for fancy subtitling.

Edit: I found a rather serious bug in the CorePNG encoder. If a frame was a really hard to compress, all the frames after that would just the same size.
Fixed in v0.2
The correct size for the PNG compressed subtitle clip is 5MB.

[Zarxrax]

Wow this png codec looks like it could be perfect for me! However, I need a codec to be video for windows compatable so I can export in it from Adobe After Effects. Are the developers planning on adding VFW support? Also I was wondering if it supports rgb32 encoding, as an alpha channel is important as well.

[Neo Neko]

@jcsston
Yes go man go!

And yes a VFW version would be stupa spiffy!

:D :D :D :D :D :D :D :D

[jcsston]

This is my first VFW codec so be warned ;)
CorePNG-v0.4-DShow-VFW.7z (http://corecodec.org/project/showfiles.php?group_id=39)
I've added support for RGB32/Alpha channel but I don't have clips/software to test if it preserves the alpha.

Neo Neko: :D :D :D :D :D :D :D :D

Edit: Link updated

[Chainmax]

Awesome! I only wish I had my computer with me so that I could try the VFW version :( (I'm writing from a cybercofee, long story).

[Zarxrax]

jcsston: thanks sooo much! This works great! I successfully compressed an 8gb huffyuv file to 37mb :D however, your code for the alpha channel seems to crash any program that trys to encode in 32bit mode. Encode works fine for 24bit though.

[jcsston]

Originally posted by Zarxrax
jcsston: thanks sooo much! This works great! I successfully compressed an 8gb huffyuv file to 37mb :D however, your code for the alpha channel seems to crash any program that trys to encode in 32bit mode. Encode works fine for 24bit though.
Opps, that was a rather simple typo bug :o
I checked the Alpha channel support via AviSynth and GraphEdit for the VFW codec. It works. (VirtualDub doesn't support the Alpha channel and always compresses to 24-bits)
CorePNG-v0.4-DShow-VFW (http://corecodec.org/project/showfiles.php?group_id=39)

8gb huffyuv file to 37mb I hope that is a typo, 221:1 lossless compression sounds a little extreme ;)

[Zarxrax]

Thanks! And thats not a typo, its just a very simple (mostly blank) video stream. It seems huffyuv is quite inefficient at compressing empty frames.

[Neo Neko]

Question jcsston. This is a stream of PNGs. But is each frame a PNG in and of itself aka a Key frame. Or are there or would it be possible to do somthing like a quick non-lossy diff and create PNG delta frames. When the difference between frames is relatively small encoding what did not change as large transparent areas could help compression immensly. Any thoughts?

[ChristianHJW]

= MNG !

[ChristianHJW]

I am playing devil's advovat now :

Why is nobody using a good DV codec, like the free Panasonic codec ?

When i exported the Matrix MOV trailer into a DV compressed AVI from QT6 Pro, and then recompressed it with HuffYuv, the size of the resulting Huffie file was 3x bigger ? Did i miss anything important here ? Is lossless DV compression of inferior quality, like having a reduced bitdepths of 8 bit or so ?

[jkwarras]

DV is a lossy format, it's already compressed in the DV tape. So don't recompress to muc htimes your file or you will degrade the quality. To see what i mean, make a colorbar clip and then encode it with any Dv codec. Then recompress it 10 times and see if you see any difference, maybe not at fist sight but take snapshots and you will see differences form the original.

Sorry, a little off topic.

[jkwarras]

Originally posted by Zarxrax
jcsston: thanks sooo much! This works great! I successfully compressed an 8gb huffyuv file to 37mb :D

Is this correct? 8BG to 37MB and still lossless?!!:eek:

Can this codec be used for realtime editing for ex. in Premiere?

PS: I know is in alpha stage but seems SO impresive:D

[outlyer]

Originally posted by jkwarras
Is this correct? 8BG to 37MB and still lossless?!!:eek:Don't expect this performance in real life video. Zarxrax clarified that this video was mostly blank.

I've only done pair ok quick tests until now. With a VHS cap it takes approx. 2x the size of the YUY2 huffyuv (and approx. the same size as RGB huffyuv). The same goes for a DVD rip (of course cleaner source).

Can this codec be used for realtime editing for ex. in Premiere?As stated before it's quite slow (on most machines) for real time.

On my tests, on an Athlon XP 1800:
VHS source, DVD resolution gives ~1.5 fps.
DVD source, 368x272 px it's approx. 9 fps.


Still, it will kick serious ass on a solid/low colour source... BTW any ideas if it will perform specially well on anime? I'm thinking of something like Futurama, which has quite solid colours...

[Atamido]

Originally posted by outlyer
Still, it will kick serious ass on a solid/low colour source... BTW any ideas if it will perform specially well on anime? I'm thinking of something like Futurama, which has quite solid colours... I just compressed a small clip from a simpsons episode.

01:47.265 - 02:18.472 S03E17 - 8F13 Homer at the Bat
512x384 pixels
31.44 seconds
No audio

Size:
158,184KB Huffyuv
113,192KB PNG

Compression time:
0:24 Huffyuv
1:58 PNG

CPU Usage on playback:
http://www.jkfanclub.com:81/png-task.png
The first lump is Huffyuv and the second lump is PNG. After a few playbacks these seemed like normal charts. Again, this is on an Athlon 2100+.

The scene has several different types of colors and some fades. The original source had been the DVD, but what I used was resized and recompressed so the lines where a little more fuzzy. I suspect that if I used the original DVD, the more solid lines would offer a higher compression. Also, if you are planning on using a denoise filter, using it before PNG would make the file much smaller.

[Chainmax]

Originally poste by Neo Neko:
Question jcsston. This is a stream of PNGs. But is each frame a PNG in and of itself aka a Key frame. Or are there or would it be possible to do somthing like a quick non-lossy diff and create PNG delta frames. When the difference between frames is relatively small encoding what did not change as large transparent areas could help compression immensly. Any thoughts?
I second that question. I'd guess that (much like MJPEG and huffYUV) each frame is a keyframe. Would it be possible to implement P and B-Frames for this? I'd assume that even when compressing everything to PNG (i.é: lossless, right?), the inclusion of P and B-Frames would greatly reduce filesize.
Are we (me and Neo Neko) right?
Originally posted by ChristianHJW:
= MNG !
:confused: What do you mean by that?

P.S: realtime decoding speed isn't important when capturing, right?

[Chainmax]

Some comments and a question from someone that tried corePNG:

I tried out the VfW version (v.0.3). On my Athlon XP 2000 box, it isn't very fast; using VirtualDub to recompress a fairly clean 720x480 YUY2 capture to CorePNG gives me an encoding rate of 1.0-2.0 frames/second. Also, as far as I can tell, CorePNG operates only in RGB, making encoded files significantly larger than HuffYUV-encoded YUY2 files.

I understand that the VfW version is still pretty experimental, and in its current state it doesn't seem useful for capturing. Are results with the DirectShow encoder/decoder any different?

[Tommy Carrot]

Originally posted by Chainmax
I second that question. I'd guess that (much like MJPEG and huffYUV) each frame is a keyframe. Would it be possible to implement P and B-Frames for this? I'd assume that even when compressing everything to PNG (i.é: lossless, right?), the inclusion of P and B-Frames would greatly reduce filesize.
Are we (me and Neo Neko) right?



Well, ffv1 can use p-frames, but the overall gain is not much with it.

[Atamido]

From my example above it took almost two minutes to encode a 31 second clip. So, no, it wouldn't be very useful for capturing in most cases. In fact, on the average clip I would probably would come out a little larger than the same clip compressed to Huffyuv. The cases where it would be most useful are:


1. When speed is not a concern and you are compressing anime or CGI where there are large chunks of solid color.

2. You want an alpha channel for transparency.

3. Hard subs using transparency for a faster computer.

[Atamido]

Originally posted by Neo Neko
Question jcsston. This is a stream of PNGs. But is each frame a PNG in and of itself aka a Key frame. Or are there or would it be possible to do somthing like a quick non-lossy diff and create PNG delta frames. When the difference between frames is relatively small encoding what did not change as large transparent areas could help compression immensly. Any thoughts? I just tried this using my simple rendered scene that is 10 seconds long. 14,903KB Huffyuv
2,785KB PNG
3,719KB Delta compressed as PNGBecause the delta of each frame is almost random noise, it is harder to compress than the original frame. This was a single scene, of an ultra pure source. I don't expect that many cases will get better than this. Here is the AVISynth script I used:clip = converttorgb24(avisource("3 Blocks - original.avi"))
Sub = Subtract(clip.Trim(1,0),clip)
Sub

[jcsston]

Originally posted by Chainmax
Some comments and a question from someone that tried corePNG:
Some comments and a question from someone that tried corePNG:
quote:I tried out the VfW version (v.0.3). On my Athlon XP 2000 box, it isn't very fast; using VirtualDub to recompress a fairly clean 720x480 YUY2 capture to CorePNG gives me an encoding rate of 1.0-2.0 frames/second. Also, as far as I can tell, CorePNG operates only in RGB, making encoded files significantly larger than HuffYUV-encoded YUY2 files.

I understand that the VfW version is still pretty experimental, and in its current state it doesn't seem useful for capturing. Are results with the DirectShow encoder/decoder any different?

The VFW version and the DShow versions will have the same compression performace size and should be the same speed wise.

Pamel's tests are very close to what I came up with.
I added simple diff delta frame compression IPIPIPIP and the result was larger than keyframe only.

[Atamido]

Well, I was wrong and I should really test more before posting. It looks like the Diff compressibility compared to the original is dependant on the source. Here is the results of using the StarwarsAAC5_1anamorphicXviD.mkv test file with the above process:311,895KB Huffyuv
325,213KB PNG

310,646KB Delta compressed as Huffyuv
300,661KB Delta compressed as PNGSo, it looks like the Huffyuv was able to do a better job on the original source, but PNG was able to do a better job on the Delta.

But, in both cases, it would force you to use P frames. One of the benefits of these two formats has always been that you can cut anywhere because they are all I frames. It would certainly save some space for certain clips, but you would lose a little flexibility. If jcsston adds the option to do either, than it will be a good option.

Edit: Here is the same data for the Simpson's clip from earlier:158,184KB Huffyuv
113,192KB PNG

127,349KB Delta compressed as Huffyuv
45,274KB Delta compressed as PNGThese are some impressive results.

[MfA]

Pamel, given what subtract actually does I wouldnt put much faith in those numbers (try to reconstruct the original sequence from the encoded file :).

Usually delta coding expands the files. Partly because you have to use either 9 bits for the delta frame or modular arithmetic, which due to the wrap around doesnt exactly do much good for compression, and partly because when there is motion taking the delta does more harm than good.

With real motion compensation you might eek out an extra 20% compression if you do it right.

[Atamido]

Originally posted by MfA
Pamel, given what subtract actually does I wouldnt put much faith in those numbers (try to reconstruct the original sequence from the encoded file :). Unfortunately I have been unable figure out how to do this without a while/for statement, but I don't see any reason that it wouldn't work.

Diff = Video1 - Video2
Video2 = Video1 - Diff

That is very easy to prove and I have taken the diffs of video's before and been able to use it to reconstruct the original, but this is a little different because each frame depends on the one before it.

[Neo Neko]

Well PNG with delta on natural content would likely benefit little or none. But For Anime, Cartoons, or 3D renders it might get insane. And I do mean insane.

[Atamido]

jcsston just got P frames working with Diffs as described above. I tried it out and the results are close to the above estimates. Currently, you set the number of P frames that you want in a row, and it uses that each time. To detect if it would be more efficient to use an I or P frame would require encoding each frame twice, so better but twice as slow.

He also added the option to choose Fast/Normal/Best for the level of compression, and to be able to choose which of PNG's internal lossless filters to use during compression. So lots of testing to be had there, although setting to Fastest with all filters was the exact same speed/size as Fastest with no filters.

From the Simpsons clip from earlier:

158,184KB Huffyuv
130,582KB All I frames Fastest
113,192KB All I frames Normal
109,812KB All I frames Best
73,654KB 2 P frames Normal
61,868KB 100 P frames Fastest
50,369KB 100 P frames Normal
49,189KB 100 P frames BestFor playback, the 2 P frames stays mostly at 94-98% CPU and hits 100% every now and then. For 100 P frames, it stays at 100% the whole time. You can still see the graph above for the all I frames CPU usage, which is the same as playing back a video encoded with Best or Fastest.

The Best setting encodes almost 4 times slower than Normal. Encoding with Fastest was about twice as fast as Normal. Encoding with P frames was about the same time as without.

Once the algorithm is in place to test whether an I or a P frame is more efficient, there should be even more gains to be had for anyone willing to spend the extra time encoding when lossless or an alpha channel is needed.

All of this was with an Athlon 2100+. If anyone has a P4 3Ghz with dual channel ram, I would love to see what it could pull off.
Edit: Added Huffyuv and 100 P frames Fastest to the size list. Also, a PSNR test was run between the Huffyuv and 100 P frames Best to ensure there was no data loss.

[Chainmax]

Originally posted by Pamel:
From the Simpsons clip from earlier:


code:--------------------------------------------------------------------------------130,582KB All I frames Fastest
113,192KB All I frames Normal
109,812KB All I frames Best
73,654KB 2 P frames Normal
50,369KB 100 P frames Normal
49,189KB 100 P frames Best--------------------------------------------------------------------------------
This is just awesome. Could B-Frames be implemented too?

jcsston: keep up the good work :). I truly hope that this will evolve to be a viable alternative to huffYUV (or even MJPEG) as a capture codec, at least on anime/cartoons.