WebRTC နှင့် ဗီဒီယို စောင့်ကြည့်ခြင်း- ကင်မရာများမှ ဗီဒီယို latency ကို ကျွန်ုပ်တို့ အနိုင်ယူနည်း

cloud ဗီဒီယိုစောင့်ကြည့်ရေးစနစ်ကို စတင်လုပ်ဆောင်သည့်နေ့မှစ၍၊ Ivideon ကို အရှုံးမပေးဘဲ ဖြေရှင်းချက်မရရှိဘဲ ပြဿနာတစ်ခုနှင့် ရင်ဆိုင်ခဲ့ရသည် - ဤသည်မှာ ကျွန်ုပ်တို့၏ ဧဝရတ်တောင်တက်ခြင်းဖြစ်ပြီး စွမ်းအင်များစွာယူခဲ့ရသော်လည်း ယခုအခါတွင် ကျွန်ုပ်တို့သည် နောက်ဆုံးတွင် ရပြီဖြစ်သည်။ လက်ဝါးကပ်တိုင်ပလပ်ဖောင်း၏ထိပ်တွင် ရေခဲပုဆိန်ကို ချိတ်ထားသည်။

အင်တာနက်မှ အသံနှင့် ဗီဒီယို ထုတ်လွှင့်ခြင်းစနစ်သည် စက်ကိရိယာများ၊ ဝဘ်ဖောက်သည်များနှင့် ၎င်းတို့ပံ့ပိုးပေးသည့် စံချိန်စံညွှန်းများပေါ်တွင်မူတည်ပြီး Network Address Translators များနှင့် firewalls များရှေ့တွင်လည်း မှန်ကန်စွာ လုပ်ဆောင်သင့်ပါသည်။ cloud ဗီဒီယိုစောင့်ကြည့်ရေးအသုံးပြုသူတစ်ဦးသည် analog ကင်မရာများကိုအသုံးပြုသော်လည်း၊ ဝန်ဆောင်မှုကိုရယူလိုပြီး ခေတ်အမီဆုံးစက်ပစ္စည်းပေါ်တွင် တိုက်ရိုက်ဗီဒီယိုထုတ်လွှင့်မှုကို ကြည့်ရှုလိုပါသည်။

အသုံးပြုသူသည် နှောင့်နှေးမှုအနည်းဆုံးဖြင့် ဗီဒီယိုများကို ကြည့်ရှုလိုသည်မှာ အလွန်အရေးကြီးပါသည်။ ဘရောက်ဆာတစ်ခုတွင် latency နည်းသော ဗီဒီယိုကိုပြသရန် တစ်ခုတည်းသောနည်းလမ်းမှာ WebRTC (ဝဘ်အချိန်နှင့်တစ်ပြေးညီ ဆက်သွယ်မှု) ကို အသုံးပြုရန်ဖြစ်သည်။ WebRTC သည် ဘရောက်ဆာများတွင် ဗီဒီယိုနှင့် အသံများကို ရွယ်တူအချင်းချင်း ထုတ်လွှင့်ခြင်းအတွက် နည်းပညာအစုံအလင်ဖြစ်ပြီး၊ အစပိုင်းတွင် ကြာမြင့်ချိန်နည်းပါးသော ဗီဒီယိုစီးကြောင်းများကို ထုတ်လွှင့်ခြင်းနှင့် ဖွင့်ခြင်းအတွက် ဒီဇိုင်းထုတ်ထားသည်။ ဤရည်ရွယ်ချက်အတွက်၊ အခြားအရာများကြားတွင်၊ UDP ပရိုတိုကောကို အသုံးပြုသည်။

အင်ဂျင်အသစ်က သုံးစွဲသူကို ပေးတဲ့အရာကို မပြောပြခင်မှာ ဘာကြောင့် HLS နည်းပညာတွေကို ပံ့ပိုးရသလဲ၊ ဘာကြောင့် ဆက်လုပ်ဖို့ ဆုံးဖြတ်ခဲ့တာလဲဆိုတာ သင့်ကို သတိပေးပါလိမ့်မယ်။

HLS အင်ဂျင်- အားသာချက် အားနည်းချက်

(c)

HLS (HTTP Live Streaming) နည်းပညာကို Apple မှ တီထွင်ခဲ့သောကြောင့် ၎င်းကို Apple စက်ပစ္စည်းများတွင် ပထမဆုံး ပံ့ပိုးပေးခဲ့ခြင်းမှာ အံ့သြစရာမဟုတ်ပါ။ ယနေ့ခေတ်တွင် HLS ဗီဒီယိုကို set-top box အားလုံးနီးပါးနှင့် OS ကို အသုံးပြုသော စက်ပစ္စည်းများစွာတွင်လည်း ပံ့ပိုးပေးထားပါသည်။ Android.

