முகப்பு WebRTC மீடியா பேரம்: கோடெக் தேர்வு வழிமுறையை விளக்குதல்

நிகழ்நேர தகவல்தொடர்பு (RTC) உலகில், WebRTC ஒரு முக்கிய தொழில்நுட்பமாக விளங்குகிறது, இது பியர்-டு-பியர் ஆடியோ, வீடியோ மற்றும் டேட்டா சேனல்களை நேரடியாக வலை உலாவிகளுக்குள் செயல்பட வைக்கிறது. இந்த இணைப்புகளை நிறுவுவதில் ஒரு முக்கியமான, ஆனால் பெரும்பாலும் சிக்கலான அம்சம் மீடியா பேரம் பேசும் செயல்முறை, குறிப்பாக கோடெக் தேர்வின் நுணுக்கமான நடனம். இந்த செயல்முறை ஒரு WebRTC அழைப்பில் உள்ள இரு தரப்பினரும் பரிமாறப்படும் மீடியா ஸ்ட்ரீம்களைப் புரிந்துகொண்டு ரெண்டர் செய்ய முடியும் என்பதை உறுதி செய்கிறது. முகப்பு டெவலப்பர்களுக்கு, வலுவான, உயர்தரமான மற்றும் உலகளவில் இணக்கமான RTC பயன்பாடுகளை உருவாக்குவதற்கு இந்த வழிமுறையைப் பற்றிய ஆழமான புரிதல் இன்றியமையாதது.

அடிப்படை: செஷன் டெஸ்கிரிப்ஷன் புரோட்டோகால் (SDP)

WebRTC மீடியா பேரத்தின் மையத்தில் செஷன் டெஸ்கிரிப்ஷன் புரோட்டோகால் (SDP) உள்ளது. SDP என்பது மல்டிமீடியா அமர்வுகளை விவரிக்கப் பயன்படுத்தப்படும் ஒரு உரை அடிப்படையிலான வடிவமாகும். இது மீடியாவை மாற்றுவதற்காக அல்ல, மாறாக அந்த அமர்வுகளின் திறன்கள் மற்றும் அளவுருக்களைத் தொடர்புகொள்வதற்காகப் பயன்படுத்தப்படுகிறது. இரண்டு பியர்கள் ஒரு WebRTC இணைப்பைத் தொடங்கும்போது, அவர்கள் SDP ஆஃபர்கள் மற்றும் பதில்களைப் பரிமாறிக்கொள்கிறார்கள். இந்த பரிமாற்றம் பின்வருவனவற்றை விவரிக்கிறது:

• அனுப்பப்படும் மீடியா வகைகள் (ஆடியோ, வீடியோ, தரவு).
• ஒவ்வொரு மீடியா வகைக்கும் ஆதரிக்கப்படும் கோடெக்குகள்.
• மீடியாவை அனுப்புவதற்கும் பெறுவதற்கும் நெட்வொர்க் முகவரிகள் மற்றும் போர்ட்கள்.
• குறியாக்கம், அலைவரிசை மற்றும் பல போன்ற பிற அமர்வு சார்ந்த அளவுருக்கள்.

கோடெக் தேர்வு வழிமுறை இந்த SDP பரிமாற்றத்திற்குள் செயல்படுகிறது. ஒவ்வொரு பியரும் அதன் ஆதரிக்கப்படும் கோடெக்குகளை விளம்பரப்படுத்துகிறது, மேலும் தொடர்ச்சியான பேரங்கள் மூலம், இருவரும் பயன்படுத்தக்கூடிய ஒரு பொதுவான கோடெக்குகளின் தொகுப்பிற்கு வருகிறார்கள். வெவ்வேறு உலாவிகள், இயக்க முறைமைகள் மற்றும் வன்பொருள் வெவ்வேறு கோடெக்குகளை வெவ்வேறு செயல்திறன் மற்றும் தர நிலைகளில் ஆதரிக்கக்கூடும் என்பதால் இங்குதான் சிக்கல் எழுகிறது.

WebRTC-ல் கோடெக்குகளைப் புரிந்துகொள்ளுதல்

தேர்வு வழிமுறையில் மூழ்குவதற்கு முன், கோடெக்குகள் என்றால் என்ன, அவை ஏன் முக்கியமானவை என்பதை சுருக்கமாக வரையறுப்போம்:

• கோடெக் (கோடர்-டிகோடர்): ஒரு கோடெக் என்பது தரவை சுருக்கி மற்றும் விரிக்கும் ஒரு சாதனம் அல்லது நிரலாகும். WebRTC-ல், கோடெக்குகள் மூல ஆடியோ மற்றும் வீடியோ தரவை நெட்வொர்க்கில் அனுப்புவதற்கு ஏற்ற வடிவத்தில் குறியாக்கம் செய்வதற்கும் (சுருக்கம்), பின்னர் அந்த சுருக்கப்பட்ட தரவை பெறும் முனையில் மீண்டும் இயக்கக்கூடிய வடிவத்திற்கு டிகோட் செய்வதற்கும் (விரித்தல்) பொறுப்பாகும்.
• நோக்கம்: அவற்றின் முதன்மை நோக்கம் மீடியா ஸ்ட்ரீம்களை அனுப்புவதற்குத் தேவையான அலைவரிசையைக் குறைப்பதாகும், இது குறைந்த திறன் கொண்ட நெட்வொர்க்குகளில் கூட நிகழ்நேர தகவல்தொடர்பை சாத்தியமாக்குகிறது. அவை வெவ்வேறு சாதனங்கள் மற்றும் தளங்களுக்கு இடையில் இணக்கத்தன்மையை உறுதி செய்வதிலும் ஒரு பங்கு வகிக்கின்றன.

WebRTC பொதுவாக பல ஆடியோ மற்றும் வீடியோ கோடெக்குகளை ஆதரிக்கிறது. நீங்கள் சந்திக்கும் மிகவும் பொதுவானவை:

ஆடியோ கோடெக்குகள்:

• Opus: WebRTC ஆடியோவிற்கான நடைமுறைத் தரநிலை. இது பேச்சு மற்றும் இசை இரண்டிற்கும் வடிவமைக்கப்பட்ட ஒரு பல்துறை, திறந்த மூல மற்றும் ராயல்டி இல்லாத கோடெக் ஆகும், இது பரந்த அளவிலான நெட்வொர்க் நிலைமைகள் மற்றும் பிட்ரேட்டுகளில் சிறந்த தரத்தை வழங்குகிறது. இது அனைத்து WebRTC பயன்பாடுகளுக்கும் மிகவும் பரிந்துரைக்கப்படுகிறது.
• G.711 (PCMU/PCMA): பழைய, பரவலாக இணக்கமான கோடெக்குகள், ஆனால் பொதுவாக Opus-ஐ விட குறைவான செயல்திறன் கொண்டவை. PCMU (μ-law) வட அமெரிக்கா மற்றும் ஜப்பானில் பொதுவானது, அதே நேரத்தில் PCMA (A-law) ஐரோப்பா மற்றும் உலகின் பிற பகுதிகளில் பயன்படுத்தப்படுகிறது.
• iSAC: கூகிளால் உருவாக்கப்பட்ட மற்றொரு வைட்பேண்ட் ஆடியோ கோடெக், இது மாறுபடும் நெட்வொர்க் நிலைமைகளுக்கு ஏற்ப மாற்றிக்கொள்ளும் திறனுக்காக அறியப்படுகிறது.
• ILBC: குறைந்த அலைவரிசைக்காக வடிவமைக்கப்பட்ட ஒரு பழைய, நேரோபேண்ட் கோடெக்.

வீடியோ கோடெக்குகள்:

• VP8: கூகிளால் உருவாக்கப்பட்ட ஒரு திறந்த மூல, ராயல்டி இல்லாத வீடியோ கோடெக். இது பரவலாக ஆதரிக்கப்படுகிறது மற்றும் நல்ல செயல்திறனை வழங்குகிறது.
• VP9: VP8-ன் வாரிசு, இது ஒத்த பிட்ரேட்டுகளில் மேம்பட்ட சுருக்க செயல்திறன் மற்றும் உயர் தரத்தை வழங்குகிறது. இதுவும் கூகிளிடமிருந்து ஒரு திறந்த மூல மற்றும் ராயல்டி இல்லாத கோடெக் ஆகும்.
• H.264 (AVC): மிகவும் திறமையான மற்றும் பரவலாக ஏற்றுக்கொள்ளப்பட்ட தனியுரிம வீடியோ கோடெக். இது மிகவும் பொதுவானதாக இருந்தாலும், அதன் உரிமம் சில பயன்பாடுகளுக்கு ஒரு கருத்தாக இருக்கலாம், இருப்பினும் பெரும்பாலான உலாவிகள் அதை WebRTC-க்கு வழங்குகின்றன.
• H.265 (HEVC): H.264-க்கு இன்னும் திறமையான வாரிசு, ஆனால் மிகவும் சிக்கலான உரிமத்துடன். WebRTC-ல் HEVC-க்கான ஆதரவு H.264-ஐ விட குறைவாகவே உள்ளது.

செயல்பாட்டில் கோடெக் தேர்வு வழிமுறை

கோடெக் தேர்வு செயல்முறை முதன்மையாக SDP ஆஃபர்/ஆன்சர் மாதிரியால் இயக்கப்படுகிறது. இது பொதுவாக எவ்வாறு செயல்படுகிறது என்பதற்கான எளிமைப்படுத்தப்பட்ட முறிவு இங்கே:

படி 1: ஆஃபர் (Offer)

ஒரு WebRTC பியர் (Peer A என்று அழைப்போம்) ஒரு அழைப்பைத் தொடங்கும்போது, அது ஒரு SDP ஆஃபரை உருவாக்குகிறது. இந்த ஆஃபரில் அது ஆதரிக்கும் அனைத்து ஆடியோ மற்றும் வீடியோ கோடெக்குகளின் பட்டியல், వాటికి సంబంధించిన పారామీటర్లు மற்றும் ప్రాధాన్యత క్రమంలో ఉంటాయి. இந்த ஆஃபர் சிக்னலிங் சர்வர் வழியாக மற்ற பியருக்கு (Peer B) அனுப்பப்படுகிறது.

ஒரு SDP ஆஃபர் பொதுவாக இப்படி இருக்கும் (எளிமைப்படுத்தப்பட்ட துணுக்கு):

v=0
...
a=rtpmap:102 opus/48000/2
a=rtpmap:103 VP8/90000
a=rtpmap:104 H264/90000
...

இந்த துணுக்கில்:

• a=rtpmap வரிகள் கோடெக்குகளை விவரிக்கின்றன.
• எண்கள் (எ.கா., 102, 103) பேலோடு வகைகள், இந்த அமர்விற்குள் கோடெக்குகளுக்கான உள்ளூர் அடையாளங்காட்டிகள்.
• opus/48000/2 Opus கோடெக்கைக் குறிக்கிறது, 48000 Hz மாதிரி விகிதம் மற்றும் 2 சேனல்கள் (ஸ்டீரியோ).
• VP8/90000 மற்றும் H264/90000 பொதுவான வீடியோ கோடெக்குகள்.

படி 2: பதில் (Answer)

பியர் B, SDP ஆஃபரைப் பெறுகிறது. பின்னர் அது பியர் A-வின் ஆதரிக்கப்படும் கோடெக்குகளின் பட்டியலை ஆய்வு செய்து, அதை தனது சொந்த ஆதரிக்கப்படும் கோடெக்குகளின் பட்டியலுடன் ஒப்பிடுகிறது. இரு பியர்களும் கையாளக்கூடிய மிக உயர்ந்த பொதுவான கோடெக்கைக் கண்டுபிடிப்பதே குறிக்கோள்.

பொதுவான கோடெக்கைத் தேர்ந்தெடுப்பதற்கான வழிமுறை பொதுவாக பின்வருமாறு:

1. பியர் A-வின் விளம்பரப்படுத்தப்பட்ட கோடெக்குகளை ஒவ்வொன்றாகப் பார்க்கவும், பொதுவாக ஆஃபரில் அவை வழங்கப்படும் வரிசையில் (இது பெரும்பாலும் பியர் A-வின் விருப்பத்தை பிரதிபலிக்கிறது).
2. பியர் A-வின் பட்டியலில் உள்ள ஒவ்வொரு கோடெக்கிற்கும், பியர் B-ம் அதே கோடெக்கை ஆதரிக்கிறதா என்று சரிபார்க்கவும்.
3. ஒரு பொருத்தம் காணப்பட்டால்: இந்த கோடெக் அந்த மீடியா வகைக்கு (ஆடியோ அல்லது வீடியோ) தேர்ந்தெடுக்கப்பட்ட கோடெக்காக மாறுகிறது. பின்னர் பியர் B இந்த தேர்ந்தெடுக்கப்பட்ட கோடெக் மற்றும் அதன் அளவுருக்களை உள்ளடக்கிய ஒரு SDP பதிலை உருவாக்குகிறது, அதற்கு ஒரு பேலோடு வகையை ஒதுக்குகிறது. பதில் சிக்னலிங் சர்வர் வழியாக பியர் A-க்கு மீண்டும் அனுப்பப்படுகிறது.
4. அனைத்து கோடெக்குகளையும் சரிபார்த்த பிறகும் பொருத்தம் காணப்படவில்லை என்றால்: இது அந்த மீடியா வகைக்கு ஒரு பொதுவான கோடெக்கைப் பேரம் பேசத் தவறியதைக் குறிக்கிறது. இந்த வழக்கில், பியர் B தனது பதிலில் இருந்து அந்த மீடியா வகையை விட்டுவிடலாம் (அழைப்பிற்கான ஆடியோ அல்லது வீடியோவை திறம்பட முடக்குகிறது) அல்லது ஒரு மாற்று வழியைப் பேரம் பேச முயற்சிக்கலாம்.

பியர் B-யின் SDP பதில் பின்னர் ஒப்புக்கொள்ளப்பட்ட கோடெக்கை உள்ளடக்கியிருக்கும்:

v=0
...
m=audio 9 UDP/TLS/RTP/SAVPF 102
...
a=rtpmap:102 opus/48000/2
...
m=video 9 UDP/TLS/RTP/SAVPF 103
...
a=rtpmap:103 VP8/90000
...

ஒப்புக்கொள்ளப்பட்ட கோடெக்குகளுக்கு பியர் B எந்த பேலோடு வகையைப் பயன்படுத்தும் (எ.கா., Opus-க்கு 102, VP8-க்கு 103) என்பதை பதில் இப்போது குறிப்பிடுவதைக் கவனியுங்கள்.

படி 3: இணைப்பு நிறுவுதல்

இரு பியர்களும் SDP ஆஃபர்கள் மற்றும் பதில்களைப் பரிமாறி, பொதுவான கோடெக்குகளை ஒப்புக்கொண்டவுடன், அவர்கள் மீடியாவைப் பரிமாறத் தொடங்கத் தேவையான அளவுருக்களை நிறுவியுள்ளனர். WebRTC ஸ்டாக் பின்னர் இந்தத் தகவலைப் பயன்படுத்தி மீடியா போக்குவரத்தை (RTP over UDP) கட்டமைத்து, பியர்-டு-பியர் இணைப்பை நிறுவுகிறது.

கோடெக் தேர்வைப் பாதிக்கும் காரணிகள்

அடிப்படை வழிமுறை நேராக இருந்தாலும் (முதல் பொதுவான கோடெக்கைக் கண்டுபிடி), நடைமுறைச் செயலாக்கம் மற்றும் உண்மையில் தேர்ந்தெடுக்கப்பட்ட கோடெக் பல காரணிகளால் பாதிக்கப்படுகிறது:

1. உலாவி செயலாக்கங்கள் மற்றும் இயல்புநிலைகள்

வெவ்வேறு உலாவிகள் (Chrome, Firefox, Safari, Edge) WebRTC-ன் சொந்த உள் செயலாக்கங்கள் மற்றும் அவற்றின் சொந்த இயல்புநிலை கோடெக் விருப்பங்களைக் கொண்டுள்ளன. உதாரணமாக:

• Chrome/Chromium அடிப்படையிலான உலாவிகள் பொதுவாக VP8 மற்றும் Opus-க்கு முன்னுரிமை அளிக்கின்றன.
• Firefox-ம் Opus மற்றும் VP8-க்கு சாதகமாக உள்ளது, ஆனால் இயங்குதளத்தைப் பொறுத்து H.264-க்கு வெவ்வேறு விருப்பங்களைக் கொண்டிருக்கலாம்.
• Safari வரலாற்று ரீதியாக H.264 மற்றும் Opus-க்கு வலுவான ஆதரவைக் கொண்டுள்ளது.

இதன் பொருள், ஒரு உலாவி தனது ஆதரிக்கப்படும் கோடெக்குகளை SDP ஆஃபரில் பட்டியலிடும் வரிசை, பேரத்தின் முடிவை கணிசமாக பாதிக்கலாம். பொதுவாக, உலாவிகள் தங்களுக்கு விருப்பமான, மிகவும் திறமையான அல்லது பொதுவாக ஆதரிக்கப்படும் கோடெக்குகளை முதலில் பட்டியலிடுகின்றன.

2. இயக்க முறைமை மற்றும் வன்பொருள் திறன்கள்

அடிப்படை இயக்க முறைமை மற்றும் வன்பொருள் கோடெக் ஆதரவையும் பாதிக்கலாம். உதாரணமாக:

• சில அமைப்புகள் சில கோடெக்குகளுக்கு (எ.கா., H.264) வன்பொருள்-துரிதப்படுத்தப்பட்ட குறியாக்கம்/டிகோடிங்கைக் கொண்டிருக்கலாம், இதனால் அவற்றைப் பயன்படுத்துவது மிகவும் திறமையானதாக இருக்கும்.
• மொபைல் சாதனங்கள் டெஸ்க்டாப் கணினிகளுடன் ஒப்பிடும்போது வெவ்வேறு கோடெக் ஆதரவு சுயவிவரங்களைக் கொண்டிருக்கலாம்.

3. நெட்வொர்க் நிலைமைகள்

ஆரம்ப SDP பேரத்தின் ஒரு பகுதியாக நேரடியாக இல்லாவிட்டாலும், நெட்வொர்க் நிலைமைகள் தேர்ந்தெடுக்கப்பட்ட கோடெக்கின் செயல்திறனில் ஒரு முக்கிய பங்கு வகிக்கின்றன. WebRTC அலைவரிசை மதிப்பீடு (BE) மற்றும் தழுவல் ஆகியவற்றிற்கான வழிமுறைகளை உள்ளடக்கியது. ஒரு கோடெக் தேர்ந்தெடுக்கப்பட்டவுடன்:

• தழுவல் பிட்ரேட்: Opus மற்றும் VP9 போன்ற நவீன கோடெக்குகள் கிடைக்கக்கூடிய நெட்வொர்க் அலைவரிசையின் அடிப்படையில் அவற்றின் பிட்ரேட் மற்றும் தரத்தை மாற்றியமைக்க வடிவமைக்கப்பட்டுள்ளன.
• பாக்கெட் இழப்பு மறைத்தல் (PLC): பாக்கெட்டுகள் இழந்தால், கோடெக்குகள் தரத்தில் உணரப்படும் சீரழிவைக் குறைக்க காணாமல் போன தரவை யூகிக்க அல்லது புனரமைக்க நுட்பங்களைப் பயன்படுத்துகின்றன.
• கோடெக் மாறுதல் (குறைவாகப் பொதுவானது): சில மேம்பட்ட சூழ்நிலைகளில், நெட்வொர்க் நிலைமைகள் கடுமையாக மாறினால், பயன்பாடுகள் கோடெக்குகளை மாறும் வகையில் மாற்ற முயற்சிக்கலாம், இருப்பினும் இது ஒரு சிக்கலான முயற்சியாகும்.

ஆரம்ப பேரம் இணக்கத்தன்மையை நோக்கமாகக் கொண்டுள்ளது; தற்போதைய தகவல்தொடர்பு தேர்ந்தெடுக்கப்பட்ட கோடெக்கின் தழுவல் தன்மையைப் பயன்படுத்துகிறது.

4. பயன்பாட்டு-குறிப்பிட்ட தேவைகள்

டெவலப்பர்கள் ஜாவாஸ்கிரிப்ட் API-கள் மூலம் SDP ஆஃபர்/பதிலைக் கையாளுவதன் மூலம் கோடெக் தேர்வை பாதிக்கலாம். இது ஒரு மேம்பட்ட நுட்பம், ஆனால் இது பின்வருவனவற்றை அனுமதிக்கிறது:

• குறிப்பிட்ட கோடெக்குகளை கட்டாயப்படுத்துதல்: ஒரு பயன்பாட்டிற்கு ஒரு குறிப்பிட்ட கோடெக்கிற்கான கடுமையான தேவை இருந்தால் (எ.கா., மரபு அமைப்புகளுடன் இயங்குவதற்காக), அது அதன் தேர்வை கட்டாயப்படுத்த முயற்சி செய்யலாம்.
• கோடெக்குகளுக்கு முன்னுரிமை அளித்தல்: SDP ஆஃபர் அல்லது பதிலில் கோடெக்குகளை மறுவரிசைப்படுத்துவதன் மூலம், ஒரு பயன்பாடு தனது விருப்பத்தை சமிக்ஞை செய்யலாம்.
• கோடெக்குகளை முடக்குதல்: ஒரு கோடெக் சிக்கலானது என்று அறியப்பட்டால் அல்லது தேவைப்படாவிட்டால், அதை வெளிப்படையாக விலக்கலாம்.

நிரலாக்கக் கட்டுப்பாடு மற்றும் SDP கையாளுதல்

உலாவிகள் SDP பேரத்தின் பெரும்பகுதியை தானாகவே கையாளும் அதே வேளையில், முகப்பு டெவலப்பர்கள் WebRTC ஜாவாஸ்கிரிப்ட் API-களைப் பயன்படுத்தி சிறந்த கட்டுப்பாட்டைப் பெறலாம்:

1. `RTCPeerConnection.createOffer()` மற்றும் `createAnswer()`

இந்த முறைகள் SDP ஆஃபர் மற்றும் பதில் பொருட்களை உருவாக்குகின்றன. `setLocalDescription()` ஐப் பயன்படுத்தி `RTCPeerConnection` இல் இந்த விளக்கங்களை அமைப்பதற்கு முன், நீங்கள் SDP சரத்தை மாற்றலாம்.

2. `RTCPeerConnection.setLocalDescription()` மற்றும் `setRemoteDescription()`

இந்த முறைகள் முறையே உள்ளூர் மற்றும் தொலை விளக்கங்களை அமைக்கப் பயன்படுத்தப்படுகின்றன. `setLocalDescription` (ஆஃபர் செய்பவருக்கு) மற்றும் `setRemoteDescription` (பதில் அளிப்பவருக்கு) இரண்டும் வெற்றிகரமாக அழைக்கப்பட்டால் பேரம் நடக்கிறது.

3. `RTCSessionDescriptionInit`

`RTCSessionDescriptionInit` இன் `sdp` பண்பு SDP ஐக் கொண்ட ஒரு சரம் ஆகும். நீங்கள் இந்த சரத்தை பாகுபடுத்தி, அதை மாற்றி, பின்னர் அதை மீண்டும் ஒன்றுசேர்க்கலாம்.

எடுத்துக்காட்டு: VP8 ஐ விட VP9 க்கு முன்னுரிமை அளித்தல்

VP8 ஐ விட VP9 விரும்பப்படுவதை உறுதிசெய்ய விரும்புகிறீர்கள் என்று வைத்துக்கொள்வோம். ஒரு உலாவியில் இருந்து இயல்புநிலை SDP ஆஃபர் அவற்றை இதுபோன்ற வரிசையில் பட்டியலிடலாம்:

a=rtpmap:103 VP8/90000
a=rtpmap:104 VP9/90000

VP9 க்கு முன்னுரிமை அளிக்க நீங்கள் SDP ஆஃபரை இடைமறித்து வரிகளை மாற்றலாம்:

let offer = await peerConnection.createOffer();

// Modify the SDP string
let sdpLines = offer.sdp.split('\n');
let vp8LineIndex = -1;
let vp9LineIndex = -1;

for (let i = 0; i < sdpLines.length; i++) {
    if (sdpLines[i].startsWith('a=rtpmap:') && sdpLines[i].includes('VP8/90000')) {
        vp8LineIndex = i;
    }
    if (sdpLines[i].startsWith('a=rtpmap:') && sdpLines[i].includes('VP9/90000')) {
        vp9LineIndex = i;
    }
}

if (vp8LineIndex !== -1 && vp9LineIndex !== -1) {
    // Swap VP8 and VP9 lines if VP9 is listed after VP8
    if (vp9LineIndex > vp8LineIndex) {
        [sdpLines[vp8LineIndex], sdpLines[vp9LineIndex]] = [sdpLines[vp9LineIndex], sdpLines[vp8LineIndex]];
    }
}

offer.sdp = sdpLines.join('\n');

await peerConnection.setLocalDescription(offer);
// ... send offer to remote peer ...

எச்சரிக்கை: நேரடி SDP கையாளுதல் எளிதில் உடையக்கூடியதாக இருக்கலாம். உலாவி புதுப்பிப்புகள் SDP வடிவங்களை மாற்றக்கூடும், மற்றும் தவறான மாற்றங்கள் பேரங்களை உடைக்கக்கூடும். இந்த அணுகுமுறை பொதுவாக மேம்பட்ட பயன்பாட்டு நிகழ்வுகளுக்கு அல்லது குறிப்பிட்ட இயங்குதன்மை தேவைப்படும்போது ஒதுக்கப்பட்டுள்ளது.

4. `RTCRtpTransceiver` API (நவீன அணுகுமுறை)

கோடெக் தேர்வை பாதிப்பதற்கான ஒரு வலுவான மற்றும் பரிந்துரைக்கப்பட்ட வழி `RTCRtpTransceiver` API ஐப் பயன்படுத்துவதாகும். நீங்கள் ஒரு மீடியா டிராக்கைச் சேர்க்கும்போது (எ.கா., `peerConnection.addTrack(stream.getAudioTracks()[0], 'audio')`), ஒரு டிரான்ஸீவர் உருவாக்கப்படுகிறது. நீங்கள் பின்னர் டிரான்ஸீவரைப் பெற்று அதன் direction மற்றும் விருப்பமான கோடெக்குகளை அமைக்கலாம்.

ஒரு டிரான்ஸீவருக்கு ஆதரிக்கப்படும் கோடெக்குகளைப் பெறலாம்:

const transceivers = peerConnection.getTransceivers();
transceivers.forEach(transceiver => {
    if (transceiver.kind === 'audio') {
        const codecs = transceiver.rtpSender.getCapabilities().codecs;
        console.log('Supported audio codecs:', codecs);
    }
});

அனைத்து உலாவிகளிலும் உலகளவில் டிரான்ஸீவரில் நேரடி `setPreferredCodec` முறை இல்லை என்றாலும், WebRTC விவரக்குறிப்பு உலாவிகள் SDP இல் வழங்கப்பட்ட கோடெக்குகளின் வரிசையை மதிப்பதன் மூலம் இயங்குதன்மையை நோக்கமாகக் கொண்டுள்ளது. மிகவும் நேரடி கட்டுப்பாடு பெரும்பாலும் `createOffer`/`createAnswer` மூலம் SDP ஆஃபர்/பதில் உருவாக்கத்தைக் கையாளுவதிலிருந்தும், விளக்கத்தை அமைப்பதற்கு முன்பு கோடெக்குகளை வடிகட்டுதல்/மறுவரிசைப்படுத்துவதிலிருந்தும் வருகிறது.

5. `RTCPeerConnection` கட்டுப்பாடுகள் (`getUserMedia`-க்கு)

`navigator.mediaDevices.getUserMedia()` ஐப் பயன்படுத்தி மீடியா ஸ்ட்ரீம்களைப் பெறும்போது, கோரப்பட்ட மீடியாவின் தரம் அல்லது வகையைப் பாதிப்பதன் மூலம் கோடெக் தேர்வுகளை மறைமுகமாக பாதிக்கக்கூடிய கட்டுப்பாடுகளை நீங்கள் குறிப்பிடலாம். இருப்பினும், இந்த கட்டுப்பாடுகள் முதன்மையாக மீடியா பிடிப்பையே பாதிக்கின்றன, பியர்களுக்கு இடையிலான கோடெக்குகளின் பேரத்தை அல்ல.

உலகளாவிய பயன்பாடுகளுக்கான சவால்கள் மற்றும் சிறந்த நடைமுறைகள்

ஒரு உலகளாவிய WebRTC பயன்பாட்டை உருவாக்குவது மீடியா பேரம் தொடர்பான தனித்துவமான சவால்களை அளிக்கிறது:

1. உலகளாவிய உலாவி மற்றும் சாதனப் பிரிவினை

உலகம் பரந்த அளவிலான சாதனங்கள், இயக்க முறைமைகள் மற்றும் உலாவி பதிப்புகளைப் பயன்படுத்துகிறது. உங்கள் WebRTC பயன்பாடு இந்த பிரிவினை முழுவதும் தடையின்றி செயல்படுவதை உறுதி செய்வது ஒரு பெரிய தடையாகும்.

• எடுத்துக்காட்டு: தென் அமெரிக்காவில் ஒரு பழைய ஆண்ட்ராய்டு சாதனத்தில் உள்ள ஒரு பயனர் கிழக்கு ஆசியாவில் சமீபத்திய iOS சாதனத்தில் உள்ள ஒரு பயனரை விட வேறுபட்ட H.264 சுயவிவரங்கள் அல்லது கோடெக் ஆதரவைக் கொண்டிருக்கலாம்.

2. நெட்வொர்க் மாறுபாடு

இணைய உள்கட்டமைப்பு உலகம் முழுவதும் கணிசமாக வேறுபடுகிறது. தாமதம், பாக்கெட் இழப்பு மற்றும் கிடைக்கக்கூடிய அலைவரிசை வியத்தகு முறையில் வேறுபடலாம்.

• எடுத்துக்காட்டு: மேற்கு ஐரோப்பாவில் அதிவேக ஃபைபர் ஆப்டிக் நெட்வொர்க்குகளில் உள்ள இரண்டு பயனர்களுக்கு இடையிலான அழைப்பு, தென்கிழக்கு ஆசியாவின் கிராமப்புற பகுதியில் மொபைல் நெட்வொர்க்கில் உள்ள பயனர்களுக்கு இடையிலான அழைப்பை விட மிகவும் வித்தியாசமான அனுபவத்தைக் கொண்டிருக்கும்.

3. மரபு அமைப்புகளுடன் இயங்குதன்மை

பல நிறுவனங்கள் ஏற்கனவே உள்ள வீடியோ கான்பரன்சிங் வன்பொருள் அல்லது மென்பொருளை நம்பியுள்ளன, அவை சமீபத்திய WebRTC கோடெக்குகள் அல்லது நெறிமுறைகளை முழுமையாக ஆதரிக்காமல் இருக்கலாம். இந்த இடைவெளியைக் குறைப்பதற்கு G.711 அல்லது H.264 போன்ற பொதுவான, ஆனால் குறைவான திறமையான கோடெக்குகளுக்கான ஆதரவை செயல்படுத்துவது பெரும்பாலும் தேவைப்படுகிறது.

சிறந்த நடைமுறைகள்:

• ஆடியோவுக்கு Opus-க்கு முன்னுரிமை கொடுங்கள்: Opus WebRTC-ல் மிகவும் பல்துறை மற்றும் பரவலாக ஆதரிக்கப்படும் ஆடியோ கோடெக் ஆகும். இது பல்வேறு நெட்வொர்க் நிலைமைகளில் விதிவிலக்காக சிறப்பாக செயல்படுகிறது மற்றும் அனைத்து பயன்பாடுகளுக்கும் மிகவும் பரிந்துரைக்கப்படுகிறது. உங்கள் SDP ஆஃபர்களில் இது முக்கியமாக பட்டியலிடப்பட்டுள்ளதை உறுதிசெய்யவும்.
• வீடியோவுக்கு VP8/VP9-க்கு முன்னுரிமை கொடுங்கள்: VP8 மற்றும் VP9 திறந்த மூல மற்றும் பரவலாக ஆதரிக்கப்படுகின்றன. H.264-ம் பொதுவானது என்றாலும், VP8/VP9 உரிமக் கவலைகள் இல்லாமல் நல்ல இணக்கத்தன்மையை வழங்குகின்றன. உங்கள் இலக்கு தளங்களில் ஆதரவு சீராக இருந்தால் சிறந்த சுருக்க செயல்திறனுக்காக VP9-ஐக் கருத்தில் கொள்ளுங்கள்.
• ஒரு வலுவான சிக்னலிங் சர்வரைப் பயன்படுத்தவும்: SDP ஆஃபர்கள் மற்றும் பதில்களை வெவ்வேறு பிராந்தியங்களில் திறமையாகவும் பாதுகாப்பாகவும் பரிமாறிக்கொள்ள ஒரு நம்பகமான சிக்னலிங் சர்வர் முக்கியமானது.
• பல்வேறு நெட்வொர்க்குகள் மற்றும் சாதனங்களில் விரிவாகச் சோதிக்கவும்: நிஜ உலக நெட்வொர்க் நிலைமைகளை உருவகப்படுத்தி, உங்கள் உலகளாவிய பயனர் தளத்தைப் பிரதிநிதித்துவப்படுத்தும் பரந்த அளவிலான சாதனங்கள் மற்றும் உலாவிகளில் உங்கள் பயன்பாட்டைச் சோதிக்கவும்.
• WebRTC புள்ளிவிவரங்களைக் கண்காணிக்கவும்: கோடெக் பயன்பாடு, பாக்கெட் இழப்பு, ஜிттер மற்றும் பிற அளவீடுகளைக் கண்காணிக்க `RTCPeerConnection.getStats()` API-ஐப் பயன்படுத்தவும். இந்தத் தரவு வெவ்வேறு பிராந்தியங்களில் செயல்திறன் தடைகள் மற்றும் கோடெக் தொடர்பான சிக்கல்களை அடையாளம் காண விலைமதிப்பற்றது.
• மாற்று உத்திகளைச் செயல்படுத்தவும்: சிறந்ததை நோக்கமாகக் கொள்ளும்போது, சில கோடெக்குகளுக்கு பேரம் தோல்வியடையக்கூடிய சூழ்நிலைகளுக்குத் தயாராக இருங்கள். சரியான மாற்று வழிமுறைகளை வைத்திருங்கள்.
• சிக்கலான சூழ்நிலைகளுக்கு சர்வர்-பக்க செயலாக்கத்தை (SFU/MCU) கருத்தில் கொள்ளுங்கள்: பல பங்கேற்பாளர்கள் உள்ள அல்லது பதிவு செய்தல் அல்லது டிரான்ஸ்கோடிங் போன்ற மேம்பட்ட அம்சங்கள் தேவைப்படும் பயன்பாடுகளுக்கு, செலக்டிவ் ஃபார்வர்டிங் யூனிட்கள் (SFUs) அல்லது மல்டிபாயின்ட் கண்ட்ரோல் யூனிட்கள் (MCUs) பயன்படுத்துவது செயலாக்கத்தை இறக்கி, கிளையன்ட் பக்க பேரத்தை எளிதாக்கும். இருப்பினும், இது சர்வர் உள்கட்டமைப்பு செலவுகளைச் சேர்க்கிறது.
• உலாவி தரநிலைகளில் புதுப்பித்த நிலையில் இருங்கள்: WebRTC தொடர்ந்து உருவாகி வருகிறது. புதிய கோடெக் ஆதரவு, தரநிலை மாற்றங்கள் மற்றும் உலாவி-குறிப்பிட்ட நடத்தைகள் குறித்து அறிந்திருங்கள்.

முடிவுரை

WebRTC மீடியா பேரம் மற்றும் கோடெக் தேர்வு வழிமுறை, சிக்கலானதாகத் தோன்றினாலும், அடிப்படையில் இரண்டு பியர்களுக்கு இடையில் ஒரு பொதுவான தளத்தைக் கண்டுபிடிப்பதாகும். SDP ஆஃபர்/ஆன்சர் மாதிரியைப் பயன்படுத்துவதன் மூலம், WebRTC பகிரப்பட்ட ஆடியோ மற்றும் வீடியோ கோடெக்குகளை அடையாளம் கண்டு இணக்கமான தகவல்தொடர்பு சேனலை நிறுவ முயல்கிறது. உலகளாவிய பயன்பாடுகளை உருவாக்கும் முகப்பு டெவலப்பர்களுக்கு, இந்த செயல்முறையைப் புரிந்துகொள்வது குறியீடு எழுதுவது மட்டுமல்ல; இது உலகளாவிய தன்மைக்காக வடிவமைப்பதாகும்.

Opus மற்றும் VP8/VP9 போன்ற வலுவான, பரவலாக ஆதரிக்கப்படும் கோடெக்குகளுக்கு முன்னுரிமை அளிப்பது, பல்வேறு உலகளாவிய சூழல்களில் கடுமையான சோதனைகளுடன் இணைந்து, தடையற்ற, உயர்தர நிகழ்நேர தகவல்தொடர்புக்கு அடித்தளமிடும். கோடெக் பேரத்தின் நுணுக்கங்களில் தேர்ச்சி பெறுவதன் மூலம், நீங்கள் WebRTC-ன் முழு திறனையும் திறந்து, உலகளாவிய பார்வையாளர்களுக்கு விதிவிலக்கான பயனர் அனுபவங்களை வழங்க முடியும்.