Skip navigation

How to frameserve from Premiere CS5?

Sep 23, 2010 9:54 AM

  Latest reply: nitrobg, Oct 20, 2013 9:29 AM
Replies 1 2 3 4 Previous Next
  • Currently Being Moderated
    Dec 1, 2010 5:53 AM   in reply to taravasya

    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!)

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 1, 2010 6:09 AM   in reply to taravasya
    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 1, 2010 8:23 AM   in reply to taravasya

    --

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 1, 2010 8:48 AM   in reply to taravasya
    Perhaps an "autopilot" option could be added to the frameserver that would automatically "click" the Next and Stop Serving

    No more click to next. Look very closely:

    http://photomir.dn.ua/tutorials/adobe/temp_blogs/debugmode-frameserver -cs5/debugmode-frameserver-cs5.html

    when there is a lack of serving activity for a certain duration of time--60 to 120 seconds

    I repeat:

    I made a deal with a programmer about the automatic stop serving, at a given time the system is idle

    Next serving will be started automaticaly by AME. We don`t have to do for this anything.

    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.

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 1, 2010 9:46 AM   in reply to Colin Brougham

    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?


    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 1, 2010 9:59 AM   in reply to Stan Jones

    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?)

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 1, 2010 10:06 AM   in reply to taravasya
    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 1, 2010 1:08 PM   in reply to Colin Brougham
    but I'll gladly provide help to any other programmer

    Untill this moment help from him, its full "ZERO" It`s all i can say about it...

    The Google translation leaves a little to be desired. It's too literal at times.

    Sorry,... I do not have another opportunity to communicate with you. Maybe you tell me another alternative?

    Will this be a user-configurable option, or hard-wired into the code

    How you think it will be right? I think better to have a choice...

    I agree that there doesn't need to be any watch folder functionality built into the frameserver--that's pointless.

    OK. I am glad that at least on this issue all clear

    ------

    Now, about the changes, fixes and improvements where necessary. About support...
    Until now, the man with whom I work (programmer), was very diligent, performers and responsive to my requests.
    Example of this last idea, voiced here - automatic stop serving. At the present time his already work on this. While originally, this was no agreement. That is, people just went to my assignment.

    So,... I think if he will be satisfied with pay, we can expect to support him at least for a certain period. Half of year, maybe a year. But  if we will be ve-e-e-e-ery long talk about it, and collect money through these same six  months or a year, then we are hardly able to count on his support. Think about this...

    Good Luck

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 2, 2010 5:52 AM   in reply to taravasya

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

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 5, 2010 6:27 AM   in reply to Stile35_DJ

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

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 5, 2010 6:37 AM   in reply to Colin Brougham

    Thanks, Colin.

     

    Can you briefly summarize how the multiple items queued in the AME feature should work?  I'm not getting my head around the mechanics of it, or how it would be used in the real world.

     

    -Jeff

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 5, 2010 9:34 AM   in reply to Jeff Bellune

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

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 5, 2010 10:08 AM   in reply to Colin Brougham

    Got the idea now, thanks.  The watch folder was the missing piece of the puzzle for me.

     

    Have you had a chance to test the timeout feature at all?

     

    -Jeff

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 5, 2010 10:25 AM   in reply to Jeff Bellune

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 5, 2010 11:38 AM   in reply to Stile35_DJ

    What your source video?

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 5, 2010 11:56 AM   in reply to Stile35_DJ
    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 5, 2010 7:36 PM   in reply to Stile35_DJ

    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:

     

    frameserver-vdub64.png

     

    Tomorrow, I'll try to do a brief screen recording of the frameserver in action, just in case anyone needs further proof

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 6, 2010 7:23 PM   in reply to Stile35_DJ

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

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 7, 2010 5:30 AM   in reply to Stile35_DJ

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 7, 2010 8:26 AM   in reply to Stile35_DJ

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 7, 2010 11:05 AM   in reply to Colin Brougham

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 7, 2010 6:55 PM   in reply to Stile35_DJ

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 8, 2010 6:42 AM   in reply to Colin Brougham

    Thanks so much for getting the word and the demos out there Colin.

    This looks great.

     

    If anyone thinks they might use this can I please urge you to contribute financially to the project, as Colin and I and others have done. Even a small contributions will benefit us all and help us get there soon!

     

    Cheers

     

    Mark

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 8, 2010 6:45 AM   in reply to taravasya

    Taravasya,

     

    Yes, I did contribute a small amount to the project! Thank you for making this happen. Looks like it's nearly there.

     

    Cheers

     

    Mark

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 8, 2010 7:02 AM   in reply to Mark Morreau

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

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 8, 2010 9:32 AM   in reply to Colin Brougham

    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!

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 8, 2010 9:44 AM   in reply to Magnus Allgurén

    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!

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 9, 2010 6:55 AM   in reply to Colin Brougham

    Looking forward to this.

    Just chipped in a few bucks.

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 9, 2010 7:04 AM   in reply to Ann Bens

    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

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 11, 2010 6:15 AM   in reply to Stile35_DJ

    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!

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 12, 2010 8:46 AM   in reply to Colin Brougham

    I just donated to the project. I may or may not ever use the DMFS functionality. I'm just a big fan of this type of innovation - user driven.

     

    Steve Brame

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 14, 2010 8:56 AM   in reply to Colin Brougham

    Colin, thanks for your efforts and the demo video.  Just donated my tidbit and am eagerly awaiting release.  Will all the donors be contacted, or should we continue to check this thread for updates?

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 19, 2010 12:25 PM   in reply to Stile35_DJ

    Hello. I am also interested in Frameserve for AP.CS5. Answer please how to get it? I use the Google translator, and I do not know if everything I understand, is it enough to pay for this site http://photomir.dn.ua/debug/index.html any amount to get it or a concrete. write step by step what to do to get frameserve.

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 19, 2010 12:37 PM   in reply to arturpu

    Nothing has to do. The required amount already collected. It remains just wait until the developer will finish the final version of the plugin. At the moment, remained unresolved only one bug (if I remember correctly). Once work on it finished, everyone will be able to use it. I think it very quickly becomes publicly available. You can optionally just donate any amount which you find comfortable, that would stimulate the further development of the project ... But this does not necessarily ...
    I hope that within the next 7-10 days the final version will be ready.
    Good luck!
    PS / Do you speak Russian?

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 19, 2010 12:42 PM   in reply to taravasya

    respected imergo, and everyone else who took part in paying for the work of the programmer. Firstly thank you all very much. And secondly, you can just watch this topic. This forum will be the second place, which I'll post a link to the final release of the plugin ...
    First place will be a forum where it all began (the above I pointed him)

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 19, 2010 12:46 PM   in reply to Stile35_DJ

    привет, я польский, я не говорю на русском, но тем быстрее он говорит на русском языке, чем на английском языке.
    Спасибо за ваш быстрый ответ, если вы знаете что-нибудь еще, дайте мне знать в порядке?
    может быть на русском языке:)
    Мой адрес: arturpu@o2.pl

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 19, 2010 1:25 PM   in reply to taravasya

    sory dubel


     
    |
    Mark as:
  • Currently Being Moderated
    Dec 20, 2010 6:54 AM   in reply to Stile35_DJ

    UNEXCITING UPDATE:

     

    The frameserver is about 90% functional right now. A bug with RGB24 frameserving that caused transitions to render weird alpha issues has been fixed, which was the last major bug that was discovered. The frameserver also has a new name: Advanced Frameserver. Keepin' it simple

     

    The last major hurdle that is being worked on is not so much a bug-squashing stampede, but rather some major overhauling to the way the frameserver dishes up frames to external applications. Generally, encoding from a frameserved signpost AVI file is as fast as encoding from an intermediate file. However, there is a significant slowdown when serving from a sequence with render-intensive effects or when using MRQ during export; this is primarily evident when using poorly multi-threaded apps like Squeeze or VirtualDub. However, when encoding to something like CCE or when using the multi-threaded version of Avisynth between the frameserver and VirtualDub, the time differential diminished or disappeared.

     

    So, what the developer is working on is a method to request multiple frames in parallel and cache them, so that encoding applications that maybe aren't as efficient will have a "pool" of served frames to pull from, instead of asking for them one by one. This increases the overhead a bit, since the frameserver will have to cache a certain number of frames, but should be offset by much shorter encoding times. In order to implement this, however, the frameserver needs to be more or less written from scratch, so that's why there haven't been any updates lately. The frameserver is essentially complete; it's just being hot-rodded now

     

    I'll update as we get closer to a revamped version of the frameserver--stay tuned. My thanks to everyone for your interest and support of the project.

     
    |
    Mark as:
Actions

More Like This

  • Retrieving data ...

Bookmarked By (2)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points