HLS အင်ဂျင်သည် ဗီဒီယိုဒေတာကို တိုက်ရိုက်ထုတ်လွှင့်ရန် AAC သို့မဟုတ် MP264 အော်ဒီယိုလိုင်းများနှင့်အတူ လူသိများသော H3 ဗီဒီယိုကုဒ်ဒက်ကို အသုံးပြုသည်။ အသံနှင့် ဗီဒီယိုဒေတာစီးကြောင်းတစ်ခုလုံးကို MPEG-TS သယ်ယူပို့ဆောင်ရေးကွန်တိန်နာတစ်ခုထဲသို့ ထုပ်ပိုးထားသည်။ HTTP ပရိုတိုကောမှတစ်ဆင့် ထုတ်လွှင့်မှုအတွက်၊ ထုတ်လွှင့်မှုတွင်ပါရှိသော အချက်အလက်များကို m3u8 အစီအစဉ်များတွင် ဖော်ပြထားသည့် အပိုင်းအစများအဖြစ် ပိုင်းခြားထားသည်။ ထိုမှသာလျှင် ဤအပိုင်းအစများ၊ အစီအစဉ်များနှင့်အတူ HTTP မှတဆင့် ပို့လွှတ်ပါသည်။ အလိုအလျောက် ဖြတ်တောက်ခြင်းသည် စက္ကန့်ပိုင်းအတွင်း နှောင့်နှေးမှုကို ဆိုလိုသည်။ ၎င်းသည် MPEG-TS ကွန်တိန်နာ၏ အင်္ဂါရပ်တစ်ခုဖြစ်သည်။

HLS အင်ဂျင်သည် multibitrate စီးကြောင်းများ၊ Live/VOD များကိုလည်း ပံ့ပိုးပေးပါသည်။

HLS ၏အဓိကအားသာချက်များ

• အဓိကဘရောက်ဆာအားလုံးတွင် built-in ပံ့ပိုးမှု;
• အကောင်အထည်ဖော်ရလွယ်ကူခြင်း (WebRTC နှင့် နှိုင်းယှဉ်လျှင်)
• အပိုင်းများကို CDN တွင်တစ်ကြိမ် အပ်လုဒ်လုပ်ထားနိုင်သောကြောင့် ထုတ်လွှင့်မှုအမျိုးအစားအားလုံးကို ကြီးမားသောပရိသတ်ထံ စုစည်းရန် အလွန်အဆင်ပြေပြီး ထိရောက်မှုရှိပါသည်။

အင်ဂျင်ရဲ့ ရိုးရှင်းပေမယ့် အရာအားလုံးက ထင်သလောက် မချောမွေ့ပါဘူး။ အဓိကပြဿနာမှာ ပြင်ပကစားသမားဆော့ဖ်ဝဲရေးသားသူများသည် ဥပမာအားဖြင့် ပံ့ပိုးထားသော အသံဖော်မတ်များနှင့်ပတ်သက်၍ Apple ၏အကြံပြုချက်များမှ ဝေးကွာသွားခြင်းကြောင့်ဖြစ်သည်။ အထူးသဖြင့်၊ များစွာသော developer များသည် mpeg2 ဗီဒီယို၊ mpeg2 အော်ဒီယိုစသည်ဖြင့် လူကြိုက်များသော အော်ဒီယိုထုတ်လွှင့်မှုများနှင့် လုပ်ဆောင်နိုင်စွမ်းကို စတင်ထည့်သွင်းလာကြသည်။ ထို့ကြောင့်၊ ၎င်းတို့သည် မတူညီသော ပလေယာများအတွက် မတူညီသော အစီအစဉ်ဖော်မတ်များကို ဖန်တီးရန် လိုအပ်ပါသည်။

သို့သော် HLS အင်ဂျင်တွင် အကြီးမားဆုံးပြဿနာတစ်ခုမှာ ဒေတာလွှဲပြောင်းမှုတွင် latency မြင့်မားခြင်းဖြစ်သည်။

"ဘရိတ်" ၏မူလအစ

HLS ၏ latency မြင့်မားရခြင်း၏ အဓိကအကြောင်းရင်းမှာ အရည်အသွေးအမြင့်ဆုံးပုံများရရှိရန် ပရိုဂရမ်မာများက အင်ဂျင်ကို ဖန်တီးခဲ့ခြင်းကြောင့်ဖြစ်သည်။ ထို့ကြောင့်၊ အသုံးပြုထားသော ဘောင်ကြားကာလ၏ ကန့်သတ်ချက်များ နှင့် ပြန်ဖွင့်သည့်ကြားခံ၏ အရွယ်အစားသည် တိုက်ရိုက်ဗီဒီယိုထုတ်လွှင့်မှုများအတွက် ရိုးရှင်းစွာ မသင့်လျော်ပါ။ ထို့အတွက်ကြောင့် 5-7 စက္ကန့်အတွင်း ဗီဒီယိုထုတ်လွှင့်မှုတွင် နှောင့်နှေးမှုရှိသည်။

တစ်ဖက်တွင်၊ ဥပမာအားဖြင့်၊ ဗီဒီယို hosting server မှရုပ်ရှင်တစ်ကားကိုကြည့်ရှုသူများအတွက်၊ ဤအရာသည် များစွာမဟုတ်ပါ။ သို့သော် ဗီဒီယိုစောင့်ကြည့်စနစ်များအတွက်၊ ဗီဒီယိုဖိုင်များ ထုတ်လွှင့်ရာတွင် နှောင့်နှေးမှုသည် အလွန်အရေးကြီးပါသည်။

ဝန်ထမ်းတွေက သူတို့ရဲ့ မော်နီတာကနေ တစ်နာရီ တစ်ကြိမ် မော်နီတာကနေ ကြည့်နေတဲ့ ရုံးခန်းကို ကြည့်နေတယ်ဆိုရင် 5 စက္ကန့် နှောင့်နှေးမှုဟာ လုံးဝ အရေးမကြီးပါဘူး။ ဒါပေမယ့် လူတွေက ဥပမာ၊ ဘောလုံးပွဲတစ်ခု ထုတ်လွှင့်တဲ့အခါ ချတ်မှာ GOOOOL လို့ရေးထားပြီးသား၊ ဒါပေမယ့် ဒီဗီဒီယိုမှာ မပေါ်သေးပါဘူး :)။ ကျွန်ုပ်တို့တွင် Ivideon သည် Skype ကို လက်တွေ့ကျကျ အစားထိုးသင့်သည့် အသုံးပြုသူကိစ္စများစွာရှိနှင့်ပြီးဖြစ်သည်။

HLS တွင် latency ကို ကျော်ဖြတ်ရန် ဖြစ်နိုင်ပါသလား။ ဤမေးခွန်း၏အဖြေသည် အတွေ့အကြုံရှိ ကြွက်များကို သုတ်သင်ရှင်းလင်းပေးသူ အတွေ့အကြုံမရှိသေးသော ပိုးမွှားထိန်းချုပ်ရေး ကျွမ်းကျင်သူများထံ ဟောပြောချက်တစ်ခုတွင် “ကြွက်များကို မသုတ်သင်နိုင်သော်လည်း ၎င်းတို့၏ အရေအတွက်ကို ကျိုးကြောင်းဆီလျော်စွာ အနိမ့်ဆုံးအထိ လျှော့ချနိုင်သည်” ဟူ၍ဖြစ်သည်။ HLS တွင် နှောင့်နှေးခြင်းနှင့် အတူတူပင်၊ ၎င်းကို သုညအထိ လျှော့ချရန် မဖြစ်နိုင်သော်လည်း နှောင့်နှေးမှုကို သိသိသာသာ လျှော့ချနိုင်သည့် စျေးကွက်တွင် ဖြေရှင်းချက်များ ရှိပါသည်။

ဒဏ်ငွေဖြတ်တောက်မှုများ

အင်ဂျင်၏နောက်ထပ်အားနည်းချက်မှာ ဒေတာလွှဲပြောင်းခြင်းအတွက် သေးငယ်သောဖိုင်များကို အသုံးပြုခြင်းဖြစ်သည်။ ဒီဟာက ဘာများ မှားနေပြီလဲလို့ ထင်ရလိမ့်မယ်။

ကြားခံတစ်ခုမှ တစ်ခုသို့ ဖိုင်အသေးအမြောက်အများကို ကူးယူရန် ကြိုးစားသူတိုင်းသည် ထိုအစု၏ ရေးသားမှုနှုန်းသည် အရွယ်အစားတူ ဖိုင်ကြီးတစ်ခုထက် များစွာနိမ့်ပါးသည်ကို သတိပြုမိပေမည်။ hard drive သို့ဝင်ရောက်မှု၏ပြင်းထန်မှုသည်သိသိသာသာတိုးလာသည်၊ ၎င်းသည်ယေဘုယျအားဖြင့်ကွန်ပျူတာတစ်ခုလုံး၏စွမ်းဆောင်ရည်ကိုအပျက်သဘောဆောင်သည်။ ထို့ကြောင့်၊ သေးငယ်သော 10 စက္ကန့်အပိုင်းအတွင်း ဗီဒီယိုဒေတာကို ပို့လွှတ်ခြင်းသည်လည်း အင်ဂျင်ကြာချိန်ကို တိုးစေသည်။

HLS နည်းပညာ၏ ကောင်းကျိုး ဆိုးကျိုးအားလုံးကို အတိုချုံးကြည့်ကြပါစို့။

HLS ၏ အားသာချက်များ

1. မည်သည့်စက်ပစ္စည်းများနှင့်မဆို လုပ်ဆောင်နိုင်မှု။ စမတ်ဖုန်း၊ တက်ဘလက်၊ လက်တော့ပ် သို့မဟုတ် desktop PC ဖြင့်ဖြစ်စေ ခေတ်မီစက်ကိရိယာတစ်ခုခုတွင် ဗီဒီယိုများကို ကြည့်ရှုနိုင်သည်။ အဓိကအချက်မှာ ဝဘ်ဘရောက်ဆာသည် နောက်ဆုံးပေါ်ဖြစ်ပြီး HTML5 နှင့် Media Source Extensions များနှင့် တွဲဖက်အသုံးပြုနိုင်ခြင်းပင်ဖြစ်သည်။
2. ရုပ်ပုံအရည်အသွေး အထူးကောင်းမွန်သည်။ အသုံးပြုထားသော adaptive data transmission function သည် သင့်အား အင်တာနက်ချိတ်ဆက်မှု၏ bandwidth ပေါ်မူတည်၍ ထုတ်လွှင့်သော ဗီဒီယို၏အရည်အသွေးကို dynamically ပြောင်းလဲနိုင်စေပြီး algorithm သည် အမြင့်ဆုံးအရည်အသွေးကို ထိန်းသိမ်းရန် ကြိုးစားနေချိန်တွင်ဖြစ်သည်။
3. အသုံးပြုသူ၏စက်ကိရိယာများ၏ ရှုပ်ထွေးသောပုံစံဖွဲ့စည်းမှုပြုလုပ်ရန် မလိုအပ်ပါ။

အားနည်းချက်များကို:

1. အချို့သောစက်ပစ္စည်းများတွင် အင်ဂျင်နှင့်အလုပ်လုပ်ရန်အတွက် အကန့်အသတ်ဖြင့်ပံ့ပိုးမှု။
2. ရုပ်ပုံထုတ်လွှင့်ရာတွင် နှောင့်နှေးမှု မြင့်မားသည်။
3. ဖိုင်အသေးစားများအသုံးပြုခြင်းကြောင့် ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ခြင်း၏ ရှုပ်ထွေးမှုများ သိသိသာသာတိုးလာပါသည်။ ကွန်တိန်နာ၏ သဘောသဘာဝကြောင့်၊ ကျွန်ုပ်တို့သည် အပိုင်းအရွယ်အစားထက် latency ကို မည်သည့်အခါမျှ ရရှိနိုင်မည်မဟုတ်ပါ။

HLS ၏ အားနည်းချက်များသည် ကျွန်ုပ်တို့အတွက် ၎င်း၏အားသာချက်များကို သာလွန်စေပြီး အခြားရွေးချယ်စရာများကို ရှာဖွေရန် တွန်းအားပေးခဲ့သည်။

WebRTC ဆိုတာဘာလဲ

(c)

WebRTC ပလပ်ဖောင်းကို ဘရောက်ဆာများနှင့် မိုဘိုင်းအပလီကေးရှင်းများကြားတွင် latency အနည်းဆုံးဖြင့် တိုက်ရိုက်ထုတ်လွှင့်နေသည့် ဗီဒီယိုနှင့် အသံဒေတာကို ထုတ်လွှင့်ရန်အတွက် Google မှ 2011 ခုနှစ်တွင် တီထွင်ခဲ့သည်။ ယင်းအတွက်၊ စံ UDP ပရိုတိုကောနှင့် အထူးစီးဆင်းမှုထိန်းချုပ်မှု အယ်လဂိုရီသမ်များကို အသုံးပြုထားသည်။ ယနေ့တွင် ၎င်းသည် open source ပရောဂျက်တစ်ခုဖြစ်ပြီး ၎င်းကို Google မှ တက်ကြွစွာ ထိန်းသိမ်းထားပြီး တီထွင်လျက်ရှိသည်။

WebRTC သည် peer-to-peer ဗီဒီယိုနှင့် အသံထုတ်လွှင့်ခြင်းအတွက် နည်းပညာအစုတစ်ခုဖြစ်သည်။ ဥပမာအားဖြင့်၊ WebRTC ကိုအသုံးပြုသောအသုံးပြုသူဘရောက်ဆာများသည် ဒေတာသိမ်းဆည်းရန်နှင့် လုပ်ဆောင်ရန်အတွက် အဝေးထိန်းဆာဗာများကို အသုံးမပြုဘဲ ဒေတာအချင်းချင်း တိုက်ရိုက်လွှဲပြောင်းနိုင်သည်။ အချက်အလက်အားလုံးကို သုံးစွဲသူများ၏ ဘရောက်ဆာများနှင့် မိုဘိုင်းအပလီကေးရှင်းများမှလည်း လုပ်ဆောင်ပါသည်။

ဤနည်းပညာ၏ အဆင်ပြေမှုနှင့် ကျယ်ပြန့်သော စွမ်းဆောင်ရည်များကို လူကြိုက်များသော ဘရောက်ဆာအားလုံး၏ ဆော့ဖ်ဝဲရေးသားသူများက သဘောကျကြသည်။ WebRTC ပံ့ပိုးမှုကို လက်ရှိတွင် Mozilla Firefox၊ Opera၊ Google Chrome (နှင့် Chromium-based ဘရောက်ဆာအားလုံး) အပြင် ... ကို လည်ပတ်နေသော မိုဘိုင်းအက်ပ်များတွင် ရရှိနိုင်ပါသည်။ Android နှင့် iOS။

၎င်း၏သံသယမရှိသောအားသာချက်များအားလုံးအတွက်၊ WebRTC တွင် သိသာထင်ရှားသောအားနည်းချက်များစွာရှိသည်။

အခက်အခဲများ၏ရွေးချယ်မှု

WebRTC နည်းပညာသည် P2P အကြောင်းဖြစ်သောကြောင့် ကွန်ရက် အပြန်အလှန်ဆက်သွယ်မှုများတွင် ပိုမိုရှုပ်ထွေးပါသည်။ အမှားရှာရန်၊ စမ်းသပ်ရန် ခက်ခဲပြီး မှန်းဆမရသော ပြုမူနိုင်သည်။ တစ်ချိန်တည်းမှာပင်၊ ကျွန်ုပ်တို့သည် NAT နှင့် firewall ကိုကျော်လွှားရန်လိုအပ်သည်၊ UDP ကိုပိတ်ဆို့ထားသည့်ကွန်ရက်များတွင်လည်ပတ်မှုသေချာရန်လိုသည်။

Google ၏ WebRTC အကောင်အထည်ဖော်မှုသည် အသုံးပြုရန် အလွန်ခက်ခဲသည်။ SDK တပ်ဆင်ခြင်းဝန်ဆောင်မှုများကို ဆောင်ရွက်ပေးသည့် ကုမ္ပဏီတစ်ခုလုံးပင် ရှိပါသည်။ ထို့အပြင်၊ Google ၏ အကောင်အထည်ဖော်မှုသည် ဗီဒီယိုတစ်ခုလုံးကို ပြန်လည်ကုဒ်သွင်းခြင်းမပြုဘဲ ကျွန်ုပ်တို့၏စနစ်နှင့် ပေါင်းစပ်ရန် အလွန်ခက်ခဲပါသည်။

သို့သော်၊ ကျွန်ုပ်တို့သည် သုံးစွဲသူများအား ပြည့်စုံသော "တိုက်ရိုက်" ဗီဒီယိုဖြင့် အလုပ်လုပ်ရန်နှင့် ဖန်သားပြင်ပေါ်ရှိ ပုံနှင့် ၎င်းတို့ကိုယ်တိုင် အဖြစ်အပျက်များကြားတွင် နောက်ကျကျန်နေမှုကို လျှော့ချပေးလိုသည်မှာ ကြာပါပြီ။ ထို့အပြင်၊ နှောင့်နှေးမှုများသည် အရေးကြီးသော၊ ပိုမိုသက်တောင့်သက်သာရှိသော PTZ ကင်မရာများကို အသုံးပြုစေလိုသောဆန္ဒရှိခဲ့ပါသည်။

အခြားသော ပြတ်တောက်မှုဆန့်ကျင်ရေး အကောင်အထည်ဖော်မှုများတွင် လုပ်ဆောင်နိုင်စွမ်းမှာ အကန့်အသတ်များရှိနေသေးပြီး သိသိသာသာ ပိုဆိုးလာသည်ဟု ယူဆပါက WebRTC ကို အသုံးပြုရန် ဆုံးဖြတ်ခဲ့သည်။

ငါတို့ဘာလုပ်ခဲ့လဲ။

WebRTC ပလပ်ဖောင်းကို မှန်ကန်စွာအကောင်အထည်ဖော်ခြင်းသည် လွယ်ကူသောအလုပ်မဟုတ်ပါ။ မှားယွင်းသော တွက်ချက်မှု သို့မဟုတ် မှန်ကန်မှု တစ်စုံတစ်ရာသည် ဗီဒီယိုထုတ်လွှင့်မှုတွင် နှောင့်နှေးစေသည်သာမက အခြားပလပ်ဖောင်းများနှင့် နှိုင်းယှဉ်ပါက လျော့နည်းသွားရုံသာမက တိုးလာနိုင်သည်။

WebRTC မှန်ကန်စွာအလုပ်လုပ်နိုင်စေရန်အတွက်၊ ဝဘ်ဗီဒီယိုနှင့်လုပ်ဆောင်ရန်အတွက် စထရပ်၏နည်းပညာအဆင့်မြှင့်တင်မှုကို လုပ်ဆောင်ရန် လိုအပ်ပါသည်။ အဲဒါ ငါတို့လုပ်ခဲ့တာ။

ပထမဦးစွာ၊ ကျွန်ုပ်တို့သည် WebRTC အချက်ပြမှု ပရိုတိုကောဆာဗာကို Websocket တွင် အကောင်အထည်ဖော်ခဲ့ပြီး webrtc.org SDK ကိုအခြေခံ၍ cloud တွင် WebRTC ရွယ်တူဆာဗာကိုလည်း ချထားခဲ့သည်။ ၎င်း၏တာဝန်မှာ ဗီဒီယိုကူးပြောင်းခြင်းမရှိဘဲ H.264 + Opus/G.711 ဖော်မတ်ရှိ သုံးစွဲသူ WebRTC ရွယ်တူများထံ ဗီဒီယိုထုတ်လွှင့်မှုများကို ဖြန့်ဝေရန်ဖြစ်သည်။

Websocket သည် လူကြိုက်များသော ဝဘ်ဘရောက်ဆာများအားလုံးတွင် အရည်အသွေးမြင့် ပံ့ပိုးမှုရှိပြီးဖြစ်သောကြောင့် အချက်ပြပရိုတိုကောအဖြစ် Websocket ကို ရွေးချယ်ခဲ့သည်။ ထို့အတွက်ကြောင့် သင်သည် AJAX နှင့် နှိုင်းယှဉ်လျှင် TCP နှင့် TLS ထပ်ခါတလဲလဲ လက်ဆွဲနှုတ်ဆက်ခြင်းအတွက် အချိန်နှင့် အရင်းအမြစ်များကို ဖြုန်းတီးခြင်းကို သိသိသာသာ လျှော့ချနိုင်ပါသည်။

အမှန်မှာ၊ မူရင်းအားဖြင့် WebRTC သည် အရင်းအမြစ်နှင့် client အပလီကေးရှင်းများကြား အချိန်နှင့်တစ်ပြေးညီ ဗီဒီယိုဆက်သွယ်မှုကို မှန်ကန်စွာသတ်မှတ်ခြင်း၊ ထိန်းသိမ်းခြင်းနှင့် ရပ်တန့်ရန် လိုအပ်သော အချက်ပြပရိုတိုကောကို ပေးဆောင်ခြင်းမဟုတ်ပါ။

အချက်ပြနည်းပညာကို အမှီအခိုကင်းစွာ အကောင်အထည်ဖော်နိုင်ရန်၊ ဝဘ်ပရိုတိုကောများစွာ (Websocet၊ WebRTC) အတွက် ပံ့ပိုးမှုဖြင့် ကျွန်ုပ်တို့၏ ကိုယ်ပိုင် အချက်ပြဆာဗာကို ဖွံ့ဖြိုးတိုးတက်ရန် လိုအပ်ပါသည်။ အချိန်နှင့်တပြေးညီ session များနှင့် အသိပေးချက်များကို လုံခြုံစွာ စီမံခန့်ခွဲနိုင်မှု၊ ဗီဒီယို စီမံခန့်ခွဲမှုနှင့် အခြားအရာများစွာ ပါဝင်ပါသည်။

ကျွန်ုပ်တို့သည် P2P မှမဟုတ်ဘဲ latency ကိုလျှော့ချခြင်းဖြင့်၊ UDP နှင့် flow control မှတဆင့် latency ကိုလျှော့ချခြင်းဖြင့် P2P ၏ကန့်သတ်ချက်များကိုကျော်လွှားနိုင်ခဲ့သည်။ အဓိကအသုံးပြုမှုကိစ္စမှာ ဘရောက်ဆာမှတစ်ဆင့် p2p စကားဝိုင်းများဖြစ်သောကြောင့် ၎င်းကို WebRTC တွင်လည်း တည်ဆောက်ထားသည်။

မိုဘိုင်း ကလိုင်းယင့်တွင်၊ ကျွန်ုပ်တို့သည် စီးဆင်းမှု ထိန်းချုပ်မှုကို မှန်ကန်စွာ လုပ်ဆောင်မှသာ webrtc.org SDK ကို အသုံးပြု၍ ပလေယာကို အကောင်အထည် ဖော်ခဲ့ခြင်းဖြစ်ပြီး၊ သိရှိထားသော Forward Error Correction (FEC) အစီအစဉ်များ ရှိပြီး၊ ဘရောက်ဆာအားလုံးအတွက် ပက်ခ်များကို ပြန်လည်ပေးပို့ခြင်း ယန္တရားကို မှန်ကန်စွာ အကောင်အထည်ဖော် ဆောင်ရွက်ပါသည်။ webrtc.org SDK ကို Google မှတက်ကြွစွာတီထွင်နေရန်လည်း အရေးကြီးပါသည်။

WebRTC ကို အကောင်အထည်ဖော်ခြင်း၏ ရလဒ်ကား အဘယ်နည်း။

ကင်မရာများမှ တိုက်ရိုက်ဗီဒီယိုကို ကြည့်ရှုရန်အတွက် WebRTC ကိုအခြေခံ၍ သင့်ကိုယ်ရေးကိုယ်တာအကောင့်သို့ ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ထားသော ပလေယာအသစ်ကို ပေါင်းထည့်ထားပါသည်။ ၎င်းသည် လျင်မြန်သော ဗီဒီယိုတင်ခြင်းအမြန်နှုန်းများကို ထောက်ပံ့ပေးပြီး ကြည့်ရှုချိန်တိုးလာသည်နှင့်အမျှ latency စုဆောင်းခြင်းပြဿနာကို လုံးဝဖယ်ရှားပေးပါသည်။

Ivideon cloud ဝန်ဆောင်မှုတွင် WebRTC ပံ့ပိုးကူညီမှုကို မိတ်ဆက်ပြီးနောက်၊ ကျွန်ုပ်တို့၏ဖောက်သည်များသည် ယခုအခါတွင် အပြည့်အဝ တိုက်ရိုက်ထုတ်လွှင့်သည့် ဗီဒီယိုကို ကြည့်ရှုနိုင်ပြီဟု ယုံကြည်ချက်အပြည့်ဖြင့် ပြောနိုင်ပါသည်။ ယခု ဗီဒီယို အစီအစဉ်များကို ထုတ်လွှင့်သည့်အခါ နှောင့်နှေးမှုသည် တစ်စက္ကန့်ထက် မပိုပါ။ နှိုင်းယှဉ်ရန်အတွက် ယခင် HLS အင်ဂျင်က ဗီဒီယိုပေးပို့မှုကို 5-7 စက္ကန့်နှောင့်နှေးစေပါသည်။ ဗီဒီယိုသရုပ်ပြမှုအမြန်နှုန်း၏ ကွာခြားချက်မှာ အလွန်သိသာထင်ရှားပြီး ကျွန်ုပ်တို့၏ဗီဒီယိုဝန်ဆောင်မှုကို စတင်လုပ်ဆောင်ပြီးနောက် သုံးစွဲသူက ၎င်းကို ချက်ချင်းသတိပြုမိမည်ဖြစ်သည်။

ကျွန်ုပ်တို့မျှော်လင့်ထားသည့်အတိုင်း၊ ပလေယာအသစ်ကို အကောင်အထည်ဖော်ခြင်းသည် PTZ ၏တုံ့ပြန်မှုနှင့် ကင်မရာနှင့် အသံဆက်သွယ်မှုတို့ကို ပိုမိုကောင်းမွန်စေသည်။

အာရုံစူးစိုက်ချင်သော သိမ်မွေ့သောအချက်တစ်ခုသာရှိသည်။ WebRTC ပလေယာအသစ်သည် စမ်းသပ်မုဒ်တွင် လက်ရှိလုပ်ဆောင်နေပါသည်။ ထို့အတွက်ကြောင့် ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ဖောက်သည်များအားလုံးအတွက် ၎င်းကို မူရင်းအတိုင်း ဖွင့်မထားပါ။ သို့သော် ကင်မရာဆက်တင်များတွင် သက်ဆိုင်ရာအကြောင်းအရာကိုဖွင့်ခြင်းဖြင့် ၎င်းကိုသင်ကိုယ်တိုင် အသက်သွင်းနိုင်သည် (၎င်းကိုလုပ်ဆောင်ရန်၊ သို့သွားပါ။ ပုဂ္ဂလိကရုံး).

Ivideon ဝန်ဆောင်မှုတွင် WebRTC အကောင်အထည်ဖော်မှု၏အင်္ဂါရပ်များ

WebRTC သည် လက်ရှိတွင် စမ်းသပ်ဆဲနည်းပညာတစ်ခု ဖြစ်နေဆဲဖြစ်သည်။ ၎င်း၏ပံ့ပိုးမှုအား ဘရောက်ဆာများနှင့် အသုံးပြုသူစက်ပစ္စည်းများအားလုံးတွင် မှန်ကန်စွာ အကောင်အထည်ဖော်နိုင်ခြင်းမရှိသေးသည့်အပြင် ကင်မရာအားလုံးတွင်လည်း မဟုတ်ပါ။

ထို့ကြောင့် ကျွန်ုပ်တို့သည် WebRTC ပလေယာအား သုံးစွဲသူအားလုံးအတွက် ပုံသေအဖြစ် မသတ်မှတ်ရသေးသည့် အကြောင်းရင်းဖြစ်သည်။

ယခုအချိန်တွင်၊ Google Chrome ဘရောက်ဆာများတွင်သာ WebRTC ကိုအသုံးပြုရန် အကြံပြုအပ်ပါသည်။ Firefox နှင့် Safari ၏ နောက်ဆုံးဗားရှင်းများသည် ဤနည်းပညာကို ပံ့ပိုးပေးသော်လည်း ကံမကောင်းစွာဖြင့်၊ ၎င်းသည် မတည်ငြိမ်သေးပါ။

