BadApple... again :)

Stef · Post by **Stef** » Tue Sep 04, 2012 10:16 pm

Drop down to 24 FPS can help of course, it help on needed processing to unpack frames, but it also help on the total size as reducing to 24 FPS will reduce the total number of frame to 6530 to 6530 * 24 / 30 = 5224 frames...
What i can do is to reduce to 25 FPS on a PAL system, but i would not do it on NTSC as 25 is not a good number for a 60 FPS base, but it's ok for 50 FPS base.

Chilly Willy · Post by **Chilly Willy** » Tue Sep 04, 2012 10:54 pm

djcouchycouch wrote:If you dropped it to 28 or 24 frames per second, it wouldn't help? You'd have a bit more time for processing a frame, which is the bottleneck, right?

When I worked at Ubisoft, achieving 30 frames per second on a game usually meant around 25

The original video is 30 FPS, so going with an "odd" rate like 28 or 24 would require blending frames to avoid stutter from simply dropping one frame out of every X frames. That would RAISE the memory needed since blended frames generally don't compress as well.

djcouchycouch · Post by **djcouchycouch** » Tue Sep 04, 2012 11:31 pm

how about blending frames offline? convert the video from 30 to 24 on the PC.

I have no idea if it'll make something nice. I'm just throwing out ideas.

Chilly Willy · Post by **Chilly Willy** » Wed Sep 05, 2012 1:54 am

djcouchycouch wrote:how about blending frames offline? convert the video from 30 to 24 on the PC.

I have no idea if it'll make something nice. I'm just throwing out ideas.

It doesn't matter who is doing the blending - a blended frame will generally compress less. So whatever bandwidth you save in going to 24 FPS would likely be lost in larger compressed frames.

Of course, dropping frames could be tried just to see how objectionable it is... many games have gone with lower frame rates on lesser systems that way - just play the video at 15 FPS instead of 30 by ignoring every other frame. So it all just comes down to where you compromise the quality. He already made one by moving to 4 level grayscale for the video.

Stef · Post by **Stef** » Fri Oct 12, 2012 9:53 pm

New version, get it here :

https://dl.dropbox.com/u/93332624/dev/m ... Apple5.bin

Again a nice speed boost but still too slow to be 30 FPS (actually it can maintain it but only for few periods).
I wrote a tool that generate the dico unpacking assembly code.
Code is a bit larger than storing dicos directly but not that much (some kilobytes). The code for dico unpacking is now really fast, it was taking between 5 to 17 scanlines with previous assembly code using dico object, now the generated code takes between 2 to 6 scanlines which is almost 3 times faster ! I cannot improve more the dico unpacking code but i can still improve some others unpacking... unfortunately that won't help much for worst case, i guess i can still improve performance by 30% at best but i think i won't waste time in that.

What i will try to do is to simplify decompression so i can unpack the movie at 30 FPS, the drawback is that it won't fit anymore in 4MB (probably 6 or 7 MB). I think i will cut it half and that will permit to also add PCM sound

dr. apocalipsis · Post by **dr. apocalipsis** » Tue Oct 16, 2012 1:04 am

I'm following your project from the start, and you deserve a ton of Kudos.

I would love to see an uncompressed version with PCM sound in the meantime to your final build.

God job bro!

Stef · Post by **Stef** » Tue Oct 16, 2012 9:43 am

Thanks

I would really like to see it at full speed with PCM music too

Actually the video will still be packed (with an unpacked video only a very short part would fit in 4 MB) but just with a simpler scheme. For now the tiles are packed in 2bpp, they can be rotated too...
So i have to unrotate them and then rebuild a 4bpp tiles from 2 2bpp tiles which is really time consuming.
What i will do is to directly pack 4bpp tiles, the compression ratio won't be that good and i won't be able to use some alternatives compression scheme as "deriving" (use another tile as reference and only modify some pixels) or "copy" (directly copy from previous tile) but that simplify unpacking so i will gain time on the unpack process

GManiac · Post by **GManiac** » Tue Oct 16, 2012 2:04 pm

Stef wrote:For now the tiles are packed in 2bpp, they can be rotated too...

I noticed there is no practically gray pixels. Maybe it's better to use two 1bpp layers (planes A and B): one for black & white and one for gray?

And then for speeding up pixel-chain decoding you can use array[256] of values: 1 byte = 8 * 1bpp -> 8 * 4bpp (VDP format).

Stef · Post by **Stef** » Tue Oct 16, 2012 6:01 pm

GManiac wrote:
Stef wrote:For now the tiles are packed in 2bpp, they can be rotated too...
I noticed there is no practically gray pixels. Maybe it's better to use two 1bpp layers (planes A and B): one for black & white and one for gray?

And then for speeding up pixel-chain decoding you can use array[256] of values: 1 byte = 8 * 1bpp -> 8 * 4bpp (VDP format).

Indeed there is not much gray used but still it improve quite a lot the video quality. I could use 1bpp tile, i just need to modify a bit my codec for that, maybe i will test that just to see if i can still keep the complete video in 4 MB.
About your look up table for decompression, i cannot use this method as it require to send too much tiles to the VDP. I do not have enough bandwidth for that, it's why I'm packing 2 2bpp tile in 1 4bpp tile.
With 1bpp tile i can pack 4 tile in 1 but i waste some space in mixed blank tiles...

Stef · Post by **Stef** » Mon Oct 29, 2012 11:15 pm

Time for a new version !
https://dl.dropbox.com/u/93332624/dev/m ... Apple6.bin

I made many changes but the result does not necessary show it.
The encoder now generates directly 4bpp tiles with 2 frames packed in one so i don't have to handle it in the decoder

