ხშირად ჩნდება კითხვა: როგორ დავუკავშიროთ IP კამერა NVR-ს, თუ ის არ არის თავსებადობის სიაში?

ორი ვარიანტია ONVIF და RTSP

დავიწყოთ ONVIF პროტოკოლით (ღია ქსელის ვიდეო ინტერფეისის ფორუმი)

ONVIF არის ზოგადად მიღებული პროტოკოლი IP კამერების, NVR-ების თანამშრომლობისთვის, პროგრამული უზრუნველყოფა, იმ შემთხვევაში, თუ ყველა მოწყობილობა სხვადასხვა მწარმოებლისაა. ONVIF შეიძლება შევადაროთ ინგლისურიადამიანთა საერთაშორისო კომუნიკაციისთვის.

დარწმუნდით, რომ დაკავშირებული მოწყობილობები მხარს უჭერენ ONVIF-ს ზოგიერთ მოწყობილობაზე ONVIF შეიძლება გამორთული იყოს ნაგულისხმევად.
ან ONVIF ავტორიზაცია შეიძლება გამორთული იყოს, რაც ნიშნავს, რომ შესვლა/პაროლი ყოველთვის ნაგულისხმევად იქნება
WEB-ისთვის შესვლის/პაროლის მიუხედავად

ასევე აღსანიშნავია, რომ ზოგიერთი მოწყობილობა იყენებსცალკე პორტი ONVIF პროტოკოლით მუშაობისთვის

ზოგიერთ შემთხვევაში, ONVIF პაროლი შეიძლება განსხვავდებოდეს WEB წვდომის პაროლისგან.

რა არის ხელმისაწვდომი ONVIF-ის საშუალებით დაკავშირებისას?

მოწყობილობის აღმოჩენა

ვიდეო გადაცემა

აუდიო მონაცემების მიღება და გადაცემა

კონტროლი PTZ კამერები(PTZ)

ვიდეო ანალიტიკა (როგორიცაა მოძრაობის ამოცნობა)

ეს პარამეტრები დამოკიდებულია ONVIF პროტოკოლის ვერსიების თავსებადობაზე. ზოგიერთ შემთხვევაში, ზოგიერთი პარამეტრი მიუწვდომელია ან არ მუშაობს სწორად.

კ და ONVIF-ის გამოყენებით

SNR და Dahua ჩამწერებში ONVIF პროტოკოლიმდებარეობს დისტანციური მოწყობილობის ჩანართზე, მწარმოებლის ხაზი

აირჩიეთ არხი, რომელსაც მოწყობილობა დაუკავშირდება

მწარმოებლის ჩანართიდან აირჩიეთ ONVIF

დააკონკრეტეთ ip მისამართიმოწყობილობები

RTSPპორტი ნაგულისხმევად რჩება

კამერების გამოყენება ONVIF პორტი 8080
(2017 წლიდან, ONVIF-ის ახალ მოდელებზე პორტი შეიცვალა 80-ით Alpha და Mira სერიებისთვის)
OMNY კამერები ბაზაგამოყენება ONVIF პორტი 80, რეგისტრატორში მითითებულია როგორც HTTP პორტი

სახელი

პაროლიმოწყობილობის პარამეტრების მიხედვით

დისტანციური არხინაგულისხმევი არის 1. თუ მოწყობილობა მრავალარხიანია, მითითებულია არხის ნომერი.

დეკოდერის ბუფერი— ვიდეო ნაკადის ბუფერირება, რომელიც მიუთითებს დროის მნიშვნელობაზე

სერვერის ტიპიაქ არის TCP, UDP განრიგის არჩევანი

TCP- ამყარებს კავშირს გამგზავნსა და მიმღებს შორის, უზრუნველყოფს ყველა მონაცემის მიმღებამდე მისვლას ცვლილებების გარეშე და საჭირო თანმიმდევრობით და ასევე არეგულირებს გადაცემის სიჩქარეს.

TCP-ისგან განსხვავებით, UDPარ ამყარებს წინასწარ კავშირს, არამედ უბრალოდ იწყებს მონაცემთა გადაცემას. UDP არ აკონტროლებს, რომ მიღებულია მონაცემები და არ ამრავლებს მათ დაკარგვის ან შეცდომის შემთხვევაში.

UDP ნაკლებად საიმედოა ვიდრე TCP. მაგრამ მეორეს მხრივ, ის უზრუნველყოფს ნაკადების უფრო სწრაფ გადაცემას დაკარგული პაკეტების ხელახალი გადაცემის არარსებობის გამო

განრიგი- ავტომატური ტიპის გამოვლენა.

ასე გამოიყურება დაკავშირებული მოწყობილობები Dahua-ში

მწვანე სტატუსი ნიშნავს, რომ ჩამწერი და კამერა წარმატებით არის დაკავშირებული

წითელი სტატუსი ნიშნავს, რომ კავშირის პრობლემაა. მაგალითად, კავშირის პორტი არასწორია.

მეორე კავშირის მეთოდია RTSP(რეალურ დროში სტრიმინგის პროტოკოლი)

RTSPრეალურ დროში ნაკადის პროტოკოლი, რომელიც აღწერს ბრძანებებს ვიდეო ნაკადის გასაკონტროლებლად.

