It should be possible to mimic the Exporter API with your own then within your codebase manually open the .prm file (it is a DLL after all) and do your own initialization of it and calls to it exactly the same way that AME does.
I've been looking at doing a very similar thing for Filters. IE making a shim to an AE plugin that isn't threadsafe. If I can mimic the AE API and set the new CS4 and above PF_OutFlag2_PPRO_DO_NOT_CLONE_SEQUENCE_DATA_FOR_RENDER flag then call the AE filter I want to run it May just work in CS4 (coz the old AE filter is 32bit it can't also be CS5).
Are you confusing terms btw?
I am trying to create a custom exporter that has h.264 encoder capabilities.
In CS3 and prior Premiere has "Compilers" (invoked from Export->Movie) and "Custom Compilers" (invoked from Export->[thename]).
In CS4 and above Premiere has no direct Export anymore (ie Compilers are Deprecated). Premiere, AE and Encore call Media Encoder. AME has only one sort of backend called "Exporters".
So I'm assuming when you said "Custom Exporter" that you meant your "Exporter".
I bring that up in case you're thinking of making a (legacy <= CS3) "Custom Compiler" and hoping to be able to call the (Main Concept OEM'ed) H.264 "Exporter" that is in CS4 & CS5. Getting that to work would be a world of hurt.
'keep us in the loop.
Thanks for your response!
Maybe I sounded too erratic when I said "create a custom exporter that has h.264 encoder capabilities.". The idea is to offer the user a h.264 video encoding option when exporting.
Yes, "custom exporter" means an own developed exported based on SDK exporter example that comes with the SDK.
I am afraid I have to abandon the idea of invoke the *.prm file used for H.264 as long as I will have to hardly research how to setup the calls that Media Encoder or Premiere does. Instead, I can make use of some third party libraries that helps in encoding video into mp4 container (where video is in H264) which is my final target.
As a headlight for someone, x264 seems to me a perfect candidate to do that!
Anyway, I like your "world of hurt" expression; it´s been a while since I started out with the SDK, but finally I am seeing the end of the tunnel...
Fyi I've been working on a x264 front end plugin for a while now. It needs some serious cleaning up to make it into a state that's ready for distribution though.
My goal is BluRay "legal"* output.
*by legal I mean it will pass the bluray replication tests.
I'm doing it for two reasons,
A: The Main Concept encoder is awful at High Quality HD output. (x264 beats it in bake offs every year)
B: The Main Concept encoder doesn't make Bluray legal output. It will "work" on most Bluray players when burnt onto BD-R but it's not good enough for professional production. i.e. sent off to a bluray replication house.
It's not as easy as it looks to shim it to the Adobe SDK. I've been working with the x264 developers for quite some time to resolve some serious problems. For example: the handling of color spaces properly etc. (pc.709 & pc.601 -> rec.709 & rec.601).
So, if you have some other plan (which it seems like you do based on pre-processing you say you want to do) then it can be a good engine to use but trust me it ain't easy to get it to actually make the output the way you want.
I finally managed to encode h264 within the exporter plugin code.
I had to spawn a command line process, which is just a simple call to x264.exe with a bunch of options, taken directly from exporter GUI dialog. The I redirect the output of the process and have the exported analyzing this output, so it gives feedback about the progress of it.
Thanks for all the tips!