Re: [EFM] Video distribution
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
>
>
>