ამ ბრძანებების გამოყენებით, ვიდეო ნაკადი გადაიცემა წყაროდან მიმღებამდე

მაგალითად, IP კამერიდან DVR-მდე ან სერვერზე.

რა არის ხელმისაწვდომი RTSP-ით დაკავშირებისას?

ვიდეო გადაცემა

აუდიო მონაცემების მიღება და გადაცემა

უპირატესობაგადაცემის ეს პროტოკოლი ისაა, რომ არ საჭიროებს ვერსიის თავსებადობას.

დღეს RTSP მხარს უჭერს თითქმის ყველა IP კამერას და NVR-ს

ხარვეზებიპროტოკოლი არის ის, რომ გარდა ვიდეო და აუდიო მონაცემების გადაცემისა, სხვა არაფერია ხელმისაწვდომი.

მოდით შევხედოთ კამერის დაკავშირების მაგალითსდა RTSP-ის გამოყენებით

RTSPმდებარეობს დისტანციური მოწყობილობის ჩანართზე, მწარმოებლის ხაზი, SNR და Dahua ჩამწერში ის წარმოდგენილია როგორცგენერალი

აირჩიეთ არხი, რომელსაც მოწყობილობა დაუკავშირდება

URL მისამართი- აქ ჩვენ შევიყვანთ შეკითხვის სტრიქონს, რომლისთვისაც კამერა აგზავნის ძირითადი RTSP ნაკადი ერთად მაღალი რეზოლუცია.

დამატებითი URL - აქ შეიყვანეთ მოთხოვნის სტრიქონი, რომლისთვისაც კამერა აგზავნის დამატებითი RTSP ნაკადი ერთად დაბალი გარჩევადობა.

მოთხოვნის მაგალითი:

rtsp://172.16.31.61/1 მთავარი ნაკადი

rtsp://172.16.31.61/2 დამატებითი ნაკადი

რატომ გჭირდებათ დამატებითი თემა?

მრავალსურათიან ჩამწერთან დაკავშირებულ ადგილობრივ მონიტორზე, ჩამწერი იყენებს დამატებით ძაფს რესურსების დაზოგვის მიზნით. მაგალითად, 16 ფანჯრის მქონე პატარა სურათებში საერთოდ არ არის საჭირო Full HD გარჩევადობის გაშიფვრა, საკმარისია D1. ისე, თუ გახსენით 1/4/8 ფანჯრები, ამ შემთხვევაში მთავარი ნაკადი დეკოდირდება მაღალი გარჩევადობით.

სახელიმოწყობილობის პარამეტრების მიხედვით

პაროლიმოწყობილობის პარამეტრების მიხედვით

დეკოდერის ბუფერივიდეო ნაკადის ბუფერირება, რომელიც მიუთითებს დროის მნიშვნელობაზე

სერვერის ტიპი- TCP, UDP, განრიგი (ONVIF პროტოკოლის მსგავსი)

ეს სტატია პასუხობს ყველაზე გავრცელებულ კითხვებს, როგორიცაა:

თავსებადია IP კამერა NVR-თან?

და თუ თავსებადია, როგორ დავაკავშირო!?

RTSP პროტოკოლი

RTSP (Real Time Streaming Protocol, ან, რუსულ ენაზე, რეალურ დროში ნაკადის პროტოკოლი) არის აპლიკაციის პროტოკოლი, რომელიც აღწერს ბრძანებებს ვიდეო ნაკადის კონტროლისთვის. ამ ბრძანებების გამოყენებით ჩვენ შეგვიძლია „შეუკვეთოთ“ კამერა ან სერვერი, მაგალითად, ვიდეო ნაკადის მაუწყებლობის დაწყება. დაკვრის დაწყების მოთხოვნის მაგალითი ასე გამოიყურება: PLAY rtsp://192.168.0.200/h264 RTSP/1.0

ანუ, RTSP არის უბრალოდ ბრძანებების ნაკრები ვიდეო ნაკადის გასაკონტროლებლად. ჩავატაროთ ექსპერიმენტი. ამისათვის ჩვენ გვჭირდება IP კამერა, რომელიც მხარს უჭერს RTSP პროტოკოლს და მის RTSP მისამართს. ეს მისამართი ასე გამოიყურება: rtsp:// /მპეგ. თქვენ შეგიძლიათ იპოვოთ ის კამერის სახელმძღვანელოში ან API აღწერილობაში. მოხერხებულობისთვის, ჩვენ ჩამოვთვლით RTSP მისამართებს რამდენიმე პოპულარული კამერისთვის ცხრილში. მას შემდეგ რაც გავარკვიეთ კამერის RTSP მისამართი, ვხსნით სტანდარტულ პლეერს, რომელიც მხარს უჭერს RTSP-ს. ეს შეიძლება იყოს ერთ-ერთი შემდეგი პროგრამა: Windows Media Player, QuickTime, Media Player Classic, VLC მედია ფლეერი, RealPlayer, MPlayer. ჩვენ ავირჩიეთ QuickTime. გახსენით მენიუ "ფაილი > გახსნა URL" და შეიყვანეთ ჩვენი RTSP მისამართი. QuickTime შემდეგ დაუკავშირდება კამერას და დაუკრავს პირდაპირ ვიდეოს. ჩამწერი მოწყობილობები, რომლებიც მუშაობენ IP ვიდეოსათვალთვალო სისტემებში, იღებენ ვიდეოს კამერებიდან ან HTTP პროტოკოლის გამოყენებით - ანუ, ისევე, როგორც ჩვენ ვტვირთავთ JPEG სურათებს ვებსაიტებიდან, ან ნაკადის სახით RTSP-ის საშუალებით - ანუ, ისევე, როგორც მივიღეთ იგი სტანდარტის გამოყენებით. მოთამაშე ბოლო მაგალითში. IP კამერების პარამეტრებში, მონაცემთა გადაცემის ნაკადის ვარიანტი შეიძლება დაინიშნოს როგორც RTSP TCP-ზე, RTSP UDP-ზე ან უბრალოდ RTP. ასე რომ, RTSP არის ბრძანებების ნაკრები ნაკადის კონტროლისთვის. მაგრამ რას ნიშნავს სხვა აბრევიატურები: TCP, UDP, RTP? TCP, UDP და RTP არის სატრანსპორტო მექანიზმები (პროტოკოლები), რომლებიც რეალურად გადასცემენ ვიდეოს.

