[AG-DEV] Re: media tools (was Re: [AG-TECH] AccessGrid 3: What information is available)

Justin Binns binns at mcs.anl.gov
Thu May 26 09:03:50 CDT 2005

I think it's clear that no one wants to deal with C++/Tcl/Python in one 
app, which is precisely the driving force behind the desire to 
re-factor.  If someone wanted to write an AG-native video solution right 
now, for instance (i.e., a native Node Service that directly captured 
and streamed video, for instance), they'd have to use all three 
languages - the AGTk as it exists (2.3.x) requires Python for tightly 
integrated components.  While language interop is being fixed, I think 
the real point here is that there are plenty of developers who, for 
whatever reason (good, bad, philosophical, technical, other) don't want 
to or can't use Tcl in building their application.  And while I 
recognize that to make an application like vic work the middle layer you 
describe is necessary, the fundamental components (that are already 
written as C++ modules) have no particular need to be bound to one 
middle layer.  It'd be nice if the modules that do capture, encoding, 
decoding, network, etc. could be decoupled from the rest of the system, 
and used independently.  I think that's the desire, and I think it's a 
laudable goal - reduce the number of requirements placed upon the 
developer for use of the fundamental pieces, and the pieces will be used 
more widely.  Tcl is a big sticking point right now for a lot of people, 
not because Tcl is bad (I'm really not making a philosophical point 
here), but because Tcl isn't always an option.

Justin Binns

Andrew Swan wrote:

>Rhys Hawkins wrote:
>>I'm going to try and avoid language wars as best as possible, but I
>>need a starting point to explain what I would like to happen. I believe
>>that the lower levels should be C, my reasons are:
>> - libcommon is C and it works
>> - most free/OS codecs are in C/C++
>> - capturing interfaces are in C
>> - better access to platform specific services for performance (eg
>>Quicktime on Mac, DirectShow in win)
>right, i don't think there is any disagreement about this and
>this is indeed how the tools are currently organized.
>>So what I would like to see developed is a C library(ies) of rtp et al,
>>capture interfaces, codecs. This can then be wrapped into whatever
>>higher level language you want. For the AG this would probably be
>>python, with the GUI in wxPython. In terms of the VIC code, this could
>>be achieved by ripping out the TCL/TK stuff from the codecs in VIC, ie
>>so the decoders no longer derive from TclObject and modify the
>>interfaces as appropriate. How feasible is this?
>>The benefit of this is that anybody could use this library, wrap it in
>>another language if they so desire(python, java, tcl/tk) and write their
>>own consumer or producer app and *know* that they will be compatible
>>with other video applications used in the AG. And if we have a common
>>stable base, then we might finally get away from H.261 only AG sessions!
>it is feasible but i don't think it is very desirable.  to dive
>down slightly deeper, there are really 3 software "layers" in
>vic.  at the lowest level are the codecs, network stack, etc.
>written in c++.  at the top level is the user interface, written
>in tcl/tk.  between these layers is code that handles the
>creation, configuration, and cleanup of the low level objects.
>this is the code that, for instance, creates the pipeline of
>grabber-encoder-transmitter-network needed to send video and
>the pipeline of network-decoder-renderer needed to receive and
>display video.  this code reacts to events from the low level
>(e.g., a new source begins transmitting or an existing source
>changes formats).  it also reacts to events from the ui (e.g.,
>the user clicks on a thumbnail to begin displaying a sender
>or the user changes the resolution at which a stream is to be
>the issue is that both this middle layer and the ui layer are
>written in tcl.  if you want to throw tcl out completely and
>rewrite user interfaces in python, you also lose that middle
>layer and have to re-implement it in python as well.  assuming
>you do this, you now have two implementations of the middle
>layer, one in tcl and one in python.  any experienced software
>developer will agree that that is a situation to be avoided if
>of course, another compromise would be to leave the tcl middle
>layer alone and to have apps that include c++, tcl, and python,
>all in the same address space.  can we agree that is something
>that nobody wants?

More information about the ag-dev mailing list