[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] questions about grouping media streams in RTP and SDP (RFC3388 etc), advice needed
RFC3388 tagging/grouping cannot be used
- simultaneous encoding is explicitly forbidden (no Multiple
Description Coding)
- grouping of layers explicitly forbidden (no Layered Coding)
I talked about this in my presentation at IETF (page 6):
http://www3.ietf.org/proceedings/05nov/slides/avt-3.pdf
My presentation was about standard-compatible Multiple Description
Coding (MDC). You can find the draft here:
http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-vitali-ietf-avt-mdc-lc-00.txt
Your scheme is in fact an unbalanced multiple description coding scheme,
isn't it? You transmit the full video and a low-resolution video to be
used for concealment (1+1/4).
The question of dependency between streams has also been raised for the
new Scalable Video Codec (SVC).
Andrea
Dave Singer wrote:
> Hi
>
> we have a need to group together two media streams, in the style of RFC
> 3388 <http://www.ietf.org/rfc/rfc3388.txt> but we're unsure whether an
> existing group type is suitable or not, and if it's not, we'd like to
> agree on a new one, and document it (presumably in an RFC).
>
> What we have is a normal media stream, and a separate 'repair' or
> 'entry' stream, that can be used when tuning in, or after loss, but is
> otherwise un-needed. An example might be a video stream with a low
> I-frame interval (say every 15 seconds), with a repair stream which has
> only I-frames that are equivalent to the time-parallel non-I frame, at a
> frequency of say 1 per second.
>
> It's not clear to us whether this is "one media flow" in the sense of
> FID, or not. The example offers AMR and GSM audio, which are
> alternatives, and DTMF tones along with audio, which are supplementary
> to each other. Perhaps we fall afoul of this restriction:
>
> "An application that encodes the same media using different codecs
> simultaneously MUST NOT use FID to group those media lines."
>
> or this one, for layered encoding:
>
> "FID MUST NOT be used to group "m" lines that do not represent the same
> information." (Though how DTMF tones and their associated audio pass
> this test is not clear).
>
> Nor is it clear that the FEC group of RFC 4756 is right, either. For a
> start, we may wish to use this new ID in combination with FEC, and
> secondly this tune-in stream has different characteristics. For
> example, one can typically ignore all FEC and (as long as there are no
> errors) decode the stream correctly. Ignoring the tune-in stream
> entirely may mean that you will never find a tune-in point, making the
> normal stream useless.
>
> So, can we use FID for associating a repair stream with its base (we tag
> the streams so we know which is which, of course)?
>
> p.s. RFC 4756 claims in the IANA section that the FEC group is
> registered under SDP characteristics, but actually I can find no
> registry anywhere in IANA of group types.
>
>
--
______________________________________________________________
Andrea VITALI andrea.vitali at st.com
tel (+39) 039 603 7244 mobile (+39) 347 93 08 433
fax (+39) 039 603 6129
STMicroelectronics
Centro Direzionale COLLEONI - Palazzo "DIALETTICA"
20041 Agrate Brianza (MI) ITALY
______________________________________________________________
begin:vcard
fn:Andrea Vitali
n:Vitali;Andrea
email;internet:andrea.vitali at st.com
tel;work:+39 039 603 7244
tel;fax:+39 039 603 6129
tel;home:+39 035 34 08 14
tel;cell:+39 347 93 08 433
x-mozilla-html:FALSE
version:2.1
end:vcard
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt