QUICK UPDATE: We're getting very close to the end of the project. The necessary funds have been collected; it's just a matter of putting them together from the various payment collection services now At this point, the frameserver is functional and stable. The programmer is trying to work on optimizing the frameserver now, hopefully to take advantage of multithreading, etc. The goal is to add as little overhead in the frameserving process, and make it at least as fast--if not faster--than exporting an intermediate file and encoding from that. We're shooting for sometime in the middle of this coming week for a release; as with most software, that is subject to fluctuation. Stay tuned here for more... Many thanks to everyone who contributed to the project! ... View more

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 ... View more

EXCELLENT! That is simply awesome--thank you so much for supporting the effort. We're working on some refinements to the timeout function now, but other than that, the plug-in is feature-complete, stable, and very usable. A final release should be imminent. Again, thank you for your belief in this project and your generosity! ... View more

Thanks Mark! I appreciate you weighing in. I just threw $10 more into the hat, in the hopes that we can get this out to everyone sooner rather than later. I would guess that by next week, we'll have a final release version, assuming no show-stopper bugs are found, and that improvements and optimizations continue at the rate they have. I'll keep you all posted... ... View more

FWIW, this doesn't appear to be universal with this update... mine went smoothly. I didn't say it was, and it hasn't affected everyone with previous updates, either. As far as I can tell, no one has ever uncovered the series of factors that contribute to this. Personally, every single CS4 update forced me to do this dance, on both of my systems; I haven't had a problem with any of the Premiere Pro CS5 updates, but I can't install the current Photoshop or Illustrator updates (both fail on both systems). There seems to be little rhyme or reason for it... ... View more

I will try to find an easier way but at least I know what to do if this does not work. Do let us know if you discover one--so far, anyone else that has been struck by this issue (with previous updates) has had to go through this deactive/uninstall/clean/reinstall/update routine. It's not pretty, I'll grant you, but it seems to be the only way to get back up and running. Sorry for the bad news... good luck ... View more

...and the "Hey I'm a Premiere Pro Update and all your retail installation are belong to us" reversion to trial mode rears its ugly head yet again... This has been a recurring nightmare with Premiere Pro updates, unfortunately. For a number of users, installing an update somehow causes the software to revert to trial mode, which prevents you from using a number of formats and codecs that you previously had access to (like MPEG). Sadly, the only remedy is to deactivate your software, uninstall it, run the Adobe CS5 Clean Tool a couple of times (rebooting each time), and then reinstall. Immediately after reinstallation, launch something like Bridge and perform the updates from there. Wish there was an easier way, but this has been a random issue since sometime in the CS4 cycle. Post back if you get into any trouble during the process; as long as you proceed as listed above, you should be back up and running. ... View more

AND YET ANOTHER UPDATE: This is the big one, folks: the auto-timeout feature is now part of the FrameServer plug-in, and is fully functional! There is a new option in the encoding settings for the frameserver that allows you to set a timeout of 10-120 seconds. You set this option for any frameserved AVI that you would like to automatically terminate when the frameserver is no longer pushing frames. The timeout can be used with either Export or Queue, but it's with Queue where it is most powerful. If you send a number of frameserved items to the AME queue with timeouts set, you can have the signpost AVI files saved into the watch folder of a third-party encoder. When the encoder works through the first signpost file, the timeout begins counting down; when time is up, the current frameserver ends and the next one in the AME queue begins. The signpost AVI created by this frameserved item lands in the third-party encoder's watch folder, and the process continues. It works amazingly well. The real power of this would be to combine it with network frameserving, where your watch folder is somewhere on your network that both of your computers can access; your host machine is simply dishing out frames, while the render machine is the one doing the heavy lifting. This would all be happening in the background, thanks to the AME queue and the new timeout capability of the FrameServer. I did a screen recording of this iteration of the plug-in in action; as before, please review and let me know if you have any questions. Click to view MP4 online or right-click and Save As to view locally. ... View more