This is nice for speed but has the drawback to reduce the compression ratio as increasing a bit the data to unpack...
I use 8 dictionaries, they are quite similar but compared to 1 dico I gain about 450 KB. I still generate them "manually" and we could get better compression with an algorithm to find best alternate dictionaries.
Unfortunately I am still not full speed, and far from it in some part

The number of tiles to unpack is just too important and I cannot get it fast enough for the moment. I can have up to 500 tiles to unpack in 800 scanlines which is just impossible to get with my current unpacking method... But i have some ideas again to improve that :p

You will notice the video is not anymore complete (around 2/3 of the original) because it does not fit anymore in 4 MB and also because i want to keep some bits for the future PCM inclusion

Some numbers for interested :

Tile :
------
RAW size : 75264000 bytes
Packed size : 3345212 bytes (26761699 bits)
Plain : 2017342 tiles - packed in tilemap
RAW : 2064 tiles - 67080 bytes (536640 bits)
PlainAndPix : 31057 tiles - 141510 bytes (1132084 bits)
Dico : 119325 tiles - 1301830 bytes (10414642 bits)
DeriveSame : 7821 tiles - 45888 bytes (367108 bits)
DeriveOther : 83578 tiles - 625065 bytes (5000526 bits)
Copy : 3874 tiles - 1937 bytes (15496 bits)

Tilemap :
----------
packed size : 206162 bytes

Stef · Post by **Stef** » Fri Nov 02, 2012 1:07 am

A new version a lot faster but with very low compression :

https://dl.dropbox.com/u/93332624/dev/m ... Apple7.bin

Close to full speed now, I'm seeing the light

Stef · Post by **Stef** » Sun Nov 04, 2012 12:25 pm

New version

https://dl.dropbox.com/u/93332624/dev/m ... Apple8.bin

This time I am finally full speed or very close to

I believe there is still 2 or 3 few part with a minor frame rate drop.
I back to several compression schemes even for tiles (though simplified compared to firsts ones) but i had to pass all the tile unpacking code to assembly as some tilemap unpacking to get it running fast enough...
The tilemap also uses several compression schemes (plainAndPix, Deriving previous, RLE, RLE binary...)but that is less relevant as the tiles are far away in term of cpu usage :p

Note that i fixed the address error on real hardware present in version 7 (too much optimization :p) so it's now back working on real hardware

Here are the numbers :

Code: Select all

RAW tiles size : 59709440
Packed tiles size : 3252400 - 26019200

Tiles repartition :

name        |  number  |  size in bytes
--------------------------------------------------
Plain tiles    1605845   packed in tilemap
RAW tiles         4758         157014 
PlainAndPix      43562         339980
Dico            122670        1845700 
DeriveSame        7931          67145 
DeriveOther      77809         839216 
Copy              3345           3345 

tilemap packed size : 195945 bytes

I would like to improve a bit the compression if possible then add PCM and it will be finally done !

Chilly Willy · Post by **Chilly Willy** » Sun Nov 04, 2012 6:12 pm

This latest one really works nice! I'm not sure where the slow downs occur, that's how close to full speed it is. Runs nice on the CDX.

I notice you added a wait for C at the end of the clip.

Stef · Post by **Stef** » Sun Nov 04, 2012 10:27 pm

I identified 3 parts where there is a minor slow down, my current version add a FPS meter so i can track it easily

I could probably get rid off of it but at the cost of a worst compression...
I guess almost people won't even notice the slowdown without the fps meter and i don't want to spent more time on that as reduce the compression, i will already need to split the movie in 2 parts, don't want to split in 3 parts...
Also i added a method to resynchronize video after a slowdown (video play faster for a short period so it stay synchronized with sound).

Now i have about 700 KB to hold 111 second of PCM

And of course i want a good quality for it... i calculated that 2 bits ADPCM @22050 Khz would fit in, problem is that i don't have a good 2 bits codec right now. I remember your CVSD codec which can pack in 2 bits or 3 bits. If the 3 bits was ok, the 2 bits sounded a bit rough but i wonder if we can get any better with a 1:4 compression.

Yep now you can restart the video at end (even during playback actually)

Chilly Willy · Post by **Chilly Willy** » Mon Nov 05, 2012 1:20 am

Stef wrote:I identified 3 parts where there is a minor slow down, my current version add a FPS meter so i can track it easily

A first person shooter meter? Is it Doom or Quake based?

I could probably get rid off of it but at the cost of a worst compression...
I guess almost people won't even notice the slowdown without the fps meter and i don't want to spent more time on that as reduce the compression, i will already need to split the movie in 2 parts, don't want to split in 3 parts...
Also i added a method to resynchronize video after a slowdown (video play faster for a short period so it stay synchronized with sound).

I figured that despite the average person not noticing a slower area, you'd still need to resync with the audio. If you didn't, people would eventually notice when the audio got far enough out of sync. That's the biggest issue players have to deal with on any clip of significant length.

Now i have about 700 KB to hold 111 second of PCM
And of course i want a good quality for it... i calculated that 2 bits ADPCM @22050 Khz would fit in, problem is that i don't have a good 2 bits codec right now. I remember your CVSD codec which can pack in 2 bits or 3 bits. If the 3 bits was ok, the 2 bits sounded a bit rough but i wonder if we can get any better with a 1:4 compression.

Well, some things sound better with CVSD than others. If you remember, I did Bad Apple as CVSD 2-bit some time back... the rom had both the English and Japanese versions. The CVSD binary data is about 1182 KB for each one, but that's the whole song. It sounds better as CVSD than AMBTC at 2 bits per sample. Here's the binary for the CVSD version... press UP for English and DOWN for Japanese.

http://www.mediafire.com/?ryavlxjrlv5dbtz

Yep now you can restart the video at end (even during playback actually)

Very handy...