Some very desirable additions to AVS Video Editor 4's aready impressive capabilitie woud include:
1) A mechanism to apply to video overlays the effects -- e. g., blur, TV Simulation, Grey Out, etc. -- presently applicable only to the main video. For still-image overlays, this is doable using an external photo editor, but a) that's no help with video clip overlays, and b) it would greatly simplify matters to be able to work directly within the AVS Video Editor.
2) A mechanism to "soften" the edges of an overlay's containing rectangle so that the overlaid image "blends" more naturally with an underlying main video. Hard edges work for simple picture-in-picture situations, but I'm thinking of occasions where an overlay emerges as a sort of floating "dream sequence" within an area of the main video. A reasonably good workaround to do this for still image overlays uses Chromakey, but that works less well for video clip overlays.
3) A single "point trajectory" and mechanisms within the Video Overlay Editor window to textually specify exact trajectory timestamp "event" attributes. For example, I sometimes create a "blooming" overlay effect thus:
-> drag a straight line trajectory onto the preview window
-> insert timestamps along the trajectory to mark trajectory "events"
-> drag each timestamp point in turn to overlie the trajectory start
-> drag this "stacked" trajectory to a desired screen location
-> stepwise increase or decrease overlay size and/or angle at each successive timestamp
The resultant overlay appears to bloom from (or recede into) a single point within the video frame. It can be quite impressive but, because the timestamps must be marked on the initial trajectory before it's collapsed and relocated as described, the method is tedious and, because achied graphically, prone to imprecision and uneven progression.
If the initial trajectory is "collapsed" to a point before marking intermediate timestamps, the editor disallows adding timestamps, apparently because new ones would implicity lie outside the default start/end timestamps. Textually entering timestamp attributes could avoid problem. One implementation might be managing trajectory "events" via a "list" -type control capable of accepting insertions/deletions with newly inserted timestamps' settings defaulting to those of its existing immediate predecessor. Double-clicking a list member would open a dialog to display/edit its settings for
-> temporal offset from overlay onset (absolute or percentage)
-> X/Y location relative to a main video frame reference (.e. g., upper left corner) where the overlay should be centered
-> overlay size in some useful metric (e. g., pixels or positive nonzero percentage of overall video frame size)
-> +/- degrees (mod 360) of rotation angle from "rightside up,"
-> ideally, transparency would also be a modifiable setting linkable to trajectory timestamps, enabling a sort of "winking" effect
Rate/direction of size/angle(/transparency) change would remain, as now, implicit in time/size/angle(/transpaerncy) differences between successive timestamps' settings.
4) Even without any of the foregoing, some metrical display of the (fixed or initial) X/Y placement position of overlay objects (texts, graphics, images, clips, etc.) relative to a main frame reference would be extremly useful. The grid is helpful but imprecise.