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