Menerbitkan strim kamera: RTSP dan HLS bukan tepi yang sama

Anda membuka satu port kamera, menghala pemain ke arahnya dan menganggap masalah internet sudah selesai. Kemudian telefon tidak dapat memainkannya, pelayar tidak dapat memainkannya, dan halaman pentadbiran kamera hanya sejauh satu laluan yang tersalah taip dari tepi awam. Model penghantaran yang anda pilih, RTSP atau HLS, menentukan sebahagian besar perkara itu sebelum apa-apa peraturan tembok api ditulis. VPN hanya menyediakan bahagian peribadi.

VPN membaiki laluan sumber, bukan laluan penonton

VPS yang disambungkan ke LAN kamera melalui terowong boleh mencapai kamera pada alamat peribadinya, dan itu benar-benar berguna. Ini bermakna kamera tidak memerlukan port masuk sendiri dan penghala rumah kekal tertutup. Ia tidak memberitahu anda bahasa apa yang akan dituturkan oleh penonton. Pemain desktop, pelayar, telefon dan televisyen pintar menyokong protokol yang berbeza, dan setiap satu mempunyai jangkaan sendiri tentang TLS, pengesahan dan codec.

Inilah andaian yang wajar dibuang: menerbitkan bermakna menjadikan sumber boleh dicapai. Menerbitkan sebenarnya bermakna memberikan khalayak yang ditentukan cara yang disokong untuk menggunakan media. Strim yang diterbitkan mempunyai format, khalayak dan kelayakan; kamera yang boleh dicapai tidak mempunyai satu pun daripadanya. Kebolehcapaian ialah bahagian yang diselesaikan oleh terowong, dan titik masuk penonton ialah bahagian yang masih perlu anda reka bentuk.

RTSP ialah rundingan, bukan satu port

RTSP membawa kawalan sesi: klien meminta penerangan, menyediakan satu atau lebih trek media, kemudian memainkan. Pengangkutan media itu sendiri dirundingkan semasa penyediaan itu, sebab itulah protokol itu tidak digambarkan dengan baik oleh satu port TCP yang dipindahkan. Rundingan itulah bahagian yang orang terlepas pandang apabila membandingkan peraturan tembok api.

Bergantung pada titik akhir, RTP mungkin tiba pada port UDP berasingan atau diselitkan pada sambungan kawalan. Geganti yang hanya memindahkan 554 dan menganggap selebihnya akan berfungsi biasanya menghasilkan sesi yang bersambung, melaporkan satu trek dan kemudian tidak memaparkan apa-apa. Semak pengangkutan yang sebenarnya dirundingkan oleh kamera anda sebelum menulis peraturan untuknya. Tangkapan di sebelah peribadi menjawabnya dalam satu minit, dan meneka menelan kos satu malam.

Untuk khalayak kecil dan dikenali dengan pemain yang serasi, geganti RTSP yang dikonfigurasikan dengan sengaja boleh menjadi jawapan yang tepat. Hadkan sumber mana yang boleh ditariknya dan wajibkan pengesahan di geganti. Catat pemain yang anda uji, kerana strim RTSP yang berfungsi dalam VLC masih boleh gagal dalam pelayar.

HLS ialah senarai main serta sumber

Penonton HLS mengambil senarai main, kemudian mengambil segmen media yang dinamakan senarai itu. Spesifikasi HLS mentakrifkan model sumber itu, dan butiran operasi yang penting ialah senarai main merujuk kepada URL lain. Rujukan relatif diselesaikan berbanding lokasi senarai main, jadi proksi yang menulis semula laluan mesti menulis semula secara konsisten.

Jika kamera sudah menyediakan HLS yang boleh digunakan, frontend awam boleh memindahkan permintaan senarai main dan segmen itu melalui terowong. Perhatikan kunci, ubah hala dan URL yang dijana oleh aplikasi. Mana-mana URL mutlak yang menunjuk ke hos peribadi akan pecah sebaik sahaja penonton di luar LAN mengikutinya. Laluan relatif ialah yang bertahan daripada penulisan semula proksi, jadi utamakan di mana-mana anda mengawal output yang dijana.

Jika kamera hanya bertutur RTSP, sesuatu mesti menukar sumber ke format penonton. Pembungkusan semula dan transkod adalah kerja yang berbeza: pembungkusan semula mengekalkan codec, manakala transkod mengekod semula untuk keserasian, dan hanya yang kedua memakan CPU dengan serius. Kedua-duanya tidak menjadi perlu semata-mata kerana ada VPN di laluan.

Rancang pautan naik berdasarkan tempat pengedaran berlaku. Satu pengambilan peribadi yang membekalkan perkhidmatan media awam berkelakuan sangat berbeza daripada setiap penonton yang menarik strim sendiri melalui terowong. Corak kedua biasanya berakhir dengan sambungan rumah yang tepu dan kamera yang kelihatan gagal secara rawak.

Letakkan pengesahan pada tepi yang anda terbitkan

TLS, pengesahan penonton dan pengelogan akses tergolong pada titik masuk awam, bukan pada kamera. Ini memisahkan kelayakan kamera daripada kelayakan strim. Ia juga memberi anda satu tempat untuk membatalkan akses apabila seorang ahli khalayak pergi. Meletakkan kawalan itu pada kamera pula bermakna setiap perubahan khalayak menjadi perubahan pentadbiran pada peranti yang tidak sepatutnya boleh dicapai secara awam.

Pisahkan VPN dan kebenaran pentadbir kamera daripada laluan penerbitan. VPS yang boleh mencapai antara muka web kamera untuk menarik strim tidak sepatutnya juga menjadi mesin yang mendedahkan antara muka itu. Khalayak tidak sepatutnya mengetahui alamat kamera.

Kemudian sahkan kedua-dua hujung yang benar-benar anda bina dan bukan menganggap rantai itu berfungsi:

$ 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

Semakan sumber peribadi yang berjaya dan pengambilan senarai main yang berjaya di tepi awam membuktikan dua separuh reka bentuk yang berbeza. Uji keduanya secara berasingan. Main semula daripada jenis klien yang sama dengan yang digunakan khalayak anda ialah satu-satunya ujian yang merangkumi seluruh rantai.

Apa yang akhirnya anda miliki ialah rantai dengan tujuan pada setiap pautan: sumber peribadi, pengambilan terhad, pembungkusan terpilih, pintu masuk penonton yang dibenarkan. Tiada pautan itu yang pilihan, dan tiada yang tercipta dengan membuka port.