TCP პროტოკოლი

ვთქვათ, ჩვენ ავირჩიეთ RSTP მეთოდი TCP-ზე და გვინდა დავიწყოთ ვიდეო ნაკადის გადაცემა. რა მოხდება სატრანსპორტო მექანიზმების დონეზე? პირველი, რამდენიმე ბრძანების გამოყენებით, დამყარდება კავშირი გამგზავნსა და მიმღებს შორის. ამის შემდეგ დაიწყება ვიდეო მონაცემების გადაცემა. ამავე დროს, TCP მექანიზმები

უზრუნველყოფს, რომ ყველა მონაცემი მიმღებამდე მიაღწიოს ცვლილებების გარეშე და საჭირო თანმიმდევრობით. TCP ასევე დაარეგულირებს გადაცემის სიჩქარეს ისე, რომ გადამცემმა არ გაგზავნოს იმაზე მეტი მონაცემი, ვიდრე მიმღებს შეუძლია დაამუშავოს, მაგალითად,

UDP არის ტრანსპორტის ალტერნატივა TCP პროტოკოლი. TCP-ისგან განსხვავებით, UDP არ ამყარებს წინასწარ კავშირს, არამედ უბრალოდ იწყებს მონაცემთა გადაცემას. UDP არ დარწმუნდება, რომ მონაცემები მიღებულია და არ აორმაგებს მათ, თუ ნაწილები აკლია ან შეცდომით არის ჩამოსული. UDP ნაკლები

უფრო საიმედო ვიდრე TCP. მაგრამ მეორეს მხრივ, ის უზრუნველყოფს ნაკადების უფრო სწრაფ გადაცემას დაკარგული პაკეტების ხელახალი გადაცემის მექანიზმის არარსებობის გამო. განსხვავება TCP და UTP პროტოკოლებში შეიძლება აისახოს შემდეგი მაგალითით. ორი მეგობარი ხვდება. TCP ვარიანტი:

ივანე: ”გამარჯობა! ვისაუბროთ? (კავშირი დამყარდა)
სემიონი: ”გამარჯობა! მოდით!" (კავშირი დამყარდა)
ივანე: ”გუშინ მაღაზიაში ვიყავი. გესმის? (მონაცემთა გადაცემა)
სემიონი: "დიახ!" (დადასტურება)
ივანე: „იქ ჩამოიტვირთა ახალი ტექნიკა. გესმის? (მონაცემთა გადაცემა)
სემიონი: "არა" (დადასტურება)
ივანე: „იქ ჩამოიტვირთა ახალი ტექნიკა. გესმის? (ხელახალი გადაცემა)
სემიონი: "დიახ!" (დადასტურება)
ივანე: „ხვალ ისევ იქ ვიქნები. გესმის? (მონაცემთა გადაცემა)
სემიონი: "დიახ!" (დადასტურება)
UDP ვარიანტი
ივანე: ”გამარჯობა! გუშინ მაღაზიაში ვიყავი" (მონაცემთა გადაცემა)
ივანე: ”იქ გადმოიტვირთა ახალი აღჭურვილობა” (მონაცემთა გადაცემა)
ივანე: "ხვალ ისევ იქ ვიქნები" (მონაცემთა გადაცემა)
ივანე: ”მე შემიძლია გავარკვიო ფასები თქვენთვის” (მონაცემთა გადაცემა)
ივანე: ”ისინი დაპირდნენ ფასდაკლებას კარგი მოცულობისთვის” (მონაცემთა გადაცემა)
ივანე: "თუ გინდა, დარეკე - ჩვენ ერთად წავალთ" (მონაცემთა გადაცემა)
სემიონი: "დიახ, დავრეკავ" (მონაცემთა გადაცემა)

თქვენ ასევე შეგიძლიათ იხილოთ განსხვავება პროტოკოლებში შემდეგი ექსპერიმენტის ჩატარებით: სცადეთ კამერის დაყენება RTSP-ზე TCP რეჟიმში და ხელის ქნევა ლინზის წინ - დაინახავთ შეფერხებას მონიტორის ეკრანზე. ახლა გაუშვით იგივე ტესტი RTSP-ში UDP რეჟიმში. დაგვიანება ნაკლები იქნება. შეყოვნებაზე გავლენას ახდენს რამდენიმე ფაქტორი: შეკუმშვის ფორმატი, კომპიუტერის სიმძლავრე, გადაცემის პროტოკოლი და ვიდეოს გაშიფვრაში ჩართული პროგრამული უზრუნველყოფის მახასიათებლები.

