Topic: CBM Encoder

[Hydrophilic]

I imagine some people enjoy writing a GUI app, but not me.  Seems like you have to write 4 or 5 or more routines for every element of a simple command line program.  Not to mention time spent to actually design the interface ( layout, images, etc.).  So although it has taken a bit longer than I wanted, at least I have made some progress I can show.
 
I am talking about graphical user interface for the command-line encoder that was included with Media Player 128 (beta).  Although MP128 can play some 'foreign' files (like 8-bit .WAV and .AIF), it requires a (large) REU.  For other devices (like 1571/81/CMD-HD), the files need to be converted to a CBM 'native' format (such as 4-bit audio or VIC-II bitmap).  I've attached a few screen shots for anyone to comment on.
 
The first is the 'Make' dialog that accepts various arguments for the audio/video file you would like to convert for playback on C128 (possibly C64 or others).  I have not added any new features to the encoder yet.  You can see the 'Make' dialog is a bit complicated, as it reflects the many arguments that are possible with the command-line version.  In fact, some of the options are disabled (grayed out) because I haven't written GUI windows for everything yet (for example, the Video Settings... which allow you to adjust things like brightness, contrast, hue and saturation).
 
The second screen shot is the main window at 1024x768 size.  It can be resized to fit your needs.  Oh yeah, the app does not use any fancy features like DirectX or .Net framework, so it should run on any 32-bit Windows or newer (including Linux Wine).
 
Anyway, at the top you have standard menus and tool bar.  Just below them are two windows.  At the left is a little bar graph that shows the encoder's current time within the audio/video (it is currently working on frame 128 which occurs at time 00:31.75 in the original video).  The very wide white box that stretches all the way to the right will show 'future' video frames that encoder is considering... the so called 'look-ahead' buffer.  The original encoder did not use a look-ahead buffer, so this area is blank for now.
 
Below the encoder information are several windows on the left side that represent the current state ("now") of the decoder (i.e., the state of the C128 at a specific point in time during playback).  At the top is the audio playback time (currently playing audio sample 249567 at time 00:31.93 in the output file).  Below that is the state (fullness) of the audio buffer (currently 92% full, $eca bytes out of $1000).
 
Streching all the way to the bottom is a view of the decoder's frame buffers.  These are the images in the C128 memory that have already been loaded.  One of them is being displayed for the user at any given time (in this case, the very last one).  For each video buffer, you can see the VIC-II conversion of the frame, its location in C128 memory (bank 1), the compressed size, and compression ratio.  For example the current (last) frame is based at address $a000, it is encoded with 1175 bytes which is a compression of 79%.
 
Although this layout is 'logical' in that it shows the C128 frame buffers in the same order they have in RAM, it is not very meaningful to the user or the encoder.  For example, you wouldn't know that the last frame is the one being displayed 'now' had I not told you.  I'm going to change this so it shows the frames in MRU order.  That is, Most-Recently-Used order.  So for example, the last image ($a000) would appear first, followed by the previous frame, (two images above in the screen shot at $6000), followed by other prior frames (for example, the next-to-last frame at $8000 actually occurred several seconds in the past).
 
Oh yeah, to the right of that is the big 'main' window which just shows a text-file version of the 'Make' parameters.  These can be saved to a file so you can easily re-encode a video by tweaking some settings if you are not happy with the way it plays on your C128.  This is very similar to writing a batch file to call the command-line version.  But hopefully I will find the time to add some real-time refinements... for example a line could be added like

Code: [Select]

@t 01:22 vin_contrast = 1.25
which would increase the contrast of the video starting at time 1:22 of the video (presumably it was different at the start of the video).  The idea is to improve quality of scenes that encoder does a bad job of encoding (or perhaps the source video was not very good at that scene).
 
If everything goes well, I should find the time to add some VDC encoding options.  For example, I released a command-line VDC image encoder for use with Tokra's 8x2 video mode.  Well that was actually derived from the MP128 encoder.  So it shouldn't be much effort to put it 'back' in to this new version.  I also want to try VIC-II text modes for image encoding.  If that works well (and time permitting) I might even try a VDC text-based video.  Ha, ha, ha!
 
Although this is all very preliminary, at least it is making videos now.  The final attachment is from VICE which shows a screen shot from the video a few seconds later.  Hello Europe!
 

[RobertB]

