All things related to multicast

[Stig Venaas <>]

Tom Pusateri wrote:
> 
> On Nov 4, 2008, at 5:40 PM, Stig Venaas wrote:
> 
>> Frank Fulchiero wrote:
>>> I think the challenge and goal should be a system that is flexible
>>> enough to be used with hardware boxes, tuners, computer browsers, mobile
>>> browsers, software players, etc.
>>
>> Yes
>>
>>> Not sure why you could not have the best of all worlds.
>>> Besides the technical challenge of devising it, standardizing it, and
>>> getting the content owners to use it!
>>
>> If done right, the channel reflector could work from hardware boxes,
>> tuners or whatever. It's just a matter of using HTTP instead of SAP to
>> retrieve the info. You may need some ways of quering just the relevant
>> data and some way to filter hits, but I don't see any reason why it
>> can't be done.
>>
>> My dream is to be able to search lots of metadata to find interesting
>> content independently of (or not knowing) who is sending it etc. I think
>> the main problem with that though, is to get the content providers to
>> provide the metadata. I'm not impressed with the info people provide in
>> SAP.
>>
>> Stig
> 
> A friend and I wrote a multicast guide a few years back that attempted
> to show available multicast streams on a web page. It listened to SAP
> and parsed the SDP announcements and tried to create the guide based on
> time information in the SDP file. It also allowed you to upload your SDP
> file for inclusion in the guide.

We (UNINETT) tried to do the same. A guide where people could register
manually using a web form or upload SDP files, but it also tried to
collect info from SAP.

> The problem we found was that there was hardly ever any start and stop
> times in the SDP files. So every stream showed up as available when more
> often than not, the content wasn't being sourced.

Yes. We also found that. Initially we also tried to only use the SAP
announcements that were strictly according to spec, and that was only
a small percentage.

> That was just an experiment at making a guide for people to register
> their content with and we used SAP to bootstrap it. SAP doesn't scale
> and we never intended to leave it based on SAP. My point is that the SDP
> files we came across were minimal at best. I would encourage people to
> spend a little extra time to get your SDP files to accurately reflect
> your content and transmission times.

Yes.

> Taking a step back though, this is a decentralized database
> synchronization problem complicated by access control requirements.
> 
> The client needs the SDP file and it can get it via HTTP, rsync, XMPP
> file transfer, email, or a variety of other methods creative people
> might thing of to replace SAP.

Yes, all this is good, and I'm looking forward to a SAP replacement. I'm
a bit worried that metadata will remain a problem though.

Stig

> Tom