RE: [rtcweb] H.264 SVC and BUNDLE

Hi,

>There is an ongoing discussion on the MMUSIC list about the interaction
>between BUNDLE and dependency groupings (which are used in RFC 6190 to
>describe linkage between layers).  See:
>http://www.ietf.org/mail-archive/web/mmusic/current/msg09520.html
>
>The issue is not so much about exactly how BUNDLE and existing SDP
>functionality interact (I am assuming that will get figured out eventually),
>but rather about the implications of using evolving SDP proposals in an API.
>
>Do we expect the SDP output by the API to change as the IETF drafts change?
>
>Or are we really talking about "dialects" of SDP, one spoken between an
>application and the browser (presumably maintained by W3C) and another
>dialect spoken on the wire (presumably maintained by IETF MMUSIC) that
>growing increasingly out of sync over time?

Well, I would of course hope that the API uses the BUNDLE RFC - which is why trying to solve the BUNDLE issues is very high at least on my priority list :)

(That's the reason I was pinging about the SVC issue, but I'll take that discussion on the MMUSIC list.)

But, I guess that applies to whatever IETF mechanism we want to use.

Regards,

Christer




-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of
Christer Holmberg
Sent: Wednesday, August 29, 2012 11:50 AM
To: public-webrtc@w3.org; rtcweb@ietf.org
Subject: [rtcweb] H.264 SVC and BUNDLE

Hi,

At the telco yesterday one of the Microsoft guys claimed that H.264 SVC does
not work with BUNDLE, but he didn't have the details.

Could someone please explain the reason why he/she doesn't think H.264 SVC
work with BUNDLE?

(Note, that if using the same port for the different codec layers is a
problem, then it's not a BUNDLE problem - it's a generic multiplexing
problem.)

Thanks!

Regards,

Christer
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

Received on Wednesday, 29 August 2012 19:24:52 UTC