I am talking about graphical user interface for the command-line encoder that was included with Media Player 128 (beta).

     At Sunday's FCUG meeting, the members appreciated the clean-looking GUI and the drop-down menus.  What we couldn't understand was when we used a disk with no media files on it and when we clicked on INFO, the GUI just kept printing INFO in a column (i.e. INFO.. then a few seconds later, another INFO... and so on) on the left side of the screen.

          Truly,
          Robert Bernardo
          Fresno Commodore User Group
          http://videocam.net.au/fcug
          July 28-29 Commodore Vegas Expo v8 -
          http://www.portcommodore.com/commvex

P.S. I just thought of an ideal media file for Media Player 128... how about a special effects scene from Babylon 5?  In the first 3 years of B5, Amiga computers with Video Toasters created the outer space scenes.  How interesting it would be that a C128 would play such a scene created on an Amiga!

[Hydrophilic]

Yeah INFO does nothing in MP128.  The idea was to show the file statistics (video mode, audio mode, play time etc.) with actually playing the file.  I just never finished it.... I really should have removed it before releasing it.
 
I'm glad somebody appreciates the UI.  Given the general constraints of BASIC and the reduced memory (due to the ML player), I had to make a lot of comprimises in the design.  So I am a bit suprised (but pleased) to hear your report.  Maybe someday I'll find the time to port the UI to ML.
 
Babylon 5... I really liked that series.  Besides the story, it had lots of cool space battles and special effects.  It made Star Trek TNG look a bit lame in comparison.  The fact the CGI was done on an Amiga still boggles my mind.  So let me find something for a video clip....
 

[RobertB]

Besides the story, it had lots of cool space battles and special effects.  It made Star Trek TNG look a bit lame in comparison.

     I remember at a B5 convention they showed a reel of the various sfx/space battles.  Very interesting, considering all the variety they had. 

So let me find something for a video clip....

     Thanks!

          Back from yesterday's TOGA meeting,
          Robert Bernardo
          Fresno Commodore User Group
          http://videocam.net.au/fcug
          July 28-29 Commodore Vegas Expo v8 -
          http://www.portcommodore.com/commvex

[Hydrophilic]

Progress is slower than I imagined.  But it always is... I am too optimistic.  Imagine things will go faster than I should know better.
 
I have made a total mess!  Originaly designed to work for VIC-II, re-enginered for VDC, and now re-re-desgined with a GUI.  The GUI started simple working with VIC-II images, but I also wanted it to work with VDC images... just to see what is possible.
 
Unfortunately, the VIC-II / VDC code (two seperate programs before) lay in the middle of the encoding hierarchy (sp?).  So to get CBM Encoder working I have to work from the middle out!  I am sure programmers out there know the fun (or not) of bottom-up programming or, the opposite, top-down programming.  If you've ever had to do middle-out programming (for example, step into position of vacant programmer), then you know how much fun this can be!!     /end sarcasm
 
Right now I have structure like this:

Code: [Select]

CBMencoder {
   SidEncoder audio
   CBMfBuff video {
      CBMframe input[];
      CBMframe output[];
   }
}

where
 

Code: [Select]

CBMframe {
   CBMimage* img;
   double timeStamp;
   byte* decoRAM;
}

If you understand C(++) then that might actually make sense.  The important thing is that CBMframe uses a polymorphic class of CBMimage... this gets defined by the user based on GUI / command-line input.  It can be (for now) either a VIC2image or a VDCimage.  Although I've written many C classes, this is the first time I've had to write a polymorphic class (although I use them often).
 
This would be simpler if CBMimage were at the bottom of the heirarchy, but it is in the middle...  It uses ILRimage, ILRwork, and 'out' classes as 'lower' classes.  The ILRxxx classes are generic classses used directly by CBMimage, but 'out' is polymorphic... depending on if it is 'inherited' by VDCimage or VIC2image.
 
Well that situation might seem familiar to C programmers out there.  Anyway, that is where things are at now... in a HUGE state of transition.  I also recently realized that (shock!) the encoder is only going to work for C64 / C128 because the related 'audio' class is strictly defined as 'SIDencoder'.  In other words, despite all the effort to make the encoder generic / multi-platform, it will do no good for Plus/4 or VIC-20 (for example) because the video is tied to a specific audio chip...
 
Well I guess I got to fix that soon...
 
