home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!usc!rpi!batcomputer!munnari.oz.au!uniwa!pico!dean
- From: dean@pico.OZ (Dean Economou)
- Newsgroups: comp.dcom.cell-relay
- Subject: Re: Issues, mostly unresolved
- Message-ID: <930@pico.OZ>
- Date: 30 Jul 92 06:10:23 GMT
- References: <1992Jul21.201052.22822@cc.gatech.edu>
- Organization: Comp Sci, Uni. Western Australia.
- Lines: 77
- X-Newsreader: Tin 1.1 PL4
-
- nikolaid@cc.gatech.edu (Ioanis Nikolaidis) writes:
- : Related to article <1992Jul17.152436.4409@iscnvx.lmsc.lockheed.com>
- : from young@bantha.decnet.lockheed.com:
- : >3) 10 Mbps cell relay will not support HDTV?
- : >
- : > True, but it supports compressed video quite nicely, and uncompressed
- : >low resolution video, as well has high quality sound, voice mail, and
- : >works great for image distribution and distributed data bases. It allows
- : >for deskttop controlled conferencing. These things are important, probably
- : >more important than HDTV in the private network business.
- :
- : In the document COM XVIII-R 34-E of CCITT Study Group XVIII -
- : (Report R 34) of June 1990, on page 46, a specification of the
- : service integration for video is given.
- : They recognize the enormous differences of the
- : video terminal equipment capabilities and link speeds and
- : propose the following "solution":
- :
- : Video coding is performed in a "layered" fashion.
- : The sender of a video connection encodes the
- : signal with a layered approach. Each layer "adds up" some more
- : detail on the visual result of the previous layers.
- : If all layers are decoded and presented at the video
- : terminal, then the images are presented
- : with the best fidelity.
- :
- : However, the terminal equipment may be capable of receiving
- : only some of these layers (and not necessarily all). The number
- : of layers received by a terminal is related of course to the
- : quality of the equipment. A terminal is free to decode only part
- : of the transmitted layers to obtain just enough information to
- : reconstruct the image at its own level of image fidelity.
- : This alone "solves" the diversity problem of video terminals.
- :
- : The same approach can be used to cope with limited bandwidth
- : BUT we need an active network entity that selectively discards
- : the cells related to the "redundant" layers and in a way "filters
- : out" the portion of the bandwidth that is used for improvement
- : of the image. Hence, the connection can be squeezed in a slower
- : link but with a penalty on image quality.
- :
- : The subject was left for "further study" in report 34.
- :
- : My question is the following:
- :
- : If an approach is implemented as described above, what is the
- : network component that will discard the "upper" "enhancement"
- : layers of the video connection to reduce the required bandwidth
- : (to be conveyed on a (say) 10Mbps link)?
- : Will this component work on the ATM layer or on the AAL?
- : (If you reply "the ATM layer" you must show me a place in
- : the header where the video layer "level" is placed. If you
- : reply "the AAL" the question is if we will need reassembly
- : of video packets.)
- :
- : Has there been any followup to the idea?
- : OR is my copy of the standard terribly outdated?
- :
- : Final note: The direction towards a "layered" approach
- : does not encourage diversity of video coding
- : algorithms. In fact, all applicable coding methods must be
- : in reference (at least) to the overall layered structure -- i.e. if we
- : decide that layer 1 is luminosity and layer 2 is hue (a B+W receiver only
- : uses layer 1) then a coding algorithm that "mixes"
- : luminosity and hue information is not appropriate.
- :
- : ---
- : Yannis Nikolaidis
- : (nikolaid@cc.gatech.edu)
-
- Perhaps we could contemplate sending the various layers on different
- VCIs? That would make the selection somewhat easier as the VCIs
- carrying the higher resolution could be rejected at VCI set up time by
- the terminal.
-
- Dean
- (use dean@qpsx.oz.au, NOT reply)
-