Interestingly enough, the Premiere Pro CS5 5.0.3 update that just became available actually seems to make the frameserver work faster and more smoothly. Frameserved sections that were a little chunky to both playback or randomly access are now much more responsive. Wish I'd thought to have done a comparison test before installing the update--that would confirm that this isn't just a placebo effect--but I guess the most important fact is that the frameserver continues to function with the update. ... View more

ANOTHER UPDATE: I had just completed a screen recording of the FrameServer in action, when lo and behold, another new version showed up in my inbox. As such, I've done a screen recording using this latest version, which demostrates the plug-in's functionality and some of the new features. New in this update are a couple of new color space export modes--UYVY and VUYA--and the frameserving status is now integrated with the Export and Queue processes. With Export, there is no "frameserving" pop-up; instead it is the simple Encoding pop-up we're accustomed to, and with Queue, the status bar now shows the vide frame rate and audio sample rate. This contributes to a much cleaner interface and less clutter with the frameserver. At this point, the only major hurdle left is the auto timeout function; this might appear today, but I don't know for certain. When I do receive that version, I'll do another quick screen recording to show how that functionality will work. Please let me know if you have any questions or comments after you view the video below. If you can help push us closer to a final release version, your support would be greatly appreciated. Click to view MP4 online or right-click and Save As to view locally. ... View more

Right now, there isn't a testing version available; since all the funds have not been collected yet to pay the programmer who is adapting the frameserver to 64-bit, it hasn't been made available for the general public. It was entrusted to me that I not distribute this version, and for the sake of seeing a final version with all the new functionality, I must respect those wishes. Once the money has been raised in full, the plug-in will be made available for general release. I'm going to do a screen recording here shortly of the plug-in in action, as proof of its functionality and new features. I can understand anyone's reluctance to contribute financially to the project--I was reticent at first--but it would help us bring this project to a successful close. If you feel you can contribute even a few dollars, a page has been set up with several donation options: http://photomir.dn.ua/debug/index.html I'm putting in a few more bucks in a moment to help speed things along. I'll try to have a screen recording up within an hour. ... View more

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... ... View more

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 ... View more

But first I would like to see this interlaced bug fixed since my all material is interlaced and I want to keep it interlaced after export. Absolutely; obviously, this is critical to proper functioning of the frameserver. The developer is aware of the issue and working on a fix. I'm not sure if this was a regression introduced when the frameserver was converted to 64-bit, or just an issue with how the existing frameserver works with CS5. Clearly, this will be fixed. Second question is what is codec speed? Realtime or? I am asking because Frameserver for CS4 was really slow (cca. 10% of relatime). It was not connected to my config (which is very good) because CS3 frameserver encoded with 120% of relatime. General operation of SD footage seems fast; check out the screencasts above for some demonstrations of SD footage playing back and encoding. However, are you talking about effected or non-effected video? A clip or sequence without any (or many) effects plays back in realtime and randomly jumping around in the signpost AVI is very responsive. Obviously, once you stack a couple render-intensive effects on a clip, encoding and frameserving are going to slow down. Other factors like the encoder you're using and the format to which you are encoding are going to come into play as well. HD, on the other hand, seems to be less responsive. Again, the developer is working on optimizing this, so there should be improvements. ... View more

Not yet; the debug version I'm testing at this point doesn't actually even have the parameters in the Export Settings window. That part, however, is complete, if you look at the later screencasts above. Apparently the programmer is working on (or has completed) the timeout feature, and I've requested a version of that to test. To me, that ability to queue up exports like this is the major selling point; frankly, AME does most of what I need now, and I was using Sorenson 360 until CS Review came along and basically squashed that. However, I'm still not satisfied with AME's H.264 output; Squeeze does a better job of that, and Handbrake does an even better job for free! This is one of those things that, of course, I could survive without, but I'm sure that once it's available, it's going to open up many new possibilities. ... View more

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... ... View more

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.) ... View more

Ha! Yes, that's usually the case. If you tried every effect and parameter, you might have found it, but sometimes it's just easier to ask I'm well-reknowned for advocating for the Circle effect around here; I make it do all sorts of Stupid Effect Tricks ... View more