In the meantime, I've viewed quite a few Babylon 5 videos on YouTube and found one I like.  I'll try to get a CIF video (for MP128) up by the weekend.  Then I can post newer version later so you folks can see if there is any improvement...
 
Later!

[RobertB]

In the meantime, I've viewed quite a few Babylon 5 videos on YouTube and found one I like.  I'll try to get a CIF video (for MP128) up by the weekend.  Then I can post newer version later so you folks can see if there is any improvement...

     Heh, if you finish it up quickly, we could view it here at CommVEx.

          Writing from the Beat Coffeehouse in Las Vegas,
          Robert Bernardo
          Fresno Commodore User Group
          http://videocam.net.au/fcug
          July 28-29 Commodore Vegas Expo v8 -
          http://www.portcommodore.com/commvex

[Hydrophilic]

Well I just tried encoding the video and it turned out terrible   As much as I enjoy bashing my lame 2-bit audio, it was the best part of the video.  Most of the frames turned out as a garbled mess.  I've seen the original, but even knowing what to expect, I find it hard to decipher the images on the C128.  So it's FAIL.
 
I was quite surprised considering many of the space scenes have simple palette: lots of black, some gray, and maybe a touch of blue or yellow.  There were also some in-space-station scenes and they turned out pretty bad too.
 
I have a bunch of music videos I haven't released because of some mild quality issues, but this video makes them look good.  It is that bad.  If it were only mediocre I could try tweaking some settings, but it is just awefull and no amount of tweaking would make a major effect (I assume).
 
I'm suprised because the video seems rather simple and about the same complexity as most of the music videos I have done.  But it seems my human perception does not match that of my software.  Well, that is the main point of this project: to improve the video quality.  It seems I have a lot of work ahead of me.
 
So I'm off to fix it.

[RobertB]

Well I just tried encoding the video and it turned out terrible    

     

          Writing from CommVEx,
          Robert Bernardo
          Fresno Commodore User Group
          http://videocam.net.au/fcug
          July 28-29 Commodore Vegas Expo v8 - 
          http://www.portcommodore.com/commvex

[Hydrophilic]

It's been a while since I posted to this thread because I've been busy working on the app.  So this is just an update and some information that may be usefull to programmers in general.  Oh yeah, this is a lengthy post so I've broken into sections for you (skip it completely if you are in a hurry).
 
General
 
I've re-written the base image class to be completely generic, and now images are handled by derived classes specific to a particular CBM video chip.  Right now only VIC-II and VDC are implemented, but the possibility for VIC-I and TED (and whatever the PET uses) should be possible too.  (More about TED later).
 
I've got the look-ahead buffer implemented, and so far it seems to be working acceptably (it could use some tweaking).  Unfortunately because the decoder was (previously) closely tied to the input image format, the app is no longer able to produce any videos... look at the attached screen shot and compare with the previous.  You should see now the look-ahead buffer is working (set of images across the top) but there is no output (missing images on the left).
 
So it's 1 step forward and 0.9 steps back.  These things ALWAYS take longer than I imagine...
 
For Users
 
Normally the app would just run through the input frames and spit out CBM-encoded frames automatically but you can also "micro-manage" your video by stepping through input frames and/or output frames.  In the example shown I am stepping through the input frames and opened up one just to show what kind of control you can have (and what semi-useless infromation you can gain).
 
BTW, you can also convert one or more images from BMP/PPM format to CBM format (Doodle, Koala, GEOS, "tokra", etc.) without making a video.
 
Anyway, I wanted to describe the input properties window so you guys can question/criticise the design (see attached image).  At the top is some basic information like source image filename, time index, size, and some other criterea (described below).  On the left are several sliders to adjust the image properties and on the right is an actual view of the SOURCE image (not converted to CBM format yet).  Below the image are several statistics related to the image.
 
When you first open the window, it shows statistics for the entire image.  But using the drop-down menu at the bottom left (and associated Index values) you can "drill-down" to more refined statistics.  Such as the average for an entire "macroblock" row, or column.  Macroblock is the MPEG terminology.  I think character cell, or simply cell, is more common in CBM literature.  Well normally it would be a character cell for a standard VIC-II mode (for example 8x8 pixels high-res or 4x8 pixels multi-color).  But with chips like the VDC where you can program the size, a macroblock might be only 8x2 pixels.  I hope you understand   Anyway, you can drill-down to the individual macroblock level.  If you look closely at the drop-down menu, you can see besides "rows" and "columns" there is also "novette" which simply divides the full image into 9 sub-blocks (a 3x3 grid).
 
