[plumi-discuss] future of plumi / transcoding services

[Andy Nicholson]

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