MAME Movie Maker released

[cdbrown]

I'm going to keep pressing on with this buddamame way for the moment as it seems to work quite well now that I have it tweaked.  The new MovieBatch.exe works great.  I have changed the batch.bat so that the mame game window doesn't pop-up by putting this between @ and mame
start /min /wait
ie @start /min /wait mame %1

Now is there anyway to keep all the output videos to a single resolution - say 128x128?  Perhaps force buddamame to take snapshots at that res?

Cheers
-cdbrown

[Silver]

Ah did I not use the minimise control for mame? only for vdub - soon fix that!

regarding resolution. How mame outputs it is Buddabing's territory, but I belive it would be very hard to impliment in mame. The images are all at the exact original game resolution.

Virtuldub however, certainly does have the facility to resize videos to anything you want. It involves fiddling with the rom.vdb file that buddamame makes for each game, so with the current setup it may take some fiddling by BuddaBing...

Although if memory serves - @Buddabing, is the "roll your own" method (4?) still implimented in your builds? where you can specify the vdb file contents externally? If so I could alter my program to allow certain filters to be used, such as resizing etc...

[Silver]

Look like -movievideo 4 was the option, and it will look for a file vcodec.dat.

Buddabing, currently you import:

VirtualDub.video.SetCompression
VirtualDub.video.SetCompData

from the vcodec.dat. If you are interested in adding support for filters (eg resize) then all you need to do is change the import so that it imports an extra couple of lines.

This is what we currently have in the vdb file:

VirtualDub.video.SetCompression
VirtualDub.video.SetCompData
VirtualDub.video.filters.Clear();
VirtualDub.audio.filters.Clear();

With a filter we want:

VirtualDub.video.SetCompression
VirtualDub.video.SetCompData
VirtualDub.video.filters.Clear();
VirtualDub.video.filters.Add("resize");
VirtualDub.video.filters.instance[0].Config(128,128,2);
VirtualDub.audio.filters.Clear();

So the 2 extra lines to import must go after the:

VirtualDub.video.filters.Clear();

Is that doable?

EDIT: Just to clarify, I can put the filters in the vcodec.dat now, but if I do that, the next line that buddamame places after them is:

VirtualDub.video.filters.Clear();

which clears the filters. I can include that line in vcodec.dat, so all you need to do is remove the above line when movievideo 4 is selected....

[NIVO]

sounds good, i also request the size 128x128. You see in my fe, i plan to use attract vids of this size, i dont need large file sizes as i dont wish them to be that large. Not to mention it helps keep file sizes down, which is always a huge plus. Again, thx for the time in taking a look at our requests, much appreciated.

[Buddabing]

Well, there already is Howard's -moviesquare option, for creating movies that can be used as textures.

The -moviesquare option creates a 256x256 movie, IIRC.

Aspect ratio is not preserved using this option, it is up to the front end to correct it. That's how Howard and )p( wanted it.

IMO it would be more useful and not redundant to have a resize option that preserves aspect ratio. The larger dimension of the movie would be 128, or what the user specifies, and the smaller dimension would be adjusted according to the aspect ratio.

Why can't you just use the -resolution MAME parameter to do the resizing?

[cdbrown]

have tried the -resolution 128x128 in batch.bat and also within mame.ini.  But the output in moviesnp is the original resolution from within mame.  I did some playing around with the .vdb file prior to vdub being run and entered the 2 lines
VirtualDub.video.filters.Add("resize");
VirtualDub.video.filters.instance[0].Config(128,128,2);
and it produced a nice 128x128 res video.

[Silver]

If memory serves, whatever resolution you run mame at, the pngs that come out are always the same as the original game resolution.

Plus I don't think mame lets you run the games at any resolution you specify.There may be a way that you can alter the png saving code (or the image generation) to any resolution you specify within mame. In fact, it would probably be easier if there was...

