Re: [EFM] Video distribution
Bob,
One of the encoding/decoding systems allowed us to set the amount of
buffering done. Using this system, various amounts of buffering were
tested. We found that in order to remove most of the buffering, the
latency variance had to be 500us or less. We used long "fiber" facilities
with multiple transmission nodes to simulate long haul systems with that
type of inherent fixed latency. We found that overall fixed latency did
not have much to do with the need for buffering. We used different
combinations of routers and switches with multiple data source/sink points
to create varying amounts of latency variance for the different tests. We
set the quality of the encode/decode/compression to different levels
depending on what the different systems would allow.
The testing that we did was empirical, not theoretical. We were comparing
pure optical data transmission, IP based Internet and intranets, and
prototypes of Ethernet over SONET transmission technologies. We used
different video systems because there was not originally instrumentation
that could measure latency variance as a specific test. We use the video
because it would give us the best subjective awareness of the quality of
data delivery over the different transmission systems. At the time that we
were doing this, no one had any information to give us about how these
systems would perform in different circumstances. As data test systems
became available that would allow us to test for latency variance as well
as latency and data loss, we were able to quantify the issue of latency
variance in addition to the normal QOS issues addressed in the
industry. What we found out was astounding. It gave us an appreciation as
to why many businesses demand leased circuit services for their applications.
Thank you,
Roy Bynum
At 03:48 PM 9/10/2002 -0400, Bob Gaglianello wrote:
>Roy,
>
>What you have left out of this discussion is what mode your MPEG-2 encoder
>was in for the interactive video test. For standard MPEG-2 with I, P and B
>frames, there is an inherent 3-6 frame delay just do to the
>encoding/decoding process. There are other modes for lower latency but
>they have a substantial bandwidth penalty because they do not code
>B-frames, only I and P-frames. At 7-mbit/sec I assume that is the mode you
>were using.
>
>I DO NOT believe that a 1 msec latency variation (jitter) introduced an
>additional 100 msec buffering in the decoders. My feeling is that there
>was already a large buffering delay in the decoder independent of jitter.
>At most, 1 msec of jitter would repeat/drop a single frame which would
>only be 33/16 msecs of perceived latency.
>
>cheers,
>bobg
>
>Roy Bynum wrote:
>>David,
>>At WorldCom, we set up MPEG-2 encoder/decoders for a variety of video
>>test "services". We found that for high quality interactive video at an
>>average bandwidth utilization of 7Mbps, on a 45Mbps data transmission
>>facility, a latency variance of 1ms translated to an additional 100ms
>>buffering in the decoders, which gets translated into additional
>>perceived latency by the end user/viewer. A 200ms perceived latency
>>starts to become noticeable by the end user.
>>Low quality, Internet type video often has a refresh rate of 15 frames
>>per second. That is 60ms between each frame that allows time for each
>>pixel block datagram for the entire frame to be received, decoded, and
>>video buffered before the next refresh. In most cases, it the frame is
>>incomplete, the refresh will be delayed. This type of video can stand
>>Internet type latency variance because of the low refresh rate.
>>Higher quality, 60 frames per second interactive video has 16ms between
>>each frame for all of the pixel block datagrams to be received, decoded
>>and buffered in video memory. With a fixed refresh rate video, if the
>>frame is incomplete, "artifacts" appear on the screen. To prevent these
>>artifacts, on data transmission systems that have high latency or high
>>latency variance, the decoder/video display has to be delayed
>>sufficiently by buffering the received data stream pixel block
>>datagrams. The perceived effect of latency variance is the same as
>>additional base line transmission latency. The actual perception of
>>latency is greater for the effects of latency variance than it is for the
>>fixed though system latency because of the additional buffering and fixed
>>delay in the refresh of the video frames.
>>With a streaming video service, such as broadcast TV/Video, there is
>>nothing with which to compare for any perceived delay. With interactive
>>video, each person has his own actions/voice with which to compare the
>>delay in perceived response from other parties. Any end to end fixed
>>latency and latency variance are doubled, including the encode/decode
>>times as well as the transmission times. While higher speed
>>encoder/decoders will help, a high quality, low latency, low latency
>>variance transmission systems will do more to improve the end user
>>perception satisfaction than anything else.
>>Thank you,
>>Roy Bynum
>>At 06:19 AM 9/10/2002 -0700, David Berman wrote:
>>
>>>I think there is quite a bit of confusion around this. MPEG-2 digital
>>>video is not transmitted screen-by-screen but rather in a datastream
>>>representing different types of frames. The screens are reconstructed
>>>locally by the decoder, after transmission.
>>>
>>>There is no problem with a reasonable amount of buffering to deal with
>>>packet latency, even of the 50 ms Internet variety. It is only the
>>>cost of RAM which is pretty low these days. I can't see EPON latency
>>>being an issue at all.
>>>
>>>Most service providers I have spoken with require two types of video
>>>services for residential subscribers: 1) "Broadcast" video similar to
>>>cable, which is not interactive at all, and 2) Video-on-demand (VOD) in
>>>which case a video stream needs to be controlled by the viewer, with an
>>>interactive response time in the range of several hundred milliseconds.
>>>
>>>-David
>>>
>>>
>>>
>>>--- Roy Bynum <rabynum@xxxxxxxxxxxxxx> wrote:
>>> >
>>> > Kent,
>>> >
>>> > I spent a lot of time at WorldCom in 1998 and 1999 understanding the
>>> > relationship that the characteristics of the transmission facility
>>> > and
>>> > protocols have on the quality deliverability of different kinds of
>>> > video
>>> > services. I found that while a video stream will burst to the
>>> > available
>>> > bandwidth, as long as the bandwidth can deliver a "screen" within the
>>> >
>>> > allowable time for it to be decoded and displayed, the bandwidth can
>>> > be
>>> > restricted to close to that of the average of the video data stream
>>> > rate. This goes for streaming video as well as interactive video.
>>> >
>>> > The issue with interactive video is not the bandwidth as much as it
>>> > is with
>>> > the latency variance inherent with the transmission facility and
>>> > protocols. With low latency variance, streaming video and
>>> > interactive
>>> > video becomes a consistent stream with fixed, predictable,
>>> > utilization. The more that there is a latency variance, the more
>>> > that
>>> > higher bandwidth burst traffic has be supported in order to support
>>> > the
>>> > "screen" rate. Traditionally, IP routers have not been very good
>>> > at
>>> > controlling latency variance. This is where the higher bandwidth
>>> > requirements for video comes in.
>>> >
>>> > Latency variance for non-blocking Ethernet switches, in non overload
>>> > conditions, is the bit time delta between the largest frames and the
>>> > smallest frames. Latency variance for Ethernet over SONET/SDH (X.86)
>>> > is
>>> > 125us because of the OAM overhead window.
>>> >
>>> > At present, EPON appears to be headed for a latency variance in the
>>> > milliseconds. This might do for streaming video to residential
>>> > customers. I do not think that it will do for any type of high end
>>> > interactive video, regardless of the available bandwidth. If any
>>> > kind of
>>> > bandwidth gain is applied to the EPON deployment, it will be no
>>> > better than
>>> > what is in the copper facilities today.
>>> >
>>> > Streaming video can be "buffered" to compensate for latency
>>> > variance. This, however, increases the cost of the video display
>>> > equipment
>>> > because of the additional complexity in managing the "buffered"
>>> > stream. The least expensive would be a system that only needs to
>>> > buffer a
>>> > single "screen" before each "refresh". I do not know if the current
>>> > EPON
>>> > proposals will support that.
>>> >
>>> > Thank you,
>>> > Roy Bynum
>>> >
>>> >
>>> >
>>> > At 01:33 PM 9/9/2002 -0700, Mccammon, Kent G. wrote:
>>> >
>>> > >John,
>>> > >I agree with your comments about higher efficiency when broadcasting
>>> > video
>>> > >to all VDSL nodes. The PON capacity is a constraint for designing
>>> > the
>>> > >system. VOD of course changes the numbers as that traffic would be
>>> > node
>>> > >specific and customer specific depending on the type of VOD service.
>>> > If the
>>> > >PON throughput looks to be insufficient considering all services
>>> > needs;
>>> > >broadcast, VOD, telephony, and data services, an operator could plan
>>> > for a
>>> > >smaller split ratio to the VDSL node. The differential path loss
>>> > >(attenuation range) specification of the optics should be made broad
>>> > enough
>>> > >to handle PONs with low splits for VDSL, for example 1x4 while other
>>> > >operators deploy for large splits for FTTH such as 1x32
>>> > architectures. Thus,
>>> > >the operator could have architecture flexibility in the selection of
>>> > the PON
>>> > >split ratio for the services planned.
>>> > >-Kent
>>> > >
>>> > >
>>> > > > -----Original Message-----
>>> > > > From: John Limb [mailto:limb@xxxxxxxxxxxx]
>>> > > > Sent: Monday, August 26, 2002 9:50 AM
>>> > > > To: 'Mccammon, Kent G.'; stds-802-3-efm@ieee.org
>>> > > > Subject: RE: [EFM] Video distribution
>>> > > >
>>> > > >
>>> > > > Kent,
>>> > > > I'm a little confused. Perhaps you could straighten me
>>> > > > out. If you are distributing digital video from the OLT to
>>> > > > ONUs (even if connected to a VDSL
>>> > > > DSLAM) I would not think that you would need to have an
>>> > > > unused slot remainder since the OLT scheduler could start one
>>> > > > packet as soon as the previous one finished. If you were
>>> > > > sending packets from the ONT to the OLT then I could see that
>>> > > > slot remainders could occur.
>>> > > > If you are serving several hundred subs then you would
>>> > > > probably want to do mostly broadcasting rather then VOD. You
>>> > > > would probably want to use variable rate video coding (rather
>>> > > > than constant rate) in order to get a little more efficiency
>>> > > > and some statistical averaging. Even so, I suspect that most
>>> > > > packets would be max size (as Hugh says).
>>> > > > If you assume an average rate of 3 Mb/s for a high
>>> > > > quality video stream (probably even a little high for some of
>>> > > > the newer VBR codecs) 200 streams would take about 600Mb/s
>>> > > > leaving (plenty?) of room for other data, again confirming Hugh.
>>> > > >
>>> > > > John
>>> > > >
>>> > > > -----Original Message-----
>>> > > > From: owner-stds-802-3-efm@majordomo.ieee.org
>>> > > > [mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of
>>> > > > Mccammon, Kent G.
>>> > > > Sent: Friday, August 23, 2002 6:22 PM
>>> > > > To: 'gkramer@xxxxxxxxxxx'; Thomas.Murphy@xxxxxxxxxxxx;
>>> > > > stds-802-3-efm@ieee.org
>>> > > > Subject: RE: [EFM] Minutes of P2MP Optics conference 22nd Aug
>>> > 20002
>>> > > >
>>> > > >
>>> > > >
>>> > > > Glen,
>>> > > > Referring to your comment about frame size distribution from
>>> > > > actual traffic.
>>> > > >
>>> > > > > The size of unused slot remainder depends on frame size
>>> > > > distribution.
>>> > > > > This distribution for today's traffic is known and there
>>> > > > exist formula
>>> > > > > to calculate this unused remainder (for the case when assigned
>>> > slot
>>> > > > > size has no correlation to the frame sizes).
>>> > > >
>>> > > > Does anyone in the group have a traffic sample from a network
>>> > > > transporting digital video streams to give frame size
>>> > > > distribution? For example, a traffic sample for digital video
>>> > > > over fiber to a VDSL ONU to serve several hundred VDSL lines
>>> > > > to a residential gateway. That scenario may be a good one to
>>> > > > look at for traffic on a residential GigaPON connected to
>>> > > > multiple VDSL ONU locations with data and switched digital
>>> > > > video content.
>>> > > >
>>> > > > -Kent
>>> > > >
>>> > > > > -----Original Message-----
>>> > > > > From: Glen Kramer [mailto:gkramer@xxxxxxxxxxx]
>>> > > > > Sent: Friday, August 23, 2002 9:44 AM
>>> > > > > To: Thomas.Murphy@infineon.com; stds-802-3-efm@ieee.org
>>> > > > > Subject: RE: [EFM] Minutes of P2MP Optics conference 22nd Aug
>>> > 20002
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > Tom,
>>> > > > >
>>> > > > > This is to address action item #2 from the minutes.
>>> > > > >
>>> > > > > 2. Efficiency model based on guard bands and traffic type -
>>> > P2MP
>>> > > > > group?
>>> > > > >
>>> > > > >
>>> > > > > There are 3 types of overhead (or bandwidth loss):
>>> > > > >
>>> > > > > 1. Cycle overhead. This is overhead used by guard bands
>>> > (including
>>> > > > > CDR). It is measured as a number of guard bands in one cycle.
>>> > This
>>> > > > > number at least equal to the number of ONUs, but may be
>>> > > > even larger if
>>> > > > > we grant per LLID and there are multiple LLIDs per ONU.
>>> > > > >
>>> > > > > 2. Slot overhead. This overhead arises when granted slot does
>>> > not
>>> > > > > take into account frame delineation in a buffer. Since
>>> > > > frames cannot
>>> > > > > be fragmented, a frame that doesn't fit in the remainder of a
>>> > slot
>>> > > > > will be deferred to next slot (in next cycle), leaving current
>>> > slot
>>> > > > > underutilized.
>>> > > > >
>>> > > > > The size of unused slot remainder depends on frame size
>>> > > > distribution.
>>> > > > > This distribution for today's traffic is known and there
>>> > > > exist formula
>>> > > > > to calculate this unused remainder (for the case when assigned
>>> > slot
>>> > > > > size has no correlation to the frame sizes).
>>> > > > >
>>> > > > > Few protocol proposals consider how to eliminate unused
>>> > > > slot remainder
>>> > > > > completely, but it looks like it will require changes to the
>>> > frame
>>> > > > > format. P2MP group is still debating about it.
>>> > > > >
>>> > > > > 3. Frame overhead. That includes IFG and headers. Nothing
>>> > > > we can do
>>> > > > > about it.
>>> > > > >
>>> > > > > Glen
>>> > > > >
>>> > > > > > -----Original Message-----
>>> > > > > > From: owner-stds-802-3-efm@majordomo.ieee.org
>>> > > > > [mailto:owner-stds-802-3-
>>> >> > > > > > efm@xxxxxxxxxxxxxxxxxx] On Behalf Of
>>> > Thomas.Murphy@xxxxxxxxxxxx
>>> > > > > > Sent: Friday, August 23, 2002 1:57 AM
>>> > > > > > To: stds-802-3-efm@ieee.org
>>> > > > > > Subject: [EFM] Minutes of P2MP Optics conference 22nd Aug
>>> > 20002
>>> > > > > >
>>> > > > > > Hello All,
>>> > > > > >
>>> > > > > > First off I apologise for sending this mail to the
>>> > > > > > EFM reflector, however, a number of issues arose which
>>> > > > > > are relevant for other groups.
>>> > > > > >
>>> > > > > > The next phone conference is planned for next Thursday
>>> > > > > > at the old time of 11:00 Eastern
>>> > > > > >
>>> > > > > > Regards
>>> > > > > >
>>> > > > > > Tom
>>> > > > > >
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > > >
>>> >
>>>
>>>
>>>__________________________________________________
>>>Yahoo! - We Remember
>>>9-11: A tribute to the more than 3,000 lives lost
>>>http://dir.remember.yahoo.com/tribute
>>
>