ကျွန်ုပ်တို့သည် မိုဘိုင်းကိရိယာများရှိ ဘရောက်ဆာများအတွက် WebRTC ပံ့ပိုးမှုကို အကောင်အထည်မဖော်သေးပါ။ လောလောဆယ်တွင် သင်သည် မိုဘိုင်းစက်ပစ္စည်းမှ ဝင်ရောက်ပြီး WebRTC ကို စတင်အသုံးပြုပါက၊ ဤမုဒ်သည် အလုပ်မဖြစ်ပါ။ သို့သော်လည်း WebRTC သည် ကျွန်ုပ်တို့၏ မိုဘိုင်းအက်ပလီကေးရှင်းများတွင် ရနိုင်ပါသည်။ Android и iOS ကို.

ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုရှိ WebRTC အကောင်အထည်ဖော်မှု၏အင်္ဂါရပ်များအကြောင်း ဇာတ်လမ်းကို နိဂုံးချုပ်ပြီး၊ နောက်ထပ် သိမ်မွေ့သောအချက်နှစ်ချက်ကို မှတ်သားကြပါစို့။

ပထမဦးစွာ၊ နည်းပညာသည် အချိန်နှင့်တပြေးညီ တိုက်ရိုက်ဗီဒီယိုထုတ်လွှင့်ခြင်းအပေါ် အာရုံစိုက်သည်။ ထို့ကြောင့် သင့်ချန်နယ်မှ ဗီဒီယိုကို ထုတ်လွှင့်ရန် လုံလောက်သော bandwidth မရှိပါက၊ frame drops များကို သတိပြုမိလိမ့်မည် (HLS ဖြင့် ဗီဒီယိုမှေးမှိန်သွားခြင်းနှင့် latency တိုးလာသည်ကို သတိပြုမိလိမ့်မည်၊ သို့သော် frame drops များရှိလာမည်မဟုတ်ပါ)၊ သို့သော် ဗီဒီယိုကို အစစ်အမှန်အတိုင်း ထုတ်လွှင့်နေဆဲဖြစ်သည်။ အချိန်။

ဒုတိယအနေဖြင့်၊ နည်းပညာသည် အချိန်နှင့်တပြေးညီ တိုက်ရိုက်ဗီဒီယိုနှင့် အလုပ်လုပ်ရန် ဒီဇိုင်းထုတ်ထားသောကြောင့်၊ သိမ်းဆည်းထားသော ဗီဒီယိုဒေတာဖြင့် လုပ်ဆောင်ရန် ၎င်းကို ကျွန်ုပ်တို့ အသုံးမပြုပါ။

ဝန်ဆောင်မှုအတွက် အခြားပြောင်းလဲမှုများ

ယခုအချိန်တွင် Flash သည် အလိုအလျောက်အင်ဂျင်ရွေးချယ်ရေးယန္တရားတွင် ပါဝင်ခြင်းမရှိတော့ပါ။ ထိုကဲ့သို့သောပလေယာကို သင်အသုံးပြုနိုင်သေးသော်လည်း ၎င်းကိုပြုလုပ်ရန် အကောင့် သို့မဟုတ် ကင်မရာဆက်တင်များတွင် ၎င်းကို ကိုယ်တိုင်ရွေးချယ်ရန် လိုအပ်ပါသည်။ ၎င်းသည် ဖက်ရှင်အတွက် ဂုဏ်ပြုခြင်းမဟုတ်ပါ၊ ကျွန်ုပ်တို့၏ ဝန်ဆောင်မှု၏ စာရင်းဇယားများအရ Flash နှင့် အလုပ်လုပ်သော အသုံးပြုသူများမှာ လက်တွေ့တွင် ကျန်ရှိတော့မည်မဟုတ်ပါ။ အသုံးပြုသူ၏ဘရောက်ဆာက ၎င်းကို ပံ့ပိုးခြင်းရှိမရှိ ဆုံးဖြတ်ရန်ကြိုးစားရာတွင် အဖိုးတန်အချိန် 2 စက္ကန့်ခန့် ဆုံးရှုံးပါသည်။

ဤသည်မှာ ကျွန်ုပ်တို့၏ cloud ဗီဒီယိုစောင့်ကြည့်ရေးစနစ်နှင့် ကိုယ်ရေးကိုယ်တာအကောင့်တွင် သင့်ကိုစောင့်ကြိုနေသော အပြောင်းအလဲများ၏ အကျဉ်းချုပ်ဖြစ်သည်။ ကျွန်ုပ်တို့နှင့်အတူနေ၍ သတင်းကိုလိုက်နာပါ။

source: www.habr.com