How is the status of moving the video logic from urlblast to server? Is this feature planned for one of the next releases?
If it is not planned for the next releases we are thinking about implementing it on our own. Therefore, I would like to know if you already have started or if we have to start from the scratch?
I haven’t started - got derailed working on my presentation for Velocity next week.
It’s at the top of my priorities so if you don’t have something in the next week or so I’ll be starting it then (when I get back from velocity).
If you are running wptdriver (and not just a mobile environment) I can port the urlblaster code to wptdriver as a placeholder and that would only take an hour or so.
Thanks for the offer but moving the logic to wptdriver won’t be a quick solution for us. Since we are still using version 2.13 we would have to merge many manual changes first if we switch to the newest version. Thus, we prefer the direct integration to the server code even if it lasts a little longer.
However, we can offer you help at moving the video functionality to the server. Do you already have an idea which library you wan’t to use and where the best position for integration is?
The plan is to draw individual frames manually using GD, write them out to a temp location as a series of png’s and then use ffmpeg (or x264) to convert the png’s into a video.
The main issues are going to be:
Doing it efficiently. You don’t want to re-draw the whole frame every frame, particularly if it’s only the clock changing. Need to keep one image and just update the relevant parts.
Fonts for the timer. The built-in GD fonts suck so it will be a matter of finding a goot, free font that can be used with GD for the clock. Another option would be to have pre-rendered numbers and just scale those but the kerning won’t be right.
Frame rate. Initially it makes sense to just keep the 10fps and get it working but it would be nice to be able to support the 60fps that we get from mobile video capture.