If not, then there are resize filters available freely to add to virtualdub (http://neuron2.net/resize.html) that can maintain aspect ratio and trim down to a set height or width (eg 128 pixels).


On a slightly seperate note - I notice there is a ssf.txt in the listgen.zuo distribution - but all the end frames are 3000? Is this on purpose?

@cdbrown:
 the filter linked above (just download and place in your virtualdub/plugins directory) will allow you to resize and maintain aspect ratio. To resize everything to have a height of 128 add these 2 lines:

VirtualDub.video.filters.Add("smart resize (1.1)");
VirtualDub.video.filters.instance[0].Config(187,128,0,4,187,128,0x000000,"1 1 1 1 128 128 100 0 0 0 0 4 4 2 2");

(if that wraps round, thats all 1 line with all those numbers)

[cdbrown]

Those lines do work with the plugin but having to go this manually would be a big pain.  Also the encode rate drops by half (using game 005 from 19kbps to 9kbps) is that part of the filter command?  Ends up causing the the output to be blurry

[Silver]

Ah the blurryness is because its bilinear or bicubic filtering.

Config(187,128,0,4....

Change the "4" above to be one of:

0 Nearest Neighbour
1 Bilinear
2 Bicubic
3 Precise Bilinear
4 Precise Bicubic

0 should be faster and not blurry.

Any kind of filtering will add some overhead. There is an assembly optimised 2:1 reduction inbuilt in Vdub, but there will be an overhead for custom resolution changes.

@Buddabing

I had forgotton about the moviesquare option. Presumbly you already have the ability to change the output res? Obviously using that means having the code in your mame build, not all in an external program, but I lost track of whether that was a good thing or not....

[Buddabing]

Look like -movievideo 4 was the option, and it will look for a file vcodec.dat.

Buddabing, currently you import:

VirtualDub.video.SetCompression
VirtualDub.video.SetCompData

from the vcodec.dat. If you are interested in adding support for filters (eg resize) then all you need to do is change the import so that it imports an extra couple of lines.

This is what we currently have in the vdb file:

VirtualDub.video.SetCompression
VirtualDub.video.SetCompData
VirtualDub.video.filters.Clear();
VirtualDub.audio.filters.Clear();

With a filter we want:

VirtualDub.video.SetCompression
VirtualDub.video.SetCompData
VirtualDub.video.filters.Clear();
VirtualDub.video.filters.Add("resize");
VirtualDub.video.filters.instance[0].Config(128,128,2);
VirtualDub.audio.filters.Clear();

So the 2 extra lines to import must go after the:

VirtualDub.video.filters.Clear();

Is that doable?

EDIT: Just to clarify, I can put the filters in the vcodec.dat now, but if I do that, the next line that buddamame places after them is:

VirtualDub.video.filters.Clear();

which clears the filters. I can include that line in vcodec.dat, so all you need to do is remove the above line when movievideo 4 is selected....

The moviesquare option puts the following into the vdb file:

Code: [Select]

VirtualDub.video.filters.Add("resize");
VirtualDub.video.filters.instance[0].Config(256,256,1);

Please check to see if moving the Clear() line  to right after the SetRange() statement will work right.

I can also make the -moviesquare option take the parameter as the size instead of just using 256. So the MAME parameter would be -moviesquare 128 or -moviesquare 256. Moviesquaree 0 would clear it. I probably should have done that in the first place.

[Silver]

Yes - moving the clear line above the Setcompression/under the Setrange works just fine. So if you change that there will be impact on normal users, but will allow filters to be used in the vcodec.dat...

I forgot we did the resize in Vdub.

[Silver]

I've thrown together an update to the Moviebatch program - now on to version 0.2:

http://www.silverfoxy.plus.com/MovieBatch0.2.exe

For the record, its written in VB so needs the VB6 runtime files on your system (http://www.silverfoxy.plus.com/LCD/VBSystemFiles-Install.exe)


It now correctly will make the process run completely minimized (mame and vdub). I've also added a few options - the min/max movie lenth, minimum frame start as well was the movie match length (number of frames to have to match in a row before buddamame stops and declares a proper match). They are all set to defaults on startup.

I've also added a few Xvid quality options: Max quality, (quantiser=1) and then a few quantiser levels: 2,3,5,10. Don't worry if you don't know what quantiser is, basically 1= best quality. 10 is roughly where buddamame defaults to on its own I think. Obviously these effect video file size - 1,2,3,5 all make larger filesize movies than the standard. I can add others but you can have a look at the quality here.

NOTE: the below options WILL NOT WORK until buddamame is updated to accept video filters by Buddabing.

There is also a new resize option. You can either set the exact size you want, or you can tick the keep-aspect for a smart resize, which just resizes to within the largest X or Y value you specify. You can also choose the resize filter (applies to smart resize and normal) - what you want here depends on how small you want the vids and how smooth. I suggest you test and find what you want.

Note: Do not specify ODD numbers of pixels in the resize bar - most codecs don't like this and will error. Smart resize will automatically avoid this, normal resize will not (although I will change this in the next version).

NB You MUST have the SmartResize(v1.1.) filter installed in your Virtualdub plugin folder to use the smartresize option. You can download it freely here: http://neuron2.net/resize11.zip read about it here: http://neuron2.net/resize.html

[Howard_Casto]

Okay, I'll submit something to just add the -makemovie option.

I find it ironic that you call this utility "crazy and hacked up" when you had so much input into creating it. Some of the crazy and hacked up options were created at your request!

Someone else can work out the postprocessing steps to convert mng to avi and chop off the extra frames.

I think you misunderstood me.  When I asked for options to be added it was my assumption that you would add them to either your listgen utility or the batch files that do the post processing.  Hacking mame is always a bad idea because it makes the whole rig less universal. 

We have different philosophies on this.... you have always wanted to do as much as possible inside your custom build.  I've always wanted to eliminate the need for custom builds as much as possible. 

It's the same reason I switched over to the ahk script for johnny5.  When your method was the only way it could be done it was great, but even you can admit that it has severe limitations.  When I found a better way it meant that I could update my mame build immediately or even use optimized builds or crazy mame variants and still use the viewer, so I switched.  I see a similar opportunity with these new mame core changes. 

BuddaMame is a great utility for making movies, but it's not updated fast enough (How can I expect it to?  Afterall, you have a life and such ) and it's not the build of mame I'd rather run on my cabinet. 

I think the smart thing to do at this point in time (assuming that the mamedevs accept your submission).  As to add a final option to buddamame to have it automatically make entries to the ssf.txt file.  Then a system could be in place.  As new games are added to mame, silver (or whoever's willing to maintain the file)  could have the option of checking the start frames manually and releasing and update, or using buddamame to do it for him. 

And just as a note, once the mng is converted to avi (tricky, but possible, I've even seen threads on this forum) chopping of extra frames isn't terribly hard.... since everything is in frames, you just need an editor that supports frame-based timelines. 

I think you misunderstand my excitement for a more user-friendly way of doing things for a lack of appreciation for what you've been doing to get us this far. 

[Buddabing]

The Smart Resize filter maintains aspect ratio?

Also, I moved the two lines of code and recompiled BuddaMAME v0.98. Please try it and see if it works the way you want.

This is an important enough bugfix that I'll update the older versions back to v0.94.

Here's a link to BuddaMAME v0.98 (binary only)

[Buddabing]

I've created the patch to add just the -makemovie option to vanilla MAME. I'll send it off to MAMEdev.

The two questions I have are:

1) Is is possible to unify the output of -wavwrite with the output of -makemovie?

2) Will the resulting movie sync up like it does with MMM?

Also, I tried Silver's mng2avi program and it failed.

[Howard_Casto]

I don't think wavwrite is gonna sync up unless your makmovie additions make it.  In theory wavwrite and a movie tag would both start at the same time.  In practice they might be off sync by a frame or two. 

I'll be glad to look into alternative mng converters... they have to be out there. 

[Silver]

Buddabing - yes that version on buddamame 98 works perfectly - allows the resize filter to work automatically.

And yes, the resize filter (as I've set it up) will maintain the aspect ratio. So if you set 128x128 as your resolution, it will shrink the video so that the largest resolution of x/y will be 128. It will also keep the resolutions at multiples of 4 pixels to maintain codec compatibility.

I've just spotted a quick bug in my moviebatch program where it will fail to call listgen if the last directory you selected was not the listgen dir... ie if you selected the location of vdub.exe last and its in a different dir listgen won't run. All the batch/ini files will work though. Just run listgen manually, or select the locatation of listgen.exe last. I'll fix this for next release.


MNG2AVI. Does it give an error? you need to download some programs (like advmng.exe and vdubmod) - it was very quick and basic but did work for me a few others who tried it. I have not tested it with the mng's from mame though. As it currently stands I don't think that its a good solution - normal vdub can now handle the same process. Are we keen to go this mng route? I'll take a look if we are, if not I might kill mng2avi...

[Silver]

I'll be glad to look into alternative mng converters... they have to be out there. 

I am sure they are... If not, so long as there is something that can decompress them to pngs, we can build a movie out of it.

Edit: This may be dumb, but how do you record an MNG with mame? I've just tried version 0.100. It says "Shift+F12" is the default for recording, but it just seems to take a png snapshot for me... and I can't see any commandline options to output mngs...

[Buddabing]

By default, it's LEFT shift + F12 to create a mng.

I personally would rather scrap the mng2avi and use a vdb script for the conversion.

[Silver]

Woops! I was using version 0.99 - my apologies.

Yes I agree - the fewer programs the better. Virtualdub will not take mng's, nor are there any plans to (I asked a while back). If Mamedev will add png output (and if they have mng output, I can't see why not - as its considered to be moving pngs anway) then all we need is 1 script to do it. Although you will also commandline output, not manual start....

For the record, I just tried mng2avi on a 005 mng, and it created a 200 frame avi which should have been longer. I've investigated, the error is that advmng.exe can not decode the mngs that mame outputs. It crashes out decoding the 005.mng with a "unsupported bit depth" error. Yet another program I have found that can't handle mng's. As far as I am concerned, this kills mng2avi. It will/did work on the Crashtest mng video set that was floating around a while back.

I have no idea why mng's are so badly supported - is the spec changing all the time? most decoders I found "can't handle delta-compressed mngs" or only work on some mngs. There are some players that work (I think there is a frontend - emuloader? - that plays mngs but thats it. To be honest, the code needed is probably insude mame, as I guess they are using the mng library. My vote is to avoid mngs all together.

[Howard_Casto]

You guys know my feelings on mngs.  They are pure crap.  Not because the end result is bad (it's actually quite good), but because nothing can play it. 

Mng doesn't have a standard at all, that's the problem.  Getting mng creators to agree on a standard is like getting visual pinball authors to agree on a naming convention. 

I was thinking that even the loop detection could be done externally.  Mame would spit out pngs (or even an mng)  right?  Well those could be compared as they are being outputted by an external app, and the app could simply terminate mame once it detects a loop, remembering the frame it stopped on and deleting any extras that might occur before mame quits.  Again, this isn't the best solution for the end user, but it could be for anyone maintaining a list of start/stop frames. 

[cdbrown]

Silver - the vcodec.dat that is produced by your batchmaker.  I set the X max 128 and Y mas to 96 and the following is produced
VirtualDub.video.filters.instance[0].Config(320,256,0,0,320,256,0x000000,"1 1 1 2 128 96 100 0 0 1 1 4 4 2 2");

I notice it still has 320,256 references - does this have any bearing on the smart resize.  Also after a few tests, Quantiser=3 seems to provide a good quality video at a good encode rate (for 005 18kbps, 3in1semi 26kbps) and the file size is reasonable.  However 1941 encodes at 104kbps and looks fairly crap.

[Howard_Casto]

1942 would look like crap.... think about it, you just set the res to 128x96 and it's a vertical game. 

[cdbrown]

ahah - I've got you on two points HC.  First was talking about 1941 (not 1942) and the smart resize plugin used in vdub keeps the games original aspect ratio and resizes it to keep it below the res u set.  So for 1942 (using your example) I had it set to a max output 128x96, the original res is 224x256 and output is resized to 110x96.  However - it still looks crap

[Silver]

Silver - the vcodec.dat that is produced by your batchmaker.  I set the X max 128 and Y mas to 96 and the following is produced
VirtualDub.video.filters.instance[0].Config(320,256,0,0,320,256,0x000000,"1 1 1 2 128 96 100 0 0 1 1 4 4 2 2");

I notice it still has 320,256 references - does this have any bearing on the smart resize.  Also after a few tests, Quantiser=3 seems to provide a good quality video at a good encode rate (for 005 18kbps, 3in1semi 26kbps) and the file size is reasonable.  However 1941 encodes at 104kbps and looks fairly crap.

Hi yes, this is simply the plugin recording all the options in its config - several of them are grayed out when you select certain other ones. I actually just shoved the 320/256 in there as in my tests it has no bearing. The important ones are the 128/96 later on (along with the others).

regarding quality. Quantiser variations may not be the best option - if its easier I can stick in some manual "target bitrates" if that helps. Try having a manual play with compression settings in Vdub/Xvid to see what you are after.

I will say that knocking the resolution down to that size looks fairly dodgy with no compression whatsoever to me on some games. The resize filter definately has an impact. In theory I think Precise Bicubic should be the most 'detailed' but nearest neighbour may be better than you think because there is no smoothing going on....

I hate to say it, but this may be one of the reasons MNG was used, as it can be losslessly compressed quite effectively at low resolutions compared to a mpeg4 codec like Xvid. There lots of settings to try yet though.....

Also, remember you can always change the filter.sql part of listgen to create a batch for vertical and then a batch for horizontal and have differnt res settings...   In fact I should be able to include this option in the batch creator....

[cdbrown]

Just wanted to chek what some of those values are as I noticed they didn't change when altering the max X and Y values in the batch maker (the values in within the " " do change).  I now see how the resize causes the trouble.  Might need to increase to have a max 256x172 and test that.

[Buddabing]

I was thinking that even the loop detection could be done externally.

[Silver]

Just wanted to chek what some of those values are as I noticed they didn't change when altering the max X and Y values in the batch maker (the values in within the " " do change).

[Silver]

I was thinking about that. It could be done pretty easily. You take the mng and split it into pngs, then just extract the code from MMM that does the loop detection into a separate app.

All this, of course, depends on having a way to start the mng at the same time as the wavwrite.

The external app would have all the functionality that is currently built into MMM.

The problem with this (apart from figuring out how to decode the mng successfully) is that you can't detect the loop until after you've made the mng, and then decoded it. So you won't know if you've recorded far enough for a loop - equally, if the loop is short, you will end up recording loads without any need. While MNG creation may be faster than on the fly comparision that you do now, I can't see this whole process gaining much from what we have now - apart from just being an external app...

If mame could spit out pngs, then at least you could run an external app to scan them at the same time.?

For future reference, when decoding mng's to pngs, pngs are compressed and can be compressed to varying levels. The speed increase gained by using a very light compression is enourmous, as I found with my mng2avi program...

[Buddabing]

I was thinking about that. It could be done pretty easily. You take the mng and split it into pngs, then just extract the code from MMM that does the loop detection into a separate app.

All this, of course, depends on having a way to start the mng at the same time as the wavwrite.

The external app would have all the functionality that is currently built into MMM.

The problem with this (apart from figuring out how to decode the mng successfully) is that you can't detect the loop until after you've made the mng, and then decoded it. So you won't know if you've recorded far enough for a loop - equally, if the loop is short, you will end up recording loads without any need. While MNG creation may be faster than on the fly comparision that you do now, I can't see this whole process gaining much from what we have now - apart from just being an external app...

If mame could spit out pngs, then at least you could run an external app to scan them at the same time.?

For future reference, when decoding mng's to pngs, pngs are compressed and can be compressed to varying levels. The speed increase gained by using a very light compression is enourmous, as I found with my mng2avi program...

Unfortunately, vanilla MAME doesn't spit out sequences of pngs. We've got to work with what MAMEdev will give us.

The external app will search be able to search boundary.txt and will be able to generate new boundary.txt entries. Creating the first movies will take much longer than it currently does because you have to make sure you capture the entire loop in the mng. Once that is done and the full boundary.txt is created (and audited ) then movie creation will be easier.

I don't think decoding the mng will be a problem. I'll just reverse the process used to create it in MAME.

[Silver]

ok... so all we need is for vanilla mame to allow mng recording from the start....

Also I think I've kept a whole set (0.97?) worth of vdb files, which will contain the start/end point of most of the games - its not audited, and some will be wrong, but it could save a lot of time when this gets off the ground... I'll look into extracting the right info...

[Skadar]

Feel free to ignore this post completely, but I just can't help it...

18 pages of incredibly hard work for what?  What is the point of all of this?  You guys are doing all of this in order to display a small movie in your MAME front end while you are selecting a game??  Wow.  Seems like you've got time and effort to burn.

I understand the DIY-fever, but this seems a little over the top.

[2600]

Feel free to ignore this post completely, but I just can't help it...

18 pages of incredibly hard work for what?  What is the point of all of this?  You guys are doing all of this in order to display a small movie in your MAME front end while you are selecting a game??  Wow.  Seems like you've got time and effort to burn.

I understand the DIY-fever, but this seems a little over the top.

This coming from the guy who's been registered for a month with over 100 posts and who apparently doesn't have time to do stuff, but does have time to comment on other people doing things they enjoy. 

[papaschtroumpf]

Feel free to ignore this post completely, but I just can't help it...

18 pages of incredibly hard work for what?  What is the point of all of this?  You guys are doing all of this in order to display a small movie in your MAME front end while you are selecting a game??  Wow.  Seems like you've got time and effort to burn.

I understand the DIY-fever, but this seems a little over the top.

To each his own I guess. I find the movies incredibly useful when selecting a game.
I also use the movies as part of the screen saver, which is another nice way of going "hey, this game looks fun, I haven't tried it yet".
So as far as I'm concerned, thank you to Buddabing, Silver and all those involved in this effort.

[Buddabing]

Feel free to ignore this post completely, but I just can't help it...

18 pages of incredibly hard work for what?

[Buddabing]

I've created a rudimentary mng2pngs program which splits a mng into its component pngs.

A couple of notes:

1) Mng size can be greatly reduced by running MAME with the -window and the -noartwork options, except for the games that require artwork (Armor Attack, etc). This is because the mng creation process uses the window resolution, not the game resolution.

2) The "Rec Start" message is on the mng as well as the pngs. This is annoying, but may not affect us since the message should disappear before the start of the demo loop.

On to the pngs2vdb program.......

EDIT: Using the -resolution parameter will also greatly reduce the size of the mng.

[Silver]

Hmmm... thats interesting. Obviously the output of the mng is taken at a later stage in the output process than you were taking the mngs. Does this include things likes scanlines? Does  hardware stretched image get saved as it appears? Will this have an impact on detection if graphics card changes are saved?

On another note - Due to vdubs highly annoying nature of needed the starting point measured in milliseconds, but the end point in frame number, can you remind me how exactly calculate the start time point? Do you take the exact framerate of the game in use, divide by 2 (as we are making 30fps vids from 60fps games) and mulitply by the number of frames? Or did you assume all games were 60fps? I'm asking as I need to reverse calculate all the start frames from a millisecond reference....

[cdbrown]

Is there any way to change the fps to say 15 like crashtest's vids.  His vids seem quite good quality, but have a fixed size of 256x256.  Was thinking could keep the max smartresize to somewhere around that size (finding 128x128 is a tad too small), drop the fps, use a reasonable quantiser like 3 and see how that all goes?

[Silver]

Done.

http://www.silverfoxy.plus.com/MovieBatch0.3.exe

New option to set how much the frame rate is decreased by compared to the original. Default is half (0.5) - so you get 30fps for a 60fps game - same as standard buddamame. You can also choose 0.33 (20 fps for a 60fps game) and 0.25 (15fps for a 60fps game).

[cdbrown]

Damn you are good