This statistical information is not just for your amazument, but is used by the look-ahead buffer to classify frames into a scene and angle.  Hopefully this will improve quality of the output (remains to be seen!).  So at the top you can see which "scene" the image is associated with.  Also there is a "score" which is an arbitrary (under developement) value assigned to the current image relative to the best-matching image in any buffer: either the look-ahead buffer or the actual output buffer (images currently stored in the C128 during playback, see previous post).
 
If you take another look at the screen-shot, you can see I've adjusted the Luminance Scale from the default of 1.0 to a value of 1.2.  This makes the scene a bit brighter, but if you look at the statistics you can see this also resulted in some clipping.  That is, the maximum is limited to 255 but some values went over the limit and were clipped.  There are a few hundered clipped pixels, but considering there are several thousand pixels in the image, I think it is acceptable (believe me, it looks better this way).
 
The controls shown correspond with controls on many TVs (and some monitors) like this:
Luminance Scale = Contrast
Luminance Bias = Brightness
Chroma Scale = Color
Chroms Bias = (none)
Hue = Hue
 
As an example, I adjusted the "contrast" to improved the total range of luminance. As another example (not shown) you could adjust the "hue" to make Britney look like a green Martian instead of a pink Earthling... that's silly in practice, but fun to try!
 
Oh I almost forgot, if your source video has a higher frame rate than your output video then some frames will obviously need to be skipped.  For example, if you are making a video for the fast-serial bus of the C128 at the not-so-amazing rate of 4 frames/second but your source video is 24 frames/second, then obviously only 1/6 frames will be included.  In other words, 5/6 frames will be skipped.  If you look closely at the screen shot, you can see there is a little check-box for "skipped".  This tells you if a frame is destined to be omitted from your video... and you can slap the encoder in the face and make it include a specific frame if you want (which will likely cause other frames that were scheduled for inclusion to be omitted).
 
Also note that "skipped" frames are different than "dropped" frames.  A skipped frame is one that occurs too soon relative to the previous frame (based on your selected output frames/second), while a dropped frame is one that should be included in your video but due to bandwidth limitations (and poor compression of a particular frame) the image is not (can not be) included in the output.  I hope that makes sense because I don't know how to describe it better!
 
For Programmers
 
If you've read this far, then congradulations!  If you just skipped to this section, you must be in a hurry so I'll shut up and get to the point(s).
 
One serious programming issue is converting images from 16/24/32-bit format into a format for CBM computers with effeciency (and obviously good although not neccessarily perfect accuracy).  This has been previously discussed by tokra (his various threads on VDC images) and by me in previous threads of Media Player (forum Search is your friend).
 
I want to point out a mistake I made before and what I believe (now) to be correct.  So previously I had stated that for high-resoultion VIC-II mode (or equally VDC) that a cell with 2 colors from a palette of 16 would have 240 possible combinations (16*15).  I said 16*15 to omit duplicates, but that is still not right!
 
Also looking into some math texts, the number of combinations might be defined as "nCr (16,2)" which could be expressed as:
 
16! / 2! / (16-2)! = 120
 
Where ! is the factorial operator... n*(n-1)*(n-2)...*1.
 
