WebRTC ਅਤੇ ਵੀਡੀਓ ਨਿਗਰਾਨੀ: ਅਸੀਂ ਕੈਮਰਿਆਂ ਤੋਂ ਵੀਡੀਓ ਲੇਟੈਂਸੀ ਨੂੰ ਕਿਵੇਂ ਹਰਾਇਆ

ਕਲਾਉਡ ਵੀਡੀਓ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ 'ਤੇ ਕੰਮ ਕਰਨ ਦੇ ਪਹਿਲੇ ਦਿਨਾਂ ਤੋਂ, ਸਾਨੂੰ ਇੱਕ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ, ਜਿਸ ਦੇ ਹੱਲ ਤੋਂ ਬਿਨਾਂ ਅਸੀਂ ਆਈਵੀਡੀਓਨ ਨੂੰ ਛੱਡ ਸਕਦੇ ਹਾਂ - ਇਹ ਸਾਡਾ ਐਵਰੈਸਟ ਸੀ, ਚੜ੍ਹਨਾ ਜਿਸ ਵਿੱਚ ਬਹੁਤ ਊਰਜਾ ਲੱਗੀ, ਪਰ ਹੁਣ ਅਸੀਂ ਅੰਤ ਵਿੱਚ ਕਰਾਸ-ਪਲੇਟਫਾਰਮ ਬੁਝਾਰਤ ਦੇ ਸਿਖਰ ਵਿੱਚ ਇੱਕ ਬਰਫ਼ ਦੀ ਕੁਹਾੜੀ ਨੂੰ ਫਸਾਇਆ।

ਇੰਟਰਨੈੱਟ 'ਤੇ ਆਡੀਓ ਅਤੇ ਵੀਡੀਓ ਨੂੰ ਪ੍ਰਸਾਰਿਤ ਕਰਨ ਲਈ ਸਿਸਟਮ ਨੂੰ ਸਾਜ਼ੋ-ਸਾਮਾਨ, ਵੈੱਬ ਕਲਾਇੰਟਸ ਅਤੇ ਉਹਨਾਂ ਦੁਆਰਾ ਸਮਰਥਨ ਕੀਤੇ ਮਿਆਰਾਂ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਨੈੱਟਵਰਕ ਐਡਰੈੱਸ ਟ੍ਰਾਂਸਲੇਟਰਾਂ ਅਤੇ ਫਾਇਰਵਾਲਾਂ ਦੀ ਮੌਜੂਦਗੀ ਵਿੱਚ ਵੀ ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਕਲਾਉਡ ਵੀਡੀਓ ਨਿਗਰਾਨੀ ਉਪਭੋਗਤਾ ਸੇਵਾ ਤੱਕ ਪਹੁੰਚ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ, ਭਾਵੇਂ ਉਹ ਐਨਾਲਾਗ ਕੈਮਰੇ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਭ ਤੋਂ ਆਧੁਨਿਕ ਡਿਵਾਈਸ 'ਤੇ ਲਾਈਵ ਵੀਡੀਓ ਪ੍ਰਸਾਰਣ ਦੇਖਣ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦਾ ਹੈ।

ਇਹ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਉਪਭੋਗਤਾ ਘੱਟੋ-ਘੱਟ ਦੇਰੀ ਨਾਲ ਵੀਡੀਓ ਦੇਖਣਾ ਚਾਹੁੰਦਾ ਹੈ। ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਘੱਟ ਲੇਟੈਂਸੀ ਵਾਲੇ ਵੀਡੀਓ ਦਿਖਾਉਣ ਦਾ ਲਗਭਗ ਇੱਕੋ ਇੱਕ ਤਰੀਕਾ ਹੈ WebRTC (ਵੈੱਬ ਰੀਅਲ-ਟਾਈਮ ਸੰਚਾਰ) ਦੀ ਵਰਤੋਂ ਕਰਨਾ। WebRTC ਬ੍ਰਾਊਜ਼ਰਾਂ ਵਿੱਚ ਵੀਡੀਓ ਅਤੇ ਆਡੀਓ ਦੇ ਪੀਅਰ-ਟੂ-ਪੀਅਰ ਟ੍ਰਾਂਸਮਿਸ਼ਨ ਲਈ ਤਕਨੀਕਾਂ ਦਾ ਇੱਕ ਸੈੱਟ ਹੈ, ਜੋ ਸ਼ੁਰੂ ਵਿੱਚ ਘੱਟ ਲੇਟੈਂਸੀ ਵਾਲੇ ਵੀਡੀਓ ਸਟ੍ਰੀਮ ਦੇ ਪ੍ਰਸਾਰਣ ਅਤੇ ਪਲੇਬੈਕ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ। ਇਸ ਉਦੇਸ਼ ਲਈ, ਹੋਰ ਚੀਜ਼ਾਂ ਦੇ ਨਾਲ, UDP ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ.

ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਅਸੀਂ ਤੁਹਾਨੂੰ ਦੱਸਾਂਗੇ ਕਿ ਨਵਾਂ ਇੰਜਣ ਉਪਭੋਗਤਾ ਨੂੰ ਕੀ ਦਿੰਦਾ ਹੈ, ਅਸੀਂ ਤੁਹਾਨੂੰ ਯਾਦ ਕਰਾਵਾਂਗੇ ਕਿ ਅਸੀਂ HLS ਤਕਨਾਲੋਜੀਆਂ ਦਾ ਸਮਰਥਨ ਕਿਉਂ ਅਤੇ ਕਿਉਂ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਅਸੀਂ ਅੱਗੇ ਵਧਣ ਦਾ ਫੈਸਲਾ ਕਿਉਂ ਕੀਤਾ ਹੈ।

HLS ਇੰਜਣ: ਫ਼ਾਇਦੇ ਅਤੇ ਨੁਕਸਾਨ

(c)

HLS (HTTP ਲਾਈਵ ਸਟ੍ਰੀਮਿੰਗ) ਤਕਨਾਲੋਜੀ ਐਪਲ ਦੁਆਰਾ ਵਿਕਸਤ ਕੀਤੀ ਗਈ ਸੀ, ਇਸ ਲਈ ਇਹ ਕੋਈ ਹੈਰਾਨੀ ਵਾਲੀ ਗੱਲ ਨਹੀਂ ਹੈ ਕਿ ਇਸਨੂੰ ਪਹਿਲੀ ਵਾਰ ਐਪਲ ਡਿਵਾਈਸਾਂ 'ਤੇ ਸਮਰਥਿਤ ਕੀਤਾ ਗਿਆ ਸੀ। ਅੱਜ, HLS ਵੀਡੀਓ ਲਗਭਗ ਸਾਰੇ ਸੈੱਟ-ਟਾਪ ਬਾਕਸਾਂ ਅਤੇ OS ਚਲਾਉਣ ਵਾਲੇ ਬਹੁਤ ਸਾਰੇ ਡਿਵਾਈਸਾਂ ਦੁਆਰਾ ਵੀ ਸਮਰਥਿਤ ਹੈ। Android.

