Subject: [AVTCORE] Comment on draft-westerlund-avtcore-multistream-and-simulcast

From: Cullen Jennings <[email-masked]>
Date: Wed, 20 Jul 2011 07:36:04 -0700

In the case were we want to use SDP to indicate video streams are simulcast of the same thing, I think it would be better to use the SDP grouping framework instead of using SSRC to indicate this. 

I also wonder, why not just use layered codecs, seems like outperform the simulcast approach. I read section 3.1 but don't really find it convincing that this simulcast is better than layered codecs.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 20 Jul 2011 07:43:47 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Cullen Jennings (fluffy)
> Sent: Wednesday, July 20, 2011 4:36 PM
> To: IETF AVT WG; IETF MMUSIC WG
> Subject: [MMUSIC] Comment ondraft-westerlund-avtcore-multistream-and-simulcast
> 
> 
> In the case were we want to use SDP to indicate video streams are simulcast of the same thing, I think it would be better to
> use the SDP grouping framework instead of using SSRC to indicate this.

As in:
https://datatracker.ietf.org/doc/draft-begen-mmusic-redundancy-grouping/ 

> I also wonder, why not just use layered codecs, seems like outperform the simulcast approach. I read section 3.1 but don't
> really find it convincing that this simulcast is better than layered codecs.

The draft above provides some motivation why people would wanna transmit the same thing twice or more.
 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 20 Jul 2011 08:26:38 -0700

On 7.20.2011 07:36 , "Cullen Jennings" <[email-masked]> wrote:

> 
> In the case were we want to use SDP to indicate video streams are simulcast of
> the same thing, I think it would be better to use the SDP grouping framework
> instead of using SSRC to indicate this.
> 
> I also wonder, why not just use layered codecs, seems like outperform the
> simulcast approach. I read section 3.1 but don't really find it convincing
> that this simulcast is better than layered codecs.
> 

I read the word "scalable" -- can't help to chip in...

>From Magnus' draft, section 3.1, second-to-last paragraph characterizing
scalable coding, with inline comments:

> The scalable video encoding requires a more complex encoder compared
>    to non-scalable encoding.
> 
This is true from an implementation complexity viewpoint.  It is not
necessarily true from a cycle viewpoint, at least not in the encoder.  I
would argue that, in most practical cases, highly optimized scalable and
simulcast encoders require about the same number of cycles to code similar
resolutions.  Perhaps within a +/- 10% range.
In the decoder, modern standards such as H.264 SVC allow for something
called "single loop decoding", which keep the computational complexity at
only marginally higher levels than for non-scalable decoding of the highest
simulcasted solution.  There are cases where layered decoding actually takes
fewer cycles (at very high bitrates, where the overhead due to entropy
decoding of the less efficient simulcasted stream outweighs the complexity
through cross-layer prediction).
> 
> Also, if the resolution difference is big,
>    the scalable codec may in fact be only marginally more bandwidth
>    efficient, between the encoding client and the mixer, than a
>    simulcast that sends the resolutions in separate streams, assuming
>    equivalent video quality.
> 
This is correct, but it's only half of the story.  One operation point for
which most scalable codecs today are optimized is 2:1 spatial scalability,
meaning that the base layer is half the resolution in both dimensions or 1/4
of the pixel count.  Another one is (roughly) 1.5 scalability, with 720p to
1080p in mind.  SVC works still reasonably well at 1:3, although this is not
a common operation point.
The second half of the story is that SVC (as well as previous layered coding
standards) do allow for multilayer scalability.  If you know how to
implement this (it's not trivial), you get quite a bit of the gain, with the
additional advantage of having intermediate operation points that you can
use when video pictures are zoomed under user control.
In either case, modern scalable video standards, well implemented, are
always better than simulcast from a bandwidth viewpoint.  And should be.
That's information theory 101.

> 
> At the same time, with scalable video
>    encoding, the transmission of all but the lowest resolution will
>    definitely consume more bandwidth from the mixer to the other
>    participants than a non-scalable encoding, again assuming equivalent
>    video quality.

Again, this is correct.  Once again, though, only part of the story.
First, he overhead of scalable coding over non-scalable coding of the
highest resolution has decreased to levels that may not quite be background
noise, but not much higher either.  You may wish to take a look at a
document Alex Eleftheriadis and me wrote for rtcweb,
http://tools.ietf.org/html/draft-wenger-rtcweb-layered-codec-00.  It
contains a reference to the characterization tests conducted by MPEG.  Most
tests performed in academia roughly mirror those results.  Second, most of
us sit behind highly asymmetric links, such as cable modem or DSL.  In such
environments, an overhead (even a large one) for the largest picture
resolution is less penalizing than an overhead on the sending side.  Sending
bits are more expensive than receiving bits.

What the draft has omitted are SVC's superior error resilience properties
and congestion control options, when being used in an appropriately designed
system environment.  Some of that stems from temporal scalability (which
modern non-scalable video coding standards include in an occasionally
crippled form), but a lot more comes from spatial scalability.  Alex and my
draft cited above provides some input.

Regards,
Stephan

> ___________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 21 Jul 2011 11:24:44 +0200

On 2011-07-20 16:36, Cullen Jennings wrote:
> 
> In the case were we want to use SDP to indicate video streams are
> simulcast of the same thing, I think it would be better to use the
> SDP grouping framework instead of using SSRC to indicate this.

Cullen, I recommend that you go read the draft again.

We are proposing to use SDP grouping framework. We suggest that one
defines two grouping semantics SCS and SCR. One for grouping media lines
where one want to send different simulcast versions, another for
indicating the willingness to receive simulcast over a group of media
lines.

This is to enable simulcast only in one direction and to ensure that we
get offer/answer behavior. The grouping semantics is what is used to
negotiate the actual usage of simulcast or not.

We do have the SRCNAME but that is for actually indicating how different
streams map to different sources. This becomes important when an
end-point has more than one source of the same media type it want to
simulcast, like for example multiple cameras in a telepresence room.

The SRCNAME SDES item doesn't need to be in the SDP, it is only included
in the examples to show that it is possible to have them to speed up
acquisition of this information.

> 
> I also wonder, why not just use layered codecs, seems like outperform
> the simulcast approach. I read section 3.1 but don't really find it
> convincing that this simulcast is better than layered codecs.

Layered coding is less efficient to reach a particular quality level
than a stream that is encoded for that particular level without any
additional quality levels.

This means that layered encoding is guaranteed to be less efficient in
the leg from a central mixer to a receiver for selecting a given media
quality.

Layered encoding is however a bit more efficient in the leg from the
media source to the mixer than simulcasting.

The exact levels of gain varies with the target points, the number of
qualities etc.

We see that a clear use case for combining simulcast with codecs that
has certain scalability features. For example using H.264/AVC or SVC to
provide temporal scalability, but use simulcast for resolution changes.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Stephen Botzko <[email-masked]>
Date: Thu, 21 Jul 2011 07:12:44 -0400

in-line
Stephen Botzko

On Thu, Jul 21, 2011 at 5:24 AM, Magnus Westerlund <
[email-masked]> wrote:

> I agree that simulcast is important, including the case where two different
codecs are used.  In that scenario, the resolution might be the same.