But you know what??  Neither 240 nor 120 is correct!!  The correct answer is 136 (please correct me if I'm wrong).  And here is why I think so...
 
Imagine you only have 4 colors to choose from.  For example BLACK, RED, GREEN, and BLUE.  Of course they could be ANY four colors so I'll just call them 1, 2, 3, and 4.  Now imagine you want to choose the two best colors to use in character cell (or macroblock).  Here is a listing of possibilities (duplicates omitted):
 
1,1
1,2
1,3
1,4
(2,1 omitted, duplicates 1,2)
2,2
2,3
2,4
(3,1 omitted, duplicates 1,3)
(3,2 omitted, duplicates 2,3)
3,3
3,4
(4,1 omitted, duplicates 1,4)
(4,2 omitted, duplicates 2,4)
(4,3 omitted, duplicates 3,4)
4,4
 
That's a total of 4+3+2+1 = 10 combinations.  Expressed as a formula:
 
n * (n+1)/2
 
where n=4.
 
And so if you change n=16 you get:
 
16 * 17 / 2 = 136 combinations
 
If you don't believe my text, maybe this ASCII graphic may help (n=4)

Code: [Select]

a \ b | 1 | 2 | 3 | 4
 1    | * | * | * | * |
 2    | * | * | * |   |
 3    | * | * |   |   |
 4    | * |   |   |   |
All the blank spots in the "diagram" are duplicates.  There are obviously 16 cells, and if you count the occupied (not duplicate) cells there are 10 (just as stated previous).  Well I guess this does not mathematically prove anything.  But it is now what I believe to be correct and would appreciate any/all comments on the subject.
 
More importantly is when you get into multi-color mode of the VIC-II (and also TED, but with differences described later) which can have 4 (instead of only 2) colors in a cell.  The above equation, n * (n+1) / 2, is not something I invented but is well-known in mathematics (if not to programmers in general).
 
I compiled a table that used only 3 (instead of 4) colors (out of a total of 16) and came up with a mysterious number of 816!!  Researching a few math texts, I did not find any equation that would explain this.  Through trial and error, I eventually came up with this formula:
 
n * (n+1) / 2 * (n+2) / 3
 
Which equals 816 in the case of n=16.  I applied the formula to n=4 and compiled a table (n=4 because it is a small table) and got the correct result, so my forumla seems to be correct.  So if you have any math intuition, it should be obvious that case of 4 colors should have a formula of:
 
n * (n+1) / 2 * (n+2) / 3 * (n+3) / 4
 
Well it took a while (and some help from Mr. Computer) to compile a table that gives a result of 3876 combinations of 4 colors (from a palette of 16, again).  Because my "discovered" formula works with the results of my tabulation (and also a "verify" trial of fewer than 16 colors), I believe this is correct.
 
It should be obvious that it would be quite time consuming (i.e., wastefull) to try all 3876 color combinations for each character cell in a video... so my idea is to index the combinations and choose the closest one.  And then try a few combinations that are +/- 1 the choosen index... so maybe 3*4 = 12 combinations for each character cell.  Testing 12 combinations will be a LOT faster than testing 3876 combinations.
 
Which brings me back to TED.  It has far more than 16 colors in its palette.  121 to be exact.  So for high-res mode, each cell can have a combination of 121*122/2 = 7381.  That's almost twice the VIC-II multi-color mode.  But then with TED multi-color there would be 121*122/2*123/3*124/4 = 9 381 251 combinations!  Assuming each index consumes 4 bytes (assuming 32-bit computer) that would result in an index size of 35.786 MB!!  Of course RAM is cheap on modern PCs, so ~36MB is not a big deal, and with a binary search it should not take very long to locate a value in the index... for a single cell... but there are 1000 cells in a full screen and many many screens to make a video... so I think I will need another method if I ever want to support the TED in multi-color mode.
 
And of course the TED problem is also related/similar to software modes of the VIC-II (FLI, IFLI, etc.)... not that I think I'll have the time to ever implement any of that... just pointing out the programming possibilities.

[RobertB]

...the possibility for VIC-I and TED (and whatever the PET uses) should be possible too.

     Unless a PET high-resolution graphics board was uninstalled, the PET relied on the keyboard character set.  Mike Hill's PETvideo runs video at pretty good FPS, albeit with the use of keyboard characters.

          Truly,
          Robert Bernardo
          Fresno Commodore User Group
          http://videocam.net.au/fcug

P.S. Look for a future Blip.tv video of Mike Hill's presentation at CommVEx 2012 in which he demonstrates PETvideo.

[Hydrophilic]

Cool, I look forward to it.  I saw in some video clip, a glance at a vintage computer playing some video, although it was rather brief so I don't know what model it was... don't think it was a PET.
 
I was hoping somebody would have commented on the number of color combinations... like maybe my results should be obvious from such-and-such math theorem.  The problem reminds me of the binomial theorem, but it seems a bit different... I also read about something called a multinomial, but it is used for calculating probabilities in a set number of trials.  I guess it is somehow related to the topic, but the equation was quite a bit different then discussed above.
 
Anyway, I've been coding a color index for faster performance of the video encoder and discovered that the values posted above are still wrong for my purposes.  Specifically, above I was calculating the number of possible combinations of pixel pairs (hi-res) or quadruples (multi-color).  But for assigning a set of colors to a bitmap cell, the problem is subtly different.
 
So lets compare.  Imagine a video chip that can display any two colors in a cell from a palette of four colors.  I'll call the colors 0, 1, 2, 3 for typing easy but you could imagine them as BLACK, RED, GREEN, and BLUE.  So here (again) is a list of possibile pairs, with duplicates noted:
 
0,0
0,1
0,2
0,3
1,0 (duplicate)
1,1
1,2
1,3
2,0 (duplicate)
2,1 (duplicate)
2,2
2,3
3,0 (duplicate)
3,1 (duplicate)
3,2 (duplicate)
3,3
 
As previously described, this is n*(n+1)/2 unique combinations of colored pixels.  However for the problem at hand (using an optimal index table of color palettes), what is really needed is the number of unique cell palettes.  So look at the first entry in the table above: 0,0 which could represent BLACK, BLACK.  Although that is a unique pair of pixel colors, it is not needed in a table of palettes.  For example using a palette of 0,1 (BLACK, RED) you could still produce a pair of BLACK pixels (just never use RED).
 
So in terms of a cell palette, the unique combinations would be:
 
0,0 (duplicate colors)
0,1
0,2
0,3
1,0 (duplicate set)
1,1 (duplicate colors)
1,2
1,3
2,0 (duplicate set)
2,1 (duplicate set)
2,2 (duplicate colors)
2,3
3,0 (duplicate set)
3,1 (duplicate set)
3,2 (duplicate set)
3,3 (duplicate colors)
 
Wow, only 6 color palettes need to be indexed.  The formula for number of unique cell palettes is similar but different (the devil is in the details!) to the previous.  To be precise, it is n*(n-1)/2.  In terms of the VIC-II (hi-res) or VDC which have 16 colors, the formula works out to 120 combinations... which is exactly what you get from the nCr formula noted in my previous post.  I guess I'm going in circles?
 
BTW, it is not just a coincidence, I've built a table of 16*16*16*16 (VIC-II multi-color) and eliminated duplicates and get the same nCr result.  Which for quick reference is n!/r!/(n-r)! and in this case is 16!/4!/12! which works out as 1820 combinations.  The nice thing is that it is less than half of the pixel quadruple combinations of 3876 reported previously.
 
Well that's all I wanted to report.  But I also find it fascinating to think about the complexity of the video produced by the CBM chips (and indirectly this software).  I mean just consider a single bitmap cell of 8x8 pixels.  And imagine it could only have BLACK and WHITE pixels.  Because order IS important in an image, you can't eliminate duplicate combinations.  I mean sure, a reverse-font @ looks basically the same to a human as a normal (non-reverse) @ character, but I hope we can agree they are different images.  My point is the staggering number of combinations, 2^64 = 18,446,744,073,709,551,616 for a single cell limited to only BLACK and WHITE.  And the VIC-II has 1000 cells (the VDC has 2000 or more), and of course they both have 16 colors and not only 2.
 
I don't know how many combinations in total that would be... but in any case it is only for a single frame of video.  Multiply (or exponentiate) that by F frames per second and again for N seconds of video.  Mind boogling.

[RobertB]

I saw in some video clip, a glance at a vintage computer playing some video, although it was rather brief so I don't know what model it was... don't think it was a PET.

     That was probably video from the Vintage Computer Festival East 8.0 that I filmed earlier this year.  The computer was a TRS-80.

          Truly,
          Robert Bernardo
          Fresno Commodore User Group
          http://videocam.net.au/fcug



         

[Hydrophilic]

Wow, a trash 80 playing video from Star Wars?  Pretty impressive!
 
I've found some time to work on my video encoder... extremely slow progress.  HINT: if you have to write an app, be sure it is command-line and not a GUI... the GUI will take FOREVER (and a day).
 
So far my GUI version still does not produce any output (for shame), but at least it does a good (and fast) analysis of the input frames.  Attached is a screen shot yet another screen dimension (just to demonstrate the power of RESIZE).
 
Well, near the top you can see some frames of some of the first scenes I selected from the Babylon 5 video I will release before The End of The World December 2012.  There kind of small thumbnails, so let me describe them: first, is a pair missles flying over the planet's surface (I forget the name), next is an explosion (I bet you guessed that), fade to black (you got know it), then a new scene beyond the orbit of B5 (presumably near the jump gate).
 
Notice the left side is nearly empty... no output frames for now because progress is SLOW...
 
Anyway, near the center/top is the detail view of one of the input frames (explosion).  It shows several statistics and you have the option to adjust Luma/Chroma/Hue.  Slightly below/right is the output PREVIEW frame.  This is just a guess as to what the output may look like.  In fact, there are several stages of image conversion.  The first stage is shown... where a palette is assigned.  So it just shows the COLORS that will be used in the output bitmap (refer to previous posts to see what an ACTUAL bitmap would look like).
 
I plan to add some more controls to the PREVIEW so you can customize the output if you wish.  Hopefully the automatic (i.e., not customized) output will be adequate most of the time in the finished version... remains to be seen!  That was one of the biggest problems with the original version...
 
Anyway, if you have comments about the layout / controls, let me know.  Thanks!

[RobertB]

...you can see some frames of some of the first scenes I selected from the Babylon 5 video I will release before The End of The World December 2012.

     TEOTW 2012?!?  Sounds like some kind of convention! 

          Looking forward to those Bab 5 frames to be displayed on a C128,
          Robert Bernardo
          Fresno Commodore User Group
          http://videocam.net.au/fcug

[Hydrophilic]

The End of the World is like the ultimate convention!  Just don't call it TEOTW 2012 because that makes it sound like an annual event   It's more rare... bigger than Y2K... something like Y5812 if I understand the Myan calendar (which I don't).
 
RobertB you sure know how to make a challenge!  You want me to emulate Amiga generated video (Babylon 5) with a C128?  Well I came up with something that looks just a bit better than total crap.
 
Two other videos are also included: "4 Minutes" and "World Ends" ... so the theme of all of them is mass destruction.   I've included a screen shot from each of them.
 
You will need an REU to watch them or VICE.  I have a lower quality versions that run on fast serial device uIEC.  I also thought it would run on 1581... it works with 1581 emulation in older versions of VICE.  But in new versions of VICE the playback skips horribly!  I think because it finally emulates the 1581 track head delay (I don't own 1581).
 
I also tried playback of fast-serial version with FD-2000 emulation and it is worse... does not play at all!  Sometimes it will start and then quickly stop with 'FILE DATA ERROR' or won't start at all with 'BAD CODEC PARAMETERS'.  Either there is bug in VICE or the FD-2000 is sending data faster than VIC bad line (about 43 microseconds).  The 1571/81 send data ~64 microseconds so not a problem.  uIEC sends every 48 microseconds so not a problem.
 
I can post fast serial version if anyone wants it.
 
How to play the REU version
 
Download MP128gamma, and unzip to a (preferably new) folder.  Then navigate to that folder using CD commands on a real machine, or in VICE turn off true drive emulation and set device 8 to the directory where you unzipped (Settings > Peripheral Settings). 
 
Type DIRECTORY and you should see several MP128 files.  RUN "MP128INI.BAS"
 
When the player is running, navigate to the "VIDEO" folder and select any or all of the included videos to play.  If using VICE, be sure you have REU emulation enabled (Settings > Cartridge > REU) and size is 4096K or bigger.  Videos will play with smaller REU but they will end early (how much ever will fit in your REU).  Older versions of VICE do no list subdirectory... so if you don't see 'VIDEO' (file-type DIR) in the listing, select CONFIG > MEDIA FILES and change the path to VIDEO (erase anything else in path) and click OK.
 
Videos take a minute or two to load into REU with VICE ( of course you can enable warp mode and it should take just a few seconds, but be sure to turn off warp mode before you start video playback ).   If you are loading from CMD hard drive on a real machine, it is faster to unplug parallel cable if you have one... this is because parallel cable must be accessed by KERNAL calls which is much slower than reading fast-serial bus directly.
 
Sorry if that is pain!  I was really hoping it would work with FD-2000/4000 because you can fit a full video (or two) on one disk.  I also wanted to make a simple .REU file that you could just load into 1541 Ultimate (or VICE) and then start up immediately... but I've run out of time... it's the end of the world, don't ya know?
 
The videos shown here are VIC-II multicolor bitmap mode.  The encoder is also making hi-res bitmap, MC text, hi-res text modes too.  Those need more debugging so nothing to show now.  The encoder is also setup to make EBCM and VDC videos but is completely broken at the moment.  I hope to find the time to try that in my next life.
 
It was great meating you all.  Happy doomsday!

[RobertB]

You want me to emulate Amiga generated video (Babylon 5) with a C128?  Well I came up with something that looks just a bit better than total crap.
 
Two other videos are also included: "4 Minutes" and "World Ends" ...

     Ooo, I'll have to try them out.  I'm away from home (and my C128DCR) for the holidays, but as soon as I return, I will try them out.

I can post fast serial version if anyone wants it.

     I'd like to try that one, too.

How to play the REU version

     Thanks for the detailed instructions.

Happy doomsday!

     Doomsday... schmoomsday... we're all still here!

          Merry Christmas!
          Robert Bernardo
          Fresno Commodore User Group
          http://videocam.net.au/fcug

[Hydrophilic]

You can download a zip file containing two of the videos, "Babylon 5" and "4 minutes" that use reduced bandwidth for direct playback on fast serial device.  It only contains the videos, you still need the updated player, Media Player 128(gamma).  They play on my NTSC system using uIEC.  Other fast-serial devices may or may not work (they won't ever work with 1571)...
 
The videos use reduced bandwidth for direct playback without need of REU, but due to this quality suffers a lot (which is why I didn't publish them first).  Both reduced-bandwidth videos play at about 2.2 frames per second.  Although marginally acceptable for "4 Minutes" it is just terrible for "Babylon 5" because of the fast-paced battle scenes.
 
Most videos I've made use Multi-Color Bitmap mode because usually Multi-Color Text mode will run out of characters before it finishes building the image and looks really bad (if you watch these, you might not think it could be worse  ).  However, "Babylon 5" is using MC text mode!  I guess the vast areas of black "space" allow the scene to be built without running out of chars.  (BTW, the REU version of "Babylon 5" is using bitmap mode).  I used text mode in a desperate attempt to improve the frame rate.  It only improved the frame rate about 10% (2.0 -> 2.2 fps), and naturally reduce the quality a bit.  Of course the fast-serial quality is so inferior to the REU version that you wouldn't know...
 
The encoder is still far from optimal, so no telling what is really possible.  I think these videos (either fast serial or REU) demonstrate a much more consistant (but still not perfect) selection of color palette compared to previous versions.  They also demonstrate a much better encoding when facing the "white problem" (see screen shot of "4 minutes" or "World Ends" in my previous post).
 
One thing I just recently noticed that causes inconsistant palette selection.  Near the end of the "Babylon 5" video, there is a scene that shows a zoom-in of Delenn.  It starts and ends with a reasonable color palette.  About half-way through the scene (which only lasts 2~3 seconds) it strangely switches to gray scale.  Trying to figure out why the encoder would do this, I noticed that in the background some miscellanous Minbari comes into view in the background.  He is wearing a white robe... so it seems that his appearance alters the statistics enough that a new palette (mostly grayscale) is selected... but as the camera continues to zoom in he is no longer visible and the encoder reverts original color palette.  Watching the video, you probably wouldn't ever notice this background character had I not mentioned him... but he destroys the consistancy none the less.  I really don't how to fix it!
 
Oh yeah, videos "4 minutes" and "Babylon 5" are in wide-screen 16:9 aspect ratio.  "World Ends" was originally in super-wide 12:5 aspect ratio but that resulted in only about 11 char rows (88 pixels) height.  So the image was cropped horizontally with the result of 16 char rows (128 pixels) height... it now has some weird aspect ratio but I think it looks okay.  The images posted previously were made in VICE without aspect ratio correction, so they appear a bit wider than real hardware.
 
There is a bug with "low contrast" images.  About 10~15 seconds into "4 minutes" there is a scene that is mostly black background and a dark gray floor... nothing else in the image.  During this scene the encoder (for some reason yet to be determined) ended up dithering the image with rather huge blocks of black and green.  Yuck!
 
The same bug can be scene during the interior battle scenes of "Babylon 5".  The scene has really bad lighting to start, and to make things worse the room is smoke-filled.  Luckily the encoder doesn't try black-and-green to emulate dark gray (I think because it is mostly medium gray), but it still looks pretty bad.  For the REU version, I manually increased the contrast for the interior battle scene so it looks a bit better than the fast-serial version.  Of course the fast-serial version is using MC text mode, so the low-contrast images go from bad to worse.