Ինչպես ենք փորձարկում վիդեոյի QoE-ն. մեկնարկ, կանգառներ, zap time

Կապուղին անցնում է throughput թեստը բաժանորդային ամբողջ արագությամբ, իսկ դրա վրայի դիտողները շարունակում են նայել բեռնման պտտվող նշանին։ Throughput թեստը հավասարաչափ հոսք է ուղարկում։ Վիդեո նվագարկիչն այլ կերպ է աշխատում՝ սեգմենտը ներբեռնում է մեկ պոռթկումով, չափում է, թե որքան տևեց բեռնումը, և դրանով ընտրում հաջորդի բիթրեյթը։ IPTV ընդունիչն ալիքը ցույց է տալիս միայն այն բանից հետո, երբ սպասարկվում է նրա IGMP join-ը։ Մենք գնահատում ենք յուրաքանչյուր էմուլյացված դիտողին ըստ այն բանի, ինչ կնկատեր բազմոցին նստած մարդը՝ վայրկյաններ մինչև առաջին կադրը, կանգառներ, բիթրեյթը, որի վրա կանգ է առնում նվագարկիչը, ալիքի փոխարկման ժամանակը։

Ստենդը

Փորձարկվող սարքը գտնվում է վիդեոյի ուղու վրա՝ CDN-ի edge քեշ, BNG կամ BRAS, տնային CPE, Wi-Fi մուտքի կետ, SD-WAN edge, բջջային միջուկի user plane կամ WAN կապուղի՝ միացված խեղաթյուրումներով։ Ստենդն էմուլյացնում է դիտողներին երեք ձևով։ HLS և DASH նվագարկիչները HTTPS-ով պահանջում են մանիֆեստներ և սեգմենտներ սարքի հետևում գտնվող origin-ից և փոխում են բիթրեյթն ըստ բուֆերի մակարդակի և բեռնման ժամանակի։ Ընդունիչները IGMP-ով միանում են multicast IPTV ալիքներին և հեռանում դրանցից։ Տեսազանգերի բաժանորդներն իրական ժամանակի վիդեո են ուղարկում երկու ուղղությամբ։

Տրաֆիկի գեներատորը կապուղու մնացած մասը լցնում է web, VoIP և ֆայլերի փոխանցման հոսքերով՝ Ձեր տրաֆիկի պրոֆիլի կշիռներով։ WANemu-ն, որն այժմ beta փուլում է 1G և 10G կապուղիներում, ավելացնում է ուշացում, jitter և կորուստ յուրաքանչյուր ուղղությամբ՝ պատահական կամ խմբերով։ Նվագարկիչների պրոֆիլները, բիթրեյթների սանդուղքը և ալիքների ցանկը Ձերն են։

Ինչ ենք ստուգում

• Մեկնարկ. ժամանակը նվագարկման հարցումից մինչև առաջին կադրը՝ յուրաքանչյուր նվագարկիչի համար և պերցենտիլներով դիտողների միջև Ձեր երեկոյան պիկի ժամին
• Կանգառներ. rebuffering-ի դեպքերը մեկ սեսիայում և դրանց ընդհանուր տևողությունը՝ բեռի աճի ընթացքում և հենց պիկին
• Բիթրեյթ. պրոֆիլը, որի վրա կանգ է առնում յուրաքանչյուր նվագարկիչ, սեսիայի մասնաբաժինը վերին պրոֆիլում, որքան հաճախ է այն իջնում ներքև
• Edge քեշ. սեգմենտի պատասխանի ժամանակը, երբ դիտողները միաժամանակ միացնում են նույն live իրադարձությունը
• Ալիքի փոխարկում. zap time IGMP join-ից մինչև նոր ալիքը, և leave-ը, որը կանգնեցնում է հինը, երբ շատ ընդունիչներ միաժամանակ են փոխում ալիքը
• Multicast-ի որակ. MDI յուրաքանչյուր ալիքի համար վայրկյան առ վայրկյան, delay factor և media loss rate (RFC 4445)
• Տեսազանգեր. սառեցման ժամանակը, ստացված կադրային հաճախականությունը, կորուստը և jitter-ը յուրաքանչյուր զանգի համար երկու ուղղությամբ
• Խեղաթյուրումներ. նույն հավաքածուն՝ կապուղու վրա ուշացումով, jitter-ով և խմբային կորստով, ինչպես նաև այն լցնող ֆոնային տրաֆիկով, QoS-ը միացված

