-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hey
just to fill everybody on this list in, Ive stopped working with EngageMedia - so Im not working on Plumi 3.0 full-time anymore. However, its likely in the nearby future I will get to work on client projects using Plone , at which time I may get to revisit Plumi, and make some contributions and/or releases. Also I'm still available for support of Plumi 3.0 (beta) and the older releases. I'll be lurking on the list.. Nate Aune wrote: >> I mean, access via the backdoor hack that indytube currently uses >> - ie direct access to the filesystem. You do have this with blobs >> of course, but it is not just a simple file anymore. So you need >> to access it via the real API. As you know, a real implementation >> of transcoding needs to be async w.r.t plone/zope processes. > > have you seen the darksnow.convertdaemon that Thierry Benita from > atReal is using to transcode binaries with richfile.video / > richfile.audio? > https://svn.atreal.net/public/svn.darksnow.org/ConvertDaemon/buildout/buildout.cfg > it uses Twisted and seems to be working already on plone 3 - not > sure about plone.app.blob though. > yeah, i looked, it doesnt seem any different to what the current indytube does ? The current indytube is based on Twisted, and would work with plone 3 - - one would just need to download the files first instead of presuming to grab them "on-disk" based on a filename convention etc. There would be some annonying hacks to push this square peg into a round hole - and going down that path is just continuing to patch over the issue of the disconnect between the videofile and its associated transcoded versions. Hence the development of a new version of the transcoder as a network service. >> I have a grok app that wraps indytube to be a network service - >> which is still alpha , and plumi.mediahost which would be the >> connector product (un started) you can check them out on pypi > > so there is still a lot of work to do in order to get indytube > working with plone.app.blob (via plumi.mediahost)? > It would take about 2 weeks to finish all up I reckon. [btw The name of the new software was not going to carry the 'indytube' label anymore ] The transcoder network service is currently in EngageMedia's svn , but I dont know what they are doing with their svn anymore, its in read-only mode apparently. And anyway, i will move it to a standard open source project hosting service. (on more standard foss hosting service - possibly github?) https://trac.engagemedia.org/projects/browser/plumimediahost/trunk Its a Grok web app - with two functioning queues (for downloading and transcoding) . The major 2 things it gives you over indytube is a webapp GUI to configure the (currently 4) default transcoding settings (for low/high quality FLV and OGG encodings) and the ZODB-backed database of encoding jobs waiting or already done. The connector product would be simply zope event driven -- outbound pings sending a URL to the transcoder when it receives a new event based on the PlumiVideo content type (ie ObjectAddedEvent etc), and receiving back info when the transcoder is finished (all async obv.) -- to connect the transcoded videos to the original video file (via an archetype object possibly or annontations etc) http://svn.plone.org/svn/collective/plumi.mediahost/trunk/ as you know, Im not working on Plone full-time anymore, but their is a good chance I will get to finish up this work on a upcoming client contract, so I may well get to release the transcoder , and the connector product early next year. If nobody else has tagged a Plumi 3.0 release by then either, I will probably do it early next year also, and probably by then it should be compatiable with Plone 4 also. I guess the buildout SVN for the Plumi 3.0 should also move to a more standard project hosting environment. I will let the list know. >> Oh , i decided a while back not to use p4a, to complicated for me >> - I have plumi.content , which is simply a Blob with the attribs >> from the Plumi ATVideo attribs, and plumi.migration which >> migrates from the old plumi content types to the new >> plumi.content. > > oh, so ATVideo is not being used anymore, and now it's called > plumi.content? i can't really blame you for not using p4a.video. > even i find it is overly complicated. > > Nate > All the plumi 3.0 products are in pypi except for the connector plumi.mediahost , but they arent the latest anyway. The plumi 3.0 buildout by default uses the products directly from SVN , checked out via externals into src/, and doesnt use eggs (yet) The final version could/should be changed to uses eggs from the cheeseshop, rather than using the products direct from svn. http://pypi.python.org/pypi/plumi.content/0.2 http://svn.plone.org/svn/collective/plumi.content/trunk/ eg http://dev.plone.org/collective/browser/plumi.content/trunk/plumi/content/content/plumivideo.py have fun, andycat -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrmdwgACgkQGkx7dFvpDjlZSACfVfhqLFNdbT2zhOTD3tOcAZwi 9hoAn0SyWnt4TJgGkdstQE5nQ9Ec6t4w =33TP -----END PGP SIGNATURE----- _______________________________________________ Discuss mailing list [email protected] http://lists.plumi.org/listinfo/discuss
