Another way (that I know is in production) is to use RTP with a thin shim layer (length fields) to provide packet separation, straight over TCP. If we are certain we have to support RTP-over-UDP, that might be the solution that has the lowest extra implementation cost over the UDP solution. But I suspect this will have to be decided based on a set of requirements, not just a beauty contest. What is the added value of the MPEG-2 wrappers? On 01/17/11 18:23, Marshall Eubanks wrote:
On Jan 17, 2011, at 10:59 AM, Bernard Aboba wrote:
+1.
One place where we could "spend our energy wiser" might be on enabling interoperability of HTTP transported realtime media. Although peer-to-peer traffic is more desirable when possible, "HTTP fallback" is in practice required a significant fraction of the time, due to the prevalence of highly restrictive firewalls. I would agree, and that raises the issue of the "wrapper" for HTTP streaming. Note that Apple uses MPEG-2 TS for the wrapper for its live http video streaming.
( Each media file MUST be formatted as an MPEG-2 Transport Stream, an MPEG-2 Program Stream, or an MPEG-2 audio elementary stream - http://tools.ietf.org/html/draft-pantos-http-live-streaming-01 )
While this is certainly standards based, I do not think it matches or interoperates with anyone else's HTTP streaming. And, of course, this is an I-D still. Flash also does http streaming, but I believe it uses its own, proprietary, wrapper.
So, is specifying a media transport protocol for http streaming in scope ?
Regards Marshall
From: stefan.lk.hakansson@ericsson.com To: tom.taylo@huawei.com; harald@alvestrand.no; Markus.Isomaki@nokia.com Date: Sat, 15 Jan 2011 15:17:51 +0100 CC: rtc-web@alvestrand.no; dispatch@ietf.org Subject: Re: [RTW] [dispatch] Charter proposal: The activity hitherto known as "RTC-WEB at IETF"
I agree that at least for the time being it is more fruitful to focus the energy elsewhere. There is plenty of useful work that can be done about media transport (the datagram service and the potential bytestream ) and the associated APIs, and I suggest we focus on that. We can try our luck with the codec thing later on. I agree. Codec discussions seem to go on forever, and we could spend our energy wiser.
Stefan
PS Sorry for answering late, but I did not follow dispatch. I thought all related messages would go on rtc-web as well. So those of you who do not follow dispatch: perhaps you should look into the dispatch archive. _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch