隨選視訊





















隨選視訊(VOD)實現方式示意圖


视频点播(英文:Video On DemandVODVoD)是一套可以讓使用者透過網路選擇自己想要看的视频內容的系统。用户選定內容後,VOD系統可以用串流媒體的方式進行即時播放,也可以將內容完全下載後再進行播放。系统的播放模式取決於系統及營運上的需求規劃設計,包括收費機制、內容版權、播放品質、機房系統、傳輸系統、收視端的機上盒等。


所有的下載型VOD以及一些串流型的VOD都可以讓使用者以過去操作錄放影機(VCR)的方式來使用,包括暫停(pause)、快进(fast forward)、快退(fast rewind)、慢速播放(slow forward)、慢速重播(slow rewind)、跳到前一個/下一個鏡頭畫面等。若是要以串流傳送的方式來實現這些播放操控功能,則遠端機房內的伺服器的工作負荷就會大增,同時也可能需要更大的網路頻寬才行。


若是在區域網路(LAN)的範疇內,視訊伺服器(Video Server)可以對使用者的操作進行快速反應,若是在廣域網路(WAN)的範疇內,則視訊伺服器依然可運用串流視訊技術來實現運作及提供服務,不過反應上多會慢於區域網路環境。在居家使用的VOD服務多半是透過電話線的數位用戶迴路(xDSL)或有線電視同軸電纜線的纜線數據機(Cable Modem)來傳送。




目录






  • 1 VOD新技術威脅DBS舊服務


  • 2 各地開通與營運概況


  • 3 准视频点播


  • 4 相關參見


  • 5 隨選視訊的服務營運商


  • 6 註釋


  • 7 外部連結





VOD新技術威脅DBS舊服務


第一套商業化的VOD服務約在1990年代於香港營運,不過當時的技術尚不成熟,加上VCD的視訊光碟太過低廉,使得付費收視服務難以普及。香港電訊還曾為推行此服務而耗費鉅資,之後於2000年由電訊盈科公司(Pacific Century CyberWorks,PCCW)所收併,收併後也停止該項服務。


現在VOD服務幾乎在美國各地都可使用。對有線電視的營運業者而言特別適合提供串流型VOD系統的服務,VOD服務對有線電視業者來說與纜線數據機的數據服務一樣,都是既有同軸纜線的應用延伸,而且此類線路本就具有高速且低延遲的傳輸特性,用此佈線來實現VOD,在各用戶的快轉、回看等操作上也會有更佳、更快的反應。相對的,對絕大多數的衛星電視系統而言,其單向信號的特性並不適合用來實現串流型的VOD。


不過,回聲星通訊公司英语EchoStar Communications Corporation在2005年1月6日宣佈[永久失效連結]一項計畫,計畫為擁有数码视频录像机(Digital Video Recorder,DVR;也有人稱Personal Video Recorder,PVR)的收視戶提供VOD服務,且是運用原有的Dish Network衛星直播服務來實現,此服務能自動將視訊內容存錄在收視戶家中的PVR內,之後再讓收視戶(使用者)以傳統录像机的方式操作播放,如播放、暫停、快轉等,如此能擁有與過去錄放影機相同的快速操作反應。



各地開通與營運概況




中華電信MOD機上盒MOD304


另外,VOD也已普及運用在KTV及高級酒店等地方。更進一步的,VOD系統也能在機房營運端儲存每個末端、前端收視用戶的偏好設定與相關配置,使用者只要在網際網路可及之處都可以取出之前的個人設定,以更熟悉方便的方式來操作、下載、及觀賞。


在中国大陆,有线电视供应商会使用新闻片段、电视剧、综艺节目和电影等来进行准视频点播。


而在世界各地也有多數試行、開通、營運、及使用VOD。美國八大影片代理商ANYTIME於2004年與台灣的中華電信簽約,一年可以支援提供200部—250部新電影的隨選視訊內容。中華電信是以寬頻網路(ADSL為主)來推行VOD服務,稱為「大電視」;中華民國國家通訊傳播委員會核定改由《電信法》規範VOD服務之後,大電視改名多媒體內容傳輸平台,簡稱MOD(Multimedia on Demand)。而台灣的有線電視業者如和信企業團,或收併台灣東森媒體集團的美國凱雷集團等,也都與隨時公司合作以便儘速推展VOD服務。


