All things related to multicast

[Frank Fulchiero <>]

On [Jul 25], at 9:58 AM, Greg Shepherd wrote:

Greg, thanks for the feedback. Sorry for the late response...


> > Looking at the entire landscape, yes. But there do not appear to  
> > be that many standards in multicast streaming: UDP vs RTP for  
> > delivery. MPEG2 vs MPEG4 for encoding/decoding (granted, several  
> > parts, levels and profiles). SAP for announce/discovery.
>
> Oh really? Which variation of MPEG4? Who's? Now toss in DRM.

The MPEG4 standards, reference software and bitstreams are well  
documented
http://www.mpegif.org/resources.php

In Part 10 (H264) there are only a handful of profiles and levels  
which would be sensible to use, or are commonly used.
It would not be hard to get a consensus and manufacturer/developer  
support for these, if it does not already exist.
So "variation" should not be a problem.
The situation is a similar to ATSC standards: there are many, but  
only a few are used.

The whole point of open standards is that they are manufacturer  
independent, so "Who" is not a big issue.
Look at the list of companies that belong to the MPEG Industry Forum:
http://www.m4if.org/membercompanies.php
They are all committed to meeting the same set of standards.

Naturally there will be better flavors here and there, but they  
should all work together.
H.264 is young, so it may take another year or so to iron out all the  
kinks.

DRM is only a problem if you are trying to limit viewership. A player/ 
discovery system can't be all things to all people.
That is why I was trying to figure out what would work best for an  
open Education and Research video network.
Even within an open network there are ways to make streams accessible  
to only subsets of viewers without getting into DRM.
If you wanted encryption, there are existing standards that might be  
ported, such as H.325 in videoconferencing.


> > Yes, I realize your focus is for R&E, but the companies behind the  
> > commercial players can't even spell R&E.

That is probably true. But commercial players and broadcasters have  
been working on their own systems for years, along with developing  
metadata standards.
These will undoubtably be used to "monitize" content. I was chagrined  
to already see small ads on my iPod touch at the bottom of the NY  
Times App, for every article. Sheesh, the screen is already small  
enough.

The monitizing approach is unsuitable for R&E, which needs its own  
solutions. Not to say they could not be implemented utilizing the  
same technologies and metadata schema as the commercial broadcasters.


> > I think it's possible to hierarchically structure a long list of  
> > programs to make it more manageable. Good example here again is   
> > iTunes.
>
> But iTunes manages "my" files, which are constrained. If we're  
> going to have countless content sources updated schedules I want a  
> searchable calendar. And I'd prefer it not to require yet another  
> application download as a roadblock to adoption. Stick it on the  
> web and anyone can get to it from any device.

Sorry, I should have explained this better. I was referring to how  
iTunes organizes media such as Radio (over 2,300 streams), and, in  
the iTunes Store: iTunesU and Podcasts. There must be thousands of  
assets here, yet the layout and interface is not overwhelming.

Regarding browser-based schedules that link to streams, the  
technology is already there, nothing new has to be invented, it just  
needs to be refined a bit and used by multicasters.
We have DV guide, http://dvguide.arts.usf.edu/
Gustavus' Channel guide https://gustv.gac.edu/i2.php
and probably other examples I have not seen.
Zap2it, http://tvlistings.zap2it.com/tvlistings/ZCGrid.do, has a nice  
interface that could be used also.

No reason you can't have the best of both worlds: a browser-based  
schedule and the same content visible (maybe in less detail) inside a  
player app, like the Playlist in VLC or iTunes radio stations,  
podcasts, etc. I am not talking about another application, but a  
discovery system built into a media viewer.
An open-standard announce-discovery standard could also be used in  
desktop widgets, smart phone apps, etc.

One question that needs to be answered is whether multicast content  
needs it own announce/discovery system, or whether its content can  
just be rolled into existing unicast announce/discovery. Why  
differentiate between the two?
For example, I uploaded a multicast playlist to an existing popular  
video sharing site, and if you are multicast-enabled, it works fine:
http://blip.tv/file/1126038/



> > Finally, I am not pushing SAPs, just trying to best use them while  
> > waiting for something better to come along. Thanks for all your  
> > comments.
>
> We've been waiting for something better for well over 10 yrs. But  
> then we've also been waiting for the critical-mass adoption of  
> mcast sweep over the Internet....
>
> In the mean time, mcast deployments for IPTV services in edge  
> networks have been rapidly expanding globally. They don't use SAP.  
> The content schedule is provided by some proprietary middle-ware,  
> but then the target devices are proprietary as well.

Right, the middleware and devices are proprietary, which brings me  
back to my point that it would be nice to have an open standard, open  
source announce/discovery/playback system to support the needs of  
R&E. Commercial interests seem to be doing fine developing their own  
solutions, but beyond agreeing on codecs don't seem to be too  
interested in developing open-standard free-to-use ones.

Frank Fulchiero
Digital Media Specialist
Connecticut College