WebRTC ແລະ​ການ​ເຝົ້າ​ລະ​ວັງ​ວິ​ດີ​ໂອ​: ວິ​ທີ​ທີ່​ພວກ​ເຮົາ​ເອົາ​ຊະ​ນະ​ວິ​ດີ​ໂອ latency ຈາກ​ກ້ອງ​ຖ່າຍ​ຮູບ​

ຈາກມື້ທໍາອິດຂອງການເຮັດວຽກໃນລະບົບການເຝົ້າລະວັງ cloud video, ພວກເຮົາປະເຊີນກັບບັນຫາ, ໂດຍບໍ່ມີການແກ້ໄຂທີ່ພວກເຮົາສາມາດຍອມແພ້ກັບ Ivideon - ນີ້ແມ່ນ Everest ຂອງພວກເຮົາ, ການປີນໄດ້ໃຊ້ເວລາຫຼາຍພະລັງງານ, ແຕ່ໃນປັດຈຸບັນພວກເຮົາໃນທີ່ສຸດ. ຈັບຂວານກ້ອນໃສ່ເທິງສຸດຂອງປິດສະໜາຂ້າມເວທີ.

ລະບົບສໍາລັບການຖ່າຍທອດສຽງແລະວິດີໂອຜ່ານອິນເຕີເນັດບໍ່ຄວນຂຶ້ນກັບອຸປະກອນ, ລູກຄ້າເວັບແລະມາດຕະຖານທີ່ເຂົາເຈົ້າສະຫນັບສະຫນູນ, ແລະຍັງເຮັດວຽກຢ່າງຖືກຕ້ອງໃນທີ່ປະທັບຂອງ Network Address Translators ແລະ firewalls. ຜູ້ໃຊ້ເຝົ້າລະວັງວິດີໂອຄລາວຕ້ອງການເຂົ້າເຖິງການບໍລິການ, ເຖິງແມ່ນວ່າລາວຈະໃຊ້ກ້ອງຖ່າຍຮູບອະນາລັອກ, ແລະມັກເບິ່ງການຖ່າຍທອດວິດີໂອສົດໃນອຸປະກອນທີ່ທັນສະໄຫມທີ່ສຸດ.

ມັນເປັນສິ່ງສໍາຄັນຫຼາຍທີ່ຜູ້ໃຊ້ຕ້ອງການເບິ່ງວິດີໂອທີ່ມີການຊັກຊ້າຫນ້ອຍທີ່ສຸດ. ເກືອບເປັນວິທີດຽວທີ່ຈະສະແດງວິດີໂອທີ່ມີ latency ຕ່ໍາໃນຕົວທ່ອງເວັບແມ່ນການນໍາໃຊ້ WebRTC (ເວັບໄຊຕ໌ການສື່ສານໃນເວລາທີ່ແທ້ຈິງ). WebRTC ແມ່ນຊຸດຂອງເທກໂນໂລຍີສຳລັບການຖ່າຍທອດວິດີໂອ ແລະສຽງແບບ peer-to-peer ໃນໂປຣແກຣມທ່ອງເວັບ, ໃນເບື້ອງຕົ້ນອອກແບບມາສຳລັບການສົ່ງ ແລະ ການຫຼິ້ນການຖ່າຍທອດວິດີໂອທີ່ມີເວລາຕອບສະໜອງຕໍ່າ. ສໍາລັບຈຸດປະສົງນີ້, ໃນບັນດາສິ່ງອື່ນໆ, ໂປໂຕຄອນ UDP ຖືກນໍາໃຊ້.

ກ່ອນທີ່ພວກເຮົາຈະບອກທ່ານສິ່ງທີ່ເຄື່ອງຈັກໃຫມ່ໃຫ້ຜູ້ໃຊ້, ພວກເຮົາຈະເຕືອນທ່ານວ່າເປັນຫຍັງແລະເປັນຫຍັງພວກເຮົາສະຫນັບສະຫນູນເຕັກໂນໂລຊີ HLS, ແລະເປັນຫຍັງພວກເຮົາຕັດສິນໃຈທີ່ຈະກ້າວຕໍ່ໄປ.

ເຄື່ອງຈັກ HLS: ຂໍ້ດີ ແລະ ຂໍ້ເສຍ

(c)

ເທັກໂນໂລຢີ HLS (HTTP Live Streaming) ໄດ້ຖືກພັດທະນາໂດຍ Apple, ສະນັ້ນມັນຈຶ່ງບໍ່ແປກໃຈທີ່ມັນໄດ້ຮັບການສະໜັບສະໜູນເປັນຄັ້ງທຳອິດໃນອຸປະກອນ Apple. ໃນປະຈຸບັນ, ວິດີໂອ HLS ຍັງໄດ້ຮັບການສະໜັບສະໜູນໂດຍເກືອບທຸກກ່ອງ set-top ແລະອຸປະກອນຫຼາຍຢ່າງທີ່ໃຊ້ລະບົບປະຕິບັດການ. Android.

ເຄື່ອງຈັກ HLS ໃຊ້ຕົວແປງສັນຍານວິດີໂອ H264 ທີ່ມີຊື່ສຽງໃນການປະສົມປະສານກັບສະຕຣີມສຽງ AAC ຫຼື MP3 ເພື່ອຖ່າຍທອດຂໍ້ມູນວິດີໂອ. ການຖ່າຍທອດຂໍ້ມູນສຽງ ແລະວິດີໂອທັງໝົດຖືກບັນຈຸເຂົ້າໄປໃນຖັງຂົນສົ່ງ MPEG-TS. ສໍາລັບການສົ່ງຜ່ານໂປໂຕຄອນ HTTP, ຂໍ້ມູນທີ່ມີຢູ່ໃນກະແສແມ່ນແບ່ງອອກເປັນຊິ້ນທີ່ອະທິບາຍໄວ້ໃນລາຍການຫຼິ້ນ m3u8. ແລະພຽງແຕ່ຫຼັງຈາກນັ້ນຊິ້ນເຫຼົ່ານີ້, ພ້ອມກັບ playlists, ຖືກສົ່ງຜ່ານ HTTP. Chunking ອັດຕະໂນມັດຫມາຍເຖິງການຊັກຊ້າໃນວິນາທີ. ນີ້ແມ່ນຄຸນສົມບັດຂອງບັນຈຸ MPEG-TS.

ເຄື່ອງຈັກ HLS ຍັງຮອງຮັບການຖ່າຍທອດແບບ multibitrate, Live/VOD.

ປະໂຫຍດຕົ້ນຕໍຂອງ HLS:

• ສະຫນັບສະຫນູນການກໍ່ສ້າງໃນທຸກຕົວທ່ອງເວັບທີ່ສໍາຄັນ;
• ຄວາມງ່າຍຂອງການຈັດຕັ້ງປະຕິບັດ (ທຽບກັບ WebRTC);
• ມັນສະດວກຫຼາຍແລະມີປະສິດທິພາບໃນການຈັດຕັ້ງການອອກອາກາດທຸກປະເພດໃຫ້ກັບຜູ້ຊົມຂະຫນາດໃຫຍ່ເນື່ອງຈາກຄວາມຈິງທີ່ວ່າສ່ວນຕ່າງໆສາມາດອັບໂຫລດໄປຍັງ CDN ຄັ້ງດຽວ.

ເຖິງວ່າຈະມີຄວາມງ່າຍດາຍຂອງເຄື່ອງຈັກ, ບໍ່ແມ່ນທຸກສິ່ງທຸກຢ່າງແມ່ນກ້ຽງເທົ່າທີ່ມັນເບິ່ງຄືວ່າ. ບັນຫາຕົ້ນຕໍແມ່ນວ່າຜູ້ພັດທະນາຜູ້ນພາກສ່ວນທີສາມໄດ້ຍ້າຍອອກໄປຈາກຄໍາແນະນໍາຂອງ Apple, ສໍາລັບການຍົກຕົວຢ່າງ, ໃນຮູບແບບສຽງທີ່ສະຫນັບສະຫນູນ. ໂດຍສະເພາະ, ນັກພັດທະນາຈໍານວນຫຼາຍໄດ້ເລີ່ມຕົ້ນທີ່ຈະເພີ່ມຄວາມສາມາດໃນການເຮັດວຽກກັບກະແສສຽງທີ່ນິຍົມ: ວິດີໂອ mpeg2, ສຽງ mpeg2, ແລະອື່ນໆ. ດັ່ງນັ້ນ, ພວກເຂົາຕ້ອງສ້າງຮູບແບບ playlist ທີ່ແຕກຕ່າງກັນສໍາລັບຜູ້ນທີ່ແຕກຕ່າງກັນ.

ແຕ່ຫນຶ່ງໃນບັນຫາໃຫຍ່ທີ່ສຸດກັບເຄື່ອງຈັກ HLS ແມ່ນ latency ສູງໃນການໂອນຂໍ້ມູນ.

ຕົ້ນກໍາເນີດຂອງ "ເບກ"

ເຫດຜົນຕົ້ນຕໍສໍາລັບການ latency ສູງຂອງ HLS ແມ່ນຢູ່ໃນຄວາມຈິງທີ່ວ່ານັກຂຽນໂປລແກລມສ້າງເຄື່ອງຈັກເພື່ອໃຫ້ໄດ້ຮູບພາບທີ່ມີຄຸນນະພາບສູງສຸດ. ດັ່ງນັ້ນ, ພາລາມິເຕີຂອງໄລຍະຫ່າງຂອງເຟຣມທີ່ໃຊ້ ແລະຂະໜາດຂອງບັຟເຟີການຫຼິ້ນແມ່ນບໍ່ເໝາະສົມກັບການຖ່າຍທອດວິດີໂອສົດໆ. ເນື່ອງຈາກວ່ານີ້, ມີຄວາມຊັກຊ້າສູງພໍສົມຄວນໃນການສົ່ງວິດີໂອວິດີໂອ, ຊຶ່ງສາມາດ 5-7 ວິນາທີ.

ໃນອີກດ້ານຫນຶ່ງ, ນີ້ບໍ່ແມ່ນຫຼາຍ, ສໍາລັບການຍົກຕົວຢ່າງ, ສໍາລັບຜູ້ທີ່ເບິ່ງຮູບເງົາຈາກເຄື່ອງແມ່ຂ່າຍຂອງວິດີໂອໂຮດຕິ້ງ. ແຕ່ສໍາລັບລະບົບການເຝົ້າລະວັງວິດີໂອ, ການຊັກຊ້າໃນການຖ່າຍທອດວິດີໂອ footage ສາມາດມີຄວາມສໍາຄັນຫຼາຍ.

ຖ້າເຈົ້າກໍາລັງເບິ່ງຫ້ອງການທີ່ພະນັກງານເບິ່ງຈາກຈໍພາບຂອງເຂົາເຈົ້າຫນຶ່ງຊົ່ວໂມງ, ຫຼັງຈາກນັ້ນການຊັກຊ້າ 5 ວິນາທີແມ່ນບໍ່ສໍາຄັນ. ແຕ່ປະຊາຊົນເລີ່ມຈົ່ມວ່າ, ຕົວຢ່າງ, ເມື່ອອອກອາກາດການແຂ່ງຂັນບານເຕະ, ພວກເຂົາເຈົ້າໄດ້ຂຽນ GOOOOL ໃນການສົນທະນາ, ແຕ່ນີ້ຍັງບໍ່ທັນມີຢູ່ໃນວິດີໂອ :). ພວກເຮົາມີກໍລະນີຜູ້ໃຊ້ຈໍານວນຫນຶ່ງແລ້ວທີ່ Ivideon ຄວນປ່ຽນແທນ Skype.

ມັນເປັນໄປໄດ້ທີ່ຈະເອົາຊະນະຄວາມລ່າຊ້າໃນ HLS? ຄໍາຕອບຂອງຄໍາຖາມນີ້ຟັງຄືຄໍາເວົ້າຂອງຜູ້ກໍາຈັດຫນູທີ່ມີປະສົບການໃນການບັນຍາຍຕໍ່ຜູ້ຊ່ຽວຊານດ້ານການຄວບຄຸມສັດຕູພືດໃຫມ່: "ຫນູບໍ່ສາມາດຖືກກໍາຈັດໄດ້, ແຕ່ຕົວເລກຂອງພວກມັນສາມາດຫຼຸດລົງໃນລະດັບຕໍ່າສຸດທີ່ສົມເຫດສົມຜົນ." ດຽວກັນກັບການຊັກຊ້າໃນ HLS, ມັນຈະບໍ່ສາມາດຫຼຸດລົງເປັນສູນ, ແຕ່ມີວິທີແກ້ໄຂໃນຕະຫຼາດທີ່ສາມາດຫຼຸດຜ່ອນຄວາມລ່າຊ້າໄດ້ຢ່າງຫຼວງຫຼາຍ.

ຕັດລະອຽດ

ຂໍ້ເສຍອີກອັນຫນຶ່ງຂອງເຄື່ອງຈັກແມ່ນການນໍາໃຊ້ໄຟລ໌ຂະຫນາດນ້ອຍສໍາລັບການໂອນຂໍ້ມູນ. ມັນເບິ່ງຄືວ່າ, ມີຫຍັງຜິດພາດກັບສິ່ງນີ້?

ໃຜກໍ່ຕາມທີ່ພະຍາຍາມຄັດລອກໄຟລ໌ຂະຫນາດນ້ອຍຈໍານວນຫລາຍຈາກຂະຫນາດກາງຫນຶ່ງໄປຫາອີກຄົນຫນຶ່ງອາດຈະສັງເກດເຫັນວ່າຄວາມໄວການຂຽນຂອງຊຸດດັ່ງກ່າວຕ່ໍາກວ່າຫຼາຍໄຟລ໌ຂະຫນາດໃຫຍ່ທີ່ມີຂະຫນາດດຽວກັນ. ແລະຄວາມເຂັ້ມຂົ້ນຂອງການເຂົ້າເຖິງຮາດດິດເພີ່ມຂຶ້ນຢ່າງຫຼວງຫຼາຍ, ເຊິ່ງໂດຍທົ່ວໄປມີຜົນກະທົບທາງລົບຕໍ່ການປະຕິບັດຂອງຄອມພິວເຕີ້ທັງຫມົດ. ດັ່ງນັ້ນ, ການຖ່າຍທອດຂໍ້ມູນວິດີໂອໃນ chunks 10 ວິນາທີຂະຫນາດນ້ອຍຍັງປະກອບສ່ວນເຂົ້າໃນການ latency ເຄື່ອງຈັກເພີ່ມຂຶ້ນ.

ຂໍໃຫ້ສະຫຼຸບໂດຍຫຍໍ້ກ່ຽວກັບຂໍ້ດີແລະຂໍ້ເສຍຂອງເຕັກໂນໂລຢີ HLS.

ຂໍ້ດີຂອງ HLS:

1. ຄວາມສາມາດໃນການເຮັດວຽກກັບອຸປະກອນຕ່າງໆ. ທ່ານ​ສາ​ມາດ​ເບິ່ງ​ວິ​ດີ​ໂອ​ກ່ຽວ​ກັບ​ອຸ​ປະ​ກອນ​ທີ່​ທັນ​ສະ​ໄຫມ​, ບໍ່​ວ່າ​ຈະ​ເປັນ​ໂທລະ​ສັບ​ສະ​ຫຼາດ​, ແທັບ​ເລັດ​, ແລັບ​ທັອບ​ຫຼື desktop PC​. ສິ່ງທີ່ສໍາຄັນແມ່ນວ່າຕົວທ່ອງເວັບຂອງເວັບແມ່ນທັນສະໄຫມແລະເຂົ້າກັນໄດ້ກັບ HTML5 ແລະການຂະຫຍາຍແຫຼ່ງສື່.
2. ຄຸນ​ນະ​ພາບ​ຮູບ​ພາບ​ທີ່​ດີ​ເລີດ​. ຟັງຊັນການສົ່ງຂໍ້ມູນແບບປັບຕົວທີ່ໃຊ້ໄດ້ຊ່ວຍໃຫ້ທ່ານສາມາດປ່ຽນຄຸນນະພາບຂອງວິດີໂອທີ່ສົ່ງຜ່ານແບບເຄື່ອນໄຫວໂດຍອີງຕາມແບນວິດຂອງການເຊື່ອມຕໍ່ອິນເຕີເນັດ, ໃນຂະນະທີ່ລະບົບພະຍາຍາມຮັກສາຄຸນນະພາບສູງສຸດ.
3. ບໍ່ຈໍາເປັນຕ້ອງມີການຕັ້ງຄ່າສະລັບສັບຊ້ອນຂອງອຸປະກອນຂອງຜູ້ໃຊ້.

ຄົນດ້ອຍໂອກາດ:

1. ການສະຫນັບສະຫນູນຈໍາກັດສໍາລັບການເຮັດວຽກກັບເຄື່ອງຈັກໃນບາງອຸປະກອນ.
2. ຄວາມລ່າຊ້າສູງໃນການສົ່ງຮູບພາບ.
3. ການເພີ່ມຂຶ້ນຢ່າງຫຼວງຫຼາຍໃນຄ່າໃຊ້ຈ່າຍເກີນແລະຄວາມຊັບຊ້ອນຂອງການເພີ່ມປະສິດທິພາບເນື່ອງຈາກການນໍາໃຊ້ໄຟລ໌ຂະຫນາດນ້ອຍ. ເນື່ອງຈາກລັກສະນະຂອງຕູ້ຄອນເທນເນີ, ພວກເຮົາຈະບໍ່ສາມາດໄດ້ຮັບເວລາ latency ຕ່ໍາກວ່າຂະຫນາດຂອງສ່ວນ.

ຂໍ້ເສຍຂອງ HLS ເກີນຄວາມໄດ້ປຽບຂອງມັນສໍາລັບພວກເຮົາແລະບັງຄັບໃຫ້ພວກເຮົາຊອກຫາທາງເລືອກອື່ນ.

WebRTC ແມ່ນຫຍັງ

(c)

ແພລດຟອມ WebRTC ໄດ້ຖືກພັດທະນາໂດຍ Google ໃນປີ 2011 ເພື່ອສົ່ງຂໍ້ມູນການຖ່າຍທອດວິດີໂອ ແລະສຽງລະຫວ່າງຕົວທ່ອງເວັບ ແລະແອັບພລິເຄຊັນມືຖື ທີ່ມີເວລາແພັກເກັດໜ້ອຍທີ່ສຸດ. ສໍາລັບການນີ້, ອະນຸສັນຍາ UDP ມາດຕະຖານແລະວິທີການຄວບຄຸມການໄຫຼເຂົ້າພິເສດແມ່ນຖືກນໍາໃຊ້. ມື້ນີ້ມັນເປັນໂຄງການແຫຼ່ງເປີດ, ມັນຖືກຮັກສາໄວ້ຢ່າງຈິງຈັງໂດຍ Google ແລະກໍາລັງພັດທະນາ.

WebRTC ແມ່ນຊຸດຂອງເທັກໂນໂລຍີສຳລັບການສົ່ງຕໍ່ວິດີໂອ ແລະສຽງຈາກໝູ່ເພື່ອນ. ນັ້ນແມ່ນ, ສໍາລັບຕົວຢ່າງ, ຕົວທ່ອງເວັບຂອງຜູ້ໃຊ້ທີ່ໃຊ້ WebRTC ສາມາດໂອນຂໍ້ມູນໄປຫາກັນແລະກັນໂດຍກົງ, ໂດຍບໍ່ຕ້ອງໃຊ້ເຄື່ອງແມ່ຂ່າຍຫ່າງໄກສອກຫຼີກສໍາລັບການເກັບຮັກສາແລະການປຸງແຕ່ງຂໍ້ມູນ. ຂໍ້ມູນທັງໝົດຍັງຖືກປະມວນຜົນໂດຍຕົວທ່ອງເວັບຂອງຜູ້ໃຊ້ສຸດທ້າຍ ແລະແອັບພລິເຄຊັນມືຖື.

