მედია და IPTV
IPTV პლატფორმა — მიღებიდან აბონენტამდე
სტრიმის მიღება, ტრანსკოდირება, middleware, დისტრიბუცია და მედია ოპერაციები — ხარისხის მონიტორინგითა და HA-თი.
პრობლემა
არხი წყდება და მიზეზს ვერავინ ასახელებს
აბონენტი წერს, რომ სურათი „იშლება“. ჟურნალში არაფერია, რადგან მიღებასა და აბონენტის მიმღებს შორის არაფერი იზომება: bitrate არსად იწერება, CC შეცდომები არავის უჩანს, multicast მანამ მუშაობს, სანამ ერთი კომუტატორი არ გადაიტვირთება, EPG კი ჩუმად ცდება. შედეგად ყოველი ინციდენტი ვარაუდით სრულდება.
- ხარისხი მხოლოდ თვალით მოწმდება
- multicast-ის მდგომარეობა არსად ჩანს
- მიღების ერთი წყარო — მარაგის გარეშე
- EPG და middleware ხელით სწორდება
რას ვაწვდით
IPTV პლატფორმა — მიღებიდან აბონენტამდე
მიღების არქიტექტურა
სატელიტური, IP და SRT წყაროები, სარეზერვო შეყვანა და გადართვის წესი.
დამუშავება და პროფილები
ტრანსკოდირება, ABR კიბე და აუდიო/ტიტრების დამუშავება თითო არხზე.
დისტრიბუცია ქსელში
IGMP snooping, PIM, QoS და MTU — რომ multicast წვდომის ქსელში არ იშლებოდეს.
Middleware და EPG
არხების სია, გადაცემების პროგრამა, მოწყობილობების მართვა და აბონენტის უფლებები.
ხარისხის მონიტორინგი
bitrate, CC შეცდომები, PID-ების მდგომარეობა და არხის ხელმისაწვდომობა ისტორიით.
DVR და საცავი
ჩაწერის ღრმაობა, საცავის capacity და შენახვის პოლიტიკა.
არქიტექტურა
არქიტექტურა
- 01მიღება
- Satellite
- IP feed
- SRT
- 02დამუშავებატრანსკოდირება, პაკეტირება
- HLS / DASH
- ABR ladder
- 03Middleware
- EPG
- DRM
- Subscriber API
- 04დისტრიბუციაISP ქსელში მიწოდება
- Multicast
- CDN edge
- 05მონიტორინგისტრიმის ხარისხი
- Bitrate
- CC errors
- Uptime
შესაძლებლობები
შესაძლებლობები
თითოეული პუნქტი აღნიშნულია: დადასტურებული პროდაქშენ გამოცდილება თუ საინჟინრო შესაძლებლობა.
IPTV არქიტექტურა
ProvenIPTV პლატფორმა ჯგუფის საკუთარ ავტონომიურ სისტემაზე მუშაობს — იმავე ქსელში, სადაც წვდომა, ბილინგი და მონიტორინგი დგას.
- Multicast
- HLS
- EPG
სტრიმის მიღება და დამუშავება
Capability- SRT
- FFmpeg
- ABR
ISP ქსელში დისტრიბუცია
Proven- IGMP
- PIM
- QoS
VoIP და SIP
Capability- Asterisk
- SIP
- RTP
სტრიმის ხარისხის მონიტორინგი
Capability- Bitrate
- CC errors
- Grafana
DVR და საცავი
Capabilityტექნოლოგიური სტეკი
ტექნოლოგიური სტეკი
- მიღება
- SRTRTMPMulticastDVB-S2
- დამუშავება
- FFmpegABRHLSMPEG-TS
- დისტრიბუცია
- IGMPPIMQoS
- მონიტორინგი
- BitrateCC errorsGrafanaZabbix
- საცავი
- ZFSNFSDVR
თანამშრომლობის მოდელი
თანამშრომლობის მოდელი
პროექტი
ერთჯერადი scope: აუდიტი, მიგრაცია ან დანერგვა ფიქსირებული შედეგით.
რეტეინერი
ყოველთვიური საინჟინრო საათები — სპეციალისტზე წვდომა მოთხოვნისამებრ.
Co-Managed
NetWizard და თქვენი შიდა გუნდი ერთად, გაყოფილი პასუხისმგებლობით.
გამოყენების შემთხვევები
გამოყენების შემთხვევები
ISP-ს IPTV ემატება
წვდომის ქსელი უკვე არსებობს, ტელევიზია კი ახალი სერვისია. ვაშენებთ მიღებას, დისტრიბუციასა და middleware-ს არსებულ ქსელზე, multicast-ის ვალიდაციით ჯერ ლაბორატორიაში.
ხარისხზე დავა მტკიცებულების გარეშე
აბონენტი უჩივის, პროვაიდერი კონტენტის მომწოდებელს აბრალებს. ვამატებთ გაზომვას ჯაჭვის ყოველ წერტილში — და დავა ციფრით სრულდება.
მიღების რეზერვი
ერთი წყარო ერთადერთი წერტილია. ვამატებთ სარეზერვო შეყვანას ავტომატური გადართვით და შეტყობინებით, როცა გადართვა მოხდა.
ხშირი კითხვები
ხშირი კითხვები
multicast თუ unicast?
ორივე. ცოცხალი არხები multicast-ით ეფექტურია წვდომის ქსელში; unicast და ABR კი მობილურ და OTT მომხმარებელს სჭირდება. დიზაინი ორივეს ითვალისწინებს, არა ერთს.
DRM-ს აწყობთ?
ინტეგრაციას ვახორციელებთ კონტენტის მომწოდებლის მოთხოვნების მიხედვით. DRM ლიცენზირების საკითხია, არა მხოლოდ ტექნიკური — მას ხელშეკრულების პირობებიდან ვიწყებთ.
არსებულ პლატფორმაზე მუშაობთ?
დიახ. ხშირად პლატფორმის შეცვლა საჭირო არაა — საკმარისია მიღების რეზერვი, დისტრიბუციის გასწორება და გაზომვის დამატება. ჩანაცვლებას მაშინ ვთავაზობთ, როცა ამას აუდიტი ამართლებს.