Warning: long-winded post
I was playing around with videos on my Windows PC trying different formats / codecs that would work with anything. Well it seems plain old MPEG(1) will work with anything (even Windows 3.11), but it does not have very good compression or quality (maybe bad encoding software). Anyway, I came to the conclusion that MPEG-2 (.VOB files) should work with Mac, Windows, and Linux. Unfortunately, I don't think they would work on iPhone or PSP. Now MP4s will work on those portabile devices but they're not supported on Windows (at least not on standard Windows Media Player). I downloaded a program called Media Player Classic that works on Win XP and 2K but not on 95/98/ME. So I'm sticking with .VOBs for the moment. (that means I need to find an MPEG2 player for Win 3.11)
ANYWAY
This got me to thinking back about playing digital audio (see this thread (http://www.commodore128.org/index.php?topic=3108.0)) on my Commodore. I mean, I have several multi-gigabyte SD cards, but all my Commie software will only fill up half of one. It just pains me to see all that storage potential go to waste :)
All this thinking made want an MP4 player for my Commodore. So like a real hacker / moron, I started writing one. After a day or two of coding I thought to myself, somebody has already done this... I just need to check out CSdb (http://noname.c64.org/csdb/). But then I thought, I might end up stealing someone's code so I better finish what I started and then compare.
So after finishing the testing of v0.9 of my software, I spent a few hours searching CSdb for things like "digi player" "video player" and "media player" and came to the conclusion there is no comparison! By the way, search for "media player" returned 0 results. I found that surprising considering over 400 results for "digi". Completely off-topic, I also found a demo "Edge of Disgrace" which is totally awesome.
On topic, a lot of the "digi" software were demos. There were some tools for creating / playing / editing digis, but none of them came with data files! So I've downloaded several players but have nothing to play with them. It's kinda of hard to compare.
Of course there were plenty of SID players too, and finding media files for them is no problem. However, I'm not interested in those, as they are like CBM-specific MIDI files (is there a cool name like PETSCII to describe them?)
Most of the digi players / editors I found play 4-bit audio by banging SID's volume register. Is there a common filename / type for these kind of files? Like, according to the thread mentioned above, the Digimaster has DFF files, but these are 8-bit audio files.
I did find the ModPlayer which play's Amiga audio files. I'm guessing these would be .MOD files? I really don't know much about them, so if anybody has some info / links that could be helpful. Also I hear there are also Amiga .IFF files? Again any info / links would be welcome. I didn't see anything that would play .WAV files, although I probably just missed it/them.
Now let me say there is SOME comparison because the digi-players I did find work very similar to the method I use, which is not suprising considering (yes I took a peak at their code after I finished my version 0.9). HOWEVER, all the players I found work by loading the data into RAM and then playing them. Well that's great if you want to play a 10 or 20 or 30 second audio clip... but it will not work for playing a 3:30 minute song or 1:30:45 video.
Of course the idea is totally ludicrous when dealing with a 1541, but quite practical for a 1581, hard drive, or uIEC. Well you couldn't fit a video on a 1581, but you could fit one or two songs.
What I have now is player that plays my custom (I haven't seen anything else like it) audio files at 15kb/s. By the way a 1541 / 1571 can work, IF you use the exact sector interleave of 12 for tracks below the directory and 11 for tracks above. But you only get about a minute of audio (or two for 1571).
Now a 1581 or uIEC should be able to handle double the bandwidth, that is 30kb/s. This could be used for stereo audio (umm, did I mention the software is only playing mono right now). I haven't tested this yet because I don't have a second SID in my C128. I guess I could test it in VICE if somebody wanted me to.
Or the extra bandwidth could be used for video. An idea I'm still playing with... Or the extra bandwidth could be used for playing 8-bit digis (if I can figure out how Digimaster works).
So right now, it plays my custom audio format of psudo-2-bit audio. This is combination of 1-bit PW modulation plus 4-bit Volume. The 1-bit samples play at 8kHz while the volume is updated at 1/4 rate or 2kHz.
Now this format has several consequences. The pros:
- uses 1/2 the data of traditional(?) 4-bit digis
- high frequencies can be filtered
- good dynamic range / bass
The cons:
- the high frequencies are 1-bit, and sound rough, even with filtering
- the low frequencies can't be filtered (like traditional 4-bit digis)
After listening to some of the 4-bit digis on the demo software (not actual file players) that I found, I think they sound a lot better than my psudo-2-bit digis (duh). If I went with 4-bit digis, at 7.8kHz, that would mean no possibility for stereo or video... unless...
The audio sample rate was reduced to 5.23kHz. You loose a lot (more) of the high frequencies this way. But even so, the "cleaness" of 4-bit over psudo-2-bit makes this desirable. I should probably just put an option in the player. When run at 5.23kHz (at 4-bit/sample) I should get a data rate of 21kb/s with another 21kb/s to spare for stereo audio or video. I say "should" because I have not tested it... but am fairly confident it would not work with 1541/1571.
What I have tested is the 7.8kHz psudo-2-bit audio in the following scenarios:
- real c128 with uIEC (no problem)
- real c128 with 1571 (only works with optimal sector interleave)
- VICE with 1581 (no problem)
- VICE with 1541 (same problem as 1571)
Oh yeah, this requires drive to have JiffyDOS. I guess it could be programmed with a fastloader if no JiffyDOS, but since this is only possible (AFAIK) with Commodore floppy drives and they are rather useless (except maybe 1581) I haven't worked on that.
What? You're still reading this? Wow, you sure have patience!
Anyway, I just wanted to toss these ideas and questions out there and see what you folks think before I publish something foolish.
Very cool project! :) I guess you don't have a SuperCPU 128? If you did you could load everything into SuperRAM and play back at a higher bitrate?
Quote from: Hydrophilic on May 18, 2010, 05:26 PMI did find the ModPlayer which play's Amiga audio files. I'm guessing these would be .MOD files?
Yes, the Dannenberg (Ezekowitz) ModPlayer plays .MOD files.
QuoteI really don't know much about them, so if anybody has some info / links that could be helpful.
You can e-mail Vanessa Ezekowitz at vanessaezekowitz(at)gmail.com for more information on .MODs. Also you can place your questions at the forums at Amiga.org and at Amigaworld.net, and I'm sure many can help you there.
QuoteAlso I hear there are also Amiga .IFF files? Again any info / links would be welcome.
Again try the forums at Amiga.org and Amigaworld.net
QuoteI didn't see anything that would play .WAV files, although I probably just missed it/them.
There is the Dannenberg (Ezekowitz) Sound Studio v3.71 (I prefer v3.71 over the v3.8, because the latter is buggy).
QuoteOr the extra bandwidth could be used for playing 8-bit digis (if I can figure out how Digimaster works).
If you need contact information for Digimaster developer Chris Brenner, just send me a private message. He may be able to help you out.
Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
July 24-25 Commodore Vegas Expo 2010 - http://www.commodore.ca/forum (http://www.commodore.ca/forum)
and click on ComVEX
Quote from: Hydrophilic on May 18, 2010, 05:26 PMThis got me to thinking back about playing digital audio (see this thread (http://www.commodore128.org/index.php?topic=3108.0)) on my Commodore. I mean, I have several multi-gigabyte SD cards, but all my Commie software will only fill up half of one. It just pains me to see all that storage potential go to waste :)
All this thinking made want an MP4 player for my Commodore.
Well, there is the MP3 plug-in for the MMC Replay/MMC64 and for the IDE64. Several months ago, one of the SCCAN members showed me how MP3s were easily played through the MMC64. I have yet to try MP3s on my IDE64 v4.1.
Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
July 24-25 Commodore Vegas Expo 2010 - http://www.commodore.ca/forum (http://www.commodore.ca/forum)
and click on ComVEX
Quote from: redrumloaI guess you don't have a SuperCPU 128?
I wish! Maybe somebody better at hardware than me can mod Andre Fachat's design for the C128... with that kind of processing power, you might be able to do conversion real-time. My player requires .WAV/MP3/MPEGs etc to be converted for CBM format before playing. When I was messing around with video files on my PC and decided I need to convert my videos to play on my DVD player and older Windows versions (should also play on Linux and Mac), I figured I would try converting them for Commodore too.
Quote from: redrumloaIf you did you could load everything into SuperRAM and play back at a higher bitrate?
Right. Because I don't have a SuperCPU, I can try using an REU... but only in VICE, because I don't own one of them either.
Another reason I started on this is to see what kind of bitrate I can get out of various drives, 1581 and uIEC in particular. I imagine MMC, CMD-HD, or 64HDD could match, but I won't be able to test myself. Also I want to be able to play media "on the fly" without having to load everything into memory first. I guess this won't be possible for SID files because some of the ones I've seen will call an initialize routine that's located at the end of the file :(
For higher bandwidth, there is fast serial and ACIA to try. If we're lucky, uIEEE could become a possibility.
@RobertB,
Thanks for the tips about Amiga.org and Sound Studio.
Quote from: RoberBIf you need contact information for Digimaster developer Chris Brenner, just send me a private message.
Thanks for the offer. Hopefully I can figure it out myself.
Quote from: RobertBWell, there is the MP3 plug-in for the MMC Replay/MMC64 and for the IDE64. Several months ago, one of the SCCAN members showed me how MP3s were easily played through the MMC64. I have yet to try MP3s on my IDE64 v4.1.
See, I knew somebody would have already tried playing MP3s on their Commie. Do you have any more info about this?
Quote from: Hydrophilic on May 20, 2010, 04:29 AM
See, I knew somebody would have already tried playing MP3s on their Commie. Do you have any more info about this?
For more details on how the MP3 plug-in works for the IDE64, I suppose you can contact the developer. That would be Kajtár "Soci/Singular" Zsolt at kajtarzsolt(at)googlemail.com
Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
July 24-25 Commodore Vegas Expo 2010 - http://www.commodore.ca/forum
and click on ComVEX
Quote from: HydrophilicAlso I hear there are also Amiga .IFF files?
Wiki: http://en.wikipedia.org/wiki/Interchange_File_Format
Quote from: RobertBWell, there is the MP3 plug-in for the MMC Replay/MMC64 ...
As far as I remember the MP3 plugin for the MMC Reply requires a little piece of hardware: http://www.schoenfeld.de/inside/Inside_MP3AT64.txt
Regards WTE
Quote from: wte on May 21, 2010, 09:04 AM...the MP3 plugin for the MMC Reply requires a little piece of hardware...
Not only that but the MMC Replay/MMC64 is no longer manufactured.
Now that's missing hardware, :)
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
July 24-25 Commodore Vegas Expo 2010 - http://www.commodore.ca/forum (http://www.commodore.ca/forum)
and click on ComVEX
You can plug the MP3@64 into the IDE64 as well .. works a treat :-)
Thanks for the info folks! It seems the Amiga IFF are the big-endian version of MS RIFF files. This reduces the learning curve since I'm already familiar with RIFF files (at least WAV and AVI).
Both versions make heavy use of 32-bit numbers. From a programming stand-point, anything over 8-bits is the same on our little 8-bit Commies. But in terms of bandwidth / filesize, 32 bits is excessive most of the time.
So I was going to implement "CIFF" format (Commodore Interchange File Format). This would use 16-bit packet sizes. Only the file header would have a 32-bit number (for total file size).
Also there is no LIST element; the file is always a LIST of packets (even if it is only 1 packet). In case you have packet over 64kiB, you would need to split it in two or more pieces.
My player is working with custom "psudo-2-bit" audio and 4-bit audio in CIFF file format. With a little work, I think it could play native WAV 8-bit files in 4-bit resolution, but only if the sample rate is 8kHz... I don't think the CPU is up to real-time frequency translation.
16-bit WAV should also be possible with the same constraints (8kHz sample rate, reduced to 4-bit resolution), but only if I can increase the bandwidth...
Lately I've been working on 160x176 multi-color (grayscale) video. The width of 160 is the whole VIC2 multi-color screen.
The 176 height is based on aspect ratio. Although VIC2 output is for a device with 4:3 aspect ratio, measurements on my television show the visible (inside borders) aspect ratio to be very close to 6:5. Or more importantly, a multi-color pixel aspect ratio of 2:3 (hi-res pixel aspect ratio 4:3).
When I convert 4:3 video (for example 480x360) directly to 160 width, I get height of 120. Because multi-color pixels are twice the width of hi-res pixels, using a height of 240 (cropped to 200) looks fine in VICE because my PC monitor has square pixels (1:1 pixel aspect), but on a real C128/TV the image is squashed vertically (expanded horizontally). This because the VIC2/TV has a multi-color pixel aspect of approximately 2:3... Anyway, the inverse, 3/2, times 120 equals 180. And multi-color 160x180 has correct aspect on my TV.
But 180 is not a multiple of 8, which is important for my video conversion / compression scheme. So I could go with 176 or 184. Either results in minor (I can't notice) distortion to aspect ratio, but 176 reduces the bandwidth / filesize while 184 would increase it... so I'm using 160x176. This results in TV display very close to 4:3 aspect ratio (like the source video).
I just went and measured on my TV, and 160x176 is closer to 4:3 aspect than 160x180... I guess my 2:3 pixel aspect ratio isn't accurate enough...
Can any NTSC users confirm 160x176 multi-color results in an image with (approximately) 4:3 aspect ratio on a real hardware (like TV or 1084)? Is 160x180 or 160x184 any closer to 4:3?
If it helps, you can issue BASIC command GRAPHIC3,1:BOX1,0,0,159,175[,,1]
You can omit ,,1 to make a hollow box or use it to make solid box (go eat a sandwitch or brew some coffee if you choose solid box).
Is this also true for PAL on real hardware? Thanks!
Quote from: Hydrophilic on May 26, 2010, 04:03 PMCan any NTSC users confirm 160x176 multi-color results in an image with (approximately) 4:3 aspect ratio on a real hardware (like TV or 1084)? Is 160x180 or 160x184 any closer to 4:3?
I'm a bit confused. Are you using 40-column mode, or are you trying to do this in 80-column mode? In 40-column mode, multicolor on the Commodore used 160x200.
And that's leaving a border around the image,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
July 24-25 Commodore Vegas Expo 2010 - http://www.portcommodore.com/commvex
160x184 is pretty close to 4:3, and it's definitely closer than 160:180.
Quote from: seahn160x184 is pretty close to 4:3, and it's definitely closer than 160:180
Thanks saehn. Can you tell me what type of device you have (TV, monitor, NTSC, PAL)? From some PAL screen shots I've seen, they look wider than NTSC. Like I said when I checked my NTSC TV, 160x176 was best, but it could just be my TV...
Quote from: RobertBI'm a bit confused. Are you using 40-column mode, or are you trying to do this in 80-column mode? In 40-column mode, multicolor on the Commodore used 160x200.
This is 40-column mode because... I like making things difficult? (Syncing loader and player to avoid bad lines is pretty messy, and running at 1MHz).
You are correct, the multi-color screen is 160x200, but it does not cover an area with 4:3 aspect ratio (which is what standard definition video has). So if I play a SD video on the whole VIC screen, it is stretched too tall (or, equivalently, squeezed to thin). Kinda of like movies you might have seen on TV years ago, when they would squash the film horizontally so you wouldn't miss anything, but then everybody in the movie looks really tall and thin.
In other words, I need to scale the SD video to a dimension like 160x180 so on the VIC2 screen it will have 4:3 aspect ratio (that's 4/3 = 1.333). To determine aspect ratio, just get a ruler or tape measure, and measure the width of a BOX on the screen. Then measure the height. Aspect ratio is then width/height. It doesn't matter if you use cm, inches, or nautical miles (as long as both measurements are the same units)!
But I only have one TV and none of my PC monitors would accept VIC2 (40-column) video output. So I only have one measurement to go by. So I just wanted to know what size BOX other people need to draw that measures 1.333 (4:3) aspect ratio.
Using VICE doesn't count because PC monitor has square pixels while VIC2 does not (note: some video cards / monitors can display something close to VIC2 if you use strange settings like 640 x 350)
...
In the meantime (awaiting some type of size consensus), I've been working on the demultiplexer / packet scheduler.
O.M.G. This has to be the most difficult thing I've ever tried to program. Get this: I had to actually make a program flowchart! The first time in my life I ever had to make one! Sure I've made a few flowcharts in the past, but that was per request not out of neccessity. (Maybe mind is getting rusty)
I think I've got it working... more testing needed... without multiplexing audio, the frame rate is wildly inconsistent... Something like 20 to 0.2 frames per second! Of course that is also an encoder rate control problem. But we can discuss that later.
Right now, I'd like to know what size is
your BOX?
UPDATE: Before posting this, I noticed in WinVICE 2.2 there is a new setting under Settings/Video Settings/FullScreen. Here I found a checkbox "Keep Aspect Ratio" and it works in window mode too (not only fullscreen mode). Anyway, beside the checkbox is an edit box where you can type in a value. Entering 0.8 gives a close approximation without using strange video modes. I believe this is the pixel aspect ratio (different from screen aspect ratio discussed above). So this leads to another question... what pixel aspect ratio in VICE looks most like a real 40-column screen to you?
I have both an NTSC monitor and TV. I believe that NTSC and PAL have the same ration: .82. Using the BOX command and a simple test program, I've confirmed that this gets fairly accurate results. We're never going to have extremely precise results due to the variety of output devices, as you've probably guessed.
10 graphic1,1:x=100:y=100:y=y*.82
20 box1,159-x/2,99-y/2,159+x/2,99+y/2
By plugging in a 4:3 ratio, I get pretty accurate results with a physical measurement.
10 graphic1,1:x=160:y=120:y=y*.82
20 box1,159-x/2,99-y/2,159+x/2,99+y/2
That was hi-res mode, by the way. The following multi-color version is fairly close to 4:3, which amounts to slightly less than the total height (200).
10 graphic3,1:x=160:y=120:y=y*1.64
20 box1,79-x/2,99-y/2,79+x/2,99+y/2
Wow, my TV must be warped because the full VIC screen (or a few rasters short as in your program) is not 4:3, more like 6:5.
I wish I still had the test videos from back in the day when I repaired VCRs. You might have seen these test patterns before. The one I'm thinking of has a huge circle in the center that spans top to bottom (but not left to right because it is a circle, not an elipse) with an X going from each corner of the screen. With a test video like that, it would be easy to see if my TV was warped (by measuring height/width of the circle).
Quote from: seahnI have both an NTSC monitor and TV...I've confirmed that this gets fairly accurate results.
Thanks for checking on two different devices! I guess my TV really is warped :(
Quote from: seahnWe're never going to have extremely precise results due to the variety of output devices, as you've probably guessed.
I agree there isn't going to be a precise value, but I was hoping some other people would post some BOX sizes, just to see what the range of values are, so some sort of average could be used.
...
In the meantime I finally got the demuxer debugged. It's funny how you think everything is working when using test values that should cover all the bases, only to discover more bugs when you use real data...
The frame rate has improved very slightly. My last testing was with simple RLE encoding. I'm working on a slightly more complex scheme that does some memory copies and pattern runs. Of course this will never give the type of compression you'd get with entropy encoding (variable bit-size codes), but because over 50% of CPU time is spent in the IRQ (playing samples and loading data), I don't think the CPU would have the time for lots of bit shifting that entropy coding would need. I'm hoping to get the worst-case frame rate upto 1fps.
Now 1fps is less like video, and more like a slide show on crack. But right now the video is I-frames only. The real speed boost will come from P-frames, which only encode the difference between two frames of video. I don't think the CPU will be able to handle B-frames, which interperolate a frame between two encoded frames.
There are some screenshots here if you want to burn them to DVD and use... I don't see a freeware calibration DVD anywhere but maybe you can find one online anyway.
http://www.calibrate.tv/ (http://www.calibrate.tv/)
Thanks for the link. Unfortunately it seems focused on color calibration. There is a link with all the calibaration images on the disk, but none, from what I could see, would be useful for testing aspect ratio.
If anyone else (thanks again, saehn!) has a real C128 and tape measure or ruler, and a few minutes to spare, please try this program and let me know which Y value makes a BOX with aspect ratio of 1.333 (width / height)... you can type it in or download...
10 color4,1:y=180:do
20 graphic3,1:box1,0,0,159,y:getkeya$
30 ifa$<>"+"anda$<>"-"thenexit
40 ifa$="+"theny=y+1:elsey=y-1
50 loop:graphic0:printy
It's very easy to use. It will draw a BOX on the screen. Press + or - to change the height of the BOX (the Y value). Press any other key to exit the program and print the Y value.
You just need to measure the width and height on your screen (the reason you need a ruler or tape measure), and calculate aspect ratio = width/height.
It's a game! Figure out what Y value gives aspect ratio as close to 1.333 as possible. Once you know, please report the Y value and what type of display you have (NTSC or PAL, TV or monitor). Thanks!
...
I've finally finished debugging the new compression codec. What a pain! Every time I decided to change the decoder, I had to re-write and debug the encoder and then test/debug the decoder! Sometimes I wish there were two of me...
It's an extremely simple (thus fast) compression that gives an average of 47% compression. (This was tested with real video images -- traditional, "human drawn" bitmaps generally gives compression over 60%.). This is almost 50% better than the original (in terms of file size / compression). So in theory, the worst-case frame rate is almost 1 fps (0.81 is a better value), as I originally hoped...
But now it takes longer to decompress a packet than it does to load it (even though the code is fairly well optimized). This is not all bad, because it means their will be bandwidth available for audio / subtitles. But it does mean the worst-case frame rate (still only I-frames, see previous post) is under 1 fps. I don't have an exact value, but the average frame rate is 0.777 according to my testing.
So let's hope P-frames will give a dramatic improvement. Otherwise I would have to reduce the size of the video...
I use a video capture card connected to my EeePC with its tiny screen as output for my C128, so I had to change the program slightly to be able to measure the box. I quadrupled the X size to 76 pixels and with Y=105 I got a perfect 4:3 apect ratio (48x36 mm, see screenshot).
Edit: FYI, I use a PAL C128.
Thanks bacon for the PAL results!! So by my calculations, a 160 (multi-color) pixel-wide image would need to be 221 rasters tall (which explains why you would need to modify things, considering VIC-II only supports 200 rasters). This is a major difference from saehn's and my measurement for NTSC (around 192 rasters). So either something is wrong with my calculation or your capture card, or more likely (from photos of PAL screens I've seen), there is a significant difference in pixel aspect ratio between NTSC and PAL video on the C128.
Anybody else have some BOX sizes to report?
...
I thought I was ready to implement P-frames, but I realized I would need to implement screen-flipping (a.k.a. back buffers), but my code had no provision for it...
So I had to modify the IRQ routines to check for the border (a good time to flip screens). Well as long as I had to do that, I did what I didn't want to do: implement 2MHz in the border (now it can never be directly ported to the C64).
What a pain!!! Originally I had a set of IRQ routines (2 or 4 routines, depending on audio format) to play audio and load data; this change made 2 sets of IRQ routines... (4 to 8 routines). And it gets worse, the transition from 1 to 2 MHz (and vice versa) can't be done in a single IRQ routine, so 2 additional routines were added; so now there's 6 to 10 IRQ routines... and these have to co-ordinate with each other and with the main (non-IRQ) code.
The good news is the worst-case I-Frame rate has improved to around 0.92 NTSC or 0.95 PAL. This is (almost) what I originally wanted for I-Frames. The bad news is now debugging is taking longer than ever. Only now (finally!) am I really starting on coding P-Frames...
Off topic: I took a break from all that ugly coding and fired up an old save file of Final Fantasy X. There I already had every character with max MP = 999 and max HP > 9999 and all other stats (except Luck) at 255. Luck for all characters was around 120. So after another 24 hours or so of additional game time, all characters have Luck (and other basic stats) at 255, and all characters have max HP > 66666 which means if they equip armor with HP+50%, they can all have max HP of 99999. Although completely pointless, I think it's pretty cool to load up a game with all characters with max stats. The game desginers did an awesome job; I had to maximize (almost?) every node on the sphere grid to accomplish that!
On topic: after resuming coding of P-Frames, it occurred to me that even though our little 8-bit CPU can't handle B-Frames, the (32-bit) encoder can... So I'm thinking we can have the benefit of "psudo-B-Frames". Which is to say the encoder can output future frames which are used to derive current frames (contrary to P-Frames which derive current frames from past frames). Umm, maybe these should be called "F-Frames"?
Quote from: Hydrophilic on June 16, 2010, 07:49 PM
Thanks bacon for the PAL results!! So by my calculations, a 160 (multi-color) pixel-wide image would need to be 221 rasters tall (which explains why you would need to modify things, considering VIC-II only supports 200 rasters). This is a major difference from saehn's and my measurement for NTSC (around 192 rasters). So either something is wrong with my calculation or your capture card, or more likely (from photos of PAL screens I've seen), there is a significant difference in pixel aspect ratio between NTSC and PAL video on the C128.
There's quite possibly a real difference between NTSC/PAL monitors, but keep in mind that bacon was using his EeePC screen as video output. Frankly, I think your basis of comparison between NTSC/PAL should always start with a CBM monitor. Once you get into TVs and non-CBM outputs, we can expect to see a pretty wide range of variation. :-)
Quote from: saehn on June 17, 2010, 02:19 AM
Quote from: Hydrophilic on June 16, 2010, 07:49 PM
Thanks bacon for the PAL results!! So by my calculations, a 160 (multi-color) pixel-wide image would need to be 221 rasters tall (which explains why you would need to modify things, considering VIC-II only supports 200 rasters). This is a major difference from saehn's and my measurement for NTSC (around 192 rasters). So either something is wrong with my calculation or your capture card, or more likely (from photos of PAL screens I've seen), there is a significant difference in pixel aspect ratio between NTSC and PAL video on the C128.
There's quite possibly a real difference between NTSC/PAL monitors, but keep in mind that bacon was using his EeePC screen as video output. Frankly, I think your basis of comparison between NTSC/PAL should always start with a CBM monitor. Once you get into TVs and non-CBM outputs, we can expect to see a pretty wide range of variation. :-)
The problem with CBM monitors (at least the two 1084S monitors I've owned) is that you can adjust both the width and height of the picture over a wide interval, so there's no guarantee that the picture from two CBM monitors are comparable. Most TVs made the last ~10 years, on the other hand, have a fixed width/height ratio afaik. This is even more true for video capture cards and software, where you will always get a true 4:3 aspect ratio. I'd say that video capture cards are a very good basis of comparison. As for the EeePC's screen, it has square pixels so the output from the video capture card will be as correct there as on any other screen.
Yeah, I was thinking about that too. I remember the vertical size adjustment on my 2002 but wasn't sure about other monitors, and I couldn't find a list of controls online. Interesting point about the square pixels on the EeePC, but CBM monitors didn't have square pixels. The average ratio for CBM pixels has been roughly estimated as .82.
Well, in any case, as long as Hydrophilic gets close, I think we'll all be happy. I don't think anyone is expecting a high-fidelity video output on his Commodore 128. :-D
Quote from: saehn on June 17, 2010, 11:34 PMInteresting point about the square pixels on the EeePC, but CBM monitors didn't have square pixels. The average ratio for CBM pixels has been roughly estimated as .82.
The EeePC's monitor (or any other PC monitor) doesn't know anything about the pixels being output from the VIC chip, and neither does the video capture card. The capture card takes the video signal from the C128 or any other source and outputs a 4:3 aspect ratio picture to the PC, which shows it on the screen. As long as the PC monitor has square pixels the image on the screen will retain the 4:3 aspect ratio, i.e., the CBM pixels will show up with the correct ratio since the C128's video output was meant to be shown on a 4:3 aspect monitor. Hence my pointing out that the EeePC screen shows square pixels.
Quote from: bacon on June 18, 2010, 04:00 PMThe EeePC's monitor (or any other PC monitor) doesn't know anything about the pixels being output from the VIC chip, and neither does the video capture card. The capture card takes the video signal from the C128 or any other source and outputs a 4:3 aspect ratio picture to the PC, which shows it on the screen. As long as the PC monitor has square pixels the image on the screen will retain the 4:3 aspect ratio, i.e., the CBM pixels will show up with the correct ratio since the C128's video output was meant to be shown on a 4:3 aspect monitor. Hence my pointing out that the EeePC screen shows square pixels.
I get what you're saying but I still think that it's slightly off since it's 4:3 aspect ratio whereas the average CBM monitor aspect ratio is closer to .82 (this is something of a scene standard---for both NTSC and PAL---not just my own personal opinion). And as we can see from our earlier posts, your output (on the eeePC) differs from mine (on a CBM monitor).
If Hydrophilic can make it adjustable, then all problems will be solved.
Quote from: saehn on June 18, 2010, 11:50 PM
Quote from: bacon on June 18, 2010, 04:00 PMThe EeePC's monitor (or any other PC monitor) doesn't know anything about the pixels being output from the VIC chip, and neither does the video capture card. The capture card takes the video signal from the C128 or any other source and outputs a 4:3 aspect ratio picture to the PC, which shows it on the screen. As long as the PC monitor has square pixels the image on the screen will retain the 4:3 aspect ratio, i.e., the CBM pixels will show up with the correct ratio since the C128's video output was meant to be shown on a 4:3 aspect monitor. Hence my pointing out that the EeePC screen shows square pixels.
I get what you're saying but I still think that it's slightly off since it's 4:3 aspect ratio whereas the average CBM monitor aspect ratio is closer to .82 (this is something of a scene standard---for both NTSC and PAL---not just my own personal opinion). And as we can see from our earlier posts, your output (on the eeePC) differs from mine (on a CBM monitor).
If Hydrophilic can make it adjustable, then all problems will be solved.
Now I see what you mean. I thought you meant that the pixel size ratio from a CBM computer would show up as .82 on a true 4:3 display, in which case my reasoning would have been correct.
I've been thinking about the aspect ratio, and came to this conclusion. Since both NTSC and PAL TVs have 4:3 aspect ratio (not considering high-def / wide-screen), then it makes sense that PAL would appear wider than NTSC (or equivalentatly, PAL would be shorter than NTSC) because PAL has a greater vertical resoultion: 312 rasters (as opposed to only 263 rasters for NTSC).
So if 0.82 pixel aspect ratio is correct for NTSC (looks right on my PC using VICE as compared to real C128 on my TV), then 0.82 * 312 / 263 = 0.97 pixel aspect ratio for PAL. This explains why, to my confusion in the past, some people would refer to the hi-res pixels as square. They are square on PAL TVs (or very close).
I don't think our 8-bit CPU can handle resizing an entire bitmap in realtime to correct pixel aspect ratio. So now I'm thinking something like 152 x 192 multi-color image. This should appear slightly stretched vertically on NTSC and slightly stretched horizontally on PAL. Those numbers come from 38-column / 24-row mode to allow smooth scrolling.
Thus I calculate an NTSC display aspect ratio to be 1.300 (slightly strectched vertically) or 1.536 for PAL (streched a bit more, but horizontally).
...
I wanted to report I've completed my first P-Frame encoded video and am very disappointed! The file size got reduced from 320 to 310 blocks. That's only about 2 kiByte savings! And the frame-rate didn't improve much either. From approximately 0.85 to 0.95 frames / second. (0.92 NTSC, 0.97 PAL).
This was quite confusing until I investigated the issue. The main problem is inconsistant bitmap encoding. For example, a block of solid grey (choose your own shade!) might be encoded as bit-pair %01 in one frame but as %10 in another frame. So even though two frames appear the same on the screen, they are stored with different bytes, and thus benefit less in compression.
Another more complex example deals with dithering. Because of the limited color resolution of the VIC-II, many areas are not a solid color but a pattern created by dithering. Imagine a color half-way between two VIC colors that covers a character-sized area. It could be coded as
0 1 0 1
1 0 1 0
0 1 0 1
1 0 1 0
0 1 0 1
1 0 1 0
0 1 0 1
1 0 1 0
or in the opposite manner
1 0 1 0
0 1 0 1
1 0 1 0
0 1 0 1
1 0 1 0
0 1 0 1
1 0 1 0
0 1 0 1
Either way will give the same overall appearance, but because each uses a different byte sequence, using both reduces the compression.
The dithering algorithm I'm using is fairly standard. The problem is, it is quite chaotic! Pixels in one part of an image can be affected by pixels on the complete opposite side of the screen!
So that's the current situation. Need to improve frame coding consistancy. And then on to motion vectors and smooth-scrolling. Oh what fun!
Hydrophilic, you may want to talk to Algorithm. He's done some of the most impressive video rendering I've ever seen on the C64. Also, I bet he'd be a really good source of information regarding the PAL aspect ratio. Here's his contact info:
http://www.algotechproductions.com/contact/contact.htm
And check out this PAL release he did... very impressive in WinVICE:
http://noname.c64.org/csdb/release/?id=45850
Thanks for the links! That demo has a nice frame rate, but there only about 20 frames in the whole video repeated ad nauseum (I am exagerating a little). While watching it, I noticed it seemed to be using "virtual bitmap mode" which a quick peek with the VICE monitor confirmed. That was my plan 67 (when true bitmap mode proves impossible). Without doing anything else, virtual bitmap mode should triple my frame rate (from 9ki bitmap down to 3ki charset + matrix). But like I said, I'm saving that for the future...
Although there was a noticable difference between PC 1.000 pixel aspect ratio and NTSC 0.82 pixel aspect ratio, after watching the demo in both modes, I can't say which one is better. I guess it doesn't matter, as long as your close! I guess I should contact Algorithm to see what he thinks about the aspect ratio...
I was right about the dithering! I spent a few hours to re-code the encoder to simply copy (appropriate) dithered patterns. This increased the compression from approximately 44% to 64%. It also improved the average frame rate to about 1.29 fps (1.25 NTSC, 1.33 PAL).
In a few hours I made more improvement than in the past two weeks! There is a lot of room for improvement. For one thing, now it only compares pixels on a per-card 'cell' basis (4*8 pixels, aligned with text-screen char positions). There's no reason it couldn't do 4*6 or 4*4 'cells' (although 4*4 would probably provide little benefit). Also, it doesn't need to be aligned with a text-character boundery (at least not vertically). As if those possibilities weren't enough, the test video I'm using has a HUGE amount of motion in all the frames. Since the code only tests a cell with the exact same position in other frames, only about 50% of each frame gets "the treatment." Once I get motion-vectors added, another 10% to 25% percent should also benefit from "the treatment" (dither optimization).
But it isn't all good news. The main problem is the video now has dithered cells (areas 4*8 pixels) that often scream error next to other blocks (that were not copied from previous frames).
For example, imagine the original (without "treatment") was coded like this:
0 1 0 1 0 1 0 1
1 0 1 0 1 0 1 0
0 1 0 1 0 1 0 0
1 0 1 0 1 0 1 0
0 1 0 1 0 1 0 0
1 0 1 0 1 0 0 0
0 1 0 1 0 0 0 0
1 0 1 0 1 0 0 0
(the left cell is a 50% dithered image, the right is a dithered "triangle")
Now if there were no copy of "0 1 0 1 / 1 0 1 0" x 4 but there was the opposite, then result would be
1 0 1 0 0 1 0 1
0 1 0 1 1 0 1 0
1 0 1 0 0 1 0 0
0 1 0 1 1 0 1 0
1 0 1 0 0 1 0 0
0 1 0 1 1 0 0 0
1 0 1 0 0 0 0 0
0 1 0 1 1 0 0 0
I guess my ASCII art doesn't convey the idea properly. But anyway, in the first example, you should note there are never any pairs of "1 1" but there are four pairs in the second example. Also in the first example there are no "0 0" pairs between the left and right cells, but there are four pairs in the second example.
Let me summarize for those confused (even me a little). If you take a dithered image, and replace cells with those dithered from another frame, the result can produce distracting (anoying, trust me!) visual artifacts, even though each dithred cell (original and copy) by itself is a faithfull reproduction of the original (undithered) cell.
So I significantly improved compression and decreased visual quality. Well that is quite normal in the art/science of image/video compression!
So I thought, I should re-dither the areas around copied cells so that adjacent cells "mesh well" with the copied ones. That should improve video quality... and since the adjacent cells didn't benefit from "the treatment" to begin with, there should be no loss in compression. A win - win scenario!
While debugging my "improved" codec, I found a significant error in the dithering algorithim. Well not the algorithim, but my implementation. Anyway, the basic principle is to propogate the "error" (difference between source video and closest VIC-II color) to adjacent pixels. I discovered my code was discarding about 50% of the error, resulting in reduced image quality.
On a scale of 20 (one-half the 8-bit luma difference between the two closest VIC-II grays), the original code had an error of about 14. Which I think is pretty good considering the closest undithered is on a scale of 40.
After fixing the error propogation, the error was reduced to approximately 9 out of 20. That's a huge "improvement"!
Naturally I expected this to result in some file-size increase (or compression decrease). The resulting size (and playback frame-rate) is what I had about 4 weeks ago! ERRRRRRRRRRRR!
To add insult to injury, the resulting video actually appeared worse to me! The residual error has decreased by at least 50%... So how can that be?
I should probably post some screen shots, but sneaker net is out of order at the moment. Anyway, the original (before "fixing") video had plenty of dithered areas, but also lots of "solid" (undithered) areas. It was quite pleasing to the eye in my opinion. Now (after "fixing"), almost every area of the screen is dithered... areas that were previously undithered are now "sparsely dithered" which is to say large areas are almost a solid color, but have seemingly random dots mixed in.
And so it goes... 1.5 steps forward and 1.0 steps back. Any competent mathmetician could tell you telescoping functions can take a long time to converge... much like this project!
Keep it up Hydro, interesting project. Thought you might like to see this:
http://hitmen.c02.at/temp/palstuff/
Thanks for the link! Coming from Hitmen, I was expecting a demo or something... I was pleasantly suprised to see an actual web page! Not only do they demonstrate a different aspect ratio between PAL/NTSC, but they explain the notorious vertical lines of the VIC that are the bane of many C128 users. I don't have a problem on my TV, and since I have a flat C128 I assume the VIC is using NMOS not HMOS technology... I'm guessing low contrast on my TV?
Thanks for the encouragment too! I haven't worked on this for over a month (better things to do during the summer), but before a stopped, I did un-fix the "problem" so now the frame rate is back up to previously reported levels. Even after implementing smooth scrolling and possibly smaller macroblocks, I worry that true bitmap mode will not meet my expections with the audio IRQ running... which means no digi-audio or no true bitmap mode (emulated char-bitmap is promosing) or neither. I'll keep everyone posted once I get back to this project.
Warning: another long post.
Now that my summer vacation is over (or winter vacation as they would say down under) I've taken another look at video on the C128 with Media Player 128 and the results are not promising...
Because of the continuous, significant, and yet variable overhead of the audio + JiffyDOS IRQ routine, I had never previously attempted to calculate (or even scientifically estimate) the maximum theoretical frame rate of my software. I assumed that with better compression a reasonable frame rate could be achieved with (near) full screen bitmap video.
I've had time to mull over the idea this summer, and concluded I needed a solid estimate of the maximum frame rate (which is quite different from maximum data transfer speed or best video compression).
So I set up an experiment where the (IRQ) audio player + disk loader is constantly running at maximum capacity and the (main thread) is constantly "drawing" a new bitmap for each frame.
The "drawing" is a simple copy of data in memory from one of two off-screen bitmaps to the visible screen. A simple copy is approximatly (in CPU cycles) equal to the RLE/memory decompression method used for decoding real frames loaded from disk. (I can explain this more for anyone who cares.)
And a simple copy is signifcantly faster than my planed "advanced" decompression which would envolve "macroblocks".
The sad result: with the 2-bit audio + JiffyDOS IRQ routine running at peak effeciency, the main code is only able to render at a frame rate of 2 frames per second.
- P.S. I previously reported frame rates in excess of 2 fps, but this is due to luck; when an old bitmap memory has the same (or close) data as the new image, no new data is written to RAM (P-frame encoding); this improves compression and frame-rate in some cases, but is not possible for all new images; thus, it can not be used as a limiting factor.
This convinces me that full-screen bitmap video is not possible with both 2-bit audio and JiffyDOS running in the IRQ... At least not with an acceptable frame rate, which I consider to be at least 10 frames/second.
The best option is, I think, to improve the overhead of the IRQ routine. There are only two ways to do this: 1) eliminate the audio, or 2) use fast-serial instead of JiffyDOS
- P.S. I don't think you can improve the performance of the 2-bit audio as it is extremely simple (simpler than 4-bit audio for those in the know). And the JiffyDOS part is as fast as JiffyDOS protocol will allow.
Option 1 is out for now because I have no intention of eliminating audio completely. A "video" without audio can not be truly called a video in the modern sense of the term.
Option 2, fast-serial hardware, has always been my preference on the C128. Unfortunately, the C1571 lacks the capacity for a video of any reasonable length, and the uIEC / MMC / HD64 do not support fast-serial. The C1581 does support fast-serial and has enough capacity for a limited amount of video, but I do not own one. And even if I did, I hate disks! Floppy disks, CDs, DVDs, you name it. They always give me more grief than a memory card or HD ever has. (Despite my meticulous efforts to not damage the disks.)
So it may seem this project has reached a dead end...
But options 1 and 2 were the best options, not the only options.
Another option, plan 67, is to forgo true bitmap mode with emulated bitmap mode; this is simply text mode with a custom character set. (Thanks
saehn (http://www.commodore128.org/index.php?action=profile;u=367)for the link to Sabrina (http://noname.c64.org/csdb/release/?id=45850)- that demo validated my idea of emulated bitmap mode!) This offers several advantages and problems.
The best advantage is an emulated bitmap requires only 4kiB uncompressed data, a savings over 50% (a real bitmap needs 9 to 10 kiB). Another advantage is scrolling (or panning as we say in video).
However the problems are just as significant; probably greater. First, 3 of the 4 multi-colors are fixed for the entire screen (in true bitmap mode only 1 color is fixed); this will reduce the quality of all but "lucky" images with a limited palette. Another color problem is that the only color that can be manipulated "freely" (in char-cell terms) is limited to the first 8 of the 16 VIC colors. Third is the limited pixel precision; a full text screen has 1000 cells but only 256 cell-patterns; thus unless the image has highly redundant background (on the order of 3:1) the image decoded will have significant distortion. Fourth, not relevant to the user but to me as the programmer, is writing a compressor to produce such a video file.
There are other options too. Plan 74 is to wait for Craig Bruce (http://www.csbruce.com/) or some other genius to release an affordable mass-storage device that supports fast-serial protocol.
Plan 83 is for me to finish and release HDserver128 which supports B-E, M-E, Custom ROMs, MFM, fast-serial, and a bunch of other stuff nobody has done to my knowledge... but at the moment I'm focused on Media Player 128.
So right now, I'm considering option 35. This is to give up on video for the moment and concentrate on an audio-only player. (If your reading this RobertB (http://www.commodore128.org/index.php?action=profile;u=13), I haven't forgotten about DigiMaster)
I'll stop now before I bore everyone to death!
P.S. The good news. Media Player 128 has run in the test mode now for over 2 hours without crashing!
Edit5 hours later... still going... nothing outlasts the hydrogizer :)
/Edit
Quote from: Hydrophilic on October 03, 2010, 08:45 PMThis convinces me that full-screen bitmap video is not possible with both 2-bit audio and JiffyDOS running in the IRQ... At least not with an acceptable frame rate, which I consider to be at least 10 frames/second.
I guess that you'd have to go with a less-than-fullscreen bitmap for extra frame rate speed.
Quote(If your reading this RobertB (http://www.commodore128.org/index.php?action=profile;u=13), I haven't forgotten about DigiMaster)
Hooray!
Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
The Other Group of Amigoids
http://www.calweb.com/~rabel1/ (http://www.calweb.com/~rabel1/)
Southern California Commodore & Amiga Network
http://www.sccaners.org (http://www.sccaners.org)
One option you did not mention is working with Ingo and Jim Brain on implementing a fast serial routine on the uIEC that would be sufficient for your needs. This may require a bounty on commodorebounty.com but in the end such a routine could be a benefit to the whole community and if the computer side uses standard kernel calls then it could become a cart or internal ROM.
Well I did mention something similar to that; except like an idiot I referred to Craig Bruce instead of Jim Brain. :-[ Thanks for bringing that to my attention. I thought about adding fast-serial myself. I downloaded the source code for the uIEC a while back and spent some time studying it. There is plenty of unused Flash memory to code it. But I think the SREQ line would need to be reconfigured for interrupts as I don't think the controller would be fast enough to catch the signals through polling... at least not until a BurstLoad command was issued. I'll probably end up doing it if somebody doesn't beat me to it.
But I would rather work on Media Player for the moment.
Another idea that I didn't mention would be to reduce the sampling frequency. With 8kHZ rate (approx) the IRQ is getting called every 2 rasters. Reducing it to every 3 rasters would make a rate of approx 5.24kHZ. The issue is that the audio already sounds crummy, being it's only 2 bit samples. I wouldn't want to make it any worse. But since it sounds so bad to begin with, it might not make much difference.
Quote from: RobertBI guess that you'd have to go with a less-than-fullscreen bitmap for extra frame rate speed.
Now that sounds like a pretty good idea until I can get fast-serial mass storage device. I was hoping to use 38x24 mode to effeciently implement smooth-scrolling. Using anything smaller would require software. But I guess ya gotta do what ya gotta do...
So I re-ran my experiment with some different values. Here are the results, including previous report:
| Char Cells | Frames/Sec | MC bitmap | Hi-res bitmap |
| 38 x 24 | 2.0 | 152x192 | 304x192 |
| 30 x 19 | 3.4 | 120x152 | 240x152 |
| 27 x 17 | 4.0 | 108x136 | 216x136 |
So it still doesn't look very promising. But, this is testing I-frames, the worst-case scenario. With P-frames we can skip writting to RAM (and loading from disk) if the old data is the same or close to what is needed. Also with a smaller vertical size, we can run the CPU in 2MHz more often. When I first implemented fast mode it added about 25% extra frame rate. So I'm thinking with both benefits, we can have 6+ fps at the smaller size. Then maybe with motion vectors / macroblocks it can get up to 8 or 9 fps.
Of course such a small video might not be worth watching. Right now, despite the limited resolution of the VIC, at full screen you can still make out details on peoples faces, like there lips and teeth and which way their eyes are looking. With a reduced bitmap, I fear you'll only be able to see that it is person who has eyes and maybe a mouth. Well guess I won't know until I try!
I also tested this on my real C128 to make sure the fast mode code was really working. I don't think I had tested it on real hardware since I implemented fast mode. Well it works! I also tested the Multicolor + ExtendedBG mode trick to make sure it hides all the "random" pixels that appear when the CPU is at 2MHz. That works too! So I'm off to code a smaller screen...
Quote from: Hydrophilic on October 05, 2010, 10:26 AMOf course such a small video might not be worth watching. Right now, despite the limited resolution of the VIC, at full screen you can still make out details on peoples faces, like there lips and teeth and which way their eyes are looking. With a reduced bitmap, I fear you'll only be able to see that it is person who has eyes and maybe a mouth. Well guess I won't know until I try!
:) Heh, when I played Gloom (a Doom clone for the Amiga 1200), I had to reduce to video playfield to a little square in the center of the screen for me to get any kind of scrolling speed. With that small square, it was hard to recognize the any of the objects.
Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
The Other Group of Amigoids
http://www.calweb.com/~rabel1/ (http://www.calweb.com/~rabel1/)
Southern California Commodore & Amiga Network
http://www.sccaners.org (http://www.sccaners.org)
The results are still not promising. With smaller screen average frame is only about 1.5 fps. I haven't implemented mid-screen 2MHz + MCM + EBM yet. That might get the average rate up to 2.0 fps. And you can still people have eyes and see when they talk, but I don't think there's enough detail to read lips. (Not that you could do that at 2Hz anyway)
Based on this, I'm not sure what my previous experiment tells me... because if the average is 1.5 fps, then the minimum is much less; I don't have an exact value for the maximum frame rate, but it was pretty high, like 15+ fps.
I'm thinking the experiment tells the maximum full-screen decompression provided the compressed data is available fast enough... so it seems obvious to me the data rate is just too low...
I messed around with the encoding of cards / macroblocks in the P-frames and discovered some interesting things. Depending on how "sloppy" the comparison function is made, the compressor can be made to copy huge portions of old data from RAM (instead of loading from disk). For example, the best quality (virtually no loss within limits of the VIC2) produced a file size of about 320 blocks (5 seconds of video). But by changing some constants, I got the file size down to 137 blocks. Of course this noticeably reduced the quality, but it didn't result in a complete mess either.
Edit
You would think reducing file size by 50% would increase frame rate dramatically... but that small file only had a tiny improvement... about 1.65 fps... arrrr!
/Edit
So I need to develop a way to change those constants into variables. That way if a frame or two are really "hard" to encode, the quality of the image can be reduced to maintain a decent frame rate.
Similarly, the encoder is currently writing frames to the file at a constant rate. If this could be made variable, say dropping a frame that's really "hard" to encode or dropping a frame to give more data to the previous frame that was "hard" to encode, it could improve the average frame rate... albeit at the cost of a more "jittery" frame rate.
So many variables, so little time!
Edit 2
Previously, before the new smaller screen size, the average frame rate was approximately 1.0 fps. You would think that reducing the screen size (from 152x192=29.184kPix down to 108x136=14.688kPix) would significantly improve the frame rate... but it only improved by 50% (from 1.0 to 1.5 fps)
/Edit 2
Quote from: Hydrophilic on October 06, 2010, 12:34 PM...but it only improved by 50% (from 1.0 to 1.5 fps)
Hmm.
QuoteUnfortunately, the C1571 lacks the capacity for a video of any reasonable length, and the uIEC / MMC / HD64 do not support fast-serial. The C1581 does support fast-serial and has enough capacity for a limited amount of video, but I do not own one.
FWIW, you can connect a CMD hard drive to a RAMLink via parallel cable, and the appropriate software can make use of the faster throughput (Wheels does this). However, CMD hard drives and RAMLinks are not exactly widely-available. FWIW #2, when using the IDE64, I've seen very fast video framerates with its movie player plug-in. However, IDE64 is for the C64 (with the exception of being able to use C128 function keys).
Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
The Other Group of Amigoids
http://www.calweb.com/~rabel1/ (http://www.calweb.com/~rabel1/)
Southern California Commodore & Amiga Network
http://www.sccaners.org (http://www.sccaners.org)
Quote from: me on October 06, 2010, 03:03 PM
However, IDE64 is for the C64 (with the exception of being able to use C128 function keys).
Today I received word from the IDE64 developer that he is working on a beta version of the firmware in which it can use the 2 MHz of the C128 while in C64 mode (the C64 screen is blanked using shift-lock).
Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/
Southern California Commodore & Amiga Network
http://www.sccaners.org
I personally think that adding fast-serial support to the µIEC/SD2IEC project would be the most widely useful move. I’d do it myself if I thought I could get it working in less time than “a few years,†but as some of you may recall I am already way late with a variety of other projects, including a mostly unrelated µIEC enhancement. Adding more to my backlog queue would not be productive.
Does anyone think there would be much public support behind putting a bounty on adding the fast-serial feature? I am conflicted on the point; I’m in favour but have no money to put where my mouth is.
G.
I think a bounty for uIEC fast serial is a good idea, but I won't put up any money for something I plan on writing anyway... eventually... I have a large queue as well!
I CMD HD would be the way to go if they were more common and economical... and had a larger capacity...
The IDE64 sounds pretty good if it would run in 128 mode. The problem with 64 mode (even if you have access to 2MHz which the software uses) is the fixed CharROM and no ColorRAM banks. Not to mention 1/2 RAM for less video buffering / P-frame encoding, thus larger files due to less compression (of course faster transfer rate may overcome the larger file size).
I've finally coded and debugged the within-visibile-screen 2MHz audio + JiffyDOS IRQ... what a pain! The IRQ routines are like a house of cards, make one small change and the whole thing collapses. I thought I was hiding the 2MHz garbage with the MCM+EBM trick, but I was actually using the Bitmap+EBM trick. They both do the same thing (force video output to black), except the Bitmap+EBM method is faster because both bits are in the same register.
Anyway, this boosted the average frame-rate up to 2.0fps NTSC, 2.1fps PAL. I also took the time to determine the best and worst frame rates. The lowest was about 1.3fps and the highest was 6.0fps. Previously I reported 15+ fps but that was just my impression... I was wrong, there I said it.
It seems like the median frame rate was about 2.2fps (I didn't take the time to calculate the median). More importantly, I noticed the encoder is not doing a very good job. For example, whenever there was a scene change, that is when I would get the below average (1.3fps) frame rate, which is to be expected unless you seriously compromise the quality of the image. And whenever there was little movement that is when I got those above average (6.0fps) frame rates, also to be expected. But, often when there was only "modest" movement, the frame rate would still drop below average (1.5fps or so).
I'm going to work some more on the encoder. Hopefully I can get the scenes with "modest" movement up above the median. I'm thinking that would give an average of 3 to 4 fps. Then I can work on the "sloppy" control factor for a little more speed. Unfortunately it seems this will never get above 5 fps without a hardware solution.
Quote from: Payton Byrd on October 04, 2010, 11:24 PM
One option you did not mention is working with Ingo and Jim Brain on implementing a fast serial routine on the uIEC that would be sufficient for your needs. This may require a bounty on commodorebounty.com but in the end such a routine could be a benefit to the whole community and if the computer side uses standard kernel calls then it could become a cart or internal ROM.
I'd be very interested in that bounty, speaking for Commodore Bounty.
I've implemented a limited form of motion vectors and virtualized the encoding software to improve P-Frame encoding. I was hoping this would give a nice improvement, but has only given a small one. Both NTSC and PAL average 2.2 fps. Previously PAL enjoyed a speed advantage, but with the increased 2MHz zone (reduced video size), NTSC is now almost as fast (difference less than 0.1 fps)
I've tried various things to improve the compression and hopefully the frame rate as a consequence. Although I made little improvement, I learned a lot about how to make things worse!
Maybe somebody has an idea to explain this... I get better compression and frame rate with motion vectors limited to less than 8 rasters. Here is an example table of file size versus search range (rng) and block size to copy...
| Block Size | rng=8 | rng=7 | rng=6 | rng=5 | rng=4 |
| 2x4 | 150k | 100k | 110k | 120k | 130k |
| 3x4 | 160k | 110k | 120k | 130k | 140k |
| 4x4 | 170k | 120k | 130k | 140k | 150k |
| 5x4 | 180k | 130k | 140k | 150k | 160k |
This is just an example, the real data is much larger and not so pretty. But you should see that file size decreases with smaller blocks and a larger search range, until 8 raster vertical search is reached and then the size jumps considerably. Ideas?
I did find it is important if the block is to move to an area that crosses a cell row (8 full rasters corresponding to 1 text character row) that it should not be copied. This reduces compression because of the way video memory is laid out. So the encoder checks for this and avoids it. But if the block to copy does not cross a cell row, it should improve compression no matter "how far away" that it is... but according to the data, there is a huge "penalty" if the block is 8 rasters away... bizarre.
This is important because it should improve compression if blocks can be copied (moved) from arbitrarily far distances. Right now the search range is limited to 7 rasters to avoid the "penalty". This is only vertical motion; horizontal motion is not implemented.
Related to that is updating the encoder's "memory" of the scene after moving blocks around. That was bit of programming fun. I noticed through a programming error that if the blocks "memory" of the "new" value is not correct, the compression actually improves...
So I tried various methods of lying about the copied value. For example, saying that 50% comes from the real source and 50% comes from the old copy being used. I tried various fractions and limits... but in the end it turns out that the best compression occurs when you lie 100%. Always say the copied value is the real value. I guess it goes to show it's okay to lie if you do it consistantly.
Another thing I worked on was trying to optimize the color palette. Again I made marginal improvement and found a lot of ways to make things worse.
The one thing that actually worked was to simply enforce a consistant palette as much as possible. Previously only multi-color 3 (in Color RAM as opposed to system RAM) was fixed, and the encoder would choose the other 3 colors to reduce the overall error. The entries were ordered by priority so some frames might have "black" as color 0 and some frames would have "dark gray" as color 0... even when they all used both "black" and "dark gray". So now if the encoder finds the same colors in consequtive frames, it makes sure the palette entries of the new frames match the previous frame.
Now that makes sense; because the data is more consistant the compression and frame rate are better. Unexpected was the
improvement from choosing a
bad palette.
Originaly the program would test each color against the entire bitmap and assign an error to each color and then use the 3 colors with the lowest error (the 4th color is fixed remember). This method is fast and simple, but the quality of images (based on final VIC2 luma versus source video luma) is not very good... so I tried different algorithims to get a better palette. Instead of a simple sum, I tried a sum of the squared errors. I also tried calculating the error of color n+1 based on the fact that color n was also available.
Well these methods gave a "better" image in terms of overall luma error. But they considerably increased the file size. The images also appeared less pleasing because they had large amounts of dithering. The large amount of dithering would explain the increased file size.
The original "bad" palette optimization gives the best compression, and in my opinion, better images. Go figure.
Well I'll try and get some screen shots up for you this weekend. But you need to see it in action, if you can call 2.2Hz action :) Some of the scenes look like a typical VIC2 dithered image but some are really nice. My favorite parts are the screen disolves. I always think for an instant my program has crashed and then the next scene magically appears.
Strangely you would think the screen disolves / fades would suffer low compression or 'pixelation' due to lots of dithering between two different scenes. Yet these are as fast, often faster, than normal frames in the video. Go figure.
I'm gonna work on hi-res bitmaps instead of multi-color and try some other ideas to improve the frame rate. Might have an actual working demo by Christmas.
I got hi-res working and totally re-coded the video encoder to be more structured... the (original) single-file source of over 100k was getting a bit unwieldy... now it is way over 100k (multiple files) but is easier to manage... took me quite a while to squash all the memory leaks I created in the process...
The main benefit, besides better organization, is now I can "parameterize" all those weird/useful compression optimizations I spoke about in previous posts. So hopefully the encoder will be able to produce an optimal (or nearly) video through some iteration/constraint type algorithim.
Anyway, as promised, I've got some screen shots for you. I've got so much data, I can't think of good way to present it... Edit Actually I can't put that much data in one post, so you get the short, short version/Edit Let's go in this order:
Size (H x V)
Mode (Hi-Res, Multi-Color)
Quality (P-Frame, I-Frame)
In regards to Size, the fist is my first video at 40x23 cards (160x184 MC or 320x184 HR) which I thought would be close to 4:3 aspect ratio but was wrong according to responses from forum members (thanks to all who replied!)
WARNING: do no not enlarge the C128 images, it only makes them look worse... trust me! :)
Oh, I said this in previous post(s), but the images are limited to VIC-II gray scale... color is on my to-do-list :)
Here is a set of images in the smaller format to allow faster frame rate due to smaller data size and more 2MHz time. These were captured outside of the video player so the 2MHz mid-screen borders are not present.
The size is 27x17 cards (108x136 MC or 216x136 HR). This gives nearly perfect 4:3 aspect ratio on a real C128. When viewing them on a PC with perfectly square pixels, the image will appear a little wide.
WARNING: do no not enlarge the C128 images, it only makes them look worse... trust me! :)
The third Size is wide-screen format. This gives a good 16:9 aspect ratio on a real C128. Again, when viewed on a PC with square pixels, the images appear too wide.
WARNING: do no not enlarge the C128 images, it only makes them look worse... trust me! :)
I could spam the boards all day, but instead if you want more, you can download a zip file (http://sites.google.com/site/h2obsession/CBM/C128/images/mp128sample.zip) (2.58 MiB) which contains over 70 images... multiple samples from each screen size and the original images. The *pH files are mid-quality (P-Frame) hi-res; the *iH files are high-quality (I-Frame) hi-res; the *p filese are P-Frames in multi-color, and the *i filese are I-Frames in multi-color; those without i/p(H) are the originals.
What... no comments???
I guess I have to take it to the 4th dimension (color). Stay tuned...
Quote from: Hydrophilic on October 18, 2010, 04:18 AMThe third Size is wide-screen format. This gives a good 16:9 aspect ratio on a real C128.
If you go to the letterbox format, it looks as if you would have room at the bottom of the screen for other information.
Nah, not scrolly greetz, ;)
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
The Other Group of Amigoids
http://www.calweb.com/~rabel1/ (http://www.calweb.com/~rabel1/)
Southern California Commodore & Amiga Network
http://www.sccaners.org (http://www.sccaners.org)
Quote from: Hydrophilic on October 19, 2010, 04:41 AM
What... no comments???
I guess I have to take it to the 4th dimension (color). Stay tuned...
It looks great, even in B/W! I think I prefer the multicolor over hi-res. It's little more blocky, but I bet that wouldn't matter much in motion.
I've been following this with great interest, as I do all of your projects! As marvelous as it is to see anyone's projects for the C64, VIC-20, and PET, C128 projects are my favorite. Of course.
This one is awesome, BTW! :D
Quote from: saehn on October 20, 2010, 01:01 AMIt's little more blocky, but I bet that wouldn't matter much in motion.
OT: As for blocky. I made a little FMV (http://www.amidog.com/c64/) experiment for the C64 a few years ago. My goal was to have something streamed from floppy running at 25fps, so I picked a simple animation and didn't worry too much about the visual quality. In case you decide to check it out, you need to press fire button on port 1, not port 2. Silly mistake :)
Just checked it out... pretty cool! I'm sure Hydro's will look similar, but will hopefully the image quality will benefit from a larger screen size.
Quote from: Mathias Roslund on October 20, 2010, 05:29 PMAs for blocky. I made a little FMV (http://www.amidog.com/c64/) experiment for the C64 a few years ago.
Your Raycaster for the C64 with SuperCPU is interesting.
Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
Quote from: Hydrophilic on October 19, 2010, 04:41 AM
What... no comments???
All people are still deeply impressed!
Thanks all for the interest and encouragment! I was hoping to give you some color screen shots this weekend, but so far the color results are quite sad.
The only good thing in regards to color is the encoder does a good job of converting a color-source video into VIC-II monochrome. (The images posted previously were generated from monochrome, so there were no conversion issues to begin with).
Like a schizoid, I can't do 1 thing at a time. Besides working on color, I also worked on the RLE/Copy compression (now up from 67% to 70%) and did some regression testing...
I had not tested the new "in-visible-screen-2MHz" code on a real C128 until yesterday. I've been doing most of my developement in VICE. The VICE team did a good job of improving the 2MHz code I submitted years ago (in particular I/O clock stretching), but the emulator still doesn't do DRAM-refresh stretching and I think MRW instructions (INC $D030 for example) are also faulty.
I was worried the player would crash on a real C128 or run a little slower because of DRAM refresh.
To my delight, the player doesn't crash AND it runs faster! I'm guessing it doesn't crash due to good design. ;D I'm guessing it runs faster because I'm using a uIEC with the real C128. The C1581 used in VICE developement has a delay in moving from track to track... as would be expected in reality.
Well, I'm going to check out Mathias Roslund's FMV experiment and get back to Color coding. Hopefully I'll have more screen shots next weekend.
I've been thinking (danger!) that to get a good color image, you want to give priority to objects in the foreground. But there is no Z component in 2D source video. So the encoder will have to guess which pixels are foreground and which are background. That would take us to the 5th dimension... It's easy to get lost in all these dimensions :P
Quote from: Hydrophilic on October 25, 2010, 07:52 AMThat would take us to the 5th dimension... It's easy to get lost in all these dimensions :P
http://www.youtube.com/watch?v=fQP563gKwIU (http://www.youtube.com/watch?v=fQP563gKwIU)
Thanks for the link Airship. I'd never heard of them before. I see they have several songs/videos. Is there anything special about the one you linked to?
Thanks for the link Mathias Roslund! Your video has a much better frame rate than any of mine. I knew I couldn't be the first to do something like this, but I couldn't find any links before I started this project. I read your info web page and found it interesting. My encoder is already breaking the image down into 4x4 blocks (basically... it's actually variable, see previous posts). But what suprised me was your use of delta encoding... I've seen this applied to audio, but never to video!
So I'm guessing it just counts bits and spits out a sequence of bit pairs? That's a good idea in general, but with the audio IRQ constantly stealing cycles, I don't think the CPU would have enough time for anything that complex in my case. I guess plan 83 could be a video with no audio... should be able to handle complex compression and give a better frame rate.
Or, an idea somebody mentioned was to use hardware for audio. CIA#1 serial port is for the fast serial bus. But you can use CIA#2 serial port output and feed it to the SID audio input. Of course this would limit audio to 1-bit quality and require a minor hardware "device" (if you can call a cable a device), but it would reduce IRQ overhead by 75% with the same bit rate. I have no intention of implementing that, but just thought I'd toss the idea out there.
Quote from: saehnI think I prefer the multicolor over hi-res.
Thanks for the feedback! I tend to agree. I mainly did that just to make sure it works in the general case... hi-res or multi-color. All the screen shots above, and some I'm about to post all have a global palette. This means it can be implemented in real bitmap mode (and it actually has been so far), or in text-emulated bitmap mode... but this would require a little extra effort to reduce the number of distinct cells to 256 or less. Of course this would generally reduce the quality, but with a smaller memory footprint, it should give a higher frame rate all by itself, but moreover allow for more buffered frames increasing memory-copy compression and increasing frame rate yet again.
Also in keeping with the general approach, there is also possibility for Extended Background Character mode. It would have to be a really small/simple video to require only 64 cells :D Besides hi-res quality, you also get 5 global colors, or 4 global + 1 custom if you include Color RAM. Although the groundwork is there, I haven't even tried it because it would require good cell and color optimization. I'm not that far yet...
I'm still working on the color problem. I've tried several things but have yet to develop an algorithm that consistantly delivers good results. I've learned quite a bit and have some results that might prove interesting, or perhaps hilarious, depending on your sense of humor...
One of the first things I tried for color was to have the encoder try every possibility and use the one with the least error. Well even considering the small size of a VIC-II bitmap and the power of a 1+GHz 32-bit CPU with FPU, it would still take over 1 second to try all 16*15*14*13 = 43,680 combinations. Which might be okay if you only had a few images, but could take an hour or more if you have 1000+ frames of video... really sad for a 5~10 minute video!
Leaving the speed issue aside, the results were highly unstable and often unpleasant. It would often do things like mix purple and light green to make white... not pretty trust me... wish I had a good screen shot of that...
Anyway, I've attached some screen shots which show the bizarre unpredictability. Some of the frames look like what you may have seen in other digitized VIC-II video. But many look terrible. The worse part, when watching a video, is the palette keeps dramatically shifting. The last two images I've attached show 2 nearly identical frames, yet the encoder choose entirely different palettes. I'm guessing this is due to subtle differences in the over-all hue / luminance of each frame.
But the thing I found interesting was the bizarre color artifacts constructed by the human mind (or at least mine). In particular human-percieved 'color shift'. Digital cameras have to take this into account in terms of 'white balance'. Maybe it's not the exact same thing but anyway...
One example (sorry no screen shot) was if the picture used Brown as the overall (background) color instead of Black. In this case, shades of Gray would appear somewhat Blue.
Another example (first screen shot) seems to have 3 shades of purple. How many shades of purple does the VIC-II have?? Only one! Now you might think this is due to color dithering, but if you look close, there really isn't any. Well there is dithering with Black in the background, but I'm talking about the bright area around the headlight.
Now you might also think the headlight center is White or Light Gray, and the surrounding area is Cyan or Light Blue perhaps. But no. I took some time to analyze this one. It turns out the center of the headlight is Light Green, and the surrounding is Light Gray. Yet somehow the mind (at least mine) turns this into 3 shades of purple.
Due to the slow analysis time and unpredictible output of the "least error method" I've spent quite a while working on the color problem. I still haven't got a good general purpose routine, but have improved the reliability and to some extent quality.
I've posted a couple of these for you. Warning: Do not zoom in! It only makes it look worse. Trust me. :)
Although it seems to do okay for most scenes, in doesn't work well in very bright or very dark scenes. It also often uses a LOT of dithering which mackes the image unpleasant to me, and more importantly it severly hurts compression and thus frame rate.
I'm still trying to find a nice balance between this algorithm and the "simple" (less dithered) method of the screen shots of the previous post.
Man, you really know how to open up a can of worms, dude! LOL! I can't wait to see what you come up with next! I'm really enjoying the ride! :)
BTW, the 5th Dimension song I linked to uses the Declaration of Independence as its lyrics. Very inspirational to a Yank like me; I memorized most of it from the song. Their most famous song is Up! Up! And Away! (In My Beautiful Balloon). I actually saw the group live in 1969.
I can't believe they've been around that long and I haven't heard of them. 1969 makes me think of The Beatles, Elvis, and Pink Floyd. That goes to show I don't have a very wide variety when it comes to music appreciation... I thought that I did... but you proved otherwise.
I'm making progress in the color department but it is slow going. I had planned on simply adding 1 extra dimension to the problem -- hue, on the basis that VIC-II colors all have the same saturation. That is according to an excellent article on VIC-II color (http://www.pepto.de/projects/colorvic/)by Philip "Pepto" Timmermann. Of course if you read that, you'll see that Bob Yannes countered with the fact that the colors were choosen individually and are not as precise as described in the article. Either way, my experience with several TVs and Commodore monitors (and a few non-Commodore monitors) makes me agree that all colors have the same saturation.
Unfortunately, you can't determine between gray and color without saturation. So by mistake I took the project from the 4th dimension to the 6th dimension. Oooops.
Previously I said my encoder was doing 16*15*14*13 calculations to optimize the color. Wrong. It was only doing 16+15+14+13 calculations. That's several orders of magnitude difference! I'm guessing it ran slow because I am testing with a debug build. I've written more advanced graphic programs that run faster once compiled normally.
Anyway, because of the prior slow performance, and the highly unstable palette choices of the "least error method", I've developed a new color coding algorithm. It starts by building a histogram of all used colors. This takes only slightly longer than calculating the error for 1 color (which previously would be done 16+15+14+13 times).
Then it "eliminates" the less used colors and builds a palette from those that "survive". To my amazement, many scenes end up requiring only 2 hues. Not most, but many.
I have a confession. The last algorithim I tried (the last set of screen shots) was not really an algorithim. To avoid the time penalty and palette instability of the first "least error" method, the last simply choose 1 of a few hard-coded palettes. Although some of the scenes look nice, a lot of them still looked like crap. Naturally I posted the good-looking ones.
In particular, dark scenes looked terrible. And bright scenes didn't look very pleasant due to massive dithering (see the last two screen shots from the previous post as an example).
With the new "histogram and eliminate" method, dark scenes look fantastic. Bright scenes generally look better due to less dithering, but they are generally not as colorful as before. Compromises, compromises... other important benefits are better compression and usually a consistant color palette. I still need to tweak it, because occassionaly, about once every 30 frames, it will decide upon some totally crazy palette. (Much better than every 2 frames with the "least error" method).
I can post some screen shots if you like. Any suggestions would be welcome as well.
I have no suggestions :-) but we would always love to see more screenshots!
Okay here's some screen shots with some comments. That way I can tell you what I think the problem is and how I might be able to fix it, or maybe someone will have a better idea they would like to contribute.
So I'll start with the re-rendering of the last 4 frames I posted previously. In the 1st, you've got high contrast, with the black background and the white headlight. These are are the hardest scenes to digitize because you can't effectively emulate black or white. So with 2 colors used, there are only two colors left. Note you can effectively emulate light gray. The encoder will try to fudge the contrast a little to eliminate white so that it can use light gray. But it doesn't try too hard because that increases dithering, which I prefer to avoid for both asthetic reasons and the reduced compressibility. As we shall see later, sometimes it doesn't try hard enough. Overall I am pleased with the result, as the characters are more detailed than the orginal and it has higher contrast. The only thing I can think to make it look better would be to use yellow for the headlight, which would dither better with the characters... if you zoom in you can see how annoying it is where it dithers white with the flesh tones.
In the 2nd one, the scene is not as colorful in this rendering as in the previous post. Although it has lower color fidelity, it has better dynamic range. Again a 'hard scene' ranging from black to white. So you still end up with a lot of dithering, but it is a lot less than the original. So in that regard it looks better; except dithering orange with white is a bit annoying. Overall I think CBM/CSG did a good with the VIC-II palette, but orange is just too dark! :(
The third frame looks better overall in my opinion due to use of real white, instead of trying to fake it through dithering. Although it too lacks reduced color fidality because it uses to shades of gray (I think dark gray and white) and thus only has 2 real colors to work with. In the previous post, the encoder used what I call 'massive dithering.' The new code does it's best to avoid that.
The fourth frame is really questionable. On the one hand it looks a lot better due to less dithering, and it has better dynamic range (black to white again) but on the other hand there a few problems. For one, it only choose 1 color and 3 shades of gray. Which means flesh tones end up as gray. Now she looks like a zombie. Another problem you should notice there is no detail in the wall on the right side of the new image. I'm pretty sure this is because white is too bright and washes out the details, similar to over exposure in photography.
Also in regards to the fourth image (actually all images I'm posting today), the image was converted using 'full contrast'. In the first set of images I rendered, I set a global paremeter to reduce the contrast by about 20%. This was just a hold-over from the black-and-white conversion where I found that setting to produce the best results.
So I'm think I need to 'localize' the contrast setting for use on a frame-by-frame basis (instead of globably for the whole video). Of course I need to come up with a good algorithm for this, as I'm sure nobody would want to customize the contrast by hand for each frame of video...
Well it already does this to a limited extent, but only when it detects large amounts of both black and white. I think a more general purpose technique would be better. And as the new rendering of frame 4 shows, it doesn't always do a good job, even in this special case.
Now I don't know if it is an inherent limit of the VIC-II, or just my faulty algorithims, but I think the dark scenes produce some of the best looking images. Here are a few of my favorites. I think the software has improved enormously in this regard. The first color images I posted rarely had any dark scenes because they almost always looked like crap so I didn't post them. Now the dark scenes are usually the best looking.
If I could only get the 'white' scenes to look this good, I could almost call this phase of the project complete...
Oh about the images... the 1st is another frame from the motorcycle scene, but without the headlight forcing the use of white. The 2nd frame emulates light gray so it has a moderate amount of dithering. (Not the 'massive dithering' I mentioned previously.) The 3rd frame uses real light gray. This works a lot better than white, don't you think? The 4th frame features a brunette, which is why the hair is not red.
The last 4 images are what I would judge 'really good'. The 4 prior to that I would call 'acceptable' given the limits of the VIC-II and my own self-imposed constraint of a single palette for the entire bitmap (as opposed to optimizing the 3 colors in each cell).
Now here are some that I would judge anywhere from 'unacceptable' to 'absolutely terrible'.
The first thing you should know is that all of these were digitized from color video. But they all ended up as gray scale. Sometimes this is okay if the scene doesn't contain a lot of color, but these scenes contain color in at least 25% of the pixels, which means the encoder should allocate at least one hue to the palette but it does not.
In the 1st image, the flesh tones and blonde hair are missing (also in the last 2). In the 2nd image, the orange mountains and the blue sky are missing. The problem seems to me that obviously the saturation is too low. This was anticipated and the encoder is designed to increase the saturation in such scenes in order to 'reveal' colors of low saturation. But as these examples show, it isn't doing a very good job...
Disregarding the lack of color for the moment, the 1st image just doesn't look as good most other gray scale images. I think this is due to white. Unfortunately, I'm not sure how to improve it...
The last two images (no.3 and 4) are nearly identical frames from the same video, but I think you will agree #3 looks terrible! Disregarding the lack of color, I think #4 looks good. Really strange that two very similar frames would vary so drastically in quality.
If you look closely, you can see that #4 uses a dither of White and Medium Gray. But #3 chose the 'middle value' of Light Gray. And as it so happens in this particular image, most pixels are very close to Light Gray so you get a whole bunch of them, and consequently little detail.
Now by design, the encoder is trying to find the 'best color' in order to minimize dithering which improves compression and usually improves quality. But in the case of #3, we see that it can completely ruin the image. The only way I can think to prevent this is perform some type of Fourier/Laplace Transform on the bitmap. This is a computationaly intensive task and the math/algorithim can get ugly. Of course there are well-known Fast Fourier Transform algorithims, but they are still CPU intensive. Many video encoders use them via way of SIMD/MMX/3DNOW instructions, AFAIK. I have no intention of writting inline assembly, and even if this could be done acceptably in pure C, I'm thinking it is not neccessary.
I'm thinking a simple 'frequency analysis' over every 8th raster or so should suffice to determine if the encoder has choosen a 'terrible' color. This wouldn't be a true transform into the frequency domain, merely a measure of how many transitions occur on the raster. A quick-and-dirty method, if you will.
Here are some scenes where the 'saturation amplifier' actually worked to reveal some color.
Even though we get some color in image#1, I think it still looks unacceptable. #2 is okay I guess...
Which tends to make me think White is the problem. But the last two frames contain a lot of white (and properly contain no color), and look pretty good I think. So the question is how to fix the white 'problem' without breaking the good job it does on occassion...
EditActually #4 should contain color... silly me... but importantly, the image turned out well despite the high amount of White... so it isn't the mere fact of a lot of white... a pesky problem...
Is there any chance that the extremes could be averted by eliminating pure black and pure white as palette choices? I know in painting you can sometimes get better effects by limiting your palette. Just a thought, as I know NOTHING about the subject.
Keep up the great work!
At airship: I think there is a good chance! It tries to eliminate either black or white if both are used, but only if they are not used 'a lot'. I think some the of 'shock and awe' would be lost if one is dropped when they are 'important' ... high use. I guess I need to develop a better algorithim to determine when to keep and when to drop...
Having both black and white causes trouble most of the time. But if it so happens that only one hue (or 2 closely related hues) are needed, then the images actually turn out pretty good, I think. Here are a few to judge for yourself.
The 1st looks good overall, but there is a loss of detail in the face (just a blob of gray and orange pixels). The 2nd looks really good but is 'cheating' because it actually uses Dark Gray instead of Black. The third looks good and is really using black. I'm guessing because the subject is close enough to the camera that facial details aren't lost.
I've previously described some of the problems with missing color due to low saturation and demonstrated how it sometimes 'reveals' these colors and sometimes fails to do so.
So you would think (at least I did) that using source video without a lot of saturated colors would prevent this problem. Well then what better than an animated video. And for Commodore fans, what would better than an animated movie from the 1980s? Maybe you will recognize this one...
In the first image, there is nice use of color and a moderate amount of dithering. If you think the dithering is bad, you should refer to the original color images I posted which sufferred horribly from 'massive dithering'. So I'm just saying I think #1 looks good considering the alternative...
The same goes for #2
But in #3 where the camera pulls back revealing a vast area, most of the color is lost. I think this because the large area has a wide variety of colors that average to 'gray' and only the highly concentrated areas of get 'recognized' for color...
Most of the frames of the video turned out pretty good but some just don't look right to me. The 4th one is an example.
Here are some more images from the same video I thought you might enjoy. I do. I really have no comment except for image#2. I think he should be saying,
Quote from: Hydro's Imagination
My cannon is so powerful, it will destroy the palette of the VIC-II!
Well good looking images from an animated film don't really count in my opinion. They were just test how the encoder would perform with high saturation and a lot of colors.
So here are some images from some 'real videos' that actually did a good job with color. Or so I think, you be the judge.
The 1st ones does a mediocre job with a limited number of hues... it didn't get the flesh tones. #2 gets the flesh tones but suffers from a moderate amount of dithering as a consequence. #3 is a demonstration of the outfit she choose to wear... and her fingernails are really painted black, it's not a missing color...
#4 is for that Yankee, Airship. I'm really supprised the encoder picked out blue, considering how dark a color it is... the pink blob in the background is the girl from image#3... once she gets closer, the blue is lost and gets rendered as black. What I really like about #4 is the different shades of red in the flag... there really aren't multiple shades! Just a very convincing dither... I think...
Here are some images I think are interesting. The first 2 show the effect of blue light in the club very well. The last two have slightly less of a blue light effect, but the wide camera angle (with many people in the scene) suffers terribly from pixelation... Revealing the limits of the VIC-II, or at least of my encoder... I don't think there is anything that could be done except switch to hi-res mode with devastating color consequences...
There are several more real nice images and a few terribles ones that I could share, but I need to stop and take a break. Last night I actually had a very vivid dream in VIC-II color. Everything was a VIC-II color or a dither thereof. Really bizare seeing shadows and lighting effects cast in VIC-II pixelation... and instead of walking from room to room, the room would disolve in a bizarre combination of VIC-II colors only for the next room to re-materialize in its place...
I wish I were experienced enough at organic chemistry and molecular biology to turn that into a pill... I would make a fortune at the clubs...
If you haven't suffered overload yet, you can download a ZIP (http://sites.google.com/site/h2obsession/CBM/C128/images/ColorDemo2.zip) file containg over 250 screen shots (8.2MB).
Gee, I was hoping somebody would say if they like the original 'extreme dither / high color' or the new 'moderate dither / moderate color' version.
The important thing (for my sanity) is the recent break from coding has resulted in no more VIC-II Color dreams :) I did have another VIC-II dream a few nights ago, but without all the fantastic colors. That's probably better from a psychological perspective, but not quite as entertaining. Whoever develops a device to record dreams onto a DVD will make a fortune!!
I'm gonna stay off this for another week and see if you folks have any comments. With Christmas fast approaching, I don't think I'll be able to perfect color in time. So my demo will contain several videos, many monochrome and a few in color. Is that okay?
Uh... thumbs up for using Pink? :)
Quote from: airship on November 16, 2010, 06:15 AM
....using Pink? :)
At first I thought you were being sarcastic... but now I see it is a joke... umm the smiley should have clued me in.... Anyway... you're welcome... enjoy Pink :)
So after my my mental break, I'm finalizing the (demo) muxer... and adding primitive support for the VDC... please note 80-column mode only supports audio files... video is limited to 40-column (VIC-II)...
Can anyone provide links to some some SID files?
I am aware of the SID High Volume Collection for sale, but as I am not big SID fan, I have no intention to pay for a CD. I have many games / intros / demos with SID music, but I am too lazy to try extracting the SID tunes from these files.
So if anyone could point me to some SID files for me test with Media Player 128, I would appreciate it...
BTW, did I mention I will release a demo with source for this Christmas? You'll get credit of course... thanx!
Quote from: Hydrophilic on November 28, 2010, 01:42 PM
I am aware of the SID High Volume Collection for sale, but as I am not big SID fan, I have no intention to pay for a CD. I have many games / intros / demos with SID music, but I am too lazy to try extracting the SID tunes from these files.
So if anyone could point me to some SID files for me test with Media Player 128, I would appreciate it...
The High Voltage SID Collection (http://www.hvsc.de/). I'm not familiar with the collection you mentioned above, but I suspect it's a repackaging of the HVSC.
Thanks bacon! I'm glad you knew what I was thinking!
I'm downloading the PSID64 collection now for analysis. And it is free! :)
I wanted to get this online in time for Christmas, but it just so turns out the Christmas season is the busiest time of the year and I couldn't get it done in time. This is mainly due to an unexpected last minute problem I found with the demuxer. It's still not 100% fixed, but enough excuses! If I don't get it out now, it may never be released...
This is the core audio/video player and it only supports one format... well 2 if you count video without any audio... well 4 if you count hi-res seperate from multi-color... well 8 if you count char-emulated bitmaps seperate from real bitmaps... the important thing is it plays videos with only 2-bit audio (if any).
I have a seperate audio player that 1-bit, 4-bit, and 8-bit digis and am working on SID file (non-digi) support. That will eventually be merged into the player proper. I've included the source files, the binaries and 2 videos, all ready to be downloaded to your CMD-HD, uIEC/SD/CF, or other mass-storage device. Also included is a .d81 which (barely) holds one video for those who want to try it out in VICE (or want to try it on a real C1581, that would be interesting).
Even zipped up, it is too big for a forum post, so you can download it here (http://sites.google.com/site/h2obsession/CBM/C128/images/MediaPlayer128Alpha.zip). Also it's an Alpha version (pre-Beta). Intended mainly for CBM die hards. If you've been following this thread, you should be aware of most of the issues. If not, at least read the included Read Me.
With the right setup, even a noob can issue RUN"MPLAYER128.BAS". You really just need to get the files onto a JiffyDOS device and you should be good to go. Runs on both NTSC and PAL.
Funny thing is many games sound a lot different to me when running them on different standards, (NTSC or PAL), but this video player sounds pretty much the same either way. Which it should because it is locked to the video which also needs to play at the correct speed.
If you have a sharp eye, you may notice some mis-sync between the audio and video when running it on VICE. The only way I know to do it on VICE is with a C1581. But of course it has a "track read" delay (I don't think it implements head movement delay).
However with a real C128 and uIEC/SD (and, I imagine, with a CMD-HD), there is very little mis-sync. However the synchronization is pretty sloppy at this point. With some work, it should be rock solid on slower devices like the C1581.
I would be interested in any reports from PAL users (any storage device) or from any CMD-HD or FD-2000 users (any video standard). Um actually real C1581 reports would be nice too.
Anyway, Happy New Year!
I'm looking forward to fast-serial support on the uIEC so I can add that feature to the media player. JiffyDOS is just too slow, which I think you'll agree after you see the videos. Um, did I mention the audio is 2-bit... it's pretty harsh... you've been warned :)
Edit
I forgot to include the video encoder. It runs from a Windows command line. Might could run it in Wine, I dunno. Making videos would be / should be as much fun as viewing them, but it isn't very fast. On 1.5GHz P4, gray scale video compiles in real time, and color video takes twice as long. I'm gonna test on a 3GHz Centrino and write up some notes on use. It's a LOT tricker than simply viewing videos.
In the meantime, here's some more videos:
This one (http://sites.google.com/site/h2obsession/CBM/C128/images/S93.5B-5a2.bin)should be color, but most of it turned out grayscale "Bad Romance" 16:9 aspect ratio
This one (http://sites.google.com/site/h2obsession/CBM/C128/images/S92-4FAV.bin) really puts the VIC-II (and the encoder) through it's paces with bodacious use of color. Despite the exotic palette, most of it turned it out okay. It sounded fine in VICE, but on my C128, Snoop Dog had way to much base. Katy sounds fine. "California Girls" 16:9 aspect ratio
This is one of Hydro's favorites (http://sites.google.com/site/h2obsession/CBM/C128/images/cherish.bin), a dripping wet Madonna, "Cherrish". I don't know why it has such a low frame rate considering it is both gray scale and is smaller 4:3 aspect ratio. Also, it runs reliably in VICE (both NTSC and PAL), but has high likelyhood of failing to play completely on my C128. Annoying! Maybe you'll have better luck with a different setup.
Another Madonna video (http://sites.google.com/site/h2obsession/CBM/C128/images/fozen.bin). Not that I'm a huge fan, it just turns out her videos compress a lot better. Like Cherish, it is 4:3 aspect, and is gray scale, but it has a 2 to 3 x frame rate... go figure. Most of my videos have a 136 pixel height and the width varies according to aspect ratio (this to provide a consistant 2MHz area for good data bandwidth). However, I liked it so much, I decided to make a much larger, near-full-screen version (http://sites.google.com/site/h2obsession/CBM/C128/images/frozenLarge.bin)(I think 160x188 ... whatever was discussed many posts ago in this thread). Well I messed it up! First, it encoded it in color instead of grayscale, and second, I forgot to tell the encoder to use a lower bandwidth (lot less 2MHz loading). Interesting if embarassing.
Now Metallica is a band I like, unfortunately, I don't like most of their videos. Here is an exception (http://sites.google.com/site/h2obsession/CBM/C128/images/S93.5B-3LIKE.bin). King Nothing. I thought snowy atmosphere would be particulary appropriate for us in the northern hemisphere. Unfortunately, it didn't turn out as nice I would like. And this video also has a tendency to stop 3/4 of the way through (on my setup, runs fine in VICE). Grrrr. Oh, it's 4:3 aspect ratio.
This is probably my favorite video so far (http://sites.google.com/site/h2obsession/CBM/C128/images/S93B-4BLAH.bin). Poker Face. Although it doesn't have the fastest frame rate, it isn't the slowest either. More important, it has several scenes with rather different lighting properties, and the color turns out nice in nearly all of them. I actually have 2 versions, with ever so slightly different encoding parameters. One of them plays fine on my C128 and the other plays fine in VICE, but they fail to play about 50% of the time if played on the "wrong" system. Dunno why yet. If that one consistantly gives you trouble you can ask me for the other. 4:3 aspect ratio too.
Here is one in 16:9 aspect ratio (http://sites.google.com/site/h2obsession/CBM/C128/images/Stronger.bin). Stronger. Parts of it have an abnormally high frame rate because of simple black background. I'm not complaining, I like it. Note in this software, this still means a pathetic 4 or 5 fps. It's suppose to be color, but except for one scene (which is as Hydro's luck would have, features a dripping wet Britney), it turned out gray scale.
I got several more, but I think that should give you an idea of the range of what this can software can do with JiffyDOS. Of course there is still room for improvement in the video decoder and especially the encoder, but I wouldn't think it would be anything drastic to give you something like 10~20 fps. We need fast-serial for that (or some other hardware solution).
Sad thing is, I still haven't come close to filling my SD card... which is the entire reason (or at least a main reason) I started this project.
Edit 2
I just re-uploaded Media Player 128 (http://sites.google.com/site/h2obsession/CBM/C128/images/MediaPlayer128Alpha.zip) (4.7MB). It now includes some missing source files, an audio encoder, a video encoder, some batch files, and a lengthy read me explaining how to make your own videos. The encoders are Windows binaries. The player is CBM software and the player source can be compiled on just about any platform.
I'm away from my main C128DCR set-up right now until January 3. Then I'll try your program out.
Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
The Other Group of Amigoids
http://www.calweb.com/~rabel1/ (http://www.calweb.com/~rabel1/)
Southern California Commodore & Amiga Network
http://www.sccaners.org (http://www.sccaners.org)
I'm wondering if there's some place in your code for undocumented ops, especially in your timing sensitive portions.
For example, looking at some of your sources I noticed stuff like this:
jIRQ2r3.src
lda myVicY+1 ;[4] get y_scroll and stuff
and #7 ;[2] mask y_scroll
clc ;[2]
adc #constC ;[2]
adc vHeight ;[4] rasters in video
With respect to the AND / CLC sequence above, would it be desirable/useful to save 2 cycles with "ANC" instead?
If not, then how about elsewhere? How about with other "illegals" like LAX, SAX, which seem to work solid on 128s (IIRC)? ...
This page seems to describe ANC nicely : http://codebase64.org/doku.php?id=base:some_words_about_the_anc_opcode
65816 accelerator compatibility? who cares!? =)
XmX
PS: This was amusing for me as well .. http://codebase64.org/doku.php?id=base:decrease_x_register_by_more_than_1
Quote from: XmikeX on January 01, 2011, 01:32 PM
65816 accelerator compatibility? who cares!? =)
Already tried, doesn't work in SCPU turbo mode :-/
I look forward to your feedback, RobertB.
Thanks for the report, redrumloa :) It doesn't suprise me, it was only designed / tested for a stock 8502.
I hadn't thought about undocumented opcodes... the code you mentioned, XmikeX, isn't very critical... the critical part is in the 1MHz load data routines... in particular that fü¢king Byte_B ... oh what a pain... but without it, 1MHz loader would be reduced by 50%...
If you've ever had the player stop in the middle of a video (very annoying), it is probably that Byte_B code ... I'll take a look at using some undoc'd opcodes to see if I can fix that problem...
New Download for VICE Users (http://sites.google.com/site/h2obsession/CBM/C128/images/mp128a-vice.zip)(2MB)
I just realized that normal VICE will not run JiffyDOS on the 1581. Silly me, I forgot I was developing with a mod version of VICE that implements missing features of the WD1770 chip. ::)
So for VICE users, I made a new download that includes a modified version of the 1581 JiffyDOS ROM. The only thing changed is in the comparison of the CRC code. For some reason, the CBM and JiffyDOS ROMs manually calculate the CRC and then compare it with that of the WD1770. VICE will "magically" skip this part of CBM ROM (because VICE doesn't implement CRC in the WD1770), but it does not do it for the standard JiffyDOS ROM. Anyway, the modified JiffyDOS ROM simply ignores the CRC value.
Here's step by instructions for VICE users:
1. Download and unzip the VICE version of Media Player 128 Alpha (http://sites.google.com/site/h2obsession/CBM/C128/images/mp128a-vice.zip)
2. Start VICE and be sure Options>True Drive Emulation is selected
3. Go to Settings>ROM Settings>Drive and for 1581, change the file to "Jiffy-1581-mod.bin" (be sure the path is correct for wherever you un-ZIP-ed the file)
4. Go to Settings>Drive Settings, and set device 8 to a 1581
5. (Now you're ready) Attach the player disk, "mp128a-vice.d81" to drive 8
6. Enter RUN"*
That should start the BASIC part which will load the JiffyDOS handler and the MPlayer ML code.
When it asks for unit and drive, just press RETURN (accept default unit 8 and drive 0).
Next it will ask you for a filename. On the same disk is a video of "Single Ladies" so just enter "video.bin" and it should play ;D
Also included in the ZIP file is 2 more D81 images, with 1 video each; PokerFace.d81 and Somebody4Me.d81. After watching the first video, you can attach either one, and then when it asks for a filename, just enter "MYV.BIN"
Unfortunately, none of the videos fit on a 1581 disk, so they will stop when they reach the last sector on the disk ... it should be obvious because the video will stop and the audio will go into an infinite loop; just press STOP to return to the BASIC program and you can play another video.
Also, I want to appologize / explain about the flashing border. It is quite annoying! But it is for debugging purposes. Here is what the colors mean:
- Light Green - loading data and playing audio
- White - working hard - loading data, decompressing video, and playing audio
- Black - blocked - playing audio and decompressing video, but can not load the next video packet
- Blue - blocked - playing audio, maybe decrompressing video, but can not load the next audio packet
- Red - corrupt data discovered - this will happen at the end of the video (because it won't fit) or maybe due to a coding error by me
- Other color - not fully anticipated / coded exception - the player will usually continue (very rare)
If any VICE users have trouble, let me know. The videos should play in both NTSC and PAL modes. You may want to change the filter setting for NTSC to a larger value. The ML part normally sets it to a larger value for NTSC, but the BASIC companion destroys that optimization so you probably want to set it manually (something like 150) if using NTSC emulation.
EditI just wanted to add that the JiffyDOS code is *critically* designed for stock 1MHz/2MHz operation... there is no way it will ever work at accelerated speeds; However, in the new year, I look forward to implementing fast-serial drivers. Being hardware based, they should be CPU-speed independant, so there is a chance it may work on a SuperCPU (keep your fingers crossed).
Edit 2Anyone with a real C128 or who wants to make their own video should download the full Media Player 128 Alpha (http://sites.google.com/site/h2obsession/CBM/C128/images/MediaPlayer128Alpha.zip). I would love to see any video you make! If you don't want to put your video out on the WWW, at least PM or Email me... thanks and Happy New Year!
Edit 3I've posted several color images before, but they were I-Frames (high quality). The actual video uses P-Frames (lower quality) a lot so I thought I would post some of them. Many of the color frames suffer problems because, not only is the I-Frame encoding not yet as good as it is for gray-scale, but the P-Frame encoder was never optimized for color... in fact I'm suprised that color works at all!
Just think how much fun you could have if you got one of those Chameleon carts (when they come out), more CPU power and more colours to play with :-)
I think having a CPU speed agnostic fast loader would be a good thing as well.
Nice work, thanks for sharing!
And if he did it on a PC he'd have even more CPU power and colors...
Isn't the point of this to try to implement a media player on the C128 with its inherent limitations? Using something like the Chameleon would defeat the whole purpose in my opinion.
I am completely ignorant of Cameleon, but if somebody wants to adapt the software for it, I provided the source, so have fun!
Also, I changed my mind, and now plan on NOT using undocumented opcodes. This is so hopefully it can run on SuperCPU. Of course that could be considered cheating too, but it was released back in the day, so I would like the player to work with it, if possible.
redrumloa reported MP128 doesn't work on the SuperCPU, and a major reason would be because the JiffyDOS software requires 1MHz operation. Searching the forums, I only found this thread (http://www.commodore128.org/index.php?topic=3625) which had no responses.
So, can somebody confirm that you can set the SuperCPU to 1MHz with POKE 53370,0 ? That seem's dubious to me, because that is $d07a -- somewhere in the VIC I/O region, but I guess anything is possible with a hardware hack lack the SuperCPU... Thanks!
Of course I still plan to add fast-serial support which should negate the software-load issue, but until then a little tweak like this would be useful.
Also, I would like to thank everyone who downloaded and tried Media Player 128 (the limited VICE version (http://sites.google.com/site/h2obsession/CBM/C128/images/mp128a-vice.zip)or the full version (http://sites.google.com/site/h2obsession/CBM/C128/images/MediaPlayer128Alpha.zip)), and would love to hear your opinions. Actually, I was expecting a bunch of "that's crap" comments and (maybe) some "that's cool" comments. So far it seems like the opinion is "whatever".
So if I can make a request, could you let me know if you try it, and what setup you used (VICE, real NTSC, real PAL, C1581, uIEC, CMD HD, etc.) Thanks again!
Although I think it should work as-is with CMD-HD and uIEC (and JiffyDOS C1581), I was curious about 64HDD. Has anybody tried it? There is a thread somewhere about experiences with 64hdd, and it is noted it supports fast serial, but no mention about JiffyDOS. When I check the website, it says Tolerent** and ** says "LPT port latency is critical. My personal experience suggests that many fast loaders lose synchronisation"
Quote from: Hydrophilic on January 14, 2011, 12:17 PMredrumloa reported MP128 doesn't work on the SuperCPU, and a major reason would be because the JiffyDOS software requires 1MHz operation.
The SuperCPU has a switch which disables its built-in JiffyDOS.
FCUG celebrating 30 years,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
Quote from: Hydrophilic on January 14, 2011, 12:17 PM
I am completely ignorant of Cameleon, but if somebody wants to adapt the software for it, I provided the source, so have fun!
It's an FPGA implementation of the C64 with an accelerated processor (don't know if whether they've implemented a 65816 of if it's jus a sped-up 6510) and VGA out, in cartridge form, so you plug it into the expansion port of your C64. Not sure if it takes over all the C64 functionality or if the SID is still used for sound, but at least the VIC and processor is in the FPGA.
Quote
Also, I changed my mind, and now plan on NOT using undocumented opcodes. This is so hopefully it can run on SuperCPU. Of course that could be considered cheating too, but it was released back in the day, so I would like the player to work with it, if possible.
The SCPU 128 was released in the late 90s. That's not what I consider "back in the day". On the other hand, I don't consider anything cheating; it's your prerogative as the developer to do whatever pleases you. I just had the impression that you wanted to implement this on a stock C128.
Thanks for the info about the Chameleon. Would it even work with the C128, in 128 mode of course?
You are right bacon, I would like it to run on a stock C128 becuse that is all I've got... but it would be nice if it could run on a 65816... using undoc'd opcodes could shave a cycle here or there, but the main problem is JiffyDOS is software based and hogs a lot of CPU power.
Also, I reread redrumloa's post, and it says it MP128 doesn't work in turbo mode... so it works with SuperCPU at 1 and 2 MHz speed? That would be cool if true.
There are about half a dozen things that need to be improved, so any feedback to help me prioritize things would be appreciated. Thanks!
Quote from: Hydrophilic on January 14, 2011, 12:17 PM
So if I can make a request, could you let me know if you try it, and what setup you used (VICE, real NTSC, real PAL, C1581, uIEC, CMD HD, etc.) Thanks again!
I was trying this on my C128D with UIEC (but NO Jiffy DOS). I think I got about 1 fps out of it. Would a faster drive produce more fps? Maybe you can utilize REUs? Using DMA-access they are blazingly fast.
Thanks for the report, tokra. The uIEC implements JiffyDOS protocol and MP128 has JiffyDOS drivers so it should work (no JiffyDOS ROM is required in the C128).
A new driver to support fast-serial hardware is planned, and it should dramatically improve frame rate.
The frame rate is all over the place! Whenever the camera moves, or zooms in, or there is a lot of action, the frame rate drops to about 1fps. When the camera is still, and there is moderate action, frame rate is about 2 to 4 fps. If there isn't much motion at all (camera and actors relatively stll), it goes much higher. Kind of a waste of disk space... not really, those frames compress about 99%.
I don't have an REU, but I agree, it would help, because the video decoder relies exclusively on Copy and RLE. Both of which an REU is good at doing. However it might not help as much as you might think, because most of the copy sequences are short (maybe 4 bytes average). Setting up the REU registers for such a short job might not pay off...
Oh no, I just thought of another problem: the REU can't do long sequences because the IRQ must constantly play audio samples. Well, I guess you could limit the REU to say, 30 to 40 bytes...
Anyway, you would still need a way to sync the REU with the IRQ... tricky stuff!
I think in the short term, best way to improve the frame rate is to improve the encoder. Besides being optimized for grayscale and not color, it only does small vertical motion detection. Unfortunately, a lot more motion is horizontal!
If you're familiar with VIC-II bitmaps, you probably know why I started with Y-shifts and left X-shifts on the TO-DO list :P
Another idea is to use char-set emulated bitmaps. This can radically reduce the amount of data the CPU needs to process, but puts strict limits on video quality. Still, this is very promising and something I plan to work on soon.
Oh, tokra, are you using PAL or an NTSC machine? Anyway, thanks again for your feedback!
Just tried it for the first time, through VICE... really cool! Impressive that you've been able to accomplish so much on a 20+ year old machine, video AND sound! Of course the framerate is slow, but eh. Still neat. What would be the ideal setup that is currently usable? uIEC NTSC/PAL 128? Would 128D or REU make a difference yet, or would those not (yet?) make a difference? Great work :-D
Thanks for your feedback, saehn! There is really no optimal setup, as this is still alpha software with no specific optimizations. Well, a mass-storage device like uIEC or CMD-HD is highly recommended because C1581 has space for only the shortest videos (all the videos I released in .d81 format are cut short).
Anyone with a CMD-HD or C64HDD to report results, I would appreciate it!
Now that I think about it, PAL has a slight speed advantage due to larger border = more 2MHz time. But the video is (loosly) locked to the audio which is (strongly) locked at approximately 7843 Hz, so there shouldn't be much difference between NTSC and PAL.
The sharp reader may have noticed I said approximately 7843 Hz. This is the sample frequency used to encode the audio, but the player will actually be off by a few dozen Hz depending on national standards. It should play at 7819.4 Hz on PAL, or play at 7867.2 Hz on NTSC.
In other words, NTSC would run about 0.6% faster than PAL. See? Not much difference. Another way to think about it is NTSC videos will be 0.3% too fast and PAL videos will be 0.3% too slow. As an example, a one hour video would be off by about 11 seconds (plus or minus, depending on PAL or NTSC standard). Note this is just a calculation... I haven't made any 1 hour videos to verify this value!
Quote from: Hydrophilic on January 18, 2011, 10:49 AM
Oh, tokra, are you using PAL or an NTSC machine? Anyway, thanks again for your feedback!
I'm using a PAL-machine. Do you think something like the Media Player could work on the VDC chip as well? I know accessing it through the registers is very cumbersome, but maybe the 2 Mhz-mode would alleviate that.
Thanks for the feedback! Nice to hear it works on real PAL. Video on the VDC would be a neat trick. With JiffyDOS, you still could not have full 2MHz capability, but you would still have a lot more CPU speed than with VIC. I don't think that would compensate for the slow VDC RAM access, but it would be interesting to try...
Note that JiffyDOS was just an easy way for me to test the concept. Well, maybe not easy (look at the source code, it's a nightmare). Anyway, I'm working on fast serial routines which should help the frame rate a bit...
Unfortunately, 2MHz mode â€" while it would aid enormously in unpacking the frames and sorting out the data â€" would not help in transferring that data to the VDC RAM, which AFAIUI operates at circa 1MHz regardless. That's why that one register has a status flag in it to say when the VDC has finished its operations and is ready to have its registers twiddled some more, and why ignoring that bit causes data to go missing.
Hydro, I assume you've seen this over on the Lemon forums? :)
http://www.lemon64.com/forum/viewtopic.php?t=36998&highlight= (http://www.lemon64.com/forum/viewtopic.php?t=36998&highlight=)
No I haven't. Thanks for the link. Man, that guy has got the color down pat! I don't see how the VIC can do that... gonna have to take a peek...
As I understand it requires a 1541 Ultimate which can transfer data at REU-like speeds... quite a bit more than a 1581, CMD-HD, or uIEC can cope with... on the other hand, wuz up with the audio? If you got that much bandwidth, why wouldn't you have 4-bit (or 8-bit) audio samples... guess all (well most) of the bandwidth is going to the VIC...
But still don't see how the VIC is doing the color... sprites under bitmap? urrr... this is gonna bug me till I find out.
EditTrying to find out more about this software, I search on CSdB for 'nuvieplayer' and #118874, but get "We're terribly sorry" message. Really strange that links through CSdB can't be found; maybe because it is hosted on sourceforge (http://jsidplay2.sourceforge.net/) ? But still... bad index, very bad, bad index...
Edit 2The link above takes you to possibly related Java SID player... but searching there turned up nothing about the nuvie player... is this a case of vaporware ? I did download the 'player' from lemon, but without any media files (or a 1541U), I dunno how useful it will be...
Edit 3Returning to CSdB, a search for "video player" also turned up 0 results. Me thinks their search no worky... I mean there has gotta be a video player of some sort for C64 right?
Sing along if you know the words:
Quote from: Aerosmith
There's someting wrong with the world today
The lightbulb's gettin' dimmed
There's meltdown in the sky
The player as well as demo-files are both linked in the original post on Lemon:
http://noname.c64.org/csdb/release/download.php?id=118874 (http://noname.c64.org/csdb/release/download.php?id=118874)
http://www.megaupload.com/?d=TEEZ58TC (http://www.megaupload.com/?d=TEEZ58TC)
The player is included in the megaupload-archive as well.
Haven't tried this myself yet, but looks pretty impressive...
Ooh, I missed the mega-upload. Now that you posted it, I remember seeing it... PARITY ERROR. Thanks, I'll give that a look!