ຄວາມສະດວກສະບາຍ ແລະ ຄວາມສາມາດຢ່າງກວ້າງຂວາງຂອງເທັກໂນໂລຢີນີ້ໄດ້ຮັບການຍົກຍ້ອງຈາກນັກພັດທະນາໂປຣແກຣມທ່ອງເວັບທີ່ນິຍົມທັງໝົດ. ການຮອງຮັບ WebRTC ໃນປະຈຸບັນມີໃຫ້ໃຊ້ໃນ Mozilla Firefox, Opera, Google Chrome (ແລະໂປຣແກຣມທ່ອງເວັບທີ່ອີງໃສ່ Chromium ທັງໝົດ), ເຊັ່ນດຽວກັນກັບໃນແອັບມືຖືທີ່ໃຊ້ງານ Android ແລະ iOS.

ສໍາລັບຂໍ້ໄດ້ປຽບທີ່ບໍ່ຕ້ອງສົງໃສຂອງມັນ, WebRTC ມີຂໍ້ເສຍທີ່ສໍາຄັນຈໍານວນຫນຶ່ງ.

ຄວາມຫຍຸ້ງຍາກໃນການເລືອກ

ເທກໂນໂລຍີ WebRTC ແມ່ນມີຄວາມຊັບຊ້ອນຫຼາຍໃນການໂຕ້ຕອບຂອງເຄືອຂ່າຍເນື່ອງຈາກຄວາມຈິງທີ່ວ່າມັນແມ່ນກ່ຽວກັບ P2P. ມັນເປັນການຍາກທີ່ຈະດີບັກ, ທົດສອບ, ແລະສາມາດປະຕິບັດຕົວບໍ່ໄດ້. ໃນເວລາດຽວກັນ, ພວກເຮົາຈໍາເປັນຕ້ອງເອົາຊະນະ NAT ແລະ firewall, ພວກເຮົາຈໍາເປັນຕ້ອງຮັບປະກັນການດໍາເນີນງານໃນເຄືອຂ່າຍທີ່ UDP ຖືກບລັອກ.

ການປະຕິບັດ WebRTC ຂອງ Google ແມ່ນມີຄວາມຫຍຸ້ງຍາກຫຼາຍທີ່ຈະນໍາໃຊ້. ຍັງມີບໍລິສັດທັງໝົດທີ່ໃຫ້ບໍລິການປະກອບ SDK. ນອກຈາກນັ້ນ, ການປະຕິບັດຂອງ Google ແມ່ນມີຄວາມຫຍຸ້ງຍາກຫຼາຍທີ່ຈະປະສົມປະສານກັບລະບົບຂອງພວກເຮົາໂດຍບໍ່ມີການເຂົ້າລະຫັດວິດີໂອທັງຫມົດຄືນໃຫມ່.

ແນວໃດກໍ່ຕາມ, ພວກເຮົາຕ້ອງການໃຫ້ຜູ້ໃຊ້ມີໂອກາດເຮັດວຽກກັບວິດີໂອ “ສົດ” ເຕັມຮູບແບບ ແລະ ຫຼຸດຜ່ອນຄວາມຊັກຊ້າລະຫວ່າງຮູບພາບໃນໜ້າຈໍ ແລະ ເຫດການຕ່າງໆ. ນອກຈາກນັ້ນ, ພວກເຮົາມີຄວາມປາດຖະຫນາທີ່ຈະໃຊ້ກ້ອງຖ່າຍຮູບ PTZ, ບ່ອນທີ່ຄວາມຊັກຊ້າແມ່ນສໍາຄັນ, ສະດວກສະບາຍກວ່າ.

ພິຈາລະນາວ່າການປະຕິບັດການຕ້ານການຊັກຊ້າອື່ນໆຍັງມີຫນ້າທີ່ຈໍາກັດແລະເຮັດວຽກທີ່ຮ້າຍແຮງກວ່າເກົ່າ, ພວກເຮົາໄດ້ຕັດສິນໃຈໃຊ້ WebRTC.

ພວກເຮົາໄດ້ເຮັດຫຍັງແລ້ວ

ການປະຕິບັດແພລະຕະຟອມ WebRTC ຢ່າງຖືກຕ້ອງບໍ່ແມ່ນວຽກທີ່ງ່າຍ. ການຄິດໄລ່ທີ່ບໍ່ຖືກຕ້ອງຫຼືບໍ່ຖືກຕ້ອງສາມາດນໍາໄປສູ່ຄວາມລ່າຊ້າໃນການຖ່າຍທອດວິດີໂອບໍ່ພຽງແຕ່ບໍ່ຫຼຸດລົງເມື່ອທຽບກັບເວທີອື່ນໆ, ແຕ່ຍັງເພີ່ມຂຶ້ນ.

ເພື່ອໃຫ້ WebRTC ເຮັດວຽກຢ່າງຖືກຕ້ອງ, ກ່ອນອື່ນ ໝົດ, ມັນ ຈຳ ເປັນຕ້ອງ ດຳ ເນີນການຍົກລະດັບເຕັກໂນໂລຢີຂອງ stack ສໍາລັບການເຮັດວຽກກັບວິດີໂອເວັບ. ນັ້ນແມ່ນສິ່ງທີ່ພວກເຮົາໄດ້ເຮັດ.

ທຳອິດ, ພວກເຮົາໄດ້ນຳໃຊ້ເຊີບເວີໂປຣໂຕຄໍສັນຍານ WebRTC ຜ່ານ Websocket, ແລະຍັງໄດ້ນຳໃຊ້ WebRTC peer server ໃນຄລາວໂດຍອີງໃສ່ webrtc.org SDK. ໜ້າທີ່ຂອງມັນແມ່ນເພື່ອແຈກຢາຍການຖ່າຍທອດວິດີໂອໃຫ້ລູກຄ້າ WebRTC ມິດສະຫາຍໃນຮູບແບບ H.264 + Opus/G.711 ໂດຍບໍ່ມີການປ່ຽນລະຫັດວິດີໂອ.

ພວກເຮົາເລືອກ Websocket ເປັນໂປໂຕຄອນສັນຍານເນື່ອງຈາກວ່າມັນມີການສະຫນັບສະຫນູນທີ່ມີຄຸນນະພາບສູງໃນຕົວທ່ອງເວັບທີ່ນິຍົມທັງຫມົດ. ດ້ວຍເຫດຜົນນີ້, ທ່ານສາມາດຫຼຸດລົງຢ່າງຫຼວງຫຼາຍບໍ່ພຽງແຕ່ການພັດທະນາດ້ານເທິງ, ແຕ່ຍັງຫຼີກເວັ້ນການເສຍເວລາແລະຊັບພະຍາກອນໃນການຈັບມື TCP ແລະ TLS ຊ້ໍາຊ້ອນເມື່ອທຽບກັບ AJAX.

ຄວາມຈິງແລ້ວແມ່ນວ່າ, ໂດຍຄ່າເລີ່ມຕົ້ນ, WebRTC ບໍ່ໄດ້ໃຫ້ໂປໂຕຄອນສັນຍານທີ່ຈໍາເປັນເພື່ອກໍານົດ, ຮັກສາ, ແລະຢຸດການສື່ສານວິດີໂອໃນເວລາທີ່ແທ້ຈິງລະຫວ່າງແຫຼ່ງແລະຄໍາຮ້ອງສະຫມັກຂອງລູກຄ້າ.

ແລະເພື່ອປະຕິບັດເຕັກໂນໂລຢີສັນຍານເປັນເອກະລາດ, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ພັດທະນາເຄື່ອງແມ່ຂ່າຍສັນຍານຂອງພວກເຮົາເອງໂດຍສະຫນັບສະຫນູນໂປໂຕຄອນເວັບຫຼາຍ (Websocet, WebRTC). ແລະມີຄວາມສາມາດໃນການຈັດການກອງປະຊຸມແລະການແຈ້ງເຕືອນຢ່າງປອດໄພໃນເວລາຈິງ, ການຈັດການວິດີໂອແລະອື່ນໆອີກ.

ພວກເຮົາໄດ້ເອົາຊະນະຂໍ້ຈໍາກັດຂອງ P2P ໂດຍການຫຼຸດຜ່ອນ latency ບໍ່ຜ່ານ P2P, ແຕ່ຜ່ານ UDP ແລະການຄວບຄຸມການໄຫຼເຂົ້າເພື່ອຫຼຸດຜ່ອນ latency. ນີ້ກໍ່ຖືກສ້າງຂຶ້ນໃນ WebRTC, ນັບຕັ້ງແຕ່ກໍລະນີທີ່ໃຊ້ຕົ້ນຕໍແມ່ນການສົນທະນາ p2p ຜ່ານຕົວທ່ອງເວັບ.

ໃນລູກຄ້າມືຖື, ພວກເຮົາໄດ້ປະຕິບັດເຄື່ອງຫຼິ້ນໂດຍໃຊ້ webrtc.org SDK, ເພາະວ່າພຽງແຕ່ມັນປະຕິບັດການຄວບຄຸມການໄຫຼຢ່າງຖືກຕ້ອງ, ມີແຜນການແກ້ໄຂຄວາມຜິດພາດ Forward (FEC) ທັງຫມົດທີ່ຮູ້ຈັກ, ແລະປະຕິບັດກົນໄກການສົ່ງແພັກເກັດສໍາລັບທຸກຕົວທ່ອງເວັບຢ່າງຖືກຕ້ອງ. ມັນຍັງມີຄວາມສໍາຄັນທີ່ webrtc.org SDK ກໍາລັງຖືກພັດທະນາຢ່າງຈິງຈັງໂດຍ Google.

ຜົນໄດ້ຮັບຂອງການປະຕິບັດ WebRTC ແມ່ນຫຍັງ?

ເພື່ອເບິ່ງວິດີໂອສົດໆຈາກກ້ອງ, ພວກເຮົາໄດ້ເພີ່ມເຄື່ອງຫຼິ້ນທີ່ປັບແຕ່ງມາໃໝ່ໂດຍອີງໃສ່ WebRTC ໃສ່ບັນຊີສ່ວນຕົວຂອງທ່ານ. ມັນສະຫນອງຄວາມໄວໃນການໂຫຼດວິດີໂອໄວແລະຫມົດກໍາຈັດບັນຫາຂອງ latency ສະສົມຍ້ອນວ່າເວລາເບິ່ງເພີ່ມຂຶ້ນ.

ຫຼັງຈາກການແນະນໍາການສະຫນັບສະຫນູນ WebRTC ໃນການບໍລິການຄລາວຂອງ Ivideon, ພວກເຮົາສາມາດເວົ້າດ້ວຍຄວາມຫມັ້ນໃຈຢ່າງສົມບູນວ່າລູກຄ້າຂອງພວກເຮົາສາມາດເບິ່ງວິດີໂອສົດໆຢ່າງເຕັມທີ່. ໃນປັດຈຸບັນຄວາມລ່າຊ້າໃນເວລາທີ່ການອອກອາກາດລໍາດັບວິດີໂອບໍ່ເກີນຫນຶ່ງວິນາທີ! ສໍາລັບການປຽບທຽບ, ເຄື່ອງຈັກ HLS ທີ່ຜ່ານມາໄດ້ສະຫນອງການຈັດສົ່ງວິດີໂອທີ່ມີຄວາມຊັກຊ້າ 5-7 ວິນາທີ. ຄວາມແຕກຕ່າງໃນຄວາມໄວການສາທິດວິດີໂອແມ່ນມີຄວາມສໍາຄັນຫຼາຍ, ແລະຜູ້ໃຊ້ຈະສັງເກດເຫັນມັນທັນທີຫຼັງຈາກທີ່ເລີ່ມເຮັດວຽກກັບການບໍລິການວິດີໂອຂອງພວກເຮົາ.

ດັ່ງທີ່ພວກເຮົາຄາດຫວັງ, ການປະຕິບັດຜູ້ນໃຫມ່ໄດ້ປັບປຸງການຕອບສະຫນອງຂອງ PTZ ແລະການສື່ສານສຽງກັບກ້ອງຖ່າຍຮູບ.

ມີພຽງແຕ່ຫນຶ່ງຈຸດອ່ອນໆທີ່ພວກເຮົາຕ້ອງການທີ່ຈະດຶງດູດຄວາມສົນໃຈ. ຕົວຫຼິ້ນ WebRTC ໃໝ່ກຳລັງເຮັດວຽກຢູ່ໃນໂໝດທົດສອບ. ແລະນັ້ນແມ່ນເຫດຜົນທີ່ພວກເຮົາບໍ່ເປີດໃຊ້ມັນສໍາລັບລູກຄ້າທັງຫມົດຂອງພວກເຮົາໂດຍຄ່າເລີ່ມຕົ້ນ. ແຕ່​ທ່ານ​ສາ​ມາດ​ກະ​ຕຸ້ນ​ຕົວ​ທ່ານ​ເອງ​ໂດຍ​ການ​ເປີດ​ໃຊ້​ງານ​ລາຍ​ການ​ທີ່​ສອດ​ຄ້ອງ​ກັນ​ໃນ​ການ​ຕັ້ງ​ຄ່າ​ກ້ອງ​ຖ່າຍ​ຮູບ (ເພື່ອ​ເຮັດ​ສິ່ງ​ນີ້​ທ່ານ​ຈໍາ​ເປັນ​ຕ້ອງ​ໄປ​ທີ່ ບັນຊີສ່ວນບຸກຄົນ).

ຄຸນນະສົມບັດຂອງການປະຕິບັດ WebRTC ໃນການບໍລິການ Ivideon

WebRTC ຍັງເປັນເຕັກໂນໂລຊີທົດລອງໃນປັດຈຸບັນ. ການສະຫນັບສະຫນູນຂອງມັນຍັງບໍ່ທັນຖືກປະຕິບັດຢ່າງຖືກຕ້ອງໃນທຸກຕົວທ່ອງເວັບແລະອຸປະກອນຜູ້ໃຊ້, ແລະບໍ່ແມ່ນຢູ່ໃນທຸກກ້ອງຖ່າຍຮູບ.

ນີ້ແມ່ນແນ່ນອນວ່າເປັນຫຍັງພວກເຮົາຍັງບໍ່ໄດ້ເຮັດໃຫ້ເຄື່ອງຫຼິ້ນ WebRTC ເປັນຄ່າເລີ່ມຕົ້ນສໍາລັບຜູ້ໃຊ້ທັງຫມົດ.

ສໍາລັບໃນປັດຈຸບັນ, ພວກເຮົາແນະນໍາໃຫ້ໃຊ້ WebRTC ຢູ່ໃນຕົວທ່ອງເວັບຂອງ Google Chrome ເທົ່ານັ້ນ. ເວີຊັນຫຼ້າສຸດຂອງ Firefox ແລະ Safari ຍັງຮອງຮັບເທກໂນໂລຍີນີ້, ແຕ່ຫນ້າເສຍດາຍ, ມັນຍັງບໍ່ຄົງທີ່.

ພວກເຮົາຍັງບໍ່ທັນໄດ້ປະຕິບັດການສະຫນັບສະຫນູນ WebRTC ສໍາລັບຕົວທ່ອງເວັບໃນອຸປະກອນມືຖື. ໃນປັດຈຸບັນ, ຖ້າທ່ານເຂົ້າສູ່ລະບົບຈາກອຸປະກອນມືຖືແລະເປີດໃຊ້ WebRTC, ຮູບແບບນີ້ຈະບໍ່ເຮັດວຽກ. ຢ່າງໃດກໍຕາມ, WebRTC ແມ່ນມີຢູ່ໃນຄໍາຮ້ອງສະຫມັກມືຖືຂອງພວກເຮົາສໍາລັບ Android и iOS.

ແລະສະຫຼຸບເລື່ອງກ່ຽວກັບລັກສະນະຂອງການປະຕິບັດ WebRTC ໃນການບໍລິການຂອງພວກເຮົາ, ໃຫ້ສັງເກດສອງຈຸດທີ່ລະອຽດອ່ອນກວ່າ.

ກ່ອນອື່ນ ໝົດ, ເຕັກໂນໂລຢີແມ່ນສຸມໃສ່ການຖ່າຍທອດວິດີໂອສົດໆໃນເວລາຈິງ. ດັ່ງນັ້ນ, ຖ້າຊ່ອງຂອງທ່ານບໍ່ມີແບນວິດພຽງພໍເພື່ອຖ່າຍທອດວິດີໂອ, ທ່ານຈະສັງເກດເຫັນການຫຼຸດລົງຂອງກອບ (ດ້ວຍ HLS ທ່ານຈະສັງເກດເຫັນວິດີໂອຫາຍໄປແລະ latency ເພີ່ມຂຶ້ນ, ແຕ່ຈະບໍ່ມີເຟຣມຫຼຸດລົງ), ແຕ່ວິດີໂອຍັງຈະອອກອາກາດຕົວຈິງ. ເວລາ.

ອັນທີສອງ, ນັບຕັ້ງແຕ່ເຕັກໂນໂລຢີຖືກອອກແບບມາເພື່ອເຮັດວຽກໂດຍສະເພາະກັບວິດີໂອສົດໆໃນເວລາຈິງ, ພວກເຮົາບໍ່ໄດ້ໃຊ້ມັນເພື່ອເຮັດວຽກກັບຂໍ້ມູນວິດີໂອທີ່ຖືກເກັບໄວ້.

ການປ່ຽນແປງອື່ນໆຕໍ່ກັບການບໍລິການ

ໃນເວລານີ້, Flash ບໍ່ໄດ້ມີສ່ວນຮ່ວມໃນກົນໄກການຄັດເລືອກເຄື່ອງຈັກອັດຕະໂນມັດອີກຕໍ່ໄປ. ທ່ານຍັງສາມາດໃຊ້ເຄື່ອງຫຼິ້ນດັ່ງກ່າວໄດ້, ແຕ່ເພື່ອເຮັດອັນນີ້, ທ່ານຈໍາເປັນຕ້ອງເລືອກມັນດ້ວຍຕົນເອງໃນບັນຊີຫຼືການຕັ້ງຄ່າກ້ອງຖ່າຍຮູບ. ນີ້ບໍ່ແມ່ນຄວາມຊົມເຊີຍຕໍ່ຄົນອັບເດດ:, ມັນເປັນພຽງແຕ່ວ່າອີງຕາມສະຖິຕິຂອງການບໍລິການຂອງພວກເຮົາ, ຕົວຈິງແລ້ວບໍ່ມີຜູ້ໃຊ້ປະໄວ້ເຮັດວຽກກັບ Flash. ແລະພະຍາຍາມກໍານົດວ່າຕົວທ່ອງເວັບຂອງຜູ້ໃຊ້ສະຫນັບສະຫນູນມັນ, ພວກເຮົາສູນເສຍເວລາທີ່ມີຄ່າປະມານ 2 ວິນາທີ.

ນີ້ແມ່ນພາບລວມສັ້ນໆຂອງການປ່ຽນແປງທີ່ລໍຖ້າທ່ານຢູ່ໃນລະບົບການເຝົ້າລະວັງວິດີໂອຄລາວ ແລະບັນຊີສ່ວນຕົວຂອງພວກເຮົາ. ຢູ່ກັບພວກເຮົາແລະຕິດຕາມຂ່າວ!

ແຫຼ່ງຂໍ້ມູນ: www.habr.com