CorePNG - New LossLess codec

[Atamido]

Here is a new lossless codec based on PNG developed by the talented jcsston. Essentially, each frame is compressed as a PNG, so if PNG does it, this codec does too. (RGBA) This new version has the ability to write P frames and to autodetect when it should. The P frame takes the difference of the previous frame and the current frame and encodes that as a PNG.

Things to note:
1. It is slower to encode than Huffyuv.
2. It is usually slower to decode than Huffyuv.
3. File sizes are usually smaller than Huffyuv.
4. It works best with large areas of similar color like Anime/cartoons.
5. P frames take a little more power to decode because the codec must take the difference of the video after decoding the frame.
6. Encoding with Auto-Delta frames is about 50% slower because it must encode each frame twice.
7. There is a maximum interval of 1000 frames between keyframes.

Here it is:
CorePNG vfw (http://corecodec.org/project/showfiles.php?group_id=39)


This really shouldn't be sitting at the bottom of another thread. Actual stats will be posted next.

[Koepi]

Nice work Pamel! :)

Is there any chance to make that codec/PNG YUV-aware? As far as i understand it, PNG uses more or less some kind of zip/gz compression, so it shouldn't be too problematic to feed it with "any" kind of data. (I'm of course aware that there are libgz-based codecs [ok, I know of one slow one] out there, but PNG is somewhat inherantly more graphics/image based.)

Anyways, thanks for your time spent on it and for your work!

regards
Koepi

[Atamido]

Whoa there speedy! This codec is ALL jcsston. I just told him to do it. ;)

Here are some test clips to show how well certain things work. (all tests were done in RGB)

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

158,184KB Huffyuv
131,190KB Loco
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 Best
40,603KB 1000 P frames Best with Auto-Delta frames


StarwarsAAC5_1anamorphicXviD.mkv From the Anamorphic test.
720x432 pixels
32.60 seconds
815 frames
No audio

311,895KB Huffyuv
325,213KB All I frames Normal
276,710KB 1000 P frames Best with Auto-Delta frames


3 Blocks, Simple rendered scene.
320x240 pixels
10.00 seconds
240 frames
No audio

14,903KB Huffyuv
2,785KB All I frames Normal
2,538KB 1000 P frames Best with Auto-Delta frames Encoding to "All I frames Normal" is about 4-5 times slower than encoding to Huffyuv. Encoding to "Best" is about 4 times slower than "All I frames Normal". Encoding to "Fastest" is about twice as fast as "All I frames Normal". And using Auto-Delta makes the encode take 50% longer. So, if encoding a clip in Huffyuv takes 1 unit of time, then a quick estimate would be:

1 Huffyuv
2 Fastest PNG
4 Normal PNG
16 Best PNG
24 Best w/ Auto-Delta.Those numbers will get a little more refined with some more testing.

Here (http://insipid.us:81/png-task.png) is an image that shows decoding the Simpsons Clip. The first hump is Huffyuv and the second hump is "All I frames Normal". There is no decoding difference with video encoded with Fastest, Normal, or Best. The 2 P frames stayed mostly at 94-98% CPU and hits 100% every now and then. For 100 P frames, it stayed at 100% the whole time. For the Auto-Delta, the CPU usage was about halfway inbetween 2 and 100 P frames.

[Koepi]

Hm, nice results - so it's definatly useful for anime/cartoon intermediate files.

My credits go out to jcsston - sorry for any confusion :) (Still thakns for the tests and announcement/forcing jcsston to code that ;) )

Best regards
Koepi

[Tommy Carrot]

Why are you compare it to Huffyuv? There are much better lossless codecs. I'm particularly curious how is it doing against ffv1 on animes or cartoons (i cannot test since i haven't got any right now).

EDIT: BTW, nice work! ;)

[Atamido]

Originally posted by Tommy Carrot
Why are you compare it to Huffyuv? There are much better lossless codecs. I'm particularly curious how is it doing against ffv1 on animes or cartoons I used Huffyuv because its the most common lossless codec. Almost everyone has used it, so its easier to get an idea.

I also wanted to try VBLE, but I'm not sure where to get it.

I made some tests with FFV1, but I couldn't play any of them back so I'm not sure about the numbers it produced. Although it did much better on the StarWars clip and a bit worse than Normal I frames on the Simpsons clip. If anyone can get this codec to work, please post a comparison.

