ზოგიერთი ცნობით, დღეს არის ასობით მილიონი 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 ბრაუზერზე Android სმარტფონზე მხოლოდ 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), მაშინ იქნება დიდი დანაკარგები ამ არხზე და, შედეგად, ვიდეოს გაყინვა ან ძლიერი არტეფაქტები.
ამ შემთხვევაში სამი ვარიანტია:
- ვიდეოს ნაკადის ტრანსკოდირება ინდივიდუალურად თითოეული მაყურებლისთვის საჭირო ბიტური სიჩქარით.
- Transcode სტრიმინგები არა თითოეული დაკავშირებული ადამიანისთვის, არამედ მაყურებელთა ჯგუფისთვის.
- წინასწარ მოამზადეთ კამერის ნაკადები რამდენიმე გარჩევადობითა და ბიტის სიჩქარით.
მეორე ვარიანტიარის სერვერის CPU-ზე დატვირთვის შემცირება ტრანსკოდირების ჯგუფების გამოყენებით. სერვერი ქმნის რამდენიმე ჯგუფს ბიტური სიჩქარით, მაგალითად ორი:
- 200 Kbps
- 1 Mbps
მესამე ვარიანტიგულისხმობს სერვერის მხრიდან ტრანსკოდირების სრულ უარყოფას და უკვე მომზადებული ვიდეო ნაკადების გამოყენებას სხვადასხვა რეზოლუციითა და ბიტის სიჩქარით. ამ შემთხვევაში, კამერა კონფიგურირებულია ორი ან სამი ნაკადის გამოსასვლელად სხვადასხვა გარჩევადობითა და ბიტის სიჩქარით და მაყურებლები გადადიან ამ ნაკადებს შორის მათი გამტარუნარიანობის მიხედვით.
ამ შემთხვევაში, სერვერზე ტრანსკოდირების დატვირთვა მიდის და გადადის თავად კამერაზე, რადგან კამერა ახლა იძულებულია დაშიფვროს ორი ან მეტი ნაკადი ერთის ნაცვლად.
შედეგად, ჩვენ განვიხილეთ სამი ვარიანტი მაყურებლის გამტარუნარიანობის მორგებისთვის. თუ ვივარაუდებთ, რომ ერთი ტრანსკოდირების სესია იკავებს 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 |
ჩვენ გადავიღეთ რამდენიმე სურათი ლატენტური მნიშვნელობების ჩასაწერად.
ხშირად ჩნდება კითხვა: როგორ დავუკავშიროთ IP კამერა NVR-ს, თუ ის არ არის თავსებადობის სიაში?
ორი ვარიანტია ONVIF და RTSP
დავიწყოთ ONVIF პროტოკოლით (ღია ქსელის ვიდეო ინტერფეისის ფორუმი)
ONVIF არის ზოგადად მიღებული პროტოკოლი IP კამერების, NVR-ების, პროგრამული უზრუნველყოფის ერთობლივი მუშაობისთვის, იმ შემთხვევაში, თუ ყველა მოწყობილობა არის სხვადასხვა მწარმოებლისგან. ONVIF შეიძლება შევადაროთ ინგლისურ ენას ადამიანთა საერთაშორისო კომუნიკაციისთვის.
დარწმუნდით, რომ დაკავშირებული მოწყობილობები მხარს უჭერენ ONVIF-ს; ზოგიერთ მოწყობილობაზე ONVIF შეიძლება გამორთული იყოს ნაგულისხმევად.
ან ONVIF ავტორიზაცია შეიძლება გამორთული იყოს, რაც ნიშნავს, რომ შესვლა/პაროლი ყოველთვის იქნება ნაგულისხმევად
WEB-ისთვის შესვლის/პაროლის მიუხედავად 
ასევე აღსანიშნავია, რომ ზოგიერთი მოწყობილობა იყენებსცალკე პორტი ONVIF პროტოკოლით მუშაობისთვის
ზოგიერთ შემთხვევაში, ONVIF პაროლი შეიძლება განსხვავდებოდეს WEB წვდომის პაროლისგან.
რა არის ხელმისაწვდომი ONVIF-ის საშუალებით დაკავშირებისას?
მოწყობილობის აღმოჩენა
ვიდეო გადაცემა
აუდიო მონაცემების მიღება და გადაცემა
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-ის გამოყენებით
.jpg)
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-თან?
და თუ თავსებადია, როგორ დავაკავშირო!?
IP კამერიდან ონლაინ მაუწყებლობის პრობლემის გადაჭრა, ზოგადად, არ საჭიროებს WebRTC-ის გამოყენებას. კამერა თავად არის სერვერი, აქვს IP მისამართი და შეიძლება პირდაპირ დაუკავშირდეს როუტერს ვიდეო კონტენტის გასავრცელებლად. რატომ გამოვიყენოთ WebRTC ტექნოლოგია?
ამის მინიმუმ ორი მიზეზი არსებობს:
1. Ethernet მაუწყებლობის მაყურებელთა რაოდენობის მატებასთან ერთად, ჯერ არხის სისქის ნაკლებობა იგრძნობა, შემდეგ კი თავად კამერის რესურსები.
2. როგორც ზემოთ აღინიშნა, IP კამერა არის სერვერი. მაგრამ რა პროტოკოლების გამოყენება შეუძლია მას დესკტოპის ბრაუზერში ვიდეოს გასაგზავნად? Მობილური მოწყობილობა? სავარაუდოდ, ეს იქნება HTTP ნაკადი, სადაც ვიდეო ჩარჩოები ან JPEG სურათები გადაიცემა HTTP-ის საშუალებით. HTTP სტრიმინგი, როგორც მოგეხსენებათ, სრულებით არ არის შესაფერისი რეალურ დროში ვიდეო სტრიმინგისთვის, თუმცა მან კარგად დაამტკიცა თავი მოთხოვნაზე ვიდეოში, სადაც ნაკადის ინტერაქტიულობა და შეყოვნება არ არის განსაკუთრებით მნიშვნელოვანი. სინამდვილეში, თუ ფილმს უყურებთ, რამდენიმე წამის დაყოვნება არ გააუარესებს მას, თუ ფილმს სხვასთან ერთად არ უყურებთ. "Ო არა! ჯეკმა მოკლა! - ალისა სპოილერს უწერს ჩატში ბობს ტრაგიკულ დასასრულამდე 10 წამით ადრე.
ან ეს იქნება RTSP/RTP და H.264, ამ შემთხვევაში ბრაუზერში უნდა იყოს დაინსტალირებული ვიდეო პლეერის დანამატი, როგორიცაა VLC ან QuickTime. ასეთი მოდული გადაიღებს და დაუკრავს ვიდეოს, ისევე როგორც თავად პლეერი. მაგრამ ჩვენ გვჭირდება რეალური ბრაუზერზე დაფუძნებული ნაკადი დამატებითი ხელჯოხების/დამატებების დაყენების გარეშე.
პირველ რიგში, მოდით გადავიღოთ IP კამერის სურათი, რათა გავარკვიოთ, რას აგზავნის ეს მოწყობილობა ბრაუზერის მიმართ. ტესტის საგანი იქნება D-Link DCS 7010L კამერა:
თქვენ შეგიძლიათ წაიკითხოთ მეტი კამერის ინსტალაციისა და კონფიგურაციის შესახებ ქვემოთ, მაგრამ აქ ჩვენ უბრალოდ გადავხედავთ, თუ რას იყენებს ის ვიდეო ნაკადისთვის. ვებ – ინტერფეისის საშუალებით კამერის ადმინისტრაციულ პანელში შესვლისას, ჩვენ ვხედავთ მსგავს რაღაცას (ბოდიში ლანდშაფტისთვის):
სურათი იხსნება ყველა ბრაუზერში და იყინება თანაბრად, დაახლოებით წამში ერთხელ. იმის გათვალისწინებით, რომ კამერაც და ლეპტოპიც, რომელზედაც ჩვენ ვუყურებთ სტრიმინგს, დაკავშირებულია ერთსა და იმავე როუტერთან, ყველაფერი უნდა იყოს გლუვი და ლამაზი, მაგრამ ეს ასე არ არის. HTTP-ს ჰგავს. მოდით გავუშვათ Wireshark ჩვენი ვარაუდების დასადასტურებლად:
აქ ჩვენ ვხედავთ TCP ფრაგმენტების თანმიმდევრობას 1514 ბაიტი სიგრძით
და საბოლოო HTTP 200 OK მიღებული JPEG სიგრძით:
ჩვენ არ გვჭირდება ასეთი ნაკადი. არ არის გლუვი, უხერხულია HTTP მოთხოვნები. რამდენ ასეთ მოთხოვნას შეუძლია წამში კამერა? არსებობს საფუძველი იმის დასაჯერებლად, რომ 10 მაყურებელზე ან უფრო ადრე, კამერა უსაფრთხოდ მოხრილდება ან დაიწყებს საშინლად რყევას და წარმოქმნის სლაიდებს.
თუ გადახედავთ კამერის ადმინისტრაციული პანელის HTML გვერდს, ნახავთ ამ საინტერესო კოდს:
თუ (ბრაუზერი_IE) DW (""); სხვა (if(mpMode == 1) var RTSPName = g_RTSPName1; სხვა შემთხვევაში if(mpMode == 2) var RTSPName = g_RTSPName2; სხვა შემთხვევაში if(mpMode == 3) var RTSPName = g_RTSPName3; var o=""; თუ (g_isIPv6) //რადგან ipv6 არ უჭერს მხარს rtsp. var host = g_netip; სხვა var host = g_host; o+=""; //გაფრთხილება(o); DW(o); )
RTSP/RTP არის ზუსტად ის, რაც გჭირდებათ ვიდეოს სათანადო დაკვრისთვის. მაგრამ იმუშავებს ეს ბრაუზერში? - არა. მაგრამ თუ დააინსტალირებთ QuickTime მოდულს, ყველაფერი იმუშავებს. მაგრამ ჩვენ ვაკეთებთ მხოლოდ ბრაუზერზე დაფუძნებულ სტრიმინგს.
აქ ასევე შეგვიძლია აღვნიშნოთ Flash Player, რომელსაც შეუძლია Wowza-ს მსგავსი სერვერის საშუალებით მიიღოს RTMP ნაკადი, რომელიც კონვერტირდება RTSP, RTP, H.264-დან. მაგრამ Flash Player, როგორც მოგეხსენებათ, ასევე არის ბრაუზერის მოდული, თუმცა ის შეუდარებლად უფრო პოპულარულია ვიდრე VLC ან QuickTime.
ამ შემთხვევაში, ჩვენ შევამოწმებთ იგივე RTSP/RTP გადაცემას, მაგრამ WebRTC-თან თავსებადი ბრაუზერი გამოყენებული იქნება როგორც სათამაშო მოწყობილობა დამატებითი ბრაუზერის დანამატების ან სხვა ხელჯოხების გარეშე. ჩვენ დავაყენებთ სარელეო სერვერს, რომელიც აიღებს სტრიმინგს IP კამერიდან და გაუგზავნის ინტერნეტში მომხმარებელთა თვითნებურ რაოდენობას WebRTC-ის მხარდაჭერილი ბრაუზერების გამოყენებით.
IP კამერის დაკავშირება
როგორც ზემოთ აღინიშნა, ტესტირებისთვის არჩეული იყო მარტივი D-Link DCS-7010L IP კამერა. აქ მთავარი შერჩევის კრიტერიუმი იყო მოწყობილობის მხარდაჭერა RTSP პროტოკოლისთვის, რადგან სწორედ ამის მეშვეობით ჩვენი სერვერი მიიღებს ვიდეო ნაკადს კამერიდან.ჩვენ ვუკავშირდებით კამერას როუტერს თანდართული პაჩ კაბელის გამოყენებით. დენის ჩართვისა და როუტერთან დაკავშირების შემდეგ კამერამ DHCP-ით აიღო IP მისამართი, ჩვენს შემთხვევაში ეს იყო 192.168.1.34 (როუტერის პარამეტრებზე რომ გადახვიდეთ, დაინახავთ, რომ DCS 7010L მოწყობილობა არის დაკავშირებული - ესე იგი. ). დროა შეამოწმოთ კამერა.
გახსენით მითითებული IP მისამართი ბრაუზერში 192.168.1.34, რომ მოხვდეთ კამერის ადმინისტრატორის ვებ ინტერფეისში. სტანდარტულად, პაროლი არ არის.
როგორც ხედავთ, ვიდეო კამერიდან სწორად გადაიცემა ადმინისტრაციულ პანელში. ამავდროულად, შესამჩნევია პერიოდული შერყევა. ეს არის ის, რასაც ჩვენ გამოვასწორებთ WebRTC-ის გამოყენებით.
კამერის დაყენება
პირველ რიგში, ჩვენ გავთიშავთ ავტორიზაციას კამერის პარამეტრებში - როგორც ტესტირების ნაწილი, ჩვენ მივცემთ ნაკადს ყველას, ვინც ითხოვს. ამისათვის გადადით პარამეტრებზე კამერის ვებ ინტერფეისში დაყენება - ქსელიდა დააყენეთ ვარიანტის მნიშვნელობა ავთენტიფიკაცია გამორთვაზე.ჩვენ ასევე ვამოწმებთ RTSP პროტოკოლის პორტის მნიშვნელობას, ნაგულისხმევად არის 554. გადაცემული ვიდეოს ფორმატი განისაზღვრება გამოყენებული პროფილის მიხედვით. თქვენ შეგიძლიათ დააყენოთ სამი მათგანი კამერაში, ჩვენ გამოვიყენებთ პირველს, live1.sdp - ნაგულისხმევად კონფიგურირებულია გამოიყენოს H.264 ვიდეოსთვის და G.711 აუდიოსთვის. საჭიროების შემთხვევაში შეგიძლიათ შეცვალოთ პარამეტრები განყოფილებაში დაყენება - აუდიო და ვიდეო.
ახლა თქვენ შეგიძლიათ შეამოწმოთ კამერის მოქმედება RTSP-ის საშუალებით. გახსენით VLC Player (შეგიძლიათ გამოიყენოთ ნებისმიერი სხვა პლეერი, რომელიც მხარს უჭერს RTSP - QuickTime, Windows Media Player, RealPlayer და ა.შ.) და Open URL დიალოგში დააყენეთ კამერის RTSP მისამართი: rtsp://192.168.1.34/live1.sdp
ისე, ყველაფერი მუშაობს ისე, როგორც უნდა. კამერა რეგულარულად აწარმოებს ვიდეო ნაკადს პლეერში RTSP პროტოკოლის მეშვეობით.
სხვათა შორის, სტრიმინგი საკმაოდ შეუფერხებლად და არტეფაქტების გარეშე მიმდინარეობს. ჩვენ იგივეს ველით WebRTC-ისგან.
სერვერის ინსტალაცია
ასე რომ, კამერა დამონტაჟებულია, ტესტირება დესკტოპის პლეერებთან და მზად არის სერვერის საშუალებით მაუწყებლობისთვის. whatismyip.com-ის გამოყენებით ჩვენ განვსაზღვრავთ კამერის გარე IP მისამართს. ჩვენს შემთხვევაში ეს იყო 178.51.142.223. რჩება მხოლოდ როუტერს ვუთხრათ, რომ 554 პორტზე RTSP-ით წვდომისას, შემომავალი მოთხოვნები გადაეცემა IP კამერას.შეიყვანეთ შესაბამისი პარამეტრები როუტერში...
...და შეამოწმეთ გარე IP მისამართი და RTSP პორტი ტელნეტის გამოყენებით:
ტელნეტი 178.51.142.223 554
მას შემდეგ რაც დავრწმუნდით, რომ არის პასუხი ამ პორტზე, ჩვენ ვაგრძელებთ WebRTC სერვერის ინსტალაციას.
ვირტუალური სერვერი Centos 64 ბიტიან Amazon EC2-ზე პასუხისმგებელი იქნება ჰოსტინგზე.
შესრულების პრობლემების თავიდან ასაცილებლად, ჩვენ ავირჩიეთ m3.medium ინსტანცია ერთი VCPU-ით:
დიახ, დიახ, ასევე არის Linode და DigitalOcean, მაგრამ ამ შემთხვევაში მინდოდა ამაზონის გამოცდა.
წინ რომ ვიხედები, დავწერ, რომ Amazon EC2 მართვის პანელში თქვენ უნდა დაამატოთ რამდენიმე წესი (წინა პორტები), რომელთა გარეშეც მაგალითი არ იმუშავებს. ეს არის პორტები WebRTC (SRTP, RTCP, ICE) ტრაფიკისთვის და პორტები RTSP/RTP ტრაფიკისთვის. თუ ცდილობთ, ამაზონის წესებს მსგავსი უნდა ჰქონდეს შემომავალი ტრაფიკისთვის:
სხვათა შორის, DigitalOcean-ით ყველაფერი უფრო მარტივი იქნება, უბრალოდ გახსენით ეს პორტები firewall-ზე ან გამორთეთ ეს უკანასკნელი. DO ინსტანციების მუშაობის უახლესი გამოცდილების თანახმად, ისინი კვლავ გასცემენ სტატიკური IP მისამართს და არ აწუხებენ NAT-ებს, რაც ნიშნავს, რომ პორტის გადაგზავნა, როგორც ამაზონის შემთხვევაში, არ არის საჭირო.
ჩვენ გამოვიყენებთ WebRTC Media & Broadcasting Server-ს Flashphoner-ისგან, როგორც სერვერის პროგრამულ უზრუნველყოფას, რომელიც გადასცემს RTSP/RTP ნაკადს WebRTC-ზე. ნაკადის სერვერი ძალიან ჰგავს Wowza-ს, რომელსაც შეუძლია RTSP/RTP ნაკადის გადაცემა Flash-ზე. ერთადერთი განსხვავება ისაა, რომ ეს ნაკადი გაიგზავნება WebRTC-ზე და არა Flash-ზე. იმათ. გულწრფელი DTLS გაივლის ბრაუზერსა და სერვერს შორის, შეიქმნება SRTP სესია და VP8-ში კოდირებული ნაკადი გადავა მაყურებელზე.
ინსტალაციისთვის დაგვჭირდება SSH წვდომა.
სპოილერის ქვემოთ მოცემულია შესრულებული ბრძანებების დეტალური აღწერა
1. ჩამოტვირთეთ სერვერის ინსტალაციის არქივი:
$wget flashphoner.com/downloads/builds/WCS/3.0/x8664/wcs3_video_vp8/FlashphonerMediaServerWebRTC-3.0/FlashphonerMediaServerWebRTC-3.0.868.tar.gz
2. გაფართოებული:
$tar -xzf FlashphonerMediaServerWebRTC-3.0.868.tar.gz
3. დაინსტალირებულია:
$cd FlashphonerMediaServerWebRTC-3.0.868
$./install.sh
ინსტალაციის პროცესში შევიყვანეთ სერვერის გარე IP მისამართი: 54.186.112.111 და შიდა 172.31.20.65 (იგივე Private IP).
4. სერვერის გაშვება:
$service ვებ ზარის სერვერის დაწყება
5. შეამოწმეთ ჟურნალები:
$tail - f /usr/local/FlashphonerWebCallServer/logs/server_logs/flashphoner.log
6. დარწმუნდით, რომ სერვერი დაწყებულია და მზად არის სამუშაოდ:
$ps aux | grep ფლეშფონერი
7. დაინსტალირებული და გაშვებული apache:
$yum დააინსტალირე httpd
$service httpd დაწყება
8. ჩამოტვირთეთ ვებ ფაილები და მოათავსეთ ისინი სტანდარტულ Apache საქაღალდეში /var/www/html
cd /var/www/html
$wget github.com/flashphoner/flashphoner_client/archive/wcs_media_client.zip
$unzip webrtc_media_client.zip
9. შეიყვანეთ სერვერის IP მისამართი flashphoner.xml კონფიგურაციაში:
10. გააჩერა firewall.
$service iptables შეჩერებულია
თეორიულად, მე-10 პუნქტის ნაცვლად, სწორი იქნებოდა ყველა საჭირო პორტის და firewall-ის წესების დაყენება, მაგრამ ტესტირების მიზნით ჩვენ გადავწყვიტეთ, რომ უბრალოდ გამორთოთ firewall.
სერვერის დაყენება
შეგახსენებთ, რომ ჩვენი WebRTC მაუწყებლობის სტრუქტურა ასეთია:
ჩვენ უკვე დავაინსტალირეთ ამ დიაგრამის ძირითადი ელემენტები, რჩება მხოლოდ ურთიერთქმედების „ისრების“ დადგენა.
ბრაუზერსა და WebRTC სერვერს შორის კავშირს უზრუნველყოფს ვებ კლიენტი, რომელიც ხელმისაწვდომია Github:. JS, CSS და HTML ფაილების ნაკრები უბრალოდ ჩაყრილია /var/www/htmlინსტალაციის ეტაპზე (იხ. პუნქტი 9 ზემოთ სპოილერის ქვეშ).
ბრაუზერსა და სერვერს შორის ურთიერთქმედება კონფიგურირებულია XML კონფიგურაციის ფაილში flashphoner.xml. აქ თქვენ უნდა შეიყვანოთ სერვერის IP მისამართი, რათა ვებ კლიენტმა შეძლოს WebRTC სერვერთან დაკავშირება HTML5 Websockets-ის მეშვეობით (პუნქტი 9 ზემოთ).
სერვერის დაყენება აქ მთავრდება; შეგიძლიათ შეამოწმოთ მისი მოქმედება:
ბრაუზერში გახსენით ვებ კლიენტის გვერდი index.html (ამისთვის Apache დაინსტალირებული იყო იმავე Amazon სერვერზე ბრძანებით yum -y დააინსტალირე httpd):
54.186.112.111/wcs_media_client/?id=rtsp://webrtc-ipcam.ddns.net/live1.sdp
Აქ webrtc-ipcam.ddns.netარის უფასო დომენი, რომელიც მიღებულია დინამიური DNS სერვერის noip.com მეშვეობით, რომელიც აკავშირებს ჩვენს გარე IP მისამართს. ჩვენ ვუთხარით როუტერს გადამისამართებულიყო RTSP მოთხოვნები 192.168.1.34-ზე NAT ქსელის მისამართის თარგმნის წესების შესაბამისად (ასევე იხილეთ ზემოთ).
Პარამეტრი id=rtsp://webrtc-ipcam.ddns.net/live1.sdpგანსაზღვრავს გასათამაშებელი ნაკადის URL-ს. WebRTC სერვერი მოითხოვს სტრიმინგებს კამერიდან, დაამუშავებს მათ და გაგზავნის ბრაუზერში დასაკრავად WebRTC-ის საშუალებით. შესაძლოა, თქვენი როუტერი მხარს უჭერს DDNS-ს. თუ არა, მაშინ IP კამერას აქვს ასეთი მხარდაჭერა:
და ასე გამოიყურება DDNS მხარდაჭერა თავად როუტერში:
ახლა თქვენ შეგიძლიათ დაიწყოთ ტესტირება და შეაფასოთ შედეგები.
ტესტირება
ბრაუზერში ბმულის გახსნის შემდეგ ხდება კავშირი WebRTC სერვერთან, რომელიც აგზავნის მოთხოვნას IP კამერას ვიდეო ნაკადის მისაღებად. მთელი პროცესი რამდენიმე წამს იღებს.
ამ დროს ბრაუზერსა და სერვერს შორის მყარდება კავშირი ვებსოკეტების საშუალებით, შემდეგ სერვერი ითხოვს IP კამერას RTSP-ის საშუალებით, იღებს H.264 სტრიმინგს RTP-ით და ტრანსკოდირებს მას VP8/SRTP-ში - რომელიც საბოლოოდ უკრავს WebRTC ბრაუზერს.
ვიდეოს ბოლოში ნაჩვენებია ვიდეო ნაკადის URL, რომლის კოპირება და გახსნა შესაძლებელია სხვა ბრაუზერის ან ჩანართიდან სანახავად.
ჩვენ დარწმუნებული ვართ, რომ ეს ნამდვილად WebRTCა.
რა მოხდება, თუ მოგვატყუეს და IP კამერიდან ვიდეო კვლავ გადაიცემა HTTP-ით? მოდი უსაქმურად არ შევხედოთ სურათს, მაგრამ შევამოწმოთ რეალურად რა სახის ტრაფიკს ვიღებთ. რა თქმა უნდა, ჩვენ კვლავ გავუშვით Wireshark და გამართვის კონსოლი Chrome-ში. Chrome ბრაუზერის კონსოლში ჩვენ ვხედავთ შემდეგს:
ამჯერად არაფერი ციმციმებს და არ ჩანს HTTP-ით გადაცემული სურათები. ამჯერად მხოლოდ ჩვენ ვხედავთ Websocket-ის ფრეიმებს და მათი უმეტესობა პინგ/პონგის ტიპებია Websocket სესიის შესანარჩუნებლად. საინტერესო ფრეიმები: დაკავშირება, მომზადებაRtspSession და onReadyToPlay - ეს არის სერვერთან კავშირის დამყარების თანმიმდევრობა: ჯერ Websocket კავშირი, შემდეგ კი ნაკადის მოთხოვნა დაკვრისთვის.
აი რას აჩვენებს chrome://webrtc-internals
გრაფიკების მიხედვით, IP კამერიდან გვაქვს ბიტრეიტი 1 Mbps. ასევე არის გამავალი ტრაფიკი, სავარაუდოდ ეს არის RTCP და ICE პაკეტები. RTT ამაზონის სერვერზე არის დაახლოებით 300 მილიწამი.
ახლა მოდით გადავხედოთ Wireshark-ს, თქვენ ნათლად შეგიძლიათ ნახოთ UDP ტრაფიკი სერვერის IP მისამართიდან. ქვემოთ მოცემულ სურათზე, პაკეტები არის 1468 ბაიტი. ეს არის WebRTC. უფრო ზუსტად, SRTP პაკეტები VP8 ვიდეო ჩარჩოებით, რომლებსაც შეგვიძლია დავაკვირდეთ ბრაუზერის ეკრანზე. გარდა ამისა, STUN-ის მოთხოვნები გადის (სურათზე ყველაზე დაბალი პაკეტი) - ეს არის WebRTC ICE, რომელიც ყურადღებით ამოწმებს კავშირს.
ასევე აღსანიშნავია შედარებით დაბალი შეყოვნება (პინგი მონაცემთა ცენტრში იყო დაახლოებით 250 ms) ვიდეოს დაკვრისთვის. WebRTC მუშაობს SRTP/UDP-ზე და, ბოლოს და ბოლოს, ეს არის პაკეტების მიწოდების ყველაზე სწრაფი გზა, განსხვავებით HTTP, RTMP და TCP მსგავსი ნაკადის მეთოდებისგან. იმათ. თვალით ხილული შეფერხება უნდა იყოს RTT + ბრაუზერის მიერ ბუფერირების, დეკოდირების და დაკვრის დრო. ვიზუალურად ამ შემთხვევაშიც ასეა – თვალი თითქმის ვერ ხედავს დაყოვნებას, ის 500 მილიწამზე ნაკლებია.
შემდეგი ტესტი აკავშირებს სხვა მაყურებლებს. მე მოვახერხე 10 Chrome ფანჯრის გახსნა და თითოეულ მათგანს აჩვენა სურათი. ამავდროულად, თავად Chrome დაიწყო ცოტა მოსაწყენი. სხვა კომპიუტერზე მე-11 ფანჯრის გახსნისას, დაკვრა გლუვი დარჩა.
WebRTC-ის შესახებ მობილურ მოწყობილობებზე
მოგეხსენებათ, WebRTC მხარს უჭერს Chrome და Firefox ბრაუზერებს Android პლატფორმაზე.მოდით შევამოწმოთ, გამოჩნდება თუ არა იქ ჩვენი გადაცემა:
სურათზე ნაჩვენებია HTC ტელეფონი; Firefox ბრაუზერი აჩვენებს ვიდეოს კამერიდან. დესკტოპიდან დაკვრის სიგლუვეში განსხვავება არ არის.
დასკვნა
შედეგად, ჩვენ შევძელით WebRTC ონლაინ მაუწყებლობის გაშვება IP კამერიდან რამდენიმე ბრაუზერზე მინიმალური ძალისხმევით. არ იყო საჭირო ტამბურით ან სარაკეტო მეცნიერების ცეკვა - მხოლოდ Linux-ისა და SSH კონსოლის საბაზისო ცოდნა.გადაცემის ხარისხი იყო მისაღებ დონეზე, ხოლო დაკვრის შეფერხება თვალისთვის უხილავი იყო.
რომ შევაჯამოთ, შეგვიძლია ვთქვათ, რომ ბრაუზერზე დაფუძნებულ WebRTC მაუწყებლებს აქვთ არსებობის უფლება, რადგან ჩვენს შემთხვევაში, WebRTC აღარ არის ყავარჯენი ან მოდული, არამედ რეალური პლატფორმა ბრაუზერში ვიდეოს დასაკრავად.
რატომ ვერ ვხედავთ WebRTC-ის ფართო გამოყენებას?
მთავარი დაბრკოლება ალბათ კოდეკების ნაკლებობაა. WebRTC საზოგადოებამ და მომწოდებლებმა უნდა გააკეთონ ძალისხმევა და შემოიტანონ H.264 კოდეკი WebRTC-ში. არაფერია სათქმელი VP8-ის წინააღმდეგ, მაგრამ რატომ უნდა უარი თქვან მილიონობით თავსებად მოწყობილობასა და პროგრამულ უზრუნველყოფას, რომელიც მუშაობს H.264-თან? პატენტები, ასეთი პატენტები...მეორე ადგილზე არ არის სრული მხარდაჭერა ბრაუზერებში. მაგალითად, IE-სა და Safari-თან დაკავშირებით, კითხვა რჩება ღია და იქ მოგიწევთ გადახვიდეთ სხვა ტიპის სტრიმინგზე ან გამოიყენოთ მოდული, როგორიცაა webrtc4all.
ასე რომ, მომავალში ვიმედოვნებთ, რომ ვიხილავთ უფრო საინტერესო გადაწყვეტილებებს, რომლებშიც არ იქნება საჭირო სტრიმინგების ტრანსკოდირება და კონვერტაცია და ბრაუზერების უმეტესობას შეეძლება ნაკადების დაკვრა პირდაპირ სხვადასხვა მოწყობილობიდან.
ვიდეო გადაცემის კომფორტული ყურება ან მისი კონფიგურაცია შესაძლებელია თქვენს პერსონალურ კომპიუტერზე პროგრამული მულტიმედიური ფლეერების გამოყენებით. დღეს ჩვენ განვიხილავთ, თუ როგორ უნდა დააკონფიგურიროთ RTSP ნაკადი Dahua Technology ქსელის აღჭურვილობისთვის ერთ-ერთ ყველაზე პოპულარულ მოთამაშეში, VLC Media Player-ში.
RTSP (Real Time Streaming Protocol) არის პროტოკოლი, რომელიც მომხმარებელს საშუალებას აძლევს დისტანციურად დაუკრას მულტიმედიური მონაცემების ნაკადი (აუდიო და ვიდეო) ჰიპერბმულის და მულტიმედიური პლეერის (ჩვენს შემთხვევაში, VLC Media Player) გამოყენებით.
თუ გჭირდებათ ვიდეო ნაკადის კონფიგურაცია, გამოიყენეთ შემდეგი ნაბიჯები:
- უპირველეს ყოვლისა, თქვენ უნდა ჩამოტვირთოთ და დააინსტალიროთ VLC Media Player, რომელიც თავისუფლად არის ხელმისაწვდომი ოფიციალურ ვებსაიტზე.
- დააჭირეთ მენიუს პუნქტს მედია – გახსენით ქსელის ნაკადი (გახსენით URL).
- შეიყვანეთ RTSP ქსელის მისამართი მოთხოვნის ხაზში.
- დააჭირეთ დაკვრის ღილაკს, როდესაც ვიდეო გამოსახულება გამოჩნდება ეკრანზე.
ლინკის ახსნა RTSP
მაგალითი:
rtsp:// :@:/cam/realmonitor?channel= &ქვეტიპი=
სად:
rtsp://admin: [ელფოსტა დაცულია]:554/cam/realmonitor?channel=1&subtype=1
Dahua Technology IP ვიდეო კამერები მხარს უჭერენ TCP და UDP მონაცემთა გადაცემის პროტოკოლებს. თუ პორტი 554 შეიცვალა, შეცვალეთ იგი ვიდეოკამერის პარამეტრების შესაბამის ველში (ვებ ინტერფეისი).
თუ რაიმე პრობლემა გაქვთ RTSP ნაკადის დაყენებისას, გთხოვთ, მიმართოთ შესაბამის განყოფილებას.
RTSP (რეალურ დროში სტრიმინგის პროტოკოლი)– რეალურ დროში ნაკადის პროტოკოლი, რომელიც შეიცავს ძირითადი ბრძანებების მარტივ კომპლექტს ვიდეო ნაკადის გასაკონტროლებლად.
RTSP წყაროების და IP კამერების დაკავშირება ვიდეო კონფერენციებში
RTSP პროტოკოლი საშუალებას აძლევს ნებისმიერ TrueConf მომხმარებელს დაუკავშირდეს IP ვიდეო კამერებს და მედიის შინაარსის სხვა წყაროებს, რომლებიც მაუწყებლობს ამ პროტოკოლის გამოყენებით დისტანციური ობიექტების მონიტორინგისთვის. მომხმარებელს ასევე შეუძლია დაუკავშირდეს ასეთ კამერებს ვიდეო კონფერენციის დროს სურათების გადასაცემად.
RTSP პროტოკოლის მხარდაჭერის წყალობით, TrueConf სერვერის მომხმარებლებს შეუძლიათ არა მხოლოდ დაუკავშირდნენ IP კამერებს, არამედ გადაიტანონ ვიდეო კონფერენციები RTSP ფლეერებსა და მედია სერვერებზე. წაიკითხეთ მეტი RTSP მაუწყებლობის შესახებ.
IP კამერების გამოყენების უპირატესობები TrueConf პროგრამული გადაწყვეტილებებით
- საოფისე ან სამრეწველო სახელოსნოში IP კამერის დაყენებით და მასთან დაკავშირებით ნებისმიერ ხელსაყრელ დროს შეძლებთ აკონტროლოთ თქვენი კომპანიის წარმოების პროცესი.
- თქვენ შეგიძლიათ დისტანციური ობიექტების მონიტორინგი მთელი საათის განმავლობაში. მაგალითად, თუ შვებულებაში მიდიხართ და არ გსურთ თქვენი ბინის უყურადღებოდ დატოვება, უბრალოდ დააინსტალირეთ ერთი ან მეტი IP კამერა. ერთ-ერთ ამ კამერაზე დარეკვით თქვენი კომპიუტერიდან TrueConf კლიენტის აპლიკაციის დაყენებით, შეგიძლიათ ნებისმიერ დროს დაუკავშირდეთ თქვენს ბინას და რეალურ დროში ნახოთ რა ხდება იქ.
- Windows-ის, Linux-ისა და macOS-ის TrueConf კლიენტის აპლიკაციებში, ყველა მომხმარებელს აქვს წვდომა ვიდეო კონფერენციების ჩაწერის შესაძლებლობაზე, რომლის წყალობითაც ვიდეოთვალთვალის დროს შეგიძლიათ ჩაწეროთ ნებისმიერი მოვლენა და მიიღოთ მათი დოკუმენტური მტკიცებულებები.
