home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / dcom / cellrel / 291 < prev    next >
Encoding:
Internet Message Format  |  1992-07-30  |  3.8 KB

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