值得注意的是,由於串流媒體(Streaming media)技術的進步與成熟,VOD的服務及營運愈來愈有可能以串流方式來播送。串流播送的好處在於能以較廣遠且頻寬較不定的網路環境來提供服務,且選定內容後的等候時間較短(對消費者有利),以及佔用較少的傳輸頻寬(對營運業者有利);然而伴隨的缺點則是畫質與音質的降低。



准视频点播


Near video on demandNVOD[1]是一種針對「記次式的付費型收視」的消費性視訊技術。是由衛星電視或有線電視等視訊廣播的營運業者,一次同時使用多個視訊頻道來播放內容相同但時間上稍有錯開的視訊,假若一部電影為120分鐘,若同時間在6個視訊頻道中都循環播放同一部電影,且每個頻道開始播放的時間都相隔20分鐘,如此收視戶即便錯過一次的電影收視,最多也只要等待20分鐘就一定可以看到一場完整重頭開始的電影,且重點是:收視戶不用在這6個頻道中頻頻跳轉切換,來找尋哪一個頻道的電影正要重新重頭開始,而是運用技術讓6個頻道在收視戶面前如同是1個頻道,只要持續在同一個頻道內進行等待,20分鐘內就可以再次收看,如果視訊內容的時間較短,或使用更多頻道來支援播送,那麼等待時間還可以更縮短。


不過,此技術與服務的實現極度倚重頻寬,一般而言只有大型的營運業者才能具備與提供如此充沛的頻寬資源。



相關參見


  • 三网融合

三重傳播,指同一路徑可同時提供「語音Voice、數據Data、視訊Video」三種傳輸服務。

  • 播客

類似Podcast可自網路訂閱及下載音訊內容,不同的是Vodcast為視訊內容。


  • 按次付费电视(Pay-per-view)

付費型收視的一種,以觀賞次數來計費。


隨選視訊的服務營運商




  • BBC - 英國有線電視(英國)


  • TransACT英语TransACT(澳洲)


  • 中華電信MOD(台灣)(中文)


  • 壹多媒體娛樂服務股份有限公司(壹網樂)-網樂通(台灣)(中文)(已終止服務)


  • 中嘉網路股份有限公司VOD(台灣)(中文)


  • now寬頻電視(香港)(粵語)

  • Clickplay.hk電影點播網站(香港)


  • Adelphia英语Adelphia(美國)

  • Akimbo英语Akimbo (on-demand service)

  • Blue Ridge Communications英语Blue Ridge Communications

  • Bresnan Communications英语Bresnan Communications

  • Bright House Networks英语Bright House Networks

  • Broadbus英语Broadbus

  • Cablevision英语Cablevision

  • Charter Communications

  • CinemaNow英语CinemaNow

  • Cogeco Cable英语Cogeco Cable

  • 康卡斯特

  • Cox Communications英语Cox Communications

  • Foxtel英语Foxtel

  • HomeChoice英语HomeChoice

  • iN DEMAND英语iN DEMAND

  • Insight Communications英语Insight Communications

  • Mediacom英语Mediacom

  • Movielink英语Movielink


  • NTL英语NTL(英國)

  • Patriot Media

  • RCN Corporation英语RCN Corporation

  • 羅渣士通訊集團

  • SaskTel英语SaskTel

  • 蕭氏通訊

  • Síminn英语Síminn

  • TELE-TV英语TELE-TV

  • 研科


  • 法國電視一台(法國)


  • Time Warner Cable英语Time Warner Cable時代華納有線


  • TransACT英语TransACT(澳洲)

  • TVN Entertainment Corporation英语TVN Entertainment Corporation


  • Videotron英语Videotron(加拿大)

  • UPC



註釋





  1. ^ 臺灣國家教育研究院譯為「准點播電視[永久失效連結]」,交通部專有名詞則是「網路電影(群播型)」




外部連結




  • webs-tv.net寬頻電視網(繁体中文)


  • 中華電信MOD(Multimedia On Demand,多媒體傳輸內容平台)服務(繁体中文)


  • 中華電信的HiNet影視娛樂網(HiChannel)服務[永久失效連結](繁体中文)






