times2
11th April 2002 16:29 UTC
(another) ape goody
hi all
i've finally got another ape plugin (semi) ready for release...
its an improved avi player which can load avis into ram for awesome speed, built in mixer, play avis with variable-speed frame blending, play forwards and backwards, change direction 'onbeat', 'scratch' avis and a whole lot of other features.
I know most of you guys favour a preset based rather than handson approach to video mixing, but maybe some of you will find it useful. i've deliberately NOT made it so it can automatically load movies from a preset as this will make most machines get into an inescapable choke-up if you tell it to load a very large movie.
know bugs... it crashes when scaling (bilinear filtering) images up from 320x240 to 400x300 (only!?)
also it doesn't check your available RAM, so if you try to load a bigger clip than you have ram, it CRAWLS.
anyway if anyones interested you can grab it at:
http://www.dmc.dit.ie/pixelcorps/player2.ape
mail me at:
pixelcorps@forwind.net
with any bug reports, success or failure stories, etc.
Montana
11th April 2002 18:14 UTC
times2, this rulz, success all the way,
good shit done, figured out what you meant with ramcrawling,
still, it rulz,
only problem, i seem to find is that it crashed when i used a 20sec DivX-converted avi,
note: the render/avi also crashed with this 20sec vid, (and yes i tried on several computers, i think avs doesn't support divx
UnConeD
11th April 2002 20:39 UTC
times2: your crash bug sounds very weird... you should be able to use a debugger to locate the crash. Even though you don't have symbolic information for Winamp.exe and vis_avs.dll, you can still debug your APE. Set Winamp.exe as your executable and start a debugging run.
I'm curious... is your bilinear filtering written in assembly and/or MMX for speedup?
UnConeD
11th April 2002 21:29 UTC
Downloaded it... wow... nice work. Here are some more tips:
- Set the default value for speed to 1, and the default value for the fade at 100%... at first I thought it wasn't working because of this :)
- Provide a short explanation of each item?
- You can save space by replacing the radio button groups with one drop-down box (your dialog is a bit cramped :))
- The images you use for the volume bar and scale don't use the correct window background (and they look weird if you use a non-standard colorscheme)... there's a parameter for the LoadImage() API call which makes windows fix this for you. Or you can use GetSysColor() if you're drawing them on the spot. Another alternative is to use a mask to draw it. Here's how to do that:
* XOR the current contents with the bitmap
* AND the current contents with the mask (mask has white for transparent, black for opaque)
* XOR the current contents with the bitmap
What happens is, the 'do not draw' pixels will be XORed twice with the same value (which doesn't change them), while the 'do draw' pixels will be set to zero and then XORed with the correct color, which is simply the same as setting it to the value itself.
- Add an about box so people know where to get other APE's by you :), or at least provide some author info. I have some short code here that I use in my APE's to turn a 'Button' window into a clickable, hovering URL that might be useful.
- You mentioned Bilinear Filtering... though I can't find this option. Perhaps you meant the oversampling checkbox (it seems to blend smoothly between frames, for slow framerate AVIs)? Actual Bilinear Filtering would rock really :), though it would probably require more RAM at higher resolutions. MMX is highly recommended... AVS requires it anyway and it provides a massive speed up when working with 32-bit color values.
- Maybe an auto-load checkbox would be handy, so that you can insert it in presets. Even a VJ could make simple presets so he doesn't have to do everything on the spot.
- Some AVI's (e.g. Elvis's pattern AVI in Worm-on-acid) contain many of the same frames. You could write a simple 'dirty rectangle' system that only stores the maximal area that changes to reduce the large memory consumption, while still having minimal overhead.
- Some codecs cause black pixels to become slightly colored (e.g. RGB 1, 1, 1) and this makes additive blending look ugly. A simple color clipping option would rock, and wouldn't cause much slowdown because you load the AVI into memory anyway.
- On some AVI's, I get an Invalid header box twice. Instead of popping up a box, why don't you display it in the AVI File box?
times2
12th April 2002 11:13 UTC
thnx
thanks guys,
montana- it sounds like your avi or your installation of divx are corrupt. the codec used is totally transparent to avs being handled at a lower level.
unconed- thanks for all the great suggestions (as always)- its gonna take a while to get through them- i'm only learning c;)
the bilinear code is implemented in C, actually written by a friend and adapted for this. it is used where the source file is different resolution from the output window, it scales the image up into ram so it can be played back fast... but theres definely a bug in there somewhere. gonna try your debugging suggestion asap.
t
times2
18th April 2002 10:08 UTC
now working in presets
hi i've just posted an update to my player2.ape
(get it at the same place:)http://www.dmc.dit.ie/pixelcorps/player2.ape
UnconeD: I've implemented a few of your suggestions
defaults are more consistent now
about page points to a documentation website (don't look yet its not finished)
drop-down boxes... maybe in the future... but doesn't AVS vis processing stop when you are scrolling a list box?
bitmap colours- i'm not actually making the api calls myself, i'm just using vc++ to compile the .rc file, so i'm not sure how to change
this. (note to self- requires further study)
if you want to post me your about box code that would be cool.
autoloading is now implemented. (was actually tricky). in fact everything now saves to the preset pretty much.
I like your dirty rectangle suggestion, however its not really practical here as i'm both loading and playing back avis bidirectionally. My next effort will be to use frame tokens to enable random-access frrame loading. And i'm thinking a simple check of the frame size in bytes might reveal whether the frame hasn't changed- in which case the frame pointer can point to the same frame store.
error messages in status box: done
colour clipping is a good idea. i'm wondering whether to have a simple on/off or to implement a threshold in the player (even more cramped interface??)
T