Adobe Premiere Pro CS5 * Titling and the Titler ... View more

Alright, I'll bite; I put up some cash for this via PayPal. I'd love to get my hands on the debug version so that I can test it out on a couple of long MPEG2 encodes I need to do. As far as the "timeout" period goes: personally, I think it should just be hard-wired. Make it about 2 minutes or so. It's one less option that needs to be set. Theoretically, it could be short, like 15 seconds, as that should give enough time for a third-party encoder to "see" the signpost file in its watch folder and begin encoding it. The frameserving would likely to be continuous then, as the encoder will just use frames as it needs them. Even if an encode is not that fast, it should still be polling the frameserver at a fairly regular pace. Ultimately, I'm pretty indifferent; whether it's built-in or user-configurable, it doesn't really matter, so long as this function actually works. I'm glad to hear that the developer is open to suggestions like this while we adapt to this new workflow. I don't know of another translation service, short of getting a speaker of both languages between us We'll just make do with good old Google... ... View more

Perhaps an "autopilot" option could be added to the frameserver that would automatically "click" the Next and Stop Serving No more click to next. Right, right; I saw that. Forgot to amend my post. I repeat: I made a deal with a programmer about the automatic stop serving, at a given time the system is idle Got it. You'll have to forgive the back-and-forth. The Google translation leaves a little to be desired. It's too literal at times. Anyway, that's great. Will this be a user-configurable option, or hard-wired into the code. No. I talk about another problem. For example: Upon completion of the first item in the queue, a frame-server itself is turned off. AME started the next item, and on your hard drive, a new file appears. What's next?? How to make a third-party encoder will automatically start coding a new file?? I think this problem does not solve within a frame-server. The only solution is a WatchFolder or custom script for application that support the command line. Who cares about the third-party encoder? If it has watch folder functionality, it will work fine: it's looking at a folder you specify, and when a file drops in there (like our frameserved AVI) it encodes it. The third-party encoders I use mostly already have watch folders, so as far as I'm concerned, as long as the current frameserved AVI has a built-in timeout to shutdown, we're all set. I agree that there doesn't need to be any watch folder functionality built into the frameserver--that's pointless. ... View more

See post 5.  That does not fully answer the question, other than Satish appears to be willing to add to the main project.  That implies a level of support, but I don't think Satish could answer that question until he sees the code.  I assume that he would not add it until it was a ready for release.  Probably a good time for someone to ask him. That's exactly my point: what does that mean? That he provides hosting for it? Support for it? Continued development for it? Whose timetable are we operating on? Etc., etc. Don't get me wrong: I'm all about supporting this, if for no other reason than it's great to see it functioning anew. To be perfectly honest, the benefit of it is rather negligible to me at this point: AME is pretty solid and serves most of my encoding needs and desires. I'd like having this tool in the toolbox, but I won't lose sleep if I don't have it; I've survived over a year without it and adapted my workflows, as I'm sure anybody on CS4 or later did. I'm just reluctant to throw good money after something as nebulous as this right now; Mama didn't raise no altruist If my qualms are settled, I'm on the boat. (PS: mark m - did you pony up for this and receive the debug version you were promised?) ... View more

So, what sort of guarantees As I said in the previous one post, when all is finished, the sources will be given to the officially developer. Later he will make official release. This is the first. Second only to good-natured to me, the attitude of the programmer. At the moment, all my requests to them properly implemented. But has Satish (the original frameserver coder) said that he will maintain the project, even if someone took over the heavy lifting? As far as I recall, he gave up on creating a 64-bit version of DMFS because of the lack of time, interest (his own--not ours!) and resources. My concern would be that, while we now have what appears to be a fully-functioning frameserver, if we do find a bug or want additional features, there is no one to address that without hiring a developer again. So who would be providing support for the frameserver? What is the incentive to the programmer who has been hired to fix bugs? While this is certainly not a guarantee ... But actually before that DMFS was distributed without any warranty too... I have no real reason to not trust you or the programmer or anyone else--everything looks to be on the up and up--but the fact remains that we never paid for the frameserver before, so expectations were fairly low. Now, some of us have a monetary commitment and involvement with the project (or will, soon ), so we want to be sure we're getting a return on our investment. Getting this thing working in CS5 is WELL worth what it's taking to get it going, so no qualms there... I'm just curious as to where we go from here. I'm not expecting a warranty, necessarily, but no one had a penny invested in this before. ... View more