RTP (რეალურ დროში სატრანსპორტო პროტოკოლი), ან რუსული რეალურ დროში სატრანსპორტო პროტოკოლით. ეს პროტოკოლი სპეციალურად შექმნილია რეალურ დროში ტრაფიკის გადასაცემად. ის საშუალებას გაძლევთ აკონტროლოთ გადაცემული მონაცემების სინქრონიზაცია, შეცვალოთ პაკეტის მიწოდების თანმიმდევრობა და, შესაბამისად, სხვებზე უფრო შესაფერისია ვიდეო და აუდიო მონაცემების გადასაცემად. ზოგადად, სასურველია გამოიყენოთ RTP ან UDP ვიდეო ნაკადის გადასაცემად. TCP-ით მუშაობა გამართლებულია მხოლოდ იმ შემთხვევაში, თუ ჩვენ მოგვიწევს მუშაობა პრობლემურ ქსელებთან, რადგან TCP პროტოკოლი შეძლებს შეასწოროს შეცდომები და წარუმატებლობები, რომლებიც წარმოიქმნება მონაცემთა გადაცემის დროს.

RTSP (რეალურ დროში სტრიმინგის პროტოკოლი)– რეალურ დროში ნაკადის პროტოკოლი, რომელიც შეიცავს მარტივ კომპლექტს ძირითადი ბრძანებებივიდეო ნაკადის გასაკონტროლებლად.

RTSP წყაროების და IP კამერების დაკავშირება ვიდეო კონფერენციებში

RTSP პროტოკოლი საშუალებას აძლევს ნებისმიერ TrueConf მომხმარებელს დაუკავშირდეს IP ვიდეო კამერებს და მედიის შინაარსის სხვა წყაროებს, რომლებიც მაუწყებლობს ამ პროტოკოლის გამოყენებით დისტანციური ობიექტების მონიტორინგისთვის. მომხმარებელს ასევე შეუძლია დაუკავშირდეს ასეთ კამერებს ვიდეო კონფერენციის დროს სურათების გადასაცემად.

RTSP პროტოკოლის მხარდაჭერის წყალობით, TrueConf სერვერის მომხმარებლებს შეუძლიათ არა მხოლოდ დაუკავშირდნენ IP კამერებს, არამედ გადაიტანონ ვიდეო კონფერენციები RTSP ფლეერებსა და მედია სერვერებზე. წაიკითხეთ მეტი RTSP მაუწყებლობის შესახებ.

IP კამერების გამოყენების უპირატესობები TrueConf პროგრამული გადაწყვეტილებებით

• საოფისე ან სამრეწველო სახელოსნოში IP კამერის დაყენებით და მასთან დაკავშირებით ნებისმიერ ხელსაყრელ დროს შეძლებთ აკონტროლოთ თქვენი კომპანიის წარმოების პროცესი.
• თქვენ შეგიძლიათ დისტანციური ობიექტების მონიტორინგი მთელი საათის განმავლობაში. მაგალითად, თუ შვებულებაში მიდიხართ და არ გსურთ თქვენი ბინის უყურადღებოდ დატოვება, უბრალოდ დააინსტალირეთ ერთი ან მეტი IP კამერა. ერთ-ერთ ამ კამერაზე დარეკვით თქვენი კომპიუტერიდან TrueConf კლიენტის აპლიკაციის დაყენებით, შეგიძლიათ ნებისმიერ დროს დაუკავშირდეთ თქვენს ბინას და რეალურ დროში ნახოთ რა ხდება იქ.
• Windows-ის, Linux-ისა და macOS-ის TrueConf კლიენტის აპლიკაციებში, ყველა მომხმარებელს აქვს წვდომა ვიდეო კონფერენციების ჩაწერის შესაძლებლობაზე, რომლის წყალობითაც ვიდეოთვალთვალის დროს შეგიძლიათ ჩაწეროთ ნებისმიერი მოვლენა და მიიღოთ მათი დოკუმენტური მტკიცებულებები.

ზოგიერთი ცნობით, დღეს არის ასობით მილიონი IP კამერები ვიდეო მეთვალყურეობისთვის. თუმცა, ვიდეოს დაკვრის შეფერხება არ არის კრიტიკული ყველა მათგანისთვის. ვიდეო მეთვალყურეობა, როგორც წესი, ხდება "სტატიკურად" - ნაკადი ჩაწერილია საცავში და შეიძლება გაანალიზდეს მოძრაობაზე. არსებობს მრავალი პროგრამული და აპარატურის გადაწყვეტა, რომელიც შემუშავებულია ვიდეო მეთვალყურეობისთვის, რომელიც კარგად ასრულებს თავის საქმეს.

ამ სტატიაში განვიხილავთ ოდნავ განსხვავებულ აპლიკაციას IP კამერები, კერძოდ, განაცხადი ონლაინ მაუწყებლებში, სადაც ეს საჭიროა დაბალი კომუნიკაციის შეფერხება.

