159
Replies
To anyone even mildly interested in having a frameserver with CS5:
I'm happy to report that this is really really real 
I've been briefly testing a debug version of the frameserver (earlier than the last videos posted here, so without a few of the new enhancements), and it works! We've uncovered a few bugs--for example, interlaced video is being automatically deinterlaced when frameserved, so that's obviously a crippling bug--but the communication lines are open and the hired programmer is working on a fix. Additionally, we'll see some new features like integration with the AME interface (e.g. all parameters are set in AME, not the FS dialog) and the ability to queue multiple items for frameserving via the AME queue, and have an auto-timeout built into the frameserver.
This is proving to be a truly international effort, and we're getting close to being able to have a release version--at present, we're about 75% of the way there on the needed funds to pay the programmer (~$360 of $500). If you'd like to help move this effort forward, and can spare even a few bucks toward it, please use the link in one of the above posts to contribute. I'll probably put a few more bucks into it, but we could use some help!
(For those interested, I've successfully encoded a file using Sorenson Squeeze, TMPGEnc Xpress, and Handbrake using the frameserver.)
Jeff,
Certainly; do note that this is based on loose Google-assisted conversations, and not anything experiential yet, but this is how I understand it to work...
There are several changes to the frameserver that have or will enable this ability. For one, the frameserver settings are now part of the Export Settings panel, just as they would be with any other codec. For example, on the Video tab, you have the RGB24, RGB32, and YUY2 options we're accustomed to, as well as the Network Frameserving option; I believe there are a couple other small options, but the test version I'm using does not have those. The Audio tab has the PCM samples option. Previously, all of these settings would have appeared in a separate frameserver setup dialog (you remember the one) that popped up after you hit Export; that dialog is no longer part of the workflow. As such, you'll now be able to save frameserver encoding presets that could be batch applied in the AME queue.
The second enhancement is that the frameserved AVI is no longer called "signpost.avi" by default; rather, like any other item exported from PPro, it takes the name of the queued clip or sequence, so you have unique signpost AVI file names. A trifle, perhaps, but I'm getting there...
The third enhancement--mostly in concert with the above--is that because that dialog is gone, there is no longer the "Next" button on the Setup dialog. Now, once you hit Export (or the AME queue begins), the signpost AVI is writte, the frameserver status window comes up, and frameserving is active. Simple change, but that sets up the next cool feature...
There will now be a user-configurable "timeout" that will be set in the export settings that will essentially terminate the current frameserving process (basically, an automated click of the "Stop Serving" button) when frames are no longer being served after that duration of time. So, let's say you set the timeout for 120 seconds; ordinarily, as encoding of the signpost AVI was continuing, frames would be continuously streaming through the frameserver even if encoding was slow. As long as that is happening, the frameserver stays active for that particular encode. Once the third-party app stops requesting frames--which it will do once encoding is completed--the timeout timer kicks in and when that duration elapses (in our case, 120 seconds), the current frameserver is terminated. If we have a number of frameserved items queued in AME, when that first one terminates, AME will automatically go to the next item; because we no longer have to manually click the "Next" button (see why that's important now 
), the next frameserver instance launches. This automatic start and stop procedure will continue until all items in the AME are processed.
Now, obviously what this necessitates is having a third-party encoder that employs watch folders--I seem to recall that you are a Sorenson Squeeze user, so you're covered. Basically, you'd create a watch folder in your third-party app, and then set the frameserver to create the signpost AVIs in that watched folder; as each signpost AVI appears in the folder, the third-party app will encode it. Since the frameserved AVI has a unique name, there is no issue with overwriting earlier encodes, since watch folders usually just append some suffix to the incoming file name. Once the third-party app stops pulling frames, the timeout timer engages, and the process continues.
I have not tested this yet, so I cannot yet comment on how it works, but that's the theory. What I am anxious to see is if this queue option can be combined with network frameserving; in my mind, this would be a truly awesome implementation, because you could then effectively offload your encoding to another system on your network, and continue working on your editing machine. Theoretically, you shouldn't incur too much of a performance hit, since all the host computer would be doing is dishing up frames across the network to another computer. We'd finally have a sort of cobbled together export farm!
Anyway, I know you asked for a brief explanation, but I'm not too good at being brief, if you haven't noticed 
Let me know if you have any questions or ideas on how to make this better. I think we're still in the cooking phase, so now is the time to refine this to work in a manner that we'd like. I should note that frameserving of HD assets and heavily-effected sequences is rather slow at this point (I believe that that was what plagued the CS4 frameserver), but the programmer is working to optimize this. So far, the guy has performed admirably, and has been receptive to feature requests and bug reports, so I have no doubt that this will happen.
Colin
EDIT: Oh, if you're up for a little more Google-translated fun, check out the thread that Vasya (the gentleman that has spearheaded this effort) is maintaining. There is quite a bit of interest by some of our overseas counterparts...
UPDATE:
I'm playing with a new version of the frameserver as I write this. There are several new features, including those that have been mentioned previously and demonstrated in the screen recordings, and some that are just starting to coalesce. Most importantly, the automatic deinterlacing bug has been fixed, or appears to be fixed, anyway; I haven't been able to recreate the problem in my testing of this version. Also, I'm frameserving a DVCPROHD 720/24pN P2 MXF clip right now using my 2.26GHz Core2Duo laptop off a single hard drive, and playback is realtime in Media Player Classic HC. Granted, this isn't a real intensive test, but it is encouraging that improvements have happened and will continue.
Here's a screen shot of a sequence I queued from PPro to AME (simple DV clip) being frameserved to VirtualDub 64-bit:
Tomorrow, I'll try to do a brief screen recording of the frameserver in action, just in case anyone needs further proof
BIG UPDATE!
I just received a new version of the frameserver, and the problem of really slow performance has been SOLVED!
Here's the basics: apparently, in the CS4 version, the Maximum Render Quality was toggled on and hardwired into the code, so that regardless of that parameter's state in the Export Settings window, frameserved AVIs were always being rendered in Maximum Render Quality. This lead to the massive slow down in performance that we witnessed in the CS4 version and to an extent in the CS5 version.
However, the new version of the frameserver exporter now functions CORRECTLY so that the MRQ is off by default and is only enabled if you check the box in the Export Settings window. I just did a quick test with a brief but effect-laden sequence frameserved to Sorenson Squeeze; the old version took about 13-14 minutes to do this particular encode, whereas the new version took less than 2 minutes! Another test with enabling MRQ in the Export Settings window slowed the external encode back to about the 13 minute range, proving that the toggle works correctly now. Additionally, playback in software players and loading the signpost AVI into encoders is virtually instanenous now, with MRQ disabled. Honestly, I can't tell the difference between the file encoded with MRQ and the one without, so I think the speed increase is going to be the more important factor here.
We also have some other cool new features, like a UYVY color space mode (which I'm sure means something to somebody 
) and the ability to network frameserve simply by saving the signpost AVI on a network share. Any computer that can access the share can encode over the network, effectively letting you offload your encoding to another system and letting you continue to edit on your main system. This feature is available due largely to the fact that the frameserver can now be queued from AME.
Coming soon: tighter integration with the Adobe interface (no extraneous pop-ups, even though they are minimal and relatively unintrusive now) and the auto-timeout feature. I didn't get to do a screen recording today, but will do one soon so you guys can see this thing in action. Not only is the FrameServer back, it's better than ever...
I just threw in $50 for this to happen.
This is a feature I have been waiting for since the release of CS5. Thank you so much, Taravasya for making this happen!
Thank you, Ann! We're trying something different with the timeout mechanism; I anticipate a new debug version today. Also, some other bugs--possibly performance-robbing ones--are in the process of being squashed. I'll keep you all posted...
FWIW: we're very close on collecting the necessary funds to pay the programmer, so if you can forgo your double soy latte for one day, your support would be greatly appreciated 
AdChoices