taravasya wrote: Yep. I made a deal with a programmer about the automatic stop serving, at a given time the system is idle. Your turn. How to implement catch the next file with encoder? Just do the same to start encoding. Perhaps a checkbox called "Automatically Start and Stop Serving" could be added to the Video options for the plug-in. Make it so this can be saved in a preset, like most of the other options, and then you can queue up a bunch of files/sequences in AME and apply the preset to all of them. Once the AME queue starts, it'll start frameserving the first queued encode, and after the frameserver detects that it's not serving frames any more for a certain duration of time, it will terminate the current frameserving and go on to the next. I think a timer is the only way to do this; the frameserver isn't going to have knowledge of what the third-party encoder is doing, so it can only measure its own time spent not doing anything. That should be good enough to provide automatic termination, I think. Does that all make sense? (This is getting good!) ... View more

taravasya wrote: you can queue up several frameserved items in AME I've been more thought. If  we make an automatic stop serving, then queue from AME can use those  programs for which provided a "watch folder" But then create queue, need to ensure to it that would be the name of each output file to  be unique. Yes, that's exactly what I'm talking about. Obviously, there needs to be some sort of "intelligence" on the part of the frameserver to know when to terminate its current process, and then relaunch; the AME queue, as far as I can imagine, would be able to handle the relaunching of the frameserver. Perhaps an "autopilot" option could be added to the frameserver that would automatically "click" the Next and Stop Serving buttons when there is a lack of serving activity for a certain duration of time--60 to 120 seconds, for example. I don't think we need to worry about unique names too much as it appears that the plug-in already respects the name of the queued sequence or file. So long as those are different, there shouldn't be any problems. Obviously, your third-party encoding app needs watch folders, but I think many of the major ones do--Sorenson Squeeze, for instance. The reason I'm interested in the queuing ability is that, theoretically, with the capability of network frameserving, we can effectively offload our encoding to another computer and continue working on the primary computer, with no major hit in performance. As far as I'm concerned, that's the main reason I'm interested in this plug-in. ... View more

OK, I'm somewhat interested in this. I was really hoping that it was going to let us use the AME queue to set up multiple exports, but even though you can queue up several frameserved items in AME, it doesn't look like it will close a previous connection and set up a new one. That would really be worth paying for, but this is impressive nonetheless. So, what sort of guarantees do we have that we're actually going to get a fully functioning product, or any product, for that matter? It's obvious that the plug-in is working now, but that doesn't mean we'll wind up with that. I'm assuming that if we donate, we won't have to pay for anything again, and we'll receive any updates for free. Do we have a means of communicating with the coder to fix bugs or add features, or is this sort of a matter of "you get what you get?" Anyway, I'm intrigued. ... View more

I just when back and uninstalled Premiere and re-installed it, to see what was going on and I was totally wrong. That seems a bit extreme for such a minor point Anyway, my goal wasn't really to call you out on it; just didn't want anyone else to think that something wasn't happening when it should be (when it really won't). Or, something like that. It's all good ... View more

What I am talking about is when you first enable the hardware rendering mode the Maximum Render Quailty mode is automatically set to ON by Premiere CS5.  At least that is how it worked on my systems. I don't believe that to be the case at all. Turning on hardware acceleration is a project-level setting (that seems to trickle from project to project, after it has been turned on), whereas Maximum Render Quality (the checkbox) is a sequence setting that is not automatically set, ever. I don't believe there is a connection, intrinsic or inherited, between the two. Unless you're not talking about MRQ (the checkbox), but rather the enhanced rendering capability of hardware MPE... ... View more