უპირველეს ყოვლისა, მოდით გავარკვიოთ ნებისმიერი შესაძლო გაუგებრობა ტერმინოლოგიაში ვებკამერებისა და IP კამერების შესახებ.

ვებკამერაარის ვიდეო გადაღების მოწყობილობა, რომელსაც არ აქვს საკუთარი პროცესორი და ქსელის ინტერფეისი. ვებკამერა საჭიროებს კავშირს კომპიუტერთან, სმარტფონთან ან სხვა მოწყობილობასთან, რომელსაც აქვს ქსელის ბარათიდა პროცესორი.

IP კამერაარის დამოუკიდებელი მოწყობილობა, რომელსაც აქვს საკუთარი ქსელის ბარათი და პროცესორი გადაღებული ვიდეოს შეკუმშვისა და ქსელში გაგზავნისთვის. ამრიგად, IP კამერა არის დამოუკიდებელი მინი კომპიუტერი, რომელიც სრულად უკავშირდება ქსელს და არ საჭიროებს სხვა მოწყობილობასთან დაკავშირებას და შეუძლია პირდაპირ ქსელში გადაცემა.

დაბალი შეყოვნება(დაბალი შეყოვნება) საკმაოდ იშვიათი მოთხოვნაა IP კამერებისა და ონლაინ მაუწყებლებისთვის. დაბალი შეყოვნებით მუშაობის აუცილებლობა ჩნდება, მაგალითად, თუ ვიდეო ნაკადის წყარო აქტიურად ურთიერთობს ამ ნაკადის მნახველებთან.

ყველაზე ხშირად, დაბალი შეყოვნება საჭიროა თამაშების გამოყენების შემთხვევებში. მაგალითებია: რეალურ დროში ვიდეო აუქციონი, ვიდეო კაზინო პირდაპირ დილერთან, ინტერაქტიული ონლაინ სატელევიზიო შოუ წამყვანთან, დისტანციური მართვაკვადკოპტერი და ა.შ.

ცოცხალი ონლაინ კაზინოს დილერი სამსახურში.

ჩვეულებრივი RTSP IP კამერა ჩვეულებრივ აწვდის ვიდეოს H.264კოდეკი და შეუძლია იმუშაოს მონაცემთა გადაცემის ორ რეჟიმში: გადარეულიდა არაინტერლედირებული.

რეჟიმი გადარეულიყველაზე პოპულარული და მოსახერხებელი, რადგან ამ რეჟიმში ვიდეო მონაცემები გადაიცემა შიდა TCP პროტოკოლით ქსელის კავშირიკამერისკენ. IP კამერიდან გადანაწილებულზე გასავრცელებლად, თქვენ უბრალოდ უნდა გახსნათ/გააგზავნოთ კამერის ერთი RTSP პორტი (მაგალითად 554) გარეთ. პლეერს შეუძლია კამერასთან დაკავშირება მხოლოდ TCP-ის საშუალებით და აიღოს ნაკადი ამ კავშირის ფარგლებში.

მეორე კამერის მუშაობის რეჟიმი არის არაინტერლედირებული. ამ შემთხვევაში, კავშირი დამყარებულია პროტოკოლის გამოყენებით RTSP/TCP, ხოლო მოძრაობა პროტოკოლის მიხედვით ცალკე მიდის RTP/UDPშექმნილი TCP არხის გარეთ.

რეჟიმი არაინტერლედირებულიუფრო ხელსაყრელია ვიდეოს მაუწყებლობისთვის მინიმალური შეყოვნებით, რადგან ის იყენებს RTP/UDP, მაგრამ ამავე დროს უფრო პრობლემატურია, თუ მოთამაშე მდებარეობს უკან NAT.

NAT-ის უკან მდებარე მოთამაშის IP კამერასთან დაკავშირებისას, მოთამაშემ უნდა იცოდეს რომელი გარე IP მისამართები და პორტები შეუძლია გამოიყენოს აუდიო და ვიდეო ტრაფიკის მისაღებად. ეს პორტები მითითებულია SDP კონფიგურაციის ტექსტში, რომელიც იგზავნება კამერაზე RTSP კავშირის დამყარებისას. თუ NAT სწორად გაიხსნა და სწორი IP მისამართები და პორტები განისაზღვრა, მაშინ ყველაფერი იმუშავებს.

ასე რომ, იმისათვის, რომ კამერიდან ვიდეო აიღოთ მინიმალური დაგვიანებით, უნდა გამოიყენოთ არ ჩარევარეჟიმი და მიიღეთ ვიდეო ტრაფიკი UDP-ის საშუალებით.

ბრაუზერები არ უჭერენ მხარს RTSP/UDP პროტოკოლის დასტას პირდაპირ, მაგრამ მხარს უჭერენ ჩაშენებული ტექნოლოგიური პროტოკოლის დასტას. WebRTC.

ბრაუზერის და კამერის ტექნოლოგიები ძალიან ჰგავს, კერძოდ SRTPის დაშიფრულია RTP. მაგრამ ბრაუზერებში სწორი განაწილებისთვის, IP კამერას დასჭირდება WebRTC სტეკის ნაწილობრივი მხარდაჭერა.

ამ შეუთავსებლობის აღმოსაფხვრელად საჭიროა შუალედური სარელეო სერვერი, რომელიც იმოქმედებს როგორც ხიდი IP კამერის პროტოკოლებსა და ბრაუზერის პროტოკოლებს შორის.

სერვერი იღებს ნაკადს IP კამერიდან მეშვეობით RTP/UDPდა აგზავნის მას დაკავშირებულ ბრაუზერებში WebRTC-ის საშუალებით.

WebRTC ტექნოლოგია მუშაობს პროტოკოლის მიხედვით UDPდა ამით უზრუნველყოფს დაბალ დაყოვნებას მიმართულებით სერვერი > ბრაუზერი. IP კამერა ასევე მუშაობს პროტოკოლის გამოყენებით RTP/UDPდა უზრუნველყოფს დაბალ დაყოვნებას მიმართულებით კამერა > სერვერი.

კამერას შეუძლია შეზღუდული რაოდენობის ნაკადების გამოშვება შეზღუდული რესურსებისა და გამტარუნარიანობის გამო. შუალედური სერვერის გამოყენება საშუალებას გაძლევთ გააფართოვოთ მაუწყებლობა IP კამერიდან დიდი რაოდენობამაყურებლები.

მეორეს მხრივ, სერვერის გამოყენებისას ჩართულია ორი საკომუნიკაციო ფეხი:
1) მაყურებელსა და სერვერს შორის
2) სერვერსა და კამერას შორის
ამ ტოპოლოგიას აქვს მთელი რიგი "მახასიათებელი" ან "ხაფანგები". ჩვენ ჩამოვთვლით მათ ქვემოთ.

Pitfall #1 - კოდეკები

გამოყენებული კოდეკები შეიძლება იყოს დაბრკოლება დაბალი შეყოვნების შესრულებისთვის და შეიძლება გააუარესოს სისტემის მთლიანი შესრულება.

მაგალითად, თუ კამერა გამოსცემს 720p ვიდეო ნაკადს H.264-ში და Chrome ბრაუზერი დაკავშირებულია ანდროიდის სმარტფონიმხოლოდ VP8-ის მხარდაჭერით.

როდესაც ტრანსკოდირება ჩართულია, ტრანსკოდირების სესია უნდა შეიქმნას თითოეული დაკავშირებული IP კამერისთვის, რომელიც დეკოდირებს H.264და შიფრავს VP8. ამ შემთხვევაში, 16 ბირთვიანი ორმაგი პროცესორიანი სერვერი შეძლებს მხოლოდ 10-15 IP კამერის მომსახურებას, დაახლოებით 1 კამერა ფიზიკურ ბირთვზე.

ამიტომ, თუ სერვერის სიმძლავრე არ იძლევა კამერების დაგეგმილი რაოდენობის ტრანსკოდირების საშუალებას, მაშინ ტრანსკოდირება თავიდან უნდა იქნას აცილებული. მაგალითად, ემსახურეთ მხოლოდ ბრაუზერებს, რომლებიც მხარს უჭერენ H.264-ს და შესთავაზეთ სხვებს გამოიყენონ მშობლიური მობილური აპლიკაცია iOS ან Android-ისთვის, სადაც არის H.264 კოდეკის მხარდაჭერა.

როგორც ტრანსკოდირების გვერდის ავლით შიგნით მობილური ბრაუზერი, შეიძლება გამოყენებულ იქნას H.L.S.. მაგრამ HTTP სტრიმინგს საერთოდ არ აქვს დაბალი შეყოვნება და ამჟამად არ შეიძლება გამოყენებულ იქნას ინტერაქტიული მაუწყებლებისთვის.

პრობლემა #2 - კამერის ბიტის სიხშირე და დაკარგვა

UDP პროტოკოლი ეხმარება გაუმკლავდეს შეყოვნებას, მაგრამ იძლევა ვიდეო პაკეტების დაკარგვის საშუალებას. ამიტომ, მიუხედავად დაბალი შეყოვნებისა, თუ ქსელში დიდი დანაკარგებია კამერასა და სერვერს შორის, სურათი შეიძლება დაზიანდეს.

დანაკარგების აღმოსაფხვრელად, თქვენ უნდა დარწმუნდეთ, რომ კამერის მიერ წარმოქმნილ ვიდეო ნაკადს აქვს ბიტრეიტი, რომელიც ჯდება კამერასა და სერვერს შორის გამოყოფილი გამტარუნარიანობისთვის.

Pitfall #3 - მაყურებლის ბიტრეიტი და დანაკარგები

სერვერთან დაკავშირებულ თითოეულ სამაუწყებლო მაყურებელს ასევე აქვს სპეციფიკური გამტარუნარიანობაჩამოტვირთვაზე.

თუ IP კამერა აგზავნის ნაკადს, რომელიც აღემატება მაყურებლის არხის შესაძლებლობებს (მაგალითად, კამერა აგზავნის 1 Mbps, და მაყურებელს შეუძლია მხოლოდ მიიღოს 500 Kbps), მაშინ იქნება დიდი დანაკარგები ამ არხზე და, შედეგად, ვიდეოს გაყინვა ან ძლიერი არტეფაქტები.

ამ შემთხვევაში სამი ვარიანტია:

1. ვიდეოს ნაკადის ტრანსკოდირება ინდივიდუალურად თითოეული მაყურებლისთვის საჭირო ბიტური სიჩქარით.
2. Transcode სტრიმინგები არა თითოეული დაკავშირებული ადამიანისთვის, არამედ მაყურებელთა ჯგუფისთვის.
3. წინასწარ მოამზადეთ კამერის ნაკადები რამდენიმე გარჩევადობითა და ბიტის სიჩქარით.

პირველი ვარიანტიტრანსკოდირებით არ არის შესაფერისი თითოეული მაყურებლისთვის, რადგან ის მოიხმარს CPU რესურსებს თუნდაც 10-15 დაკავშირებული მაყურებლით. თუმცა უნდა აღინიშნოს, რომ ეს ვარიანტი უზრუნველყოფს მაქსიმალურ მოქნილობას CPU მაქსიმალური დატვირთვით. იმათ. ეს იდეალური ვარიანტია, მაგალითად, თუ სტრიმინგს ავრცელებთ მხოლოდ 10 გეოგრაფიულად განაწილებულ ადამიანზე, თითოეული მათგანი იღებს დინამიურ ბიტრეიტს და თითოეულ მათგანს სჭირდება მინიმალური შეყოვნება.

მეორე ვარიანტიარის სერვერის CPU-ზე დატვირთვის შემცირება ტრანსკოდირების ჯგუფების გამოყენებით. სერვერი ქმნის რამდენიმე ჯგუფს ბიტური სიჩქარით, მაგალითად ორი:

• 200 Kbps
• 1 Mbps

თუ მაყურებელს არ აქვს საკმარისი გამტარობა, ის გადადის ჯგუფში, რომელშიც კომფორტულად მიიღებს ვიდეო ნაკადს. ამრიგად, ტრანსკოდირების სესიების რაოდენობა არ უდრის მაყურებელთა რაოდენობას, როგორც პირველ შემთხვევაში, მაგრამ არის ფიქსირებული რიცხვი, მაგალითად 2, თუ ჯგუფების ტრანსკოდირება ხდება. ორი.

მესამე ვარიანტიგულისხმობს სერვერის მხრიდან ტრანსკოდირების სრულ უარყოფას და უკვე მომზადებული ვიდეო ნაკადების გამოყენებას სხვადასხვა რეზოლუციითა და ბიტის სიჩქარით. ამ შემთხვევაში, კამერა კონფიგურირებულია ორი ან სამი ნაკადის გამოსასვლელად სხვადასხვა რეზოლუციით და ბიტის სიჩქარით, და მაყურებლები გადადიან ამ ნაკადებს შორის მათი გამტარუნარიანობის მიხედვით.

ამ შემთხვევაში, სერვერზე ტრანსკოდირების დატვირთვა მიდის და გადადის თავად კამერაზე, რადგან კამერა ახლა იძულებულია დაშიფვროს ორი ან მეტი ნაკადი ერთის ნაცვლად.

შედეგად, ჩვენ განვიხილეთ სამი ვარიანტი მაყურებლის გამტარუნარიანობის მორგებისთვის. თუ ვივარაუდებთ, რომ ერთი ტრანსკოდირების სესია იკავებს 1 სერვერის ბირთვს, მაშინ მივიღებთ შემდეგ CPU დატვირთვის ცხრილს:

ცხრილი აჩვენებს, რომ ჩვენ შეგვიძლია გადავიტანოთ ტრანსკოდირების დატვირთვა კამერაზე ან ტრანსკოდირების გადატანა სერვერზე. მე-2 და მე-3 ვარიანტები, როგორც ჩანს, ყველაზე ოპტიმალურია.

ტესტირება RTSP როგორც WebRTC

დადგა დრო, ჩავატაროთ რამდენიმე ტესტი, რათა დადგინდეს რეალური სურათი იმისა, რაც ხდება. ავიღოთ რეალური IP კამერა და ჩავატაროთ ტესტირება მაუწყებლობის შეყოვნების გასაზომად.

ტესტირებისთვის ავიღოთ უძველესი IP კამერა D-link DCS-2103მხარდაჭერით RTSPდა კოდეკები H.264 და G.711.

იმის გამო, რომ კამერა დიდი ხნის განმავლობაში იწვა კარადაში სხვა სასარგებლო მოწყობილობებთან და სადენებთან ერთად, მომიწია მისი გაგზავნა გადატვირთვაკამერის უკანა ღილაკზე დაჭერით 10 წამის განმავლობაში.

ქსელთან დაკავშირების შემდეგ კამერაზე მწვანე შუქი აინთო და როუტერმა სხვა მოწყობილობა დაინახა ლოკალური ქსელი IP მისამართით 192.168.1.37.

ჩვენ მივდივართ კამერის ვებ ინტერფეისზე და ვაყენებთ კოდეკებს და რეზოლუციას ტესტირებისთვის:

შემდეგ მივდივართ ქსელის პარამეტრებიდა გაიგეთ კამერის RTSP მისამართი. ამ შემთხვევაში, RTSP მისამართი live1.sdp, ე.ი. კამერა ხელმისაწვდომია მისამართზე rtsp://192.168.1.37/live1.sdp

კამერის ხელმისაწვდომობა მარტივად შეიძლება შემოწმდეს გამოყენებით VLC პლეერი. მედია - ღია ქსელის ნაკადი.