[jcsston]

I havn't tested againist VBLE because VBLE only works in YV12 mode. And comparing a RGB24 codec againist a YUV codec isn't much of a comparsion. ;)

[Wilbert]

@Pamel,

The vble codec can be found here:

http://forum.doom9.org/showthread.php?s=&threadid=53305

[jcsston]

I say again, this codec in it's current state CANNOT be compared equally to VBLE or FFV1. Both those codecs work in YV12 colorspace, half the bits of RGB24. And neither support Alpha channel.

I don't see many people comparing 44.1Khz Monkey audio to 22.05Khz FLAC :p

[Human_USB]

On fast mode I get 4 FPS and on Best I get 0 to 1 FPS. Also I do not have Auto-Delta on. I wish I got the speed Pamel got.


*EDIT*
Also my video is upside down.

*EDIT 2*
I find that when I encode in Fast mode my video comes out upside down.

[Tommy Carrot]

Originally posted by jcsston
I say again, this codec in it's current state CANNOT be compared equally to VBLE or FFV1. Both those codecs work in YV12 colorspace, half the bits of RGB24. And neither support Alpha channel.

I don't see many people comparing 44.1Khz Monkey audio to 22.05Khz FLAC :p

Well, Loco (http://forum.doom9.org/showthread.php?s=&threadid=53305&highlight=loco) codec does support rgb colorspace, and there is an option to alpha channel support too, but i've never tried it, so i don't know if it really works.

BTW, the delta-frames are great idea! I've tried CorePNG on CGI, and the size gain is huge with delta-frames.

[jcsston]

Originally posted by Tommy Carrot
Well, Loco (http://forum.doom9.org/showthread.php?s=&threadid=53305&highlight=loco) codec does support rgb colorspace, and there is an option to alpha channel support too, but i've never tried it, so i don't know if it really works.
I tried out the Loco codec and on my test clip it was larger than the Huffyuv version (both in RGB24 mode). :confused:

[Atamido]

Originally posted by Human_USB
On fast mode I get 4 FPS and on Best I get 0 to 1 FPS. Also I do not have Auto-Delta on. I wish I got the speed Pamel got.

*EDIT*
Also my video is upside down. With a lower speed processor, you are probably much more able to give an idea of the speed difference between Huffyuv and CorePNG on a given clip because the processor will be the main bottleneck.

The upsidedown video is an issue with DirectShow using the VFW codec to decode. You should not see this if playing the file back in VirtualDub. This will be fixed very soon.

[Dead2]

Hmm... You say you support Alpha channel..?

Does that mean you use RGBA all the time, or is there an option to do just RGB? I guess alpha-disabled clips would benefit from that. Btw, are there any video clips with alpha yet? if so, what for?

Yuv support should/could be quite simple actually..
If I remember correctly, you could just add the 3 output yuv bitmaps together, then compress them using regular 256color png.. After all, that is what png is really good at.


_________________
| | u |
| y |_____|
| | v |
|_________|_____|


Another thing.. for .png images there is a util called "pngcrush" that basicly re-tightens the image for those 2-15% extra compression still without loosing anything.
This could be an option "Super-compression" or something. Unfortunately it tends to take time, but I would definetely use that for testclips that I have stored permanently in lossless format.

Also, if you look at the pngcrush site, there are mentions of a few tweaks they had to do to the zlib before it would be optimal. Maybe worth checking out aswell?

Good luck! We'll be watching your progress =)

-=Dead2=-

[jcsston]

Originally posted by Dead2
Hmm... You say you support Alpha channel..?

Does that mean you use RGBA all the time, or is there an option to do just RGB? I guess alpha-disabled clips would benefit from that. Btw, are there any video clips with alpha yet? if so, what for?

Yuv support should/could be quite simple actually..
If I remember correctly, you could just add the 3 output yuv bitmaps together, then compress them using regular 256color png.. After all, that is what png is really good at.


_________________
| | u |
| y |_____|
| | v |
|_________|_____|


Another thing.. for .png images there is a util called "pngcrush" that basicly re-tightens the image for those 2-15% extra compression still without loosing anything.
This could be an option "Super-compression" or something. Unfortunately it tends to take time, but I would definetely use that for testclips that I have stored permanently in lossless format.

Also, if you look at the pngcrush site, there are mentions of a few tweaks they had to do to the zlib before it would be optimal. Maybe worth checking out aswell?

Good luck! We'll be watching your progress =)

-=Dead2=-
The Alpha channel is only compressed/used if the input is RGB32. VirtualDub only copmressed to/from RGB24 so you don't have to worry about that. The most often clips to use the Alpha channel would likely be CGI or title clips that are being used to create videos.

Thanks for the idea of having different images for YUV.

I've looked into the various things pngcrush does, but most of the things that it does to improve compression are hard-coded (need a different compile for regular compression) and it also increases decode time.

I've fixed the image flip bug with 32-bit decoding. :)
Download CorePNG VFW Codec v0.6 (http://corecodec.org/download.php/74/CorePNG_vfw_v0.6.zip)

[BetaBoy]

I asked jcsston to create a MAIN project page for CorePNG on www.CoreCodec.org for easier access and because it needed it ;)
Get it here: http://corecodec.org/projects/corepng

FYI: for those looking for a nightly Source Code 'cron job' for all the CoreCodec.org projects (including Matroska and it's associated projects) go here: http://cvs.corecodec.org/nightly/

----
Dan "BetaBoy" Marlin

[MfA]

It would be nice to have some idea of the comparitive performance against FFV1, how about using avisynth to produce an avi with just a single color component to do the comparison for now?

[Human_USB]

Originally posted by Pamel
With a lower speed processor, you are probably much more able to give an idea of the speed difference between Huffyuv and CorePNG on a given clip because the processor will be the main bottleneck.

The upsidedown video is an issue with DirectShow using the VFW codec to decode. You should not see this if playing the file back in VirtualDub. This will be fixed very soon.



But the sad thing is I have a 1800+ XP with 256 of 2600 DDR. Also my Hard drive has 8 MBs of cache so I have no clue what is killing my speed.

[BetaBoy]

Jory just released v0.6 which fixes the flipped image bug.

http://corecodec.org/projects/corepng

[Chainmax]

I second the YUV request. Also (like I asked in the original thread), could B-Frames be implemented too? What about an optional lossy mode for P-Frames (and B-Frames if they get implemented)?

[Human_USB]

Ok.... that fixed the problem. I tryed encoding a Anime episode which is 23 minutes and VDM said it was going to be 6 GB when done!!! That is HUGE!

[Atamido]

Originally posted by Human_USB
I tryed encoding a Anime episode which is 23 minutes and VDM said it was going to be 6 GB when done!!! That is HUGE! Welcome to the world of lossless encoding. Make sure to use the Auto-Delta frames. What would the size of the file be for Huffyuv?

[Human_USB]

With Huffyuv I get about 6.3 GBs.... and I was using Auto-Delta in Fast mode. I know Lossless is larger because I use FLAC for all my music. But still 6 GB lossless when the VOBs are only 1.15 GBs is a little over kill in my eyes.

[Atamido]

Originally posted by Chainmax
I second the YUV request.I don't know how feasible that would be since the PNG only accepts RGB/A, and any attempt to combine frames would be pretty hackish.Also (like I asked in the original thread), could B-Frames be implemented too?In VFW you would have the B-Frame decoder lag. You could do it in DShow, but it would mean a lot more work. Say you have three frames ABC. When you go to compress B, you would have to compress it normally, take the diff of A/B and compress that, and then take the diff of B/C and compress that. The smallest one would get stored.What about an optional lossy mode for P-Frames (and B-Frames if they get implemented)? PNG doesn't have a "lossy" mode. But I did suggest to jcsston to have an option to convert to an 8bit(256 color) PNG. You could convert every P frame to 8bit before compressing and you would get a really high compression ratio, but I'm not sure how much affect that would have on image quality.

[Atamido]

Originally posted by Human_USB
With Huffyuv I get about 6.3 GBs.... and I was using Auto-Delta in Fast mode. I know Lossless is larger because I use FLAC for all my music. But still 6 GB lossless when the VOBs are only 1.15 GBs is a little over kill in my eyes. You have to remember that the VOBS are lossy compressed. It would be like converting a 128kbit MP3 to FLAC. You are going to put on a lot of size.

Huffyuv and CorePNG aren't meant to store your movies with. You use these when you would otherwise use uncompressed video, but you don't want it to take as much space. Here are a few examples of where they are useful:

1. You render movie clips with 3D Studio Max or Maya and you want to store them losslessly so that you can do stuff with them later without losing any quality.

2. You have an movie clip of something that you use in making some home movies. You can add these clip in knowing that they are the original quality. You could have a clip of fire with (up to 256) layers of transparency that you put on different parts of the film to make it look like there are fires. (You would need something like Premiere)

3. You want to edit a movie clip in several stages, but you don't want to lose any quality by compressing it at each stage.

If you have a lossy source that you just want to store, there isn't any reason to convert it to a lossless format as it would take much more space.

[Human_USB]

ok.... thanks.

[Tommy Carrot]

Optional lossy mode is totally pointless. You would still get a _huge_ file as a result. If loss is tolerable, xvid with quant 2 is still perfect, with much, much smaller filesize.

YUV (or YV12) support is essential imo. Most source is already YUV, so there would not be loss anyway, and the bitrate would be cutted to half, or even more (afaik yuv is usually more compressable than rgb).

Of course, it is a problem that it wouldn't be real MPNG anymore. :)

[TEB]

This is awsome. Is matroska as a container format supported?

teb

[jcsston]

Originally posted by TEB
This is awsome. Is matroska as a container format supported?

teb
Yes, this codec uses the standard VFW/DShow interface and can be used in just about any container.

[TEB]

is this codec any kind of smp optimized? or is the bottleneck elsewere?

[Human_USB]

BTW.... why not use MNG? Would that not make your life easyer?

[jcsston]

Originally posted by Human_USB
BTW.... why not use MNG? Would that not make your life easyer?
Not really. MNG is much too complex to be used as a video codec. MNG is in fact closer to Flash A few quotes from the MNG website (http://www.libpng.org/pub/mng/)
# object or sprite-based approach to animation, with commands to move, copy and paste images (rather than replicate them as in GIF)
# nested loops for complex animations

[Atamido]

Originally posted by TEB
is this codec any kind of smp optimized? or is the bottleneck elsewere? I don't think that the actual compression code from libpng is optimized at all for SMP, but there are improvements that could be made other places. For instance, when doing auto-delta frames, you could encode the normal frame and the delta at the same time using different threads instead of encoding them one after the other.

[Stabmaster-Arson]

Dual AMD MP 2600+ <=============

I hereby vote for SMP optimisation/support.

Cheers!

[Atamido]

Even though this is not fair because CorePNG currently only does RGB, I went ahead and used the original converted to YUY2(See below for FFV1) to test some other lossless codecs. I used the same Simpsons clip as before. (A DVD reencoded to DivX 3.11 so it uses a YV12 colorspace.101,288KB Huffyuv in YUY2
65,868KB Loco in YUY2
63,606KB VBLE in YUY2
47,422KB FFV1 in YV12*
40,603KB 1000 P frames Best with Auto-Delta frames in RGB*FFV1 will basicaly only work in the YV12 colorspace. So, if your input is YV12, then FFV1 is lossless. That means any filtering or other colorspaces are going to be losing data.

[Tommy Carrot]

The latest ffvfw has some problems, so i suggest to try this (http://athos.leffe.dnsalias.com/ffvfw-20030927.exe) version. I've made some test with this AVS script, which was made for highlighting the difference:

clip1=avisource("source.avi")
clip2=avisource("ffv1_ac.avi") #optionally use convertoyuy2
Subtract(clip1,clip2).Levels(127,1,129,0,255)


If the source is indeed in YV12 colorspace, there is no difference, so this codec is lossless.

EDIT: of course you have to set the colorspace of ffv1 to YV12 for this.

[Atamido]

Got it to work now. Had to set everything in the settings and AVISynth to YV12 and it showed lossless in the compare.

[Chainmax]

Questions:

Is png any good for natural 24bit stuff? I believe it isn't.

I also believe YV12 shoudln't be pursued for capturing.

[TheXung]

Of course YV12 should be pursued for capturing if the final compression format will be also in YV12. I mean what final compression format isn't in YV12, that's still in popular use?

It is biased to give comparison numbers but not show or describe the source. Was that a cartoon or natural? and was it captured or DVD?

[scharfis_brain]

If capturing directly in YV12 be sure to use interlaced YV12!
If not, you'll mess up the colors in interlaced video.

btw. capturing in YV12 makes vertical chromashifting difficult (VHS caps), because interlaced YV12 can only be shifted in steps of 4 lines vertical without loss, while YUV can be shifted lossles in steps of 2 lines...

scharfi, who always caps with YUV..

[Atamido]

Originally posted by Chainmax
Is png any good for natural 24bit stuff? I believe it isn't.Yes. The only difference between 24 bit RGB and 32 bit RGB is an extra 8 bits that can be used as an alpha channel. PNG is functions just fine without and alpha channel.

[Atamido]

Originally posted by TheXung
Of course YV12 should be pursued for capturing if the final compression format will be also in YV12. I mean what final compression format isn't in YV12, that's still in popular use?

It is biased to give comparison numbers but not show or describe the source. Was that a cartoon or natural? and was it captured or DVD? ] If you are planning on filtering the video at all after capture, then you would want RGB because you would have a more video data to use in the filters. If you are capturing and encoding strait to a YV12 format, then capturing in YV12 is the only thing that makes sense.

Sorry about those numbers. They were using the same Simpsons clip as before. You will notice I just copied and pasted the line for CorePNG.

[Mr_Khyron]

Originally posted by Pamel
If you are planning on filtering the video at all after capture, then you would want RGB because you would have a more video data to use in the filters. If you are capturing and encoding strait to a YV12 format, then capturing in YV12 is the only thing that makes sense.

there are many good YV12 filter from neuron2, sh0dan etc... :rolleyes:

[Atamido]

Originally posted by Mr_Khyron
there are many good YV12 filter from neuron2, sh0dan etc... :rolleyes: Whats your point? I said, "its better to filter with more data." I didn't say "you can't filter with YV12."

[Koepi]

I think what Mr_Khyron means is that you don't gain anything by converting from YUV to RGB. If you have sources in real RGB (i.e. TV cards internally do YUV due to the composite nature of the tv signal) you're right Pamel.
If you have a dvd or captured source you're most likely dealing with YUV, which you can upsample and convert to RGB of course - but this interpolation necessary doesn't give you "real" data to work on. From my experience this interpolation step makes colours "dirty".

Hm. I think at least this is what this is all about ;)

Regards
Koepi

[jcsston]

Originally posted by scharfis_brain
If capturing directly in YV12 be sure to use interlaced YV12!
If not, you'll mess up the colors in interlaced video.

btw. capturing in YV12 makes vertical chromashifting difficult (VHS caps), because interlaced YV12 can only be shifted in steps of 4 lines vertical without loss, while YUV can be shifted lossles in steps of 2 lines...

scharfi, who always caps with YUV..
Can you give me some infomation on interlaced YV12? I've read a number of AviSynth threads about it and it seems that VFW doesn't provide a way to tell the difference between interlaced YV12 and progressive YV12?

[scharfis_brain]

hmm. interlaced YV12 isn't easy to explain, but I'll try

a interlaced full frame holds two individual fields.
we can separate this frame into its two fields.
and now we apply a RGB to YV12 conversion fieldwise (to supress chroma mixing between the fields). this means, that a 768x288 large field will have a chroma resolution of 384x144. by weaving both fields togehter you'll get the full frame, but color information is also interlaced (at half res)

as you can see the chroma is really messed up.

I've upped two examples here: http://home.arcor.de/scharfis_brain/samples/

[kastro68]

i just gave it a try a few hours ago.

Unfortunately my cpu isn't fast enough to allow capture in Real Time.

I enabled the following options:
-delta frames
-auto-delta frames
-compression level 1
-All filters

[Chainmax]

Clarification: those two questions I made are from someone that isn't a Doom9 member. I just offered him to ask his questions here.

kastro68, what are your system specs?

[Atamido]

Originally posted by Koepi
I think what Mr_Khyron means is that you don't gain anything by converting from YUV to RGB. If you have sources in real RGB (i.e. TV cards internally do YUV due to the composite nature of the tv signal) you're right Pamel.
If you have a dvd or captured source you're most likely dealing with YUV, which you can upsample and convert to RGB of course - but this interpolation necessary doesn't give you "real" data to work on. From my experience this interpolation step makes colours "dirty".
Sorry, let me clarify again. "Working with more original video data is better for filtering." So, if your capture card deals with YUY2 internally, and you are going to be filtering, then you should capture in YUY2. Obviously interpolating to RGB isn't going to gain you anything. But, you would loose a lot more of the original data by going doing a YUY2 --> YV12 conversion before doing your filtering.