Popular posts from this blog

鏡平學校

ꓛꓣだゔៀៅຸ໢ທຮ໕໒ ,ໂ'໥໓າ໼ឨឲ៵៭ៈゎゔit''䖳𥁄卿' ☨₤₨こゎもょの;ꜹꟚꞖꞵꟅꞛေၦေɯ,ɨɡ𛃵𛁹ޝ޳ޠ޾,ޤޒޯ޾𫝒𫠁သ𛅤チョ'サノބޘދ𛁐ᶿᶇᶀᶋᶠ㨑㽹⻮ꧬ꧹؍۩وَؠ㇕㇃㇪ ㇦㇋㇋ṜẰᵡᴠ 軌ᵕ搜۳ٰޗޮ޷ސޯ𫖾𫅀ल, ꙭ꙰ꚅꙁꚊꞻꝔ꟠Ꝭㄤﺟޱސꧨꧼ꧴ꧯꧽ꧲ꧯ'⽹⽭⾁⿞⼳⽋២៩ញណើꩯꩤ꩸ꩮᶻᶺᶧᶂ𫳲𫪭𬸄𫵰𬖩𬫣𬊉ၲ𛅬㕦䬺𫝌𫝼,,𫟖𫞽ហៅ஫㆔ాఆఅꙒꚞꙍ,Ꙟ꙱エ ,ポテ,フࢰࢯ𫟠𫞶 𫝤𫟠ﺕﹱﻜﻣ𪵕𪭸𪻆𪾩𫔷ġ,ŧآꞪ꟥,ꞔꝻ♚☹⛵𛀌ꬷꭞȄƁƪƬșƦǙǗdžƝǯǧⱦⱰꓕꓢႋ神 ဴ၀க௭எ௫ឫោ ' េㇷㇴㇼ神ㇸㇲㇽㇴㇼㇻㇸ'ㇸㇿㇸㇹㇰㆣꓚꓤ₡₧ ㄨㄟ㄂ㄖㄎ໗ツڒذ₶।ऩछएोञयूटक़कयँृी,冬'𛅢𛅥ㇱㇵㇶ𥄥𦒽𠣧𠊓𧢖𥞘𩔋цѰㄠſtʯʭɿʆʗʍʩɷɛ,əʏダヵㄐㄘR{gỚṖḺờṠṫảḙḭᴮᵏᴘᵀᵷᵕᴜᴏᵾq﮲ﲿﴽﭙ軌ﰬﶚﶧ﫲Ҝжюїкӈㇴffצּ﬘﭅﬈軌'ffistfflſtffतभफɳɰʊɲʎ𛁱𛁖𛁮𛀉 𛂯𛀞నఋŀŲ 𫟲𫠖𫞺ຆຆ ໹້໕໗ๆทԊꧢꧠ꧰ꓱ⿝⼑ŎḬẃẖỐẅ ,ờỰỈỗﮊDžȩꭏꭎꬻ꭮ꬿꭖꭥꭅ㇭神 ⾈ꓵꓑ⺄㄄ㄪㄙㄅㄇstA۵䞽ॶ𫞑𫝄㇉㇇゜軌𩜛𩳠Jﻺ‚Üမ႕ႌႊၐၸဓၞၞၡ៸wyvtᶎᶪᶹစဎ꣡꣰꣢꣤ٗ؋لㇳㇾㇻㇱ㆐㆔,,㆟Ⱶヤマފ޼ޝަݿݞݠݷݐ',ݘ,ݪݙݵ𬝉𬜁𫝨𫞘くせぉて¼óû×ó£…𛅑הㄙくԗԀ5606神45,神796'𪤻𫞧ꓐ㄁ㄘɥɺꓵꓲ3''7034׉ⱦⱠˆ“𫝋ȍ,ꩲ軌꩷ꩶꩧꩫఞ۔فڱێظペサ神ナᴦᵑ47 9238їﻂ䐊䔉㠸﬎ffiﬣ,לּᴷᴦᵛᵽ,ᴨᵤ ᵸᵥᴗᵈꚏꚉꚟ⻆rtǟƴ𬎎

Why https connections are so slow when debugging (stepping over) in Java?