ჩვენ დავრწმუნდით, რომ კამერა მუშაობს და გადასცემს ვიდეოს RTSP-ის საშუალებით.

ჩვენ გამოვიყენებთ Web Call Server 5-ს, როგორც სერვერს ტესტირებისთვის. ეს არის სტრიმინგის სერვერი მხარდაჭერით RTSP და WebRTCპროტოკოლები. ის დაუკავშირდება IP კამერას მეშვეობით RTSPდა აიღეთ ვიდეო ნაკადი. შემდეგი, გაანაწილეთ ნაკადი WebRTC.

ინსტალაციის შემდეგ, თქვენ უნდა გადართოთ სერვერი RTSP რეჟიმში არაინტერლედირებულირომელიც ზემოთ ვისაუბრეთ. ეს შეიძლება გაკეთდეს პარამეტრის დამატებით

Rtsp_interleaved_mode=false
ეს პარამეტრი ემატება flashphoner.properties კონფიგურაციას და საჭიროებს სერვერის გადატვირთვას:

სერვისის ვებ ზარის სერვერის გადატვირთვა
ამრიგად, ჩვენ გვაქვს სერვერი, რომელიც მუშაობს არაინტერლევადი სქემის მიხედვით, იღებს პაკეტებს IP კამერიდან UDP-ის საშუალებით და შემდეგ ავრცელებს მათ WebRTC (UDP) მეშვეობით.

სატესტო სერვერი მდებარეობს VPS სერვერზე, რომელიც მდებარეობს ფრანკფურტის მონაცემთა ცენტრში, აქვს 2 ბირთვი და 2 გიგაბაიტი ოპერატიული მეხსიერება.

კამერა მდებარეობს ლოკალურ ქსელში 192.168.1.37.

ამიტომ, პირველი რაც უნდა გავაკეთოთ არის 554 პორტის გადაგზავნა 192.168.1.37 მისამართზე შემომავალისთვის TCP/RTSPკავშირები, რათა სერვერმა დაამყაროს კავშირი ჩვენს IP კამერასთან. ამისათვის დაამატეთ მხოლოდ ერთი წესი როუტერის პარამეტრებში:

წესი ეუბნება როუტერს გადამისამართოს ყველა შემომავალი ტრაფიკი პორტში 554 და IP მისამართი 37-ზე.

თუ თქვენ გაქვთ მეგობრული NAT და იცით გარე IP მისამართი, მაშინ შეგიძლიათ დაიწყოთ ტესტირება სერვერთან.

სტანდარტული დემო პლეერი ბრაუზერში Google Chromeასე გამოიყურება:

RTSP ნაკადის დაკვრის დასაწყებად, თქვენ უბრალოდ უნდა შეიყვანოთ მისი მისამართი ველში ნაკადი.
ამ შემთხვევაში, ნაკადის მისამართია: rtsp://ip-cam/live1.sdp
აქ IP-კამერაეს არის თქვენი კამერის გარე IP მისამართი. სერვერი შეეცდება დაამყაროს კავშირი ამ მისამართზე.

შეყოვნების ტესტირება VLC vs WebRTC

მას შემდეგ რაც ჩვენ დავაკონფიგურირეთ IP კამერა და შევამოწმეთ იგი VLC, სერვერის კონფიგურაცია და ტესტირება RTSPგადინება სერვერზე განაწილებით WebRTCსაბოლოოდ შეგვიძლია შევადაროთ შეყოვნება.

ამისათვის ჩვენ გამოვიყენებთ ტაიმერს, რომელიც აჩვენებს წამის ნაწილებს მონიტორის ეკრანზე. ჩართეთ ტაიმერი და ერთდროულად დაუკარით ვიდეო ნაკადი VLC ადგილობრივადდა ზე Firefox ბრაუზერიდისტანციური სერვერის საშუალებით.

Ping სერვერზე 100 ms.
Ping ადგილობრივად 1 ms.

პირველი ტესტი ტაიმერის გამოყენებით ასე გამოიყურება:
შავ ფონზე არის ორიგინალური ტაიმერი, რომელიც აჩვენებს ნულოვან დაყოვნებას. მარცხენა VLC, უფლება Firefox, მიღება WebRTCნაკადი დისტანციური სერვერიდან.

	ნულოვანი	VLC	Firefox, WCS
დრო	50.559	49.791	50.238
შეყოვნება ms	0	768	321

ამ ტესტში ჩვენ ვხედავთ დაგვიანებას VLCორჯერ მეტი დაგვიანებით Firefox + ვებ ზარის სერვერი, იმისდა მიუხედავად, რომ VLC-ში ვიდეო უკრავს ლოკალურ ქსელში, ხოლო ვიდეო, რომელიც ნაჩვენებია Firefox-ში, გადის სერვერზე გერმანიაში მონაცემთა ცენტრში და ბრუნდება უკან. ეს შეუსაბამობა შეიძლება გამოწვეული იყოს იმით, რომ VLC მუშაობს TCP-ზე (interleaved რეჟიმი) და შეიცავს დამატებით ბუფერებს ვიდეოს გლუვი დაკვრისთვის.

ჩვენ გადავიღეთ რამდენიმე სურათი ლატენტური მნიშვნელობების ჩასაწერად.