ক্যামেরা স্ট্রিম প্রকাশ: RTSP ও HLS একই প্রান্ত নয়

আপনি ক্যামেরার একটি পোর্ট খোলেন, সেটির দিকে একটি প্লেয়ার তাক করেন এবং ধরে নেন ইন্টারনেটের সমস্যা মিটে গেছে। তারপর একটি ফোন সেটি চালাতে পারে না, একটি ব্রাউজার সেটি চালাতে পারে না, এবং ক্যামেরার প্রশাসন পৃষ্ঠাটি পাবলিক প্রান্ত থেকে কেবল একটি ভুল টাইপ করা পথের দূরত্বে থাকে। আপনি যে ডেলিভারি মডেল বেছেছেন, RTSP বা HLS, কোনো ফায়ারওয়াল নিয়ম লেখার আগেই তার বেশিরভাগ নির্ধারণ করে দেয়। VPN কেবল ব্যক্তিগত অংশটি দেয়।

VPN উৎসের পথ ঠিক করে, দর্শকের নয়

টানেলের মাধ্যমে ক্যামেরার ল্যানে যুক্ত একটি VPS ক্যামেরার কাছে তার ব্যক্তিগত ঠিকানায় পৌঁছাতে পারে, এবং এটি সত্যিই উপকারী। এর অর্থ হলো ক্যামেরার নিজের কোনো ইনবাউন্ড পোর্ট লাগে না এবং ঘরের রাউটার বন্ধ থাকে। এটি আপনাকে বলে না একজন দর্শক কোন ভাষায় কথা বলবে। ডেস্কটপ প্লেয়ার, ব্রাউজার, ফোন এবং স্মার্ট টিভি ভিন্ন ভিন্ন প্রোটোকল সমর্থন করে, এবং প্রত্যেকের TLS, প্রমাণীকরণ ও কোডেক নিয়ে নিজস্ব প্রত্যাশা আছে।

এই হলো সেই ধারণা যা বাদ দেওয়া উচিত: প্রকাশ বলতে উৎসকে নাগালের মধ্যে আনা বোঝায়। প্রকাশ আসলে বোঝায় একটি নির্দিষ্ট দর্শকগোষ্ঠীকে মাধ্যম ভোগ করার একটি সমর্থিত উপায় দেওয়া। প্রকাশিত স্ট্রিমের একটি বিন্যাস, একটি দর্শকগোষ্ঠী ও একটি ক্রেডেনশিয়াল থাকে; নাগালের মধ্যে থাকা ক্যামেরার এসবের কিছুই থাকে না। নাগালই সেই অংশ যা টানেল সমাধান করে, এবং দর্শকের প্রবেশবিন্দু সেই অংশ যা আপনাকে এখনো নকশা করতে হবে।

RTSP একটি দরকষাকষি, একটি পোর্ট নয়

RTSP সেশন নিয়ন্ত্রণ বহন করে: একটি ক্লায়েন্ট বিবরণ চায়, এক বা একাধিক মিডিয়া ট্র্যাক সেট করে এবং তারপর চালায়। মাধ্যমের পরিবহন নিজেই সেই সেটআপের সময় নির্ধারিত হয়, তাই প্রোটোকলটি একটি ফরওয়ার্ড করা TCP পোর্ট দিয়ে ভালোভাবে বর্ণনা করা যায় না। সেই দরকষাকষিই সেই অংশ যা মানুষ ফায়ারওয়াল নিয়ম তুলনা করার সময় এড়িয়ে যায়।

এন্ডপয়েন্ট অনুযায়ী RTP আলাদা UDP পোর্টে আসতে পারে বা নিয়ন্ত্রণ সংযোগে বোনা হতে পারে। কেবল 554 পাঠানো এবং বাকিটা কাজ করবে বলে ধরে নেওয়া একটি রিলে সাধারণত এমন সেশন তৈরি করে যা সংযুক্ত হয়, একটি ট্র্যাকের কথা জানায় এবং তারপর কিছুই দেখায় না। এর জন্য নিয়ম লেখার আগে যাচাই করুন আপনার ক্যামেরা আসলে কোন পরিবহন নির্ধারণ করে। ব্যক্তিগত দিকের ক্যাপচার এক মিনিটে তার উত্তর দেয়, এবং অনুমান করা এক সন্ধ্যার ক্ষতি।

সামঞ্জস্যপূর্ণ প্লেয়ারসহ ছোট, পরিচিত দর্শকগোষ্ঠীর জন্য ইচ্ছাকৃতভাবে কনফিগার করা RTSP রিলে সঠিক উত্তর হতে পারে। এটি কোন উৎস থেকে টানতে পারবে তা সীমিত করুন এবং রিলেতে প্রমাণীকরণ দাবি করুন। আপনার পরীক্ষিত প্লেয়ারগুলো লিখে রাখুন, কারণ VLC-তে কাজ করা RTSP স্ট্রিম ব্রাউজারে তবুও ব্যর্থ হতে পারে।

HLS একটি প্লেলিস্ট এবং সম্পদ

HLS দর্শক একটি প্লেলিস্ট আনে, তারপর সেই প্লেলিস্ট যে মিডিয়া সেগমেন্টগুলোর নাম বলে সেগুলো আনে। HLS স্পেসিফিকেশন সেই সম্পদ মডেলটি নির্ধারণ করে, এবং গুরুত্বপূর্ণ পরিচালন বিবরণ হলো প্লেলিস্টগুলো অন্য URL-এ নির্দেশ করে। আপেক্ষিক নির্দেশনা প্লেলিস্টের অবস্থানের সাপেক্ষে সমাধান হয়, তাই পথ পুনর্লিখনকারী প্রক্সিকে সেগুলো ধারাবাহিকভাবে পুনর্লিখন করতে হবে।

যদি ক্যামেরা ইতিমধ্যে ব্যবহারযোগ্য HLS পরিবেশন করে, একটি পাবলিক ফ্রন্টএন্ড সেই প্লেলিস্ট ও সেগমেন্ট অনুরোধগুলো টানেলের মধ্য দিয়ে পাঠাতে পারে। অ্যাপ্লিকেশনের তৈরি করা কী, পুনর্নির্দেশনা ও URL-এ নজর রাখুন। ব্যক্তিগত হোস্টের দিকে নির্দেশ করা যেকোনো পরম URL সেই মুহূর্তেই ভেঙে যায় যখন ল্যানের বাইরের কোনো দর্শক তা অনুসরণ করে। আপেক্ষিক পথগুলোই প্রক্সির পুনর্লিখন থেকে টিকে থাকে, তাই যেখানেই আপনি উৎপন্ন আউটপুট নিয়ন্ত্রণ করেন সেখানে সেগুলোকে অগ্রাধিকার দিন।

যদি ক্যামেরা কেবল RTSP বলে, তাহলে কিছু একটা উৎসকে দর্শকের বিন্যাসে রূপান্তর করতে হবে। রিপ্যাকেজিং এবং ট্রান্সকোডিং আলাদা কাজ: রিপ্যাকেজিং কোডেক সংরক্ষণ করে, অন্যদিকে ট্রান্সকোডিং সামঞ্জস্যের জন্য তা পুনরায় এনকোড করে, এবং কেবল দ্বিতীয়টিই গুরুতর CPU ব্যয় করে। দুটির কোনোটিই কেবল পথে VPN আছে বলে প্রয়োজনীয় হয়ে ওঠে না।

আপলিংকের পরিকল্পনা করুন বিতরণ কোথায় ঘটে তার ভিত্তিতে। একটি ব্যক্তিগত ইনজেস্ট যা একটি পাবলিক মিডিয়া সেবাকে খাওয়ায়, নিজের স্ট্রিম টানেল দিয়ে টানা প্রতিটি দর্শকের চেয়ে সম্পূর্ণ ভিন্ন আচরণ করে। দ্বিতীয় ধরনটি সাধারণত ভরাট ঘরোয়া সংযোগ এবং এলোমেলোভাবে ব্যর্থ দেখানো ক্যামেরায় শেষ হয়।

প্রমাণীকরণ সেই প্রান্তে রাখুন যা আপনি প্রকাশ করেন

TLS, দর্শক প্রমাণীকরণ এবং অ্যাক্সেস লগিং পাবলিক প্রবেশবিন্দুর সাথে সম্পর্কিত, ক্যামেরার সাথে নয়। এটি ক্যামেরার ক্রেডেনশিয়ালকে স্ট্রিমের ক্রেডেনশিয়াল থেকে আলাদা রাখে। এটি দর্শকগোষ্ঠীর কোনো সদস্য চলে গেলে অ্যাক্সেস প্রত্যাহারের জন্য একটি জায়গাও দেয়। সেই নিয়ন্ত্রণগুলো ক্যামেরায় রাখার অর্থ বরং এই যে দর্শকগোষ্ঠীর প্রতিটি পরিবর্তন এমন একটি ডিভাইসে প্রশাসনিক পরিবর্তন হয়ে যায় যা কখনোই পাবলিকভাবে নাগালের মধ্যে থাকা উচিত নয়।

VPN এবং ক্যামেরার প্রশাসনিক অনুমতি প্রকাশের পথ থেকে আলাদা রাখুন। স্ট্রিম টানার জন্য ক্যামেরার ওয়েব ইন্টারফেসে পৌঁছাতে পারে এমন VPS সেই ইন্টারফেস প্রকাশকারী মেশিনও হওয়া উচিত নয়। দর্শকগোষ্ঠী কখনোই ক্যামেরার ঠিকানা জানা উচিত নয়।

তারপর শৃঙ্খল কাজ করে বলে ধরে না নিয়ে আপনি আসলে যে দুটি প্রান্ত তৈরি করেছেন তা যাচাই করুন:

$ ffprobe -v error -rtsp_transport tcp rtsp://10.50.0.9:554/stream1
$ curl -sI https://stream.example.net/live/index.m3u8
HTTP/2 200
content-type: application/vnd.apple.mpegurl

ব্যক্তিগত উৎসের সফল যাচাই এবং পাবলিক প্রান্তে প্লেলিস্টের সফল সংগ্রহ নকশার ভিন্ন দুটি অর্ধেক প্রমাণ করে। সেগুলো আলাদাভাবে পরীক্ষা করুন। আপনার দর্শকগোষ্ঠী যে ধরনের ক্লায়েন্ট ব্যবহার করে সেখান থেকেই প্লেব্যাক একমাত্র পরীক্ষা যা পুরো শৃঙ্খল ঢাকে।

শেষে আপনার কাছে প্রতিটি কড়ির একটি উদ্দেশ্য থাকা একটি শৃঙ্খল থাকে: ব্যক্তিগত উৎস, সীমিত ইনজেস্ট, নির্বাচিত প্যাকেজিং, অনুমোদিত দর্শক প্রবেশ। এই কড়িগুলোর কোনোটিই ঐচ্ছিক নয়, এবং কোনোটিই পোর্ট খোলার মাধ্যমে তৈরি হয় না।