zettai
27th August 2002, 22:40
Premiere AVISynth Plugin v1.0 Bugfix release
This is an update of the Premiere Avisynth Import Plugin originally written by Ben Rudiak-Gould, see http://math.berkeley.edu/~benrg/avisynth.html. The plugin and the sourcecode can be obtained from Tom Ford's web site: http://www.ox.compsoc.net/~flend/avisynth/index.html
Changelist: Version 1.0b:
- Fixed high saturation colour error bug.
- Fixed Blank Screen bug.
- Fixed no-thumbnail bug.
- Code optimised and fixed for compling with VC7
IMPORTANT:
Although the plugin is vastly improved, please note the following caveats:
1) The plugin now includes the ability to resize to fit the preview window and timeline thumbnails. However this resize is not very accurate (as it is optimised for speed) and will give poor results if used in your export. Hence, it is very important that the resolution (and pixel aspect ratio) of your import files EXACTLY MATCH those of your output in order to maintain perfect quality.
2) Avisynth has changed since the original plugin and now uses RGB32 as the default RGB method. However, the Premiere Import Plugin expects 24 bits and hence if you are using an RGB source you will have to add ConvertToRGB24() to your script.
How the bugfix was developed:
The import plugin was written two years ago and had not been changed, or so it seems, since it's original release which contained (primarily) a black screen bug. this required the user to resize the preview window to 720x480 in order to see the footage. Later a colour bug was discovered that happened at high saturation colours. (ErMaC made a post about this last week in this thread (http://forum.doom9.org/showthread.php?s=&threadid=31915))
After years of having to cope with the problems caused by this import plugin, AbsoluteDestiny decided to download the source code and try to decipher what exactly was going wrong. With aid from one half of Turboneko Studios and ErMaC, areas in the code were pinpointed that were suspected to be the source of the main problem - the blank screen bug. It appeared that import plugin has to include its own resize routines and the plugin didn't actually have one. This resulted in only footage that matched the preview window resolution and export resolution to be processed. The other main bug was to do with the way certain high level colours were completely changing, causing ugly artefacts on footage. After much theorising, the conclusions were passed on to Tom Ford who endeavoured to tinker with the code to see if they could be resolved..
The fixes
The original plugin lacked the ability to resize information for display in Premiere, resulting in the black screen bug mentioned earlier. To combat this, a resize algorithm was added to the plugin. This resize algorithm was written by Tom Ford and applies a Nearest Neighbour resize to the footage for general display in premiere. It is desinged for speed and hence the import and export resolutions should be kept the same to maintain quality.
The colour bug was much more curious. I'll let Tom explain:
you'll be pleased to know that the colour bug was PARTICULARLY subtle
The problem was actually to do with the compile implicitally casting *(char *) to a signed int before doing a shift
This meant that if the RGB components were > 127 they would go negative
and everything would go to hell :)
Bits with 2 non-zero colour things would be particularly bad, hence the little blocks in the middle looked a bit screwed
If you remember the code it was
dst[round_x] = src[x*3+0] + (src[x*3+1] << 8) + (src[x*3+2] << 16);
Now, if some of the operands were negative, you can imagine all kind of strange effects happening
due to the + s
So, in short the colour bug was really really nasty and now it's fixed.
Future Optimisations:
There are possible future optimisations to be made but this is a fully working version. It is uncertain how much further development will occur on this plugin as the main problems have been solved. Rest assured, if further bugs present themselves we may become proactive again.
The main bottleneck with using this method for editing dvd footage is the speed of the mpeg2 decoding. It is possible that an editing version of mpeg2dec.dll will be developed to allow more fluid editing. An mpeg2dec-lite, so to speak. This could be changed in the avisynth script later for full quality or quality could be set using external registers. This may be intergrated into the plugin (allwoing d2v file loading) or may manipulate a new avisynth plugin (an mpeg2prm.dll or similar). A bicubic resize option activated by external registers is also being considered - but these are still only ideas.
This is just supposition at the moment but essentially what we want to do is to create a fast and reliable method for editing with dvd footage. This plugin release isn't any faster but it is less broken :)
RGB32 support is being worked on presently and mpeg2dec is being looked at. Please report any bugs here, to myself or to Tom. Thanks.
AbsoluteDestiny
This is an update of the Premiere Avisynth Import Plugin originally written by Ben Rudiak-Gould, see http://math.berkeley.edu/~benrg/avisynth.html. The plugin and the sourcecode can be obtained from Tom Ford's web site: http://www.ox.compsoc.net/~flend/avisynth/index.html
Changelist: Version 1.0b:
- Fixed high saturation colour error bug.
- Fixed Blank Screen bug.
- Fixed no-thumbnail bug.
- Code optimised and fixed for compling with VC7
IMPORTANT:
Although the plugin is vastly improved, please note the following caveats:
1) The plugin now includes the ability to resize to fit the preview window and timeline thumbnails. However this resize is not very accurate (as it is optimised for speed) and will give poor results if used in your export. Hence, it is very important that the resolution (and pixel aspect ratio) of your import files EXACTLY MATCH those of your output in order to maintain perfect quality.
2) Avisynth has changed since the original plugin and now uses RGB32 as the default RGB method. However, the Premiere Import Plugin expects 24 bits and hence if you are using an RGB source you will have to add ConvertToRGB24() to your script.
How the bugfix was developed:
The import plugin was written two years ago and had not been changed, or so it seems, since it's original release which contained (primarily) a black screen bug. this required the user to resize the preview window to 720x480 in order to see the footage. Later a colour bug was discovered that happened at high saturation colours. (ErMaC made a post about this last week in this thread (http://forum.doom9.org/showthread.php?s=&threadid=31915))
After years of having to cope with the problems caused by this import plugin, AbsoluteDestiny decided to download the source code and try to decipher what exactly was going wrong. With aid from one half of Turboneko Studios and ErMaC, areas in the code were pinpointed that were suspected to be the source of the main problem - the blank screen bug. It appeared that import plugin has to include its own resize routines and the plugin didn't actually have one. This resulted in only footage that matched the preview window resolution and export resolution to be processed. The other main bug was to do with the way certain high level colours were completely changing, causing ugly artefacts on footage. After much theorising, the conclusions were passed on to Tom Ford who endeavoured to tinker with the code to see if they could be resolved..
The fixes
The original plugin lacked the ability to resize information for display in Premiere, resulting in the black screen bug mentioned earlier. To combat this, a resize algorithm was added to the plugin. This resize algorithm was written by Tom Ford and applies a Nearest Neighbour resize to the footage for general display in premiere. It is desinged for speed and hence the import and export resolutions should be kept the same to maintain quality.
The colour bug was much more curious. I'll let Tom explain:
you'll be pleased to know that the colour bug was PARTICULARLY subtle
The problem was actually to do with the compile implicitally casting *(char *) to a signed int before doing a shift
This meant that if the RGB components were > 127 they would go negative
and everything would go to hell :)
Bits with 2 non-zero colour things would be particularly bad, hence the little blocks in the middle looked a bit screwed
If you remember the code it was
dst[round_x] = src[x*3+0] + (src[x*3+1] << 8) + (src[x*3+2] << 16);
Now, if some of the operands were negative, you can imagine all kind of strange effects happening
due to the + s
So, in short the colour bug was really really nasty and now it's fixed.
Future Optimisations:
There are possible future optimisations to be made but this is a fully working version. It is uncertain how much further development will occur on this plugin as the main problems have been solved. Rest assured, if further bugs present themselves we may become proactive again.
The main bottleneck with using this method for editing dvd footage is the speed of the mpeg2 decoding. It is possible that an editing version of mpeg2dec.dll will be developed to allow more fluid editing. An mpeg2dec-lite, so to speak. This could be changed in the avisynth script later for full quality or quality could be set using external registers. This may be intergrated into the plugin (allwoing d2v file loading) or may manipulate a new avisynth plugin (an mpeg2prm.dll or similar). A bicubic resize option activated by external registers is also being considered - but these are still only ideas.
This is just supposition at the moment but essentially what we want to do is to create a fast and reliable method for editing with dvd footage. This plugin release isn't any faster but it is less broken :)
RGB32 support is being worked on presently and mpeg2dec is being looked at. Please report any bugs here, to myself or to Tom. Thanks.
AbsoluteDestiny