FMUSER უფრო მარტივად გადასცემს ვიდეოს და აუდიოს!
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org -> აფრიკული
sq.fmuser.org -> ალბანური
ar.fmuser.org -> არაბული
hy.fmuser.org -> სომხური
az.fmuser.org -> აზერბაიჯანული
eu.fmuser.org -> ბასკური
be.fmuser.org -> ბელორუსული
bg.fmuser.org -> Bulgarian
ca.fmuser.org -> კატალანური
zh-CN.fmuser.org -> ჩინური (გამარტივებული)
zh-TW.fmuser.org -> ჩინური (ტრადიციული)
hr.fmuser.org -> ხორვატული
cs.fmuser.org -> ჩეხური
da.fmuser.org -> დანიური
nl.fmuser.org -> ჰოლანდიური
et.fmuser.org -> ესტონური
tl.fmuser.org -> ფილიპინური
fi.fmuser.org -> ფინური
fr.fmuser.org -> ფრანგული
gl.fmuser.org -> გალური
ka.fmuser.org -> ქართული
de.fmuser.org -> გერმანული
el.fmuser.org -> ბერძნული
ht.fmuser.org -> ჰაიტიური კრეოლური
iw.fmuser.org -> ებრაული
hi.fmuser.org -> ჰინდი
hu.fmuser.org -> Hungarian
is.fmuser.org -> ისლანდიური
id.fmuser.org -> ინდონეზიური
ga.fmuser.org -> ირლანდიური
it.fmuser.org -> იტალიური
ja.fmuser.org -> იაპონური
ko.fmuser.org -> კორეული
lv.fmuser.org -> ლატვიური
lt.fmuser.org -> ქართული
mk.fmuser.org -> მაკედონური
ms.fmuser.org -> მალაიზიური
mt.fmuser.org -> მალტური
no.fmuser.org -> ნორვეგიული
fa.fmuser.org -> სპარსული
pl.fmuser.org -> პოლონური
pt.fmuser.org -> პორტუგალიური
ro.fmuser.org -> რუმინული
ru.fmuser.org -> რუსული
sr.fmuser.org -> სერბული
sk.fmuser.org -> სლოვაკური
sl.fmuser.org -> Slovenian
es.fmuser.org -> ესპანური
sw.fmuser.org -> სუაჰილი
sv.fmuser.org -> შვედური
th.fmuser.org -> Thai
tr.fmuser.org -> თურქული
uk.fmuser.org -> უკრაინული
ur.fmuser.org -> ურდუ
vi.fmuser.org -> ვიეტნამური
cy.fmuser.org -> უელსური
yi.fmuser.org -> Yiddish
აუდიო და ვიდეო პირდაპირი მაუწყებლობის სისტემა არის რთული საინჟინრო სისტემა. პირდაპირი გადაცემის ძალიან დაბალი შეფერხების მისაღწევად, მას სჭირდება რთული სისტემის ინჟინერიის ოპტიმიზაცია და სხვადასხვა კომპონენტის გაცნობა. აქ არის რამოდენიმე გავრცელებული რჩევა:
კოდირების ოპტიმიზაცია
1. დარწმუნდით, რომ კოდეკი ჩართავს მინიმალური შეფერხების პარამეტრს. Codec– ს ზოგადად აქვს დაბალი შეყოვნების ოპტიმიზაციის შეცვლა, განსაკუთრებით H.264– სთვის. ბევრმა შეიძლება არ იცის, რომ H.264 დეკოდერი გამოაქვეყნებს გარკვეულ რაოდენობას ვიდეო ჩარჩოების ჩვენებამდე. ვიდეოსთვის, QCIF რეზოლუციით (176 × 144), ის შეინახავს 16 კადრს, ხოლო 720p ვიდეოსთვის 5 კადრი. პირველი ჩარჩოს წაკითხვისთვის, ეს დიდი შეფერხებაა. თუ არ იყენებთ H.264- ს თქვენი ვიდეოს კოდირებისა და კომპრესირებისთვის, დარწმუნდით, რომ არ იყენებთ B ჩარჩოებს, ეს ასევე უფრო დიდ გავლენას მოახდენს დაგვიანებაზე, რადგან ვიდეოში B ჩარჩოების გაშიფვრა დამოკიდებულია ვიდეო ჩარჩოები და მის შემდეგ, რაც გაზრდის დაგვიანებას.
2. შიფრატორს ჩვეულებრივ აქვს კოდის კონტროლით გამოწვეული შეფერხება, რომელსაც ასევე უწოდებენ ინიციალიზაციის შეფერხებას ან VBV ბუფერული ზომას. იგი განიხილება, როგორც ბუფერი შიფრატორსა და გამშიფრებელ ბიტსტრიმს შორის, რომელიც შეიძლება დაყენდეს რაც შეიძლება მცირე ან შეამციროს შეფერხება ვიდეოს ხარისხზე გავლენის გარეშე.
3. თუ პირველი შეფერხება მხოლოდ ოპტიმიზირებულია, უფრო მეტი ჩარჩოების ჩასმა შეიძლება ვიდეო ჩარჩოებს შორის, რომ კლიენტმა შეძლოს ვიდეოს ნაკადის გაშიფვრა მისი მიღებისთანავე. ამასთან, თუ გადაცემის პროცესში დაგროვილი დაგვიანების ოპტიმიზაცია დაგვჭირდება, უნდა გამოვიყენოთ რაც შეიძლება ნაკლები საკვანძო ჩარჩო, ანუ I- ჩარჩოები (GOP უფრო დიდი ხდება). ვიდეოს იგივე ხარისხის უზრუნველყოფის შემთხვევაში, რაც მეტია I- ჩარჩოები, მით მეტია ბიტის სიჩქარე და მეტია ქსელის სიჩქარის გადაცემა, რაც ნიშნავს, რომ კუმულაციური დაგვიანება შეიძლება მეტი იყოს. ეს ოპტიმიზაციის ეფექტი შეიძლება არ იყოს აშკარა სისტემაში მეორე დაგვიანებით, მაგრამ ეს აშკარა იქნება სისტემაში 100 მგ ან კიდევ უფრო დაბალი დაგვიანებით. ამავე დროს, შეეცადეთ გამოიყენოთ acc-lc კოდეკი აუდიოს დასაშიფრად. მიუხედავად იმისა, რომ he-acc ან he-acc 2 აქვს მაღალი კოდირების ეფექტურობა, კოდირებას უფრო დიდი დრო სჭირდება, ხოლო უფრო დიდი მოცულობის აუდიოთი გამოწვეული გადაცემის შეფერხებას ნაკლები გავლენა აქვს ვიდეო ნაკადის გადაცემაზე.
4. არ გამოიყენოთ MJPEG ვიდეოს კომპრესიის ფორმატი, მინიმუმ გამოიყენეთ MPEG4 ვიდეოს კომპრესიის ფორმატი B ჩარჩოს გარეშე (მარტივი პროფილი) და კიდევ უკეთესი გამოიყენეთ H.264 საბაზისო პროფილი (x264– ს აქვს ასევე "მკაფიო ნულოვანი დატვირთვის" ოპტიმიზაციის ჩამრთველი). ასეთ მარტივ ოპტიმიზაციას შეუძლია შეამციროს შეყოვნება, რადგან მას შეუძლია დაშიფროს სრული კადრების სიჩქარის ვიდეო უფრო დაბალი ბიტური სიჩქარით.
5. თუ ffmpeg გამოიყენება, შეამცირეთ "- გამოკვლევა" და "- ანალიზის ხანგრძლივობის" მნიშვნელობები, რომლებიც გამოიყენება ვიდეოკადრის ინფორმაციის მონიტორინგისა და მონიტორინგის დროისთვის. რაც უფრო დიდია ორი მნიშვნელობა, მით უფრო დიდია გავლენა კოდირების დაგვიანებაზე. პირდაპირ სცენაში არც კი არის საჭირო ვიდეოს ნაკადის ანალიზის ხანგრძლივობის პარამეტრის დაყენება.
6. CBR– ის ფიქსირებული სიჩქარით დაშიფვრას შეუძლია გარკვეულწილად აღმოფხვრას ქსელის გაღიზიანების გავლენა. თუ შესაძლებელია VBR კოდირების ცვლადი კოდირებით, მას შეუძლია დაზოგოს ქსელის არასაჭირო სიჩქარეს და შეამციროს გარკვეული შეფერხება. ამიტომ, ვარაუდობენ, რომ VBR მაქსიმალურად გამოიყენოს კოდირებისთვის.
ტრანსპორტის პროტოკოლის ოპტიმიზაცია
1. შეეცადეთ გამოიყენოთ HTMP ნაცვლად HLS პროტოკოლისა, რომელიც ემყარება HTTP- ს, სერვერის კვანძებს შორის გადასაცემად, რამაც შეიძლება შეამციროს გადაცემის საერთო შეფერხება. ეს ძირითადად მიზნად ისახავს საბოლოო მომხმარებლებს, რომლებიც იყენებენ HLS თამაშს.
2. თუ საბოლოო მომხმარებელი იყენებს RTMP- ს სათამაშოდ, ტრანსკოდირება უნდა განხორციელდეს მიმღებ კვანძში, რომელიც სტრიმინგის დასასრულს მიუახლოვდება, ისე, რომ გადაცემული ვიდეო ნაკადი უფრო მცირე იყოს, ვიდრე ორიგინალი ვიდეო ნაკადის.
3. საჭიროების შემთხვევაში, პერსონალური UDP პროტოკოლი შეიძლება გამოყენებულ იქნას TCP პროტოკოლის შესაცვლელად, ხოლო პაკეტის დაკარგვის გადაცემა სუსტი ქსელის კავშირის ქვეშ შეიძლება აღმოიფხვრას, რამაც შეიძლება შეამციროს დაგვიანება. მისი მთავარი მინუსია ის, რომ პერსონალური ვიდეო ნაკადის გადაცემა და გავრცელება UDP პროტოკოლის საფუძველზე არ არის საკმარისი უნივერსალური და CDN მწარმოებლები მხარს უჭერენ სტანდარტულ გადაცემის პროტოკოლს. კიდევ ერთი მინუსი ის არის, რომ შეიძლება არსებობდეს პაკეტის დაკარგვით გამოწვეული ჩაქრობა ან დაბინდვა (საკვანძო ჩარჩოს დეკოდირების მითითების არარსებობა), რაც მოითხოვს პროტოკოლის მორგებას, რომ შეასრულოს კარგი სამუშაო პაკეტის დაკარგვის კონტროლში UDP– ის საფუძველზე.
გადამცემი ქსელის ოპტიმიზაცია
1. ჩვენ დავნერგეთ რეალურ დროში ნაკადი ქსელი, რომელიც არის ახალი ტიპის ქსელის გადამცემი ქსელი თვითორგანიზებული კვანძებით. იგი არა მხოლოდ შესაფერისია შიდა მრავალ ოპერატორული ქსელის გადაცემის ოპტიმიზაციისთვის, არამედ შესაფერისია საზღვარგარეთ მყოფი მრავალი პირდაპირი მაუწყებლობის საჭიროებებისთვის.
2. შეაჩერე მიმდინარე GOP სერვერის კვანძში და ითანამშრომლე მოთამაშესთან ვიდეოს გახსნის დროის ოპტიმიზაციისთვის.
3. სერვერი აფიქსირებს მეორე დონის კადრების სიჩქარესა და კოდის სიჩქარეს, როდესაც თითოეული ვიდეო ნაკადი რეალურ დროში მიედინება თითოეულ ბმულზე და აკონტროლებს კოდის სიხშირისა და კადრების სიჩქარის რეალურ დროში მონიტორინგს.
4. კლიენტი (ბიძგი ნაკადი და თამაში) იღებს მიმდინარე ოპტიმალურ კვანძს კვაზი რეალურ დროში სერვერის დაკითხვით (ყოველ 5 წამში ერთხელ), ხოლო მიმდინარე ხარვეზის კვანძი და ხაზი ოფლაინ არის კვაზი რეალურ დროში.
ნაკადი და დაკვრის ოპტიმიზაცია
1. სისტემას შეუძლია მონაცემთა კეშირება მონაცემთა გაგზავნამდე. ამ პარამეტრის რეგულირებას ასევე სჭირდება ბალანსის პოვნა.
2. პლეერის ბუფერული კონტროლი ასევე დიდ გავლენას ახდენს ვიდეოს პირველ შეფერხებაზე. თუ მხოლოდ პირველი შეფერხებაა ოპტიმიზირებული, მონაცემების გაშიფვრა შეიძლება დაუყოვნებლივ, როდესაც ისინი მიიღებენ 0 ბუფერულის შემთხვევაში. მაგრამ სუსტ ქსელურ გარემოში ქსელური ზემოქმედების აღმოსაფხვრელად საჭიროა გარკვეული ქეშის დაყენება, ასე რომ, ჩვენ უნდა ვნახოთ ბალანსი პირდაპირი მაუწყებლობის სტაბილურობასა და პირველი ღია შეფერხების ოპტიმიზაციას შორის და შეცვალოთ ოპტიმიზირებულია ბუფერის ზომა.
3. მოთამაშის დინამიური ბუფერული სტრატეგია, რომელიც წარმოადგენს ზემოთ მოცემული მოთამაშის ქეშ-კონტროლის გაუმჯობესებულ ვერსიას. თუ ჩვენ უბრალოდ ვირჩევთ 0 ქეშსა და ფიქსირებულ ზომის ქეშს შორის ბალანსის დასადგენად, საბოლოოდ ავირჩევთ ფიქსირებული ზომის ქეშს, რომელიც არ არის სამართლიანი 100 მილიონი მობილური ინტერნეტის ტერმინალის მომხმარებლისთვის. მათი ქსელის განსხვავებული პირობები განსაზღვრავს, რომ ფიქსირებული ზომის მეხსიერება არ არის სრულყოფილი. ამიტომ, ჩვენ შეგვიძლია განვიხილოთ "დინამიური ბუფერული სტრატეგია". როდესაც მოთამაშე ჩართულია, ჩვენ ვიყენებთ ძალიან მცირე ან თუნდაც ნულოვანი ბუფერულ სტრატეგიას. შემდეგი დროის ნაჭრის ბუფერული ზომა განისაზღვრება პირველი ვიდეოს ჩამოტვირთვისთვის დახარჯული დროის მიხედვით. ამავე დროს, მიმდინარე ქსელის მონიტორინგი ხდება რეალურ დროში დაკვრის პროცესში, ხოლო ბუფერის ზომა რეგულირდება რეალურ დროში დაკვრის პროცესში. ამ გზით, პირველი გახსნის დრო შეიძლება იყოს ძალიან დაბალი, და ქსელის გამანადგურებლის გავლენა მაქსიმალურად აღმოიფხვრას.
4. დინამიური სიჩქარის თამაშის სტრატეგია. ბუფერული ზომის დინამიურად რეგულირების სტრატეგიის გარდა, ჩვენ ასევე შეგვიძლია გამოვიყენოთ რეალურ დროში მონიტორინგის ქსელის ინფორმაცია, დინამიურად შეცვალოს ბიტის სიჩქარე დაკვრის პროცესში. არასაკმარისი ქსელის გამტარობის შემთხვევაში, ჩვენ შეგვიძლია შევამციროთ ბიტის სიჩქარე დაკვრისთვის და შევამციროთ შეფერხება.
ზემოხსენებული ნაწილი არის შეყოვნების დაბალი ოპტიმიზაციის ტექნიკის ნაწილი. სინამდვილეში, როდესაც ჩვენ შეყოვნების ოპტიმიზაციას ვახდენთ, ჩვენ მხოლოდ "მცირე შეყოვნებაზე" არ ვამახვილებთ ყურადღებას, არამედ ვცდილობთ მივაღწიოთ დაბალი შეყოვნების პირობას იმ პირობით, რომ სხვა პირობებმა არ იმოქმედოს მომხმარებლის გამოცდილებაზე. ამიტომ, მისი შინაარსი მოიცავს თემების ფართო სპექტრს.
|
შეიყვანეთ ელ.წერილი სიურპრიზის მისაღებად
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org -> აფრიკული
sq.fmuser.org -> ალბანური
ar.fmuser.org -> არაბული
hy.fmuser.org -> სომხური
az.fmuser.org -> აზერბაიჯანული
eu.fmuser.org -> ბასკური
be.fmuser.org -> ბელორუსული
bg.fmuser.org -> Bulgarian
ca.fmuser.org -> კატალანური
zh-CN.fmuser.org -> ჩინური (გამარტივებული)
zh-TW.fmuser.org -> ჩინური (ტრადიციული)
hr.fmuser.org -> ხორვატული
cs.fmuser.org -> ჩეხური
da.fmuser.org -> დანიური
nl.fmuser.org -> ჰოლანდიური
et.fmuser.org -> ესტონური
tl.fmuser.org -> ფილიპინური
fi.fmuser.org -> ფინური
fr.fmuser.org -> ფრანგული
gl.fmuser.org -> გალური
ka.fmuser.org -> ქართული
de.fmuser.org -> გერმანული
el.fmuser.org -> ბერძნული
ht.fmuser.org -> ჰაიტიური კრეოლური
iw.fmuser.org -> ებრაული
hi.fmuser.org -> ჰინდი
hu.fmuser.org -> Hungarian
is.fmuser.org -> ისლანდიური
id.fmuser.org -> ინდონეზიური
ga.fmuser.org -> ირლანდიური
it.fmuser.org -> იტალიური
ja.fmuser.org -> იაპონური
ko.fmuser.org -> კორეული
lv.fmuser.org -> ლატვიური
lt.fmuser.org -> ქართული
mk.fmuser.org -> მაკედონური
ms.fmuser.org -> მალაიზიური
mt.fmuser.org -> მალტური
no.fmuser.org -> ნორვეგიული
fa.fmuser.org -> სპარსული
pl.fmuser.org -> პოლონური
pt.fmuser.org -> პორტუგალიური
ro.fmuser.org -> რუმინული
ru.fmuser.org -> რუსული
sr.fmuser.org -> სერბული
sk.fmuser.org -> სლოვაკური
sl.fmuser.org -> Slovenian
es.fmuser.org -> ესპანური
sw.fmuser.org -> სუაჰილი
sv.fmuser.org -> შვედური
th.fmuser.org -> Thai
tr.fmuser.org -> თურქული
uk.fmuser.org -> უკრაინული
ur.fmuser.org -> ურდუ
vi.fmuser.org -> ვიეტნამური
cy.fmuser.org -> უელსური
yi.fmuser.org -> Yiddish
FMUSER უფრო მარტივად გადასცემს ვიდეოს და აუდიოს!
კონტაქტები
მისამართი:
No.305 ოთახი HuiLan კორპუსი No.273 Huanpu Road Guangzhou China 510620
კატეგორიები
საინფორმაციო ბიულეტენი