Codecs for Pixel Games and it's Development

[zerowalker]

Not sure if this is the right place to put this topic, if it's wrong, please redirect me.


Now as the Topic says, it's about Codecs that's aimed, or overall is handling Pixel games very well.

Pixel Games itself is not a limitation, but it's rare you see an image like a Pixel Game, where it's just solid blocks all over the place, hence why i point to it.


Currently as far as i know, the only Codec that handles it Extremely well is Lagarith.

I don't really know why, but i think it looks for similarities like Zip does, so if many blocks are repeating it can compress it very well, compared to prediction based Codecs which is normally used.

Does anyone know other Codecs, is anything in development or can be developed etc?

As Lagarith is not really aimed towards this, meaning if a Codec Is developed for just this, it should be able to be quite improved.

Hopefully i am not alone in following this unique little pursuit.

[Guest]

What is a "pixel game"?

[zerowalker]

What is a "pixel game"?

Pixel Games itself is not a limitation, but it's rare you see an image like a Pixel Game, where it's just solid blocks all over the place, hence why i point to it.

Simply put, a game which as extremely low resolution (320x240 and such thing).

And uses "pixels" to mainting shapes, simply blocks of solid colors.

No smooth round object, simple "Black Dot, Purple Dot" etc.

That being said, Resolution is not really a "Must".