HLS ਇੰਜਣ AAC ਜਾਂ MP264 ਆਡੀਓ ਸਟ੍ਰੀਮ ਦੇ ਨਾਲ ਵੀਡੀਓ ਡੇਟਾ ਨੂੰ ਸਟ੍ਰੀਮ ਕਰਨ ਲਈ ਮਸ਼ਹੂਰ H3 ਵੀਡੀਓ ਕੋਡੇਕ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਪੂਰੀ ਆਡੀਓ ਅਤੇ ਵੀਡੀਓ ਡਾਟਾ ਸਟ੍ਰੀਮ ਨੂੰ ਇੱਕ MPEG-TS ਟ੍ਰਾਂਸਪੋਰਟ ਕੰਟੇਨਰ ਵਿੱਚ ਪੈਕ ਕੀਤਾ ਗਿਆ ਹੈ। HTTP ਪ੍ਰੋਟੋਕੋਲ ਦੁਆਰਾ ਪ੍ਰਸਾਰਣ ਲਈ, ਸਟ੍ਰੀਮ ਵਿੱਚ ਮੌਜੂਦ ਜਾਣਕਾਰੀ ਨੂੰ m3u8 ਪਲੇਲਿਸਟਸ ਵਿੱਚ ਵਰਣਿਤ ਟੁਕੜਿਆਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਹੈ। ਅਤੇ ਕੇਵਲ ਤਦ ਹੀ ਇਹ ਟੁਕੜੇ, ਪਲੇਲਿਸਟਸ ਦੇ ਨਾਲ, HTTP ਦੁਆਰਾ ਪ੍ਰਸਾਰਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ. ਆਪਣੇ ਆਪ ਚੰਕਿੰਗ ਦਾ ਮਤਲਬ ਹੈ ਸਕਿੰਟਾਂ ਵਿੱਚ ਦੇਰੀ। ਇਹ MPEG-TS ਕੰਟੇਨਰ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ।

HLS ਇੰਜਣ ਮਲਟੀਬਿਟਰੇਟ ਸਟ੍ਰੀਮ, ਲਾਈਵ/VOD ਦਾ ਵੀ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।

HLS ਦੇ ਮੁੱਖ ਫਾਇਦੇ:

• ਸਾਰੇ ਪ੍ਰਮੁੱਖ ਬ੍ਰਾਊਜ਼ਰਾਂ ਵਿੱਚ ਬਿਲਟ-ਇਨ ਸਮਰਥਨ;
• ਲਾਗੂ ਕਰਨ ਦੀ ਸੌਖ (WebRTC ਦੇ ਮੁਕਾਬਲੇ);
• ਇਹ ਬਹੁਤ ਹੀ ਸੁਵਿਧਾਜਨਕ ਅਤੇ ਕੁਸ਼ਲ ਹੈ ਕਿ ਸਾਰੇ ਪ੍ਰਕਾਰ ਦੇ ਪ੍ਰਸਾਰਣ ਨੂੰ ਇੱਕ ਵੱਡੇ ਦਰਸ਼ਕਾਂ ਲਈ ਸੰਗਠਿਤ ਕਰਨਾ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਹੈ ਕਿ ਭਾਗਾਂ ਨੂੰ ਇੱਕ ਵਾਰ CDN ਤੇ ਅਪਲੋਡ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਇੰਜਣ ਦੀ ਸਾਦਗੀ ਦੇ ਬਾਵਜੂਦ, ਸਭ ਕੁਝ ਇੰਨਾ ਨਿਰਵਿਘਨ ਨਹੀਂ ਹੈ ਜਿੰਨਾ ਇਹ ਲੱਗਦਾ ਹੈ. ਮੁੱਖ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਥਰਡ-ਪਾਰਟੀ ਪਲੇਅਰ ਡਿਵੈਲਪਰ ਐਪਲ ਦੀਆਂ ਸਿਫ਼ਾਰਸ਼ਾਂ ਤੋਂ ਦੂਰ ਚਲੇ ਗਏ ਹਨ, ਉਦਾਹਰਨ ਲਈ ਸਮਰਥਿਤ ਆਡੀਓ ਫਾਰਮੈਟਾਂ ਦੇ ਮਾਮਲੇ ਵਿੱਚ। ਖਾਸ ਤੌਰ 'ਤੇ, ਬਹੁਤ ਸਾਰੇ ਡਿਵੈਲਪਰਾਂ ਨੇ ਪ੍ਰਸਿੱਧ ਆਡੀਓ ਸਟ੍ਰੀਮਜ਼ ਦੇ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਯੋਗਤਾ ਨੂੰ ਜੋੜਨਾ ਸ਼ੁਰੂ ਕੀਤਾ: mpeg2 ਵੀਡੀਓ, mpeg2 ਆਡੀਓ, ਆਦਿ ਨਤੀਜੇ ਵਜੋਂ, ਉਹਨਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਖਿਡਾਰੀਆਂ ਲਈ ਵੱਖ-ਵੱਖ ਪਲੇਲਿਸਟ ਫਾਰਮੈਟ ਬਣਾਉਣੇ ਪਏ।

ਪਰ HLS ਇੰਜਣ ਨਾਲ ਸਭ ਤੋਂ ਵੱਡੀ ਸਮੱਸਿਆਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਡਾਟਾ ਟ੍ਰਾਂਸਫਰ ਵਿੱਚ ਉੱਚ ਲੇਟੈਂਸੀ ਹੈ।

"ਬ੍ਰੇਕਾਂ" ਦੀ ਸ਼ੁਰੂਆਤ

HLS ਦੀ ਉੱਚ ਲੇਟੈਂਸੀ ਦਾ ਮੁੱਖ ਕਾਰਨ ਇਸ ਤੱਥ ਵਿੱਚ ਹੈ ਕਿ ਪ੍ਰੋਗਰਾਮਰਾਂ ਨੇ ਉੱਚ ਗੁਣਵੱਤਾ ਵਾਲੀਆਂ ਤਸਵੀਰਾਂ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਇੰਜਣ ਬਣਾਇਆ ਹੈ। ਇਸ ਲਈ, ਵਰਤੇ ਗਏ ਫਰੇਮ ਅੰਤਰਾਲ ਦੇ ਮਾਪਦੰਡ ਅਤੇ ਪਲੇਬੈਕ ਬਫਰ ਦਾ ਆਕਾਰ ਲਾਈਵ ਵੀਡੀਓ ਪ੍ਰਸਾਰਣ ਲਈ ਢੁਕਵਾਂ ਨਹੀਂ ਹੈ। ਇਸਦੇ ਕਾਰਨ, ਵੀਡੀਓ ਫੁਟੇਜ ਦੇ ਪ੍ਰਸਾਰਣ ਵਿੱਚ ਕਾਫ਼ੀ ਦੇਰੀ ਹੁੰਦੀ ਹੈ, ਜੋ ਕਿ 5-7 ਸਕਿੰਟ ਹੋ ਸਕਦੀ ਹੈ।

ਇੱਕ ਪਾਸੇ, ਇਹ ਬਹੁਤ ਜ਼ਿਆਦਾ ਨਹੀਂ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਉਹਨਾਂ ਲਈ ਜੋ ਇੱਕ ਵੀਡੀਓ ਹੋਸਟਿੰਗ ਸਰਵਰ ਤੋਂ ਇੱਕ ਫਿਲਮ ਦੇਖਦੇ ਹਨ. ਪਰ ਵੀਡੀਓ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀਆਂ ਲਈ, ਵੀਡੀਓ ਫੁਟੇਜ ਪ੍ਰਸਾਰਿਤ ਕਰਨ ਵਿੱਚ ਦੇਰੀ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੋ ਸਕਦੀ ਹੈ।

ਜੇਕਰ ਤੁਸੀਂ ਕੋਈ ਅਜਿਹਾ ਦਫ਼ਤਰ ਦੇਖ ਰਹੇ ਹੋ ਜਿੱਥੇ ਕਰਮਚਾਰੀ ਘੰਟੇ ਵਿੱਚ ਇੱਕ ਵਾਰ ਆਪਣੇ ਮਾਨੀਟਰ ਤੋਂ ਉੱਪਰ ਦੇਖਦੇ ਹਨ, ਤਾਂ 5 ਸਕਿੰਟ ਦੀ ਦੇਰੀ ਨਾਲ ਕੋਈ ਫਰਕ ਨਹੀਂ ਪੈਂਦਾ। ਪਰ ਲੋਕਾਂ ਨੇ ਸ਼ਿਕਾਇਤ ਕਰਨੀ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੀ ਕਿ, ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਫੁੱਟਬਾਲ ਮੈਚ ਦਾ ਪ੍ਰਸਾਰਣ ਕਰਦੇ ਸਮੇਂ, ਉਹਨਾਂ ਨੇ ਪਹਿਲਾਂ ਹੀ ਚੈਟ ਵਿੱਚ GOOOOL ਲਿਖਿਆ ਸੀ, ਪਰ ਇਹ ਅਜੇ ਵੀ ਵੀਡੀਓ ਵਿੱਚ ਨਹੀਂ ਹੈ :). ਸਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਬਹੁਤ ਸਾਰੇ ਉਪਭੋਗਤਾ ਕੇਸ ਹਨ ਜਿੱਥੇ Ivideon ਨੂੰ ਅਮਲੀ ਤੌਰ 'ਤੇ ਸਕਾਈਪ ਨੂੰ ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ.

ਕੀ HLS ਵਿੱਚ ਲੇਟੈਂਸੀ ਨੂੰ ਹਰਾਉਣਾ ਸੰਭਵ ਹੈ? ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਨਵੇਂ ਪੈਸਟ ਕੰਟਰੋਲ ਮਾਹਿਰਾਂ ਨੂੰ ਦਿੱਤੇ ਭਾਸ਼ਣ ਵਿੱਚ ਇੱਕ ਤਜਰਬੇਕਾਰ ਚੂਹਿਆਂ ਨੂੰ ਖਤਮ ਕਰਨ ਵਾਲੇ ਦੇ ਭਾਸ਼ਣ ਵਾਂਗ ਜਾਪਦਾ ਹੈ: "ਚੂਹਿਆਂ ਨੂੰ ਖਤਮ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ, ਪਰ ਉਹਨਾਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।" HLS ਵਿੱਚ ਦੇਰੀ ਦੇ ਨਾਲ ਹੀ, ਇਸਨੂੰ ਜ਼ੀਰੋ ਤੱਕ ਘਟਾਉਣਾ ਸੰਭਵ ਨਹੀਂ ਹੋਵੇਗਾ, ਪਰ ਮਾਰਕੀਟ ਵਿੱਚ ਅਜਿਹੇ ਹੱਲ ਹਨ ਜੋ ਦੇਰੀ ਨੂੰ ਮਹੱਤਵਪੂਰਣ ਰੂਪ ਵਿੱਚ ਘਟਾ ਸਕਦੇ ਹਨ।

ਵਧੀਆ ਕੱਟ

ਇੰਜਣ ਦਾ ਇੱਕ ਹੋਰ ਨੁਕਸਾਨ ਡੇਟਾ ਟ੍ਰਾਂਸਫਰ ਲਈ ਛੋਟੀਆਂ ਫਾਈਲਾਂ ਦੀ ਵਰਤੋਂ ਹੈ. ਇਹ ਲਗਦਾ ਹੈ ਕਿ ਇਸ ਵਿੱਚ ਕੀ ਗਲਤ ਹੈ?

ਕਿਸੇ ਵੀ ਵਿਅਕਤੀ ਜਿਸਨੇ ਇੱਕ ਮਾਧਿਅਮ ਤੋਂ ਦੂਜੇ ਮਾਧਿਅਮ ਵਿੱਚ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਛੋਟੀਆਂ ਫਾਈਲਾਂ ਦੀ ਨਕਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਹੈ, ਨੇ ਸ਼ਾਇਦ ਦੇਖਿਆ ਹੈ ਕਿ ਅਜਿਹੇ ਸੈੱਟ ਦੀ ਲਿਖਣ ਦੀ ਗਤੀ ਉਸੇ ਆਕਾਰ ਦੀ ਇੱਕ ਵੱਡੀ ਫਾਈਲ ਨਾਲੋਂ ਬਹੁਤ ਘੱਟ ਹੈ। ਅਤੇ ਹਾਰਡ ਡਰਾਈਵ ਤੱਕ ਪਹੁੰਚ ਦੀ ਤੀਬਰਤਾ ਕਾਫ਼ੀ ਵਧ ਜਾਂਦੀ ਹੈ, ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਪੂਰੇ ਕੰਪਿਊਟਰ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਨਕਾਰਾਤਮਕ ਤੌਰ 'ਤੇ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ। ਇਸਲਈ, ਛੋਟੇ 10 ਸਕਿੰਟਾਂ ਵਿੱਚ ਵੀਡੀਓ ਡੇਟਾ ਪ੍ਰਸਾਰਿਤ ਕਰਨਾ ਵੀ ਇੰਜਣ ਦੀ ਲੇਟੈਂਸੀ ਨੂੰ ਵਧਾਉਣ ਵਿੱਚ ਯੋਗਦਾਨ ਪਾਉਂਦਾ ਹੈ।

ਆਉ HLS ਤਕਨਾਲੋਜੀ ਦੇ ਸਾਰੇ ਫਾਇਦੇ ਅਤੇ ਨੁਕਸਾਨਾਂ ਨੂੰ ਸੰਖੇਪ ਵਿੱਚ ਦੱਸੀਏ।

HLS ਦੇ ਫਾਇਦੇ:

1. ਕਿਸੇ ਵੀ ਡਿਵਾਈਸ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਸਮਰੱਥਾ. ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਆਧੁਨਿਕ ਡਿਵਾਈਸ 'ਤੇ ਵੀਡੀਓ ਦੇਖ ਸਕਦੇ ਹੋ, ਭਾਵੇਂ ਇਹ ਸਮਾਰਟਫੋਨ, ਟੈਬਲੇਟ, ਲੈਪਟਾਪ ਜਾਂ ਡੈਸਕਟੌਪ ਪੀਸੀ ਹੋਵੇ। ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਵੈਬ ਬ੍ਰਾਊਜ਼ਰ ਅਪ-ਟੂ-ਡੇਟ ਹੈ ਅਤੇ HTML5 ਅਤੇ ਮੀਡੀਆ ਸਰੋਤ ਐਕਸਟੈਂਸ਼ਨਾਂ ਦੇ ਅਨੁਕੂਲ ਹੈ।
2. ਸ਼ਾਨਦਾਰ ਚਿੱਤਰ ਗੁਣਵੱਤਾ. ਵਰਤਿਆ ਗਿਆ ਅਨੁਕੂਲਿਤ ਡੇਟਾ ਟ੍ਰਾਂਸਮਿਸ਼ਨ ਫੰਕਸ਼ਨ ਤੁਹਾਨੂੰ ਇੰਟਰਨੈਟ ਕਨੈਕਸ਼ਨ ਦੀ ਬੈਂਡਵਿਡਥ ਦੇ ਅਧਾਰ ਤੇ ਪ੍ਰਸਾਰਿਤ ਵੀਡੀਓ ਦੀ ਗੁਣਵੱਤਾ ਨੂੰ ਗਤੀਸ਼ੀਲ ਰੂਪ ਵਿੱਚ ਬਦਲਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਐਲਗੋਰਿਦਮ ਵੱਧ ਤੋਂ ਵੱਧ ਗੁਣਵੱਤਾ ਬਣਾਈ ਰੱਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ।
3. ਉਪਭੋਗਤਾ ਦੇ ਸਾਜ਼-ਸਾਮਾਨ ਦੀ ਗੁੰਝਲਦਾਰ ਸੰਰਚਨਾ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ.

ਨੁਕਸਾਨ:

1. ਕੁਝ ਡਿਵਾਈਸਾਂ 'ਤੇ ਇੰਜਣ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਸੀਮਤ ਸਮਰਥਨ।
2. ਚਿੱਤਰ ਪ੍ਰਸਾਰਣ ਵਿੱਚ ਉੱਚ ਦੇਰੀ.
3. ਛੋਟੀਆਂ ਫਾਈਲਾਂ ਦੀ ਵਰਤੋਂ ਦੇ ਕਾਰਨ ਓਵਰਹੈੱਡ ਅਤੇ ਅਨੁਕੂਲਤਾ ਦੀ ਗੁੰਝਲਤਾ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਵਾਧਾ. ਕੰਟੇਨਰ ਦੀ ਪ੍ਰਕਿਰਤੀ ਦੇ ਕਾਰਨ, ਅਸੀਂ ਕਦੇ ਵੀ ਹਿੱਸੇ ਦੇ ਆਕਾਰ ਤੋਂ ਘੱਟ ਲੇਟੈਂਸੀ ਪ੍ਰਾਪਤ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਵਾਂਗੇ।

HLS ਦੇ ਨੁਕਸਾਨਾਂ ਨੇ ਸਾਡੇ ਲਈ ਇਸਦੇ ਫਾਇਦਿਆਂ ਨੂੰ ਪਛਾੜ ਦਿੱਤਾ ਅਤੇ ਸਾਨੂੰ ਵਿਕਲਪਕ ਵਿਕਲਪਾਂ ਦੀ ਭਾਲ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕੀਤਾ।

WebRTC ਕੀ ਹੈ

(c)

WebRTC ਪਲੇਟਫਾਰਮ ਨੂੰ Google ਦੁਆਰਾ 2011 ਵਿੱਚ ਸਟ੍ਰੀਮਿੰਗ ਵੀਡੀਓ ਅਤੇ ਆਡੀਓ ਡੇਟਾ ਨੂੰ ਬ੍ਰਾਊਜ਼ਰਾਂ ਅਤੇ ਮੋਬਾਈਲ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿਚਕਾਰ ਘੱਟੋ-ਘੱਟ ਲੇਟੈਂਸੀ ਨਾਲ ਪ੍ਰਸਾਰਿਤ ਕਰਨ ਲਈ ਵਿਕਸਤ ਕੀਤਾ ਗਿਆ ਸੀ। ਇਸਦੇ ਲਈ, ਮਿਆਰੀ UDP ਪ੍ਰੋਟੋਕੋਲ ਅਤੇ ਵਿਸ਼ੇਸ਼ ਪ੍ਰਵਾਹ ਨਿਯੰਤਰਣ ਐਲਗੋਰਿਦਮ ਵਰਤੇ ਜਾਂਦੇ ਹਨ। ਅੱਜ ਇਹ ਇੱਕ ਓਪਨ ਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਹੈ, ਇਸਨੂੰ Google ਦੁਆਰਾ ਸਰਗਰਮੀ ਨਾਲ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਵਿਕਸਤ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ।

WebRTC ਪੀਅਰ-ਟੂ-ਪੀਅਰ ਵੀਡੀਓ ਅਤੇ ਆਡੀਓ ਪ੍ਰਸਾਰਣ ਲਈ ਤਕਨਾਲੋਜੀਆਂ ਦਾ ਇੱਕ ਸਮੂਹ ਹੈ। ਭਾਵ, ਉਦਾਹਰਨ ਲਈ, WebRTC ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੇ ਉਪਭੋਗਤਾ ਬ੍ਰਾਉਜ਼ਰ ਡੇਟਾ ਨੂੰ ਸਟੋਰ ਕਰਨ ਅਤੇ ਪ੍ਰੋਸੈਸ ਕਰਨ ਲਈ ਰਿਮੋਟ ਸਰਵਰਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੇ ਬਿਨਾਂ, ਇੱਕ ਦੂਜੇ ਨੂੰ ਸਿੱਧਾ ਡੇਟਾ ਟ੍ਰਾਂਸਫਰ ਕਰ ਸਕਦੇ ਹਨ। ਸਾਰੀ ਜਾਣਕਾਰੀ ਅੰਤਮ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਬ੍ਰਾਉਜ਼ਰਾਂ ਅਤੇ ਮੋਬਾਈਲ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੁਆਰਾ ਵੀ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

ਇਸ ਤਕਨਾਲੋਜੀ ਦੀ ਸਹੂਲਤ ਅਤੇ ਵਿਆਪਕ ਸਮਰੱਥਾਵਾਂ ਦੀ ਸਾਰੇ ਪ੍ਰਸਿੱਧ ਬ੍ਰਾਊਜ਼ਰਾਂ ਦੇ ਡਿਵੈਲਪਰਾਂ ਦੁਆਰਾ ਪ੍ਰਸ਼ੰਸਾ ਕੀਤੀ ਗਈ ਹੈ। WebRTC ਸਹਾਇਤਾ ਵਰਤਮਾਨ ਵਿੱਚ ਮੋਜ਼ੀਲਾ ਫਾਇਰਫਾਕਸ, ਓਪੇਰਾ, ਗੂਗਲ ਕਰੋਮ (ਅਤੇ ਸਾਰੇ ਕਰੋਮੀਅਮ-ਅਧਾਰਿਤ ਬ੍ਰਾਊਜ਼ਰਾਂ) ਦੇ ਨਾਲ-ਨਾਲ ਚੱਲ ਰਹੇ ਮੋਬਾਈਲ ਐਪਸ ਵਿੱਚ ਉਪਲਬਧ ਹੈ। Android ਅਤੇ iOS।

ਇਸ ਦੇ ਸਾਰੇ ਬਿਨਾਂ ਸ਼ੱਕ ਫਾਇਦਿਆਂ ਲਈ, WebRTC ਦੇ ਕਈ ਮਹੱਤਵਪੂਰਨ ਨੁਕਸਾਨ ਹਨ।

ਚੋਣ ਦੀਆਂ ਮੁਸ਼ਕਲਾਂ

WebRTC ਤਕਨਾਲੋਜੀ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਕਿ ਇਹ P2P ਬਾਰੇ ਹੈ, ਨੈਟਵਰਕ ਪਰਸਪਰ ਕ੍ਰਿਆਵਾਂ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਬਹੁਤ ਜ਼ਿਆਦਾ ਗੁੰਝਲਦਾਰ ਹੈ। ਇਹ ਡੀਬੱਗ ਕਰਨਾ, ਜਾਂਚ ਕਰਨਾ ਅਤੇ ਅਸੰਭਵ ਵਿਵਹਾਰ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ। ਇਸ ਦੇ ਨਾਲ ਹੀ, ਸਾਨੂੰ NAT ਅਤੇ ਫਾਇਰਵਾਲ 'ਤੇ ਕਾਬੂ ਪਾਉਣ ਦੀ ਲੋੜ ਹੈ, ਸਾਨੂੰ ਉਹਨਾਂ ਨੈੱਟਵਰਕਾਂ ਵਿੱਚ ਕਾਰਵਾਈ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ ਜਿੱਥੇ UDP ਬਲੌਕ ਕੀਤਾ ਗਿਆ ਹੈ।

Google ਦਾ WebRTC ਲਾਗੂ ਕਰਨਾ ਬਹੁਤ ਔਖਾ ਹੈ। ਇੱਥੇ ਇੱਕ ਪੂਰੀ ਕੰਪਨੀ ਵੀ ਹੈ ਜੋ SDK ਅਸੈਂਬਲੀ ਸੇਵਾਵਾਂ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ। ਨਾਲ ਹੀ, ਪੂਰੀ ਵੀਡੀਓ ਨੂੰ ਮੁੜ-ਏਨਕੋਡ ਕੀਤੇ ਬਿਨਾਂ ਸਾਡੇ ਸਿਸਟਮ ਨਾਲ ਏਕੀਕ੍ਰਿਤ ਕਰਨਾ ਗੂਗਲ ਦਾ ਲਾਗੂ ਕਰਨਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਸੀ।

ਹਾਲਾਂਕਿ, ਅਸੀਂ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਦੇ "ਲਾਈਵ" ਵੀਡੀਓ ਦੇ ਨਾਲ ਕੰਮ ਕਰਨ ਦਾ ਮੌਕਾ ਦੇਣਾ ਚਾਹੁੰਦੇ ਹਾਂ ਅਤੇ ਸਕ੍ਰੀਨ 'ਤੇ ਚਿੱਤਰ ਅਤੇ ਆਪਣੇ ਆਪ ਵਿੱਚ ਹੋਣ ਵਾਲੀਆਂ ਘਟਨਾਵਾਂ ਦੇ ਵਿਚਕਾਰ ਪਛੜ ਨੂੰ ਘੱਟ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ। ਨਾਲ ਹੀ, ਸਾਡੇ ਕੋਲ PTZ ਕੈਮਰਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਇੱਛਾ ਸੀ, ਜਿੱਥੇ ਦੇਰੀ ਨਾਜ਼ੁਕ, ਵਧੇਰੇ ਆਰਾਮਦਾਇਕ ਹੁੰਦੀ ਹੈ।

ਇਸ ਗੱਲ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ ਕਿ ਹੋਰ ਐਂਟੀ-ਲੈਗ ਲਾਗੂਕਰਨਾਂ ਵਿੱਚ ਅਜੇ ਵੀ ਸੀਮਤ ਕਾਰਜਕੁਸ਼ਲਤਾ ਹੈ ਅਤੇ ਕੰਮ ਕਾਫ਼ੀ ਮਾੜਾ ਹੈ, ਅਸੀਂ WebRTC ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ।

ਅਸੀਂ ਕੀ ਕੀਤਾ ਹੈ

WebRTC ਪਲੇਟਫਾਰਮ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਲਾਗੂ ਕਰਨਾ ਕੋਈ ਆਸਾਨ ਕੰਮ ਨਹੀਂ ਹੈ। ਕੋਈ ਵੀ ਗਲਤ ਗਣਨਾ ਜਾਂ ਅਸ਼ੁੱਧਤਾ ਵੀਡੀਓ ਪ੍ਰਸਾਰਣ ਵਿੱਚ ਦੇਰੀ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੀ ਹੈ ਨਾ ਸਿਰਫ ਦੂਜੇ ਪਲੇਟਫਾਰਮਾਂ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਘੱਟ ਰਹੀ ਹੈ, ਸਗੋਂ ਵੱਧ ਰਹੀ ਹੈ।