Ինչն է սովորաբար խափանվում

Մանր bucket-ով policer BNG-ում կամ CPE-ում։ Նվագարկիչը յուրաքանչյուր սեգմենտ ներբեռնում է պոռթկումով՝ գծի արագությամբ, policer-ը կտրում է պոռթկման սկիզբը, TCP-ն իջեցնում է արագությունը, և սեգմենտը հասնում է ավելի ուշ, քան թույլ է տալիս դրա նվագարկման ժամանակը։ Նվագարկիչը ցանցը դանդաղ է համարում և անցնում ավելի ցածր պրոֆիլի։ Տիպիկ նախագծում 50 Մբիթ/վ պրոֆիլը throughput թեստում տվեց ամբողջ արագությունը, իսկ 4K նվագարկիչը դրա վրա սեսիայի մեկ երրորդն անցկացրեց վերինից մեկ պրոֆիլ ցածր։ Ավելի մեծ burst size-ն այն վերադարձրեց վերև։

IGMP-ն ժամի սկզբին։ Դատարկ հանգույցում join-ը տևում է տասնյակ միլիվայրկյաններ, և մեկ ընդունիչով փոխարկման թեստն անցնում է։ Երբ շատ ընդունիչներ միանգամից են փոխում ալիքը, join-երը հերթ են կանգնում control plane-ում, և zap time-ն անցնում է մեկ վայրկյանից։ Առանց fast leave-ի ավելի վատ է՝ հին ալիքը շարունակում է գնալ բաժանորդային գծով, մինչև query-ի ժամաչափը սպառվի, երկու HD ալիք կիսում են մեկի համար հաշվարկված գիծը, և MDI-ն երկուսի վրա էլ կորուստ է ցույց տալիս։

Խմբային կորուստ։ Տեսազանգը դիմանում է 1 % պատահական կորստին՝ FEC-ը և սխալների քողարկումը ծածկում են այն։ Նույն 1 %-ը, երբ գալիս է խմբերով, ինչպես ծանրաբեռնված Wi-Fi բջջում կամ ռադիոկապուղում, ամեն անգամ վայրկյանի մի մասով սառեցնում է պատկերը։ Wi-Fi ստենդում դա երևում է, երբ բջիջը լցվում է մինչև նախագծային հաճախորդների քանակը, WAN կապուղում՝ Գիլբերտ–Էլիոթի մոդելով խմբային կորստի միջոցով։ Նույն միջին մակարդակի պատահական կորստով փորձարկումը դա չի տեսնում։

Ինչ կա հաշվետվության մեջ

Մեկնարկի ժամանակը, կանգառները և բիթրեյթը յուրաքանչյուր նվագարկիչի համար՝ պերցենտիլներով դիտողների միջև։ Zap time յուրաքանչյուր ալիքի համար՝ join-երի հաճախականության դիմաց։ MDI-ի delay factor և media loss rate յուրաքանչյուր ալիքի համար վայրկյան առ վայրկյան։ Սառեցման ժամանակը և կադրային հաճախականությունը յուրաքանչյուր զանգի համար։ Ամեն ինչ մեկ ժամանակագծի վրա՝ խեղաթյուրումների և սարքի հաշվիչների հետ, գումարած նվագարկիչների կարգավորումները, բիթրեյթների սանդուղքը և էմուլյատորի արժեքները, որպեսզի նույն երեկոն կրկնվի հաջորդ firmware-ի վրա։

Որտեղից սկսել

Ուղարկեք մեզ վիդեոյի ուղու վրա գտնվող սարքերը, բիթրեյթների սանդուղքը կամ ալիքների ցանկը և դիտողների պիկային քանակը։ Մենք պատասխանում ենք թեստի պլանի նախագծով՝ կետերը, ստենդի սխեման և ժամկետները։ Հաշվետվությունը մնում է Ձեզ, և Դուք կարող եք այն ցույց տալ վենդորին։ Գրեք մեզ կամ տեսեք, թե էլ ինչ է անում ստենդը։