That being said, you can look at this Thread:
When is PointResize NOT Reversible? (http://forum.doom9.org/showthread.php?t=170608)

I ask there about PointResize, which can be used to increase the resolution of a Pixel Game to any multiply of it's own size, and the information would pretty much stay the same, you just multiply the same "Dots of Color".

Which, at least in theory, should be able to stay very near the same original size, there may be ways to obtain this however by simply telling the original size and the expected one.

An Example of a Pixel Game:

https://docs.google.com/uc?export=download&id=0B_UKJFH8rbiNa2c0X0tIMTNPT2c

Note: This has manipulated transformation, but explains the idea of "Pixelation".

[Guest]

So what is your question? What are good codecs for games? What are your requirements, i.e., must it be lossless, etc.?

[zerowalker]

So what is your question? What are good codecs for games? What are your requirements, i.e., must it be lossless, etc.?

Does anyone know other Codecs, is anything in development or can be developed etc?

As Lagarith is not really aimed towards this, meaning if a Codec Is developed for just this, it should be able to be quite improved.

Forgot to mention that, Yes, Lossless is my aim.

Question is simply, Does anyone know any better, is it being developed, can/is someone interested in developing it etc.

Simply a developing discussion in accordance to this kind of codec.

As it's rare i doubt it will bea smash of posts compared to asking the development of general video codecs.

[Guest]

Simply a developing discussion in accordance to this kind of codec. OK, moving to development. Did you have some ideas about developing a codec specialized for games?

This is of interest:

http://www.compression.ru/video/ls-codec/screen_capture_codec_en.html

And of course this:

https://www.google.com/#q=lossless+codecs+for+games

[zerowalker]

Well, i don't know anything about development, algoritm and such things in detail.
But i have som general ideas for this kind of implementation.

For example:

Aiming a Codec only for Pixel games could let you prevent using any kind of prediction, you only care about the colors, solid blocks as to put it, you don't have to "think" what happens next.

Using the resolution to your Advantage, it could be possible for the Codec to try to automatically resize using Point to see if it can reduce the resolution while maintaining the original look, and then just tell the decoder "The resolution is this, play at this",
pretty much like an Aspect Ratio of a kind.

This is of interest:

http://www.compression.ru/video/ls-c..._codec_en.html

And of course this:

https://www.google.com/#q=lossless+codecs+for+games

Looked at this, MSU is heard of, and i did some tests with it in a Pixel Game video i had, but i had also introduces some Noise in it in the beginning which would take much more bitrate.
Lagarith could make it to 155mb and i could play it, though the CPU usage it quite high where the noise (Or "Un-Pixeled") was, but nothing serious, at least not in that resolution "960x720".

MSU was able to make it into 134mb, but it's impossible to play the beginning, it's slideshow completely, however the Pixeled intended areas played well, it uses a bit lower CPU usage it seems, except for Fades.


If i were to judge those, i would say MSU is the better one, though i am not sure if pixel games always follow the "Pixel Rule", some games use effects at certain points, i am not completely sure if those are able to go hand in hand with the rest of the video, probably it can as it's low resolution.

But the way MSU is unplayable if something interferes is quite bad, even if it's not optimized for it, it should at least be able to playback it, but of course the compression in that place would be lacking a lot.

Still, surprised how well MSU handled it compared to Lagarith, and MSU is quite old, which leads me to think a lot could be done with the current technologies.

[Guest]

Well, i don't know anything about development, algoritm and such things in detail. Based on your post, I'd have to agree.

[zerowalker]

Based on your post, I'd have to agree.
I take that as i didn't make any sense at all;S

Well at least if someone know and is interested they can write here at some point, which is the goal of me bringing it up.
Simply lightning the flame of interest.

[Jeroi]

Lagarith lossless video codec is what I recomend. I have used it succesfully with tv video recording purposes and MegaDrive 16bit video capturing via VirtualDub. Works creat and no image dataloss.

I looked similar problem few years a go when I was trying to record some rgb footage from megadrive. I tough is there good codec to handle pixel color data but did not see any codec spesialed in this. Irc pal just said that forget it and use lagarith and then avisynth script to handle resize, image filtering and stuff.

[zerowalker]

Well would pretty much say the same, point is though, i would like to see it improved. It pretty much stopped being developed, leaving it hanging in the balance.
But it's indeed one of the best codecs (Probably The Best) when it comes to Recoding a Pixel Games in terms of Space and Performance.

[foxyshadis]

x264 10-bit 4:4:4 is what TASvideos and other emulation sites use to distribute video now. It's far more efficient than lossless -- you can actually get some compression without giving up sharp edges or sharp colors, and of course it automatically uses only the differences from the last frame. However, unless you actually encode it lossless and give up the savings, it won't be.

For upscaling on playback you can now use pixel shaders in MPC instead of ffdshow+avisynth. JanWillem32 has posted quite a few good ones in the Software Player forum, and there are more out on the 'net, too.

For lossless, almost any screen capture codec is nearly as efficient as possible for 8/16-bit game capture; they're also the only choices for pre-resized video, since normal video codecs fail hard on pixelated video. Camstudio is extremely fast, Lagarith is slow but a little smaller, most other codecs don't have the null frames that are necessary. (Though you can remove the dups and extract timecodes in avisynth, then mux both into mkv or mp4.) Animated gif and png are actually decent formats for it. There's also a proprietary (lossy) codec specially designed for pixel video already: Bink (http://www.radgametools.com/bnkmain.htm).

[LoRd_MuldeR]

For the upscaling, NNEDI3 creates some pretty nice effect with those kind of games:
http://www.youtube.com/watch?v=0691zsXWbhA

(Though the purist might complain it destroys the original "pixel" look ^^)

[StainlessS]

A good alternative to Lagarith is Ut-video (I dont use Lagarith at all now), give it a try.

http://www.videohelp.com/tools/Ut-Video-Codec-Suite

EDIT: The thread here on D9 takes you to a page in Japanese that is not easy to find an eventual link from,
Videohelp gives an easier link.

[foxyshadis]

A good alternative to Lagarith is Ut-video

The downside of UT-video is that it records every single frame, with no differencing at all. Old video games have tons of identical or near-identical frames, so a codec that writes null frames or can include just the modified areas saves a lot of space.

[zerowalker]

x264 10-bit 4:4:4 is what TASvideos and other emulation sites use to distribute video now.


I can understand using x264 YV24, i myself use it for these cases at times.

However, 10bit?

In my tests, 10bit actually was worse than 8bit, probably because there aren't any use of that extra space, compared to "real videos".

Though that was a long time ago i tested, my memory may be incorrect.

[foxyshadis]

I can understand using x264 YV24, i myself use it for these cases at times.

However, 10bit?

In my tests, 10bit actually was worse than 8bit, probably because there aren't any use of that extra space, compared to "real videos".

Though that was a long time ago i tested, my memory may be incorrect.

10-bit gets you more accurate colors and better saturation in lights and darks, even if you don't need the reduced banding (which is rarely important for pixel graphics), and usually quality is a touch higher, but it's quite possible that it's dependent on the video. I just know that's one particular site's standard.

[zerowalker]

That much i know, but i thought that the extra 2-bit was pretty much used for "rounding errors" and preventing hard compressed conversions,artifacts or what it was.
And if that's the case, such things don't appear in Pixel Games, as there is nothing to work with, it's simply Red,Green,Yellow etc, solid blocks.

Though it may very well be true if you come to that conclusion, the only thing i am certain of is that 10bit lossless does nothing good, but i am sure that goes for all 8-bit videos, as it ain't lossless anymore.
If you could provide a comparison picture of 8-bit 10-bit encodes where you find the 10bit to be better (and settings), it would be appreciated.

It may be so that 10bit can help pixel related codecs in terms of "near transparency", which could be useful to know.

[Zarxrax]

You might want to check out CorePNG. I seem to recall it working fairly well with this type of video. But I haven't used it in probably 10 years, so maybe it's not actually as good as I remember.

Sent from my Nexus 4 using Tapatalk

[zerowalker]

I am guessing it uses PNG?

If so the compression should be very good, i am a bit skeptical about how it handles overall, especially the decoding.
Will look it up.

[Jeroi]

I wonder why there has not been developed good lossless codec that would combare incoming photos and if photos are same then insert null frames, and more better combaring line data if changes save only pixels that are changed in a line and this would be done multithreaded. Let say if there is a videogame, you can put your video game into pause, then all the incoming pinctures may be like 30minutes same image, so codec would not save any those images instead som skip information which tells to draw same image next 30minutes when decoding. Also the threaded line combarison would loop image raw lines and save and make null lines into image line if they are same. This only would save a lot of space on the hd.

Edit:

Ok it seams CorePNG does this already. I would want to take a look of it source...

[macromizer]

I wonder why there has not been developed good lossless codec that would combare incoming photos and if photos are same then insert null frames

Never heard of Lagarith?

[Jeroi]

Never heard of Lagarith?

Thanks to you I went to look about current lagarith and found this:

This document explains what the various settings for Lagarith do in
greater detail than the tool tips. In general though, leaving the

Enable Null Frames: A null frame is a special type of frame that is 0 byte
in size. This tells the program reading the video to simply reuse the
previous frame again. Null frames are a special case of delta frames, and
some programs may not handle them well. If you see the wrong frame being
decoded in a video, disabling null frames should fix this in future
encodings. Leaving null frames enabled can improve compression and speed
for videos that have identical frames.

Always Suggest RGB: This option tells Lagarith to always attempt to decode
video to RGB unless explicitly asked otherwise. If a program cannot open
files compressed with Lagarith that work in other programs, checking this
box may fix the problem.

Use Multithreading: This allows Lagarith to encode and decode the color
channels in a video in parallel. On a system that has multiple processors,
this can speed up encoding and decoding. Enabling this option on a
Hyperthreaded system appears to offer no significant speed increase, and
enabling it on a single processor system may slow down Lagarith by a
slight amount.

Mode: This allows the user to select the highest colorspace that Lagarith
can use internally. Setting the mode to RGBA will cause Lagarith to
use whatever colorspace the input video is. Setting it to RGB (Default)
will cause Lagarith to process YV12, YUY2, and RGB normally, while RGBA
video will be converted to RGB. Setting it to YUY2 will cause both RGB
and RGBA to be converted to YUY2, while YV12 will be processed unchanged.
Setting the mode to YV12 forces RGBA, RGB, and YUY2 to be converted to
YV12 before compression. Finally, Reduced Resolution converts all video
to YV12 and then halves the resolution internally; this is very lossy and
intended for "bait and switch" editing.

One final note about RGB/RGBA: RGB comes in two flavors - 24 bit RGB and
32 bit RGB. 32 bit RGB does not have any more information than RGB24, it
simply has an extra byte with some unknown value after each pixel.
This makes sure that all pixels start on a memory address that is a
multiple of 4, which is very good for MMX/SSE optimizations. The format for
RGBA is identical to RGB 32; the only difference is that in RGBA, the 4th
byte contains useful information, while in RGB32 the value is meaningless
and should be discarded by the codec. Thus, the codec should only be set to
RGBA when you are encoding video that has an alpha channel you want
preserved, since applications may output RGB as RGB32. If Lagarith
is set to RGBA and given RGB32 video, Lagarith will waste time and disk
space by preserving the value of the padding byte instead of discarding it.

It seems to support null frames already. So this mode is very good for oldschool games. And it seems to be good choice to select RGBA as mode to use what the console output is to make more speedier prosessing.

[mastrboy]

Have you looked into using the avisynth dedupe filter combined with mkv and timecodes? (http://akuvian.org/src/avisynth/dedup/)
With that filter you can get rid off all the duplicate frames before they hit the encoder.
With this solution you should only be limited by the video codecs that mkv supports with timecodes since all duplicate frames can be decimated.

[zerowalker]

Okay have now tried CorePNG, and my review of it would be,

It's very slow, when it's Not Pixelated stuff, we are talking 1-3fps at highest settings (Delta Frames OFF as it was said to be unstable).
Luckily we are, and that gives me the super speed of.... 13fps!

Why that in itself is bad, the compression itself is very good, in my test file it didn't beat Lagarith, but it may actually be cause of the Non-Pixel stuff in the beginning, as it was super slow and the size was hugely increasing there.

The amazing thing about this codec though, which i was extremely suprised with, was the Decoding speed, it's extremely good, it's faster than Lagarith by up to 100% in Pixel related stuff at times, however Lagarith could perform better at times as well.
It would normally land at 5% where Lagarith ran from 2-12%, normally being around 5-10. (CPU Usage), but if you take the age difference i think it's impressive.

Would be really nice if this codec could be improved, it's ancient so if there has been some changes that could increase the performance signicifantly this could do wonder.
If not, and the codec has it's limits near what it is, then it sadly isn't that good, though Archival is nice however, thanks to the Decoding speed and rivalry to Lagarith.


EDIT:

Ignore what i wrote about Lagarith, it seems to my surprise that LAV Filter uses A LOT more CPU Usage than the original Decoder, i thought it was the reverse.
So Lagarith wins it all.

Make sure you don't use it for Lagarith, i have always had it on thinking it was better, so might be worth checking it if you use the codec.
(Might be worth checking the performance as well, might be a System related thing as well)

[raffriff42]

Have you tried ZMBV (Zip Motion Block Video) -- it's made by DOSBox especially for "pixel games."
http://wiki.multimedia.cx/index.php?title=DosBox_Capture_Codec
This is a codec added to the DosBox project to capture screen data (like VMNC). This codec employs ZLIB compression and has intraframes and delta frames. Delta frames seem to have blocks either copied from the previous frame or XOR'ed with some block from the previous frame. A sample video I captured within DOSBox of an old 8-bit game is half the size of the same video recompressed with Lagarith.

"Like VMNC" in the quote above refers to the VMWare codec -- that's another good way to capture old games: in a virtual machine.

[zerowalker]

Tried the Codec for a 960x720 pixel video (PointResized to that), and i got like 3-4fps at 4 compressing, and pretty much the same with 9.
It got smaller then lagarith by about 30%, but it was also like 2000%(think that's right?).

[Jeroi]

zerowalker: Try the MSU codec. It seams to have developed just for pixel type capturing, it seems to outperform Lagarith and CorePNG.

[zerowalker]

Have done it, it was recommended in the beginning of the Topic.

I concluded that Lagarith's performance overall was more intriguing then the extra space MSU was able to muster.
But MSU is also quite a bit aged compared to Lagarith and other codecs, so taking that to account i think it's a very impressive codec.

[foxyshadis]

Have you tried ZMBV (Zip Motion Block Video) -- it's made by DOSBox especially for "pixel games."
http://wiki.multimedia.cx/index.php?title=DosBox_Capture_Codec

Can't believe I forgot all about that, I used to use that often and it works very well. Too bad it's not very optimized.

[zerowalker]

I actually did some testing with x264.
And my results show that 10bit is larger when it's lossless, which is logical.

YV24 is also Less than RGB, quite a bit as well which i thought was surprising.

But another thing is that CRF 0 makes a smaller size than CRF 1 (and it's like that until about 8).

This is the same case as JPEG shows, and i guess it always occur when lossless it's actually more compressible then "skipping some information".
Until you reach a certain degree.