WebRTC ਦੇ ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ, ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਵੈੱਬ ਵੀਡੀਓ ਦੇ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਸਟੈਕ ਦਾ ਤਕਨੀਕੀ ਅਪਗ੍ਰੇਡ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ। ਇਹੀ ਅਸੀਂ ਕੀਤਾ।

ਪਹਿਲਾਂ, ਅਸੀਂ Websocket ਉੱਤੇ ਇੱਕ WebRTC ਸਿਗਨਲਿੰਗ ਪ੍ਰੋਟੋਕੋਲ ਸਰਵਰ ਲਾਗੂ ਕੀਤਾ, ਅਤੇ webrtc.org SDK ਦੇ ਆਧਾਰ 'ਤੇ ਕਲਾਉਡ ਵਿੱਚ ਇੱਕ WebRTC ਪੀਅਰ ਸਰਵਰ ਵੀ ਤੈਨਾਤ ਕੀਤਾ। ਇਸਦਾ ਕੰਮ ਵੀਡੀਓ ਟ੍ਰਾਂਸਕੋਡਿੰਗ ਦੇ ਬਿਨਾਂ H.264 + Opus/G.711 ਫਾਰਮੈਟ ਵਿੱਚ ਕਲਾਇੰਟ WebRTC ਸਾਥੀਆਂ ਨੂੰ ਵੀਡੀਓ ਸਟ੍ਰੀਮਾਂ ਨੂੰ ਵੰਡਣਾ ਹੈ।

ਅਸੀਂ Websocket ਨੂੰ ਸਿਗਨਲ ਪ੍ਰੋਟੋਕੋਲ ਵਜੋਂ ਚੁਣਿਆ ਹੈ ਕਿਉਂਕਿ ਇਸ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਸਾਰੇ ਪ੍ਰਸਿੱਧ ਵੈੱਬ ਬ੍ਰਾਊਜ਼ਰਾਂ ਵਿੱਚ ਉੱਚ-ਗੁਣਵੱਤਾ ਸਮਰਥਨ ਹੈ। ਇਸਦੇ ਕਾਰਨ, ਤੁਸੀਂ ਨਾ ਸਿਰਫ਼ ਵਿਕਾਸ ਦੇ ਓਵਰਹੈੱਡ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਘਟਾ ਸਕਦੇ ਹੋ, ਸਗੋਂ AJAX ਦੇ ਮੁਕਾਬਲੇ ਵਾਰ-ਵਾਰ TCP ਅਤੇ TLS ਹੈਂਡਸ਼ੇਕ 'ਤੇ ਸਮਾਂ ਅਤੇ ਸਰੋਤ ਬਰਬਾਦ ਕਰਨ ਤੋਂ ਵੀ ਬਚ ਸਕਦੇ ਹੋ।

ਤੱਥ ਇਹ ਹੈ ਕਿ, ਮੂਲ ਰੂਪ ਵਿੱਚ, WebRTC ਸਰੋਤ ਅਤੇ ਕਲਾਇੰਟ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿਚਕਾਰ ਰੀਅਲ-ਟਾਈਮ ਵੀਡੀਓ ਸੰਚਾਰ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਕੌਂਫਿਗਰ ਕਰਨ, ਕਾਇਮ ਰੱਖਣ ਅਤੇ ਸਮਾਪਤ ਕਰਨ ਲਈ ਜ਼ਰੂਰੀ ਸਿਗਨਲ ਪ੍ਰੋਟੋਕੋਲ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦਾ ਹੈ।

ਅਤੇ ਸਿਗਨਲਿੰਗ ਤਕਨਾਲੋਜੀ ਨੂੰ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਲਾਗੂ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਕਈ ਵੈਬ ਪ੍ਰੋਟੋਕੋਲ (ਵੈਬਸੋਸੈਟ, ਵੈਬਆਰਟੀਸੀ) ਦੇ ਸਮਰਥਨ ਨਾਲ ਆਪਣੇ ਖੁਦ ਦੇ ਸਿਗਨਲ ਸਰਵਰ ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਅਤੇ ਰੀਅਲ ਟਾਈਮ, ਵੀਡੀਓ ਪ੍ਰਬੰਧਨ ਅਤੇ ਹੋਰ ਬਹੁਤ ਕੁਝ ਵਿੱਚ ਸੈਸ਼ਨਾਂ ਅਤੇ ਸੂਚਨਾਵਾਂ ਦਾ ਸੁਰੱਖਿਅਤ ਪ੍ਰਬੰਧਨ ਕਰਨ ਦੀ ਯੋਗਤਾ ਦੇ ਨਾਲ।

ਅਸੀਂ ਲੇਟੈਂਸੀ ਨੂੰ P2P ਰਾਹੀਂ ਨਹੀਂ, ਸਗੋਂ UDP ਅਤੇ ਲੇਟੈਂਸੀ ਨੂੰ ਘਟਾਉਣ ਲਈ ਪ੍ਰਵਾਹ ਨਿਯੰਤਰਣ ਦੁਆਰਾ ਘਟਾ ਕੇ P2P ਦੀਆਂ ਸੀਮਾਵਾਂ ਨੂੰ ਪਾਰ ਕੀਤਾ। ਇਹ WebRTC ਵਿੱਚ ਵੀ ਬਣਾਇਆ ਗਿਆ ਹੈ, ਕਿਉਂਕਿ ਮੁੱਖ ਵਰਤੋਂ-ਕੇਸ ਇੱਕ ਬ੍ਰਾਊਜ਼ਰ ਰਾਹੀਂ p2p ਗੱਲਬਾਤ ਹੈ।

ਮੋਬਾਈਲ ਕਲਾਇੰਟ ਵਿੱਚ, ਅਸੀਂ webrtc.org SDK ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਪਲੇਅਰ ਨੂੰ ਲਾਗੂ ਕੀਤਾ, ਕਿਉਂਕਿ ਸਿਰਫ ਇਹ ਸਹੀ ਢੰਗ ਨਾਲ ਪ੍ਰਵਾਹ ਨਿਯੰਤਰਣ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਸਾਰੀਆਂ ਜਾਣੀਆਂ ਗਈਆਂ ਫਾਰਵਰਡ ਐਰਰ ਸੁਧਾਰ (FEC) ਸਕੀਮਾਂ ਹਨ, ਅਤੇ ਸਾਰੇ ਬ੍ਰਾਊਜ਼ਰਾਂ ਲਈ ਪੈਕੇਟ ਮੁੜ ਭੇਜਣ ਦੀ ਵਿਧੀ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਇਹ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ webrtc.org SDK ਨੂੰ Google ਦੁਆਰਾ ਸਰਗਰਮੀ ਨਾਲ ਵਿਕਸਤ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ।

WebRTC ਨੂੰ ਲਾਗੂ ਕਰਨ ਦਾ ਨਤੀਜਾ ਕੀ ਹੈ?

ਕੈਮਰਿਆਂ ਤੋਂ ਲਾਈਵ ਵੀਡੀਓ ਦੇਖਣ ਲਈ, ਅਸੀਂ ਤੁਹਾਡੇ ਨਿੱਜੀ ਖਾਤੇ ਵਿੱਚ WebRTC 'ਤੇ ਆਧਾਰਿਤ ਇੱਕ ਨਵਾਂ ਅਨੁਕੂਲਿਤ ਪਲੇਅਰ ਸ਼ਾਮਲ ਕੀਤਾ ਹੈ। ਇਹ ਤੇਜ਼ ਵੀਡੀਓ ਲੋਡ ਕਰਨ ਦੀ ਗਤੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਅਤੇ ਦੇਖਣ ਦਾ ਸਮਾਂ ਵਧਣ ਨਾਲ ਲੇਟੈਂਸੀ ਇਕੱਠੀ ਹੋਣ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਖਤਮ ਕਰਦਾ ਹੈ।

Ivideon ਕਲਾਉਡ ਸੇਵਾ ਵਿੱਚ WebRTC ਸਹਾਇਤਾ ਨੂੰ ਪੇਸ਼ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਪੂਰੇ ਵਿਸ਼ਵਾਸ ਨਾਲ ਕਹਿ ਸਕਦੇ ਹਾਂ ਕਿ ਸਾਡੇ ਗਾਹਕ ਹੁਣ ਪੂਰੀ ਤਰ੍ਹਾਂ ਲਾਈਵ ਵੀਡੀਓ ਦੇਖ ਸਕਦੇ ਹਨ। ਹੁਣ ਵੀਡੀਓ ਕ੍ਰਮ ਪ੍ਰਸਾਰਿਤ ਕਰਨ ਵੇਲੇ ਦੇਰੀ ਇੱਕ ਸਕਿੰਟ ਤੋਂ ਵੱਧ ਨਹੀਂ ਹੁੰਦੀ! ਤੁਲਨਾ ਲਈ, ਪਿਛਲੇ HLS ਇੰਜਣ ਨੇ 5-7 ਸਕਿੰਟਾਂ ਦੀ ਦੇਰੀ ਨਾਲ ਵੀਡੀਓ ਡਿਲੀਵਰੀ ਪ੍ਰਦਾਨ ਕੀਤੀ। ਵੀਡੀਓ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਗਤੀ ਵਿੱਚ ਅੰਤਰ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਅਤੇ ਉਪਭੋਗਤਾ ਸਾਡੀ ਵੀਡੀਓ ਸੇਵਾ ਦੇ ਨਾਲ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਇਸਨੂੰ ਨੋਟਿਸ ਕਰੇਗਾ।

ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਉਮੀਦ ਕੀਤੀ ਸੀ, ਨਵੇਂ ਪਲੇਅਰ ਦੇ ਲਾਗੂ ਹੋਣ ਨਾਲ PTZ ਦੀ ਜਵਾਬਦੇਹੀ ਅਤੇ ਕੈਮਰੇ ਨਾਲ ਆਵਾਜ਼ ਸੰਚਾਰ ਵਿੱਚ ਸੁਧਾਰ ਹੋਇਆ ਹੈ।

ਇੱਥੇ ਸਿਰਫ਼ ਇੱਕ ਸੂਖਮ ਨੁਕਤਾ ਹੈ ਜਿਸ ਵੱਲ ਅਸੀਂ ਧਿਆਨ ਖਿੱਚਣਾ ਚਾਹੁੰਦੇ ਹਾਂ। ਨਵਾਂ WebRTC ਪਲੇਅਰ ਵਰਤਮਾਨ ਵਿੱਚ ਟੈਸਟ ਮੋਡ ਵਿੱਚ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ। ਅਤੇ ਇਸ ਲਈ ਅਸੀਂ ਇਸਨੂੰ ਆਪਣੇ ਸਾਰੇ ਗਾਹਕਾਂ ਲਈ ਮੂਲ ਰੂਪ ਵਿੱਚ ਸਮਰੱਥ ਨਹੀਂ ਕਰਦੇ ਹਾਂ। ਪਰ ਤੁਸੀਂ ਕੈਮਰਾ ਸੈਟਿੰਗਾਂ ਵਿੱਚ ਸੰਬੰਧਿਤ ਆਈਟਮ ਨੂੰ ਸਮਰੱਥ ਕਰਕੇ ਇਸਨੂੰ ਆਪਣੇ ਆਪ ਐਕਟੀਵੇਟ ਕਰ ਸਕਦੇ ਹੋ (ਇਹ ਕਰਨ ਲਈ, 'ਤੇ ਜਾਓ ਨਿੱਜੀ ਖਾਤਾ).

Ivideon ਸੇਵਾ ਵਿੱਚ WebRTC ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ

WebRTC ਫਿਲਹਾਲ ਇੱਕ ਪ੍ਰਯੋਗਾਤਮਕ ਤਕਨੀਕ ਹੈ। ਇਸਦਾ ਸਮਰਥਨ ਅਜੇ ਤੱਕ ਸਾਰੇ ਬ੍ਰਾਉਜ਼ਰਾਂ ਅਤੇ ਉਪਭੋਗਤਾ ਡਿਵਾਈਸਾਂ ਵਿੱਚ ਸਹੀ ਢੰਗ ਨਾਲ ਲਾਗੂ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ, ਅਤੇ ਸਾਰੇ ਕੈਮਰਿਆਂ ਵਿੱਚ ਵੀ ਨਹੀਂ ਹੈ।

ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ ਅਸੀਂ ਅਜੇ ਤੱਕ WebRTC ਪਲੇਅਰ ਨੂੰ ਸਾਰੇ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਡਿਫੌਲਟ ਨਹੀਂ ਬਣਾਇਆ ਹੈ।

ਫਿਲਹਾਲ, ਅਸੀਂ ਸਿਰਫ਼ Google Chrome ਬ੍ਰਾਊਜ਼ਰਾਂ ਵਿੱਚ WebRTC ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਸਿਫ਼ਾਰਿਸ਼ ਕਰਦੇ ਹਾਂ। ਫਾਇਰਫਾਕਸ ਅਤੇ ਸਫਾਰੀ ਦੇ ਨਵੀਨਤਮ ਸੰਸਕਰਣ ਵੀ ਇਸ ਤਕਨਾਲੋਜੀ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ, ਪਰ, ਬਦਕਿਸਮਤੀ ਨਾਲ, ਇਹ ਅਜੇ ਵੀ ਅਸਥਿਰ ਹੈ।

ਅਸੀਂ ਅਜੇ ਤੱਕ ਮੋਬਾਈਲ ਡਿਵਾਈਸਾਂ 'ਤੇ ਬ੍ਰਾਊਜ਼ਰਾਂ ਲਈ WebRTC ਸਮਰਥਨ ਲਾਗੂ ਨਹੀਂ ਕੀਤਾ ਹੈ। ਵਰਤਮਾਨ ਵਿੱਚ, ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਮੋਬਾਈਲ ਡਿਵਾਈਸ ਤੋਂ ਲੌਗਇਨ ਕਰਦੇ ਹੋ ਅਤੇ WebRTC ਨੂੰ ਕਿਰਿਆਸ਼ੀਲ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਮੋਡ ਕੰਮ ਨਹੀਂ ਕਰੇਗਾ। ਹਾਲਾਂਕਿ, WebRTC ਲਈ ਸਾਡੀਆਂ ਮੋਬਾਈਲ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਉਪਲਬਧ ਹੈ Android и ਆਈਓਐਸ.

ਅਤੇ ਸਾਡੀ ਸੇਵਾ ਵਿੱਚ WebRTC ਲਾਗੂ ਕਰਨ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਬਾਰੇ ਕਹਾਣੀ ਨੂੰ ਸਮਾਪਤ ਕਰਦੇ ਹੋਏ, ਆਓ ਦੋ ਹੋਰ ਸੂਖਮ ਨੁਕਤਿਆਂ ਵੱਲ ਧਿਆਨ ਦੇਈਏ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਤਕਨਾਲੋਜੀ ਰੀਅਲ ਟਾਈਮ ਵਿੱਚ ਲਾਈਵ ਵੀਡੀਓ ਦੇ ਪ੍ਰਸਾਰਣ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਹੈ। ਇਸ ਲਈ, ਜੇਕਰ ਤੁਹਾਡੇ ਚੈਨਲ ਕੋਲ ਵੀਡੀਓ ਪ੍ਰਸਾਰਿਤ ਕਰਨ ਲਈ ਲੋੜੀਂਦੀ ਬੈਂਡਵਿਡਥ ਨਹੀਂ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਫ੍ਰੇਮ ਡ੍ਰੌਪ ਵੇਖੋਗੇ (HLS ਨਾਲ ਤੁਸੀਂ ਵੀਡੀਓ ਫੇਡਿੰਗ ਅਤੇ ਵਧੀ ਹੋਈ ਲੇਟੈਂਸੀ ਵੇਖੋਗੇ, ਪਰ ਕੋਈ ਫਰੇਮ ਡ੍ਰੌਪ ਨਹੀਂ ਹੋਵੇਗਾ), ਪਰ ਵੀਡੀਓ ਅਜੇ ਵੀ ਅਸਲ ਵਿੱਚ ਪ੍ਰਸਾਰਿਤ ਕੀਤਾ ਜਾਵੇਗਾ ਸਮਾਂ

ਦੂਜਾ, ਕਿਉਂਕਿ ਟੈਕਨਾਲੋਜੀ ਨੂੰ ਰੀਅਲ ਟਾਈਮ ਵਿੱਚ ਲਾਈਵ ਵੀਡੀਓ ਦੇ ਨਾਲ ਖਾਸ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਅਸੀਂ ਇਸਦੀ ਵਰਤੋਂ ਆਰਕਾਈਵ ਕੀਤੇ ਵੀਡੀਓ ਡੇਟਾ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਨਹੀਂ ਕਰਦੇ ਹਾਂ।

ਸੇਵਾ ਵਿੱਚ ਹੋਰ ਬਦਲਾਅ

ਇਸ ਸਮੇਂ, ਫਲੈਸ਼ ਹੁਣ ਆਟੋਮੈਟਿਕ ਇੰਜਣ ਚੋਣ ਵਿਧੀ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਹੈ। ਤੁਸੀਂ ਅਜੇ ਵੀ ਅਜਿਹੇ ਪਲੇਅਰ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਅਜਿਹਾ ਕਰਨ ਲਈ ਤੁਹਾਨੂੰ ਖਾਤੇ ਜਾਂ ਕੈਮਰਾ ਸੈਟਿੰਗਾਂ ਵਿੱਚ ਇਸਨੂੰ ਮੈਨੂਅਲੀ ਚੁਣਨਾ ਹੋਵੇਗਾ। ਇਹ ਫੈਸ਼ਨ ਨੂੰ ਸ਼ਰਧਾਂਜਲੀ ਨਹੀਂ ਹੈ, ਇਹ ਸਿਰਫ ਇਹ ਹੈ ਕਿ ਸਾਡੀ ਸੇਵਾ ਦੇ ਅੰਕੜਿਆਂ ਦੇ ਅਨੁਸਾਰ, ਫਲੈਸ਼ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਅਮਲੀ ਤੌਰ 'ਤੇ ਕੋਈ ਉਪਭੋਗਤਾ ਨਹੀਂ ਬਚਿਆ ਹੈ। ਅਤੇ ਇਹ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ ਕਿ ਕੀ ਉਪਭੋਗਤਾ ਦਾ ਬ੍ਰਾਊਜ਼ਰ ਇਸਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਅਸੀਂ ਲਗਭਗ 2 ਸਕਿੰਟ ਦਾ ਕੀਮਤੀ ਸਮਾਂ ਗੁਆ ਦਿੰਦੇ ਹਾਂ।

ਸਾਡੇ ਕਲਾਉਡ ਵੀਡੀਓ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਅਤੇ ਨਿੱਜੀ ਖਾਤੇ ਵਿੱਚ ਤੁਹਾਡੀ ਉਡੀਕ ਕਰਨ ਵਾਲੇ ਬਦਲਾਵਾਂ ਦੀ ਇੱਥੇ ਇੱਕ ਸੰਖੇਪ ਜਾਣਕਾਰੀ ਹੈ। ਸਾਡੇ ਨਾਲ ਰਹੋ ਅਤੇ ਖ਼ਬਰਾਂ ਦਾ ਪਾਲਣ ਕਰੋ!

ਸਰੋਤ: www.habr.com