[hydra-dev] Some media thoughts

Joshua Colp jcolp at digium.com
Thu Apr 29 11:09:10 CDT 2010


----- Original Message -----
> All,
> 
> I've posted some design notes on media interfaces in my personal space
> on the wiki. An issue I describe is whether a MediaOperation (as
> defined in the Service Discovery white paper) should be able to
> support multiple streams, or does this simply make the design
> needlessly complex.

I've given this some thought and think that we'll definitely have to have
support for a media operation supporting multiple streams. One of the cases
that came to mind was passively recording all streams (audio and video) into
a single file.

The problem I can see us running into is expressing this when requesting that
it be done. It's entirely possible for streams to start from one source, converge
on a media operation, and then diverge. It's also possible that each stream will
need to be addressed totally individually. I suppose one way is passing in a class
containing a sequence of multistream operation descriptors, and a sequence of single
stream operation descriptors. Each stream would still be addressed individually when
building a graph but the multistream operation descriptors could have unique identifiers
so they could also be part of the resulting graph, in the position wanted even. Meh
that was just a random thought as I was typing this out.

What purpose could the major media type enum serve? I'm coming up empty. I also think
the isCompressed boolean isn't needed either.

I don't think having an enum for MediaQueryResultType provides enough indication
in the case of being partially supported. Sure, it indicates that you won't get
exactly what you asked for but how close to what you asked for will you get? We
should be able to get that information and be smart about our usage. Heck, to
borrow from the speech recognition world a bit a confidence score would do that.
A number from 0 to 100. That gives us a much greater range to work with. The media
operation just responds with a number, we sort them, and boom we know which operations
will give us the results most closely matching to what we asked for.

-- 
Joshua Colp
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:  www.digium.com  & www.asterisk.org




More information about the asterisk-scf-dev mailing list