Իրոք, որքանո՞վ է լավ WebRTC էկրանի փոխանակումը: Ես փորձարկման եմ դրել 4 կոդեկ

Ինձ միշտ հետաքրքրել է, թե ինչպես են տարբեր կոդեկները կուտակվում, երբ խոսքը վերաբերում է WebRTC-ով էկրանի համօգտագործմանը: Այսպիսով, ես որոշեցի ինքս պարզել՝ փորձարկելով չորս ամենատարածվածները՝ VP8, VP9, H.264 և AV1:

Համոզվելու համար, որ արդյունքները ամուր են, ես փորձարկումներ անցկացրեցի բովանդակության տարբեր տեսակների և ցանցային պայմանների վրա: Ես հույս չունեի միայն վիզուալ տպավորությունների վրա. ես օգտագործել եմ կադր առ կադր համեմատություններ, հաշվարկել եմ գագաթնակետային ազդանշան-աղմուկ հարաբերակցությունը (PSNR) և մանրամասն WebRTC վիճակագրություն՝ պարզ, տվյալների վրա հիմնված տեսք ստանալու համար:

Մի քայլ առաջ գնալու համար ես նույնիսկ ստեղծեցի հատուկ Chrome հավելված, որը հետևում է պրոցեսորի օգտագործմանը և՛ կոդավորման, և՛ ապակոդավորման ժամանակ: Դա ինձ լավ նայեց, թե ինչպես է յուրաքանչյուր կոդեկ ազդում համակարգի աշխատանքի վրա, քանի որ որակը հիանալի է, բայց ոչ այն դեպքում, երբ ձեր համակարգիչը կրակի մեջ է, փորձում է հետևել:

Ես նայեցի հիմնական չափորոշիչներին, ինչպիսիք են բիթերի արագությունը, շրջանակի արագությունը, լուծումը, քվանտացումը (QP), PSNR-ը և պրոցեսորի բեռնվածությունը: Ելնելով այդ ամենից՝ ես հանդես եկա մի քանի գործնական առաջարկություններով՝ օգնելու բոլորին, ովքեր փորձում են օպտիմալացնել WebRTC էկրանի փոխանակումը սեփական օգտագործման դեպքերի համար:

Փորձի մասին

Ինչու Էկրանի համօգտագործումը այնքան էլ պարզ չէ, որքան թվում է

Եթե տեսազանգի ընթացքում երբևէ կիսվել եք ձեր էկրանով և նկատել եք, որ որակն իջնում է, կամ տեսահոլովակը խափանում է, դուք միայնակ չեք: Էկրանի պարզ և սահուն համօգտագործումը իրականում ավելի բարդ է, քան թվում է:

Խնդիրը. Ամեն ինչ բազմազանության մասին է: Որոշ բովանդակություն դեռևս է, օրինակ՝ սլայդերի տախտակամած կամ փաստաթուղթ: Այլ ժամանակներում դուք կիսվում եք բարձր շարժման տեսանյութով: Այս տարբեր տեսակի բովանդակությունը պահանջում է շատ տարբեր բաներ կոդեկից: Օրինակ, արագ շարժվող տեսանյութը խլում է մի տոննա թողունակություն, մինչդեռ ստատիկ պատկերներն ավելի զգայուն են սեղմման արտեֆակտների նկատմամբ, որոնք կարող են դրանք մշուշոտ կամ խցանված տեսք տալ:

Ներդրեք իրական աշխարհի ինտերնետի խնդիրները, ինչպիսիք են փաթեթների կորուստը կամ թողունակության անկումը, և ամեն ինչ ավելի խառնաշփոթ է դառնում: Ահա թե ինչու ճիշտ կոդեկ ընտրելը և դրա աշխատանքի ճիշտ կարգավորումը շատ կարևոր է էկրանի համօգտագործումը և՛ բարձրորակ, և՛ արձագանքող դարձնելու համար:

Արդեն շատ հետազոտություններ կան այն մասին, թե ինչպես են վիդեո կոդեկները գործում ընդհանուր հոսքային սցենարներում: Սակայն էկրանի փոխանակումն ունի իր առանձնահատկությունները: Խոսքը միայն տեսահոլովակ դիտելու մասին չէ, այն իրական ժամանակում փոխազդեցության մասին է, և բովանդակության տեսակներն ամենուր են: Դա նշանակում է, որ սովորական հետազոտությունը միշտ չէ, որ կիրառվում է:

Այն, ինչ ես պատրաստվում էի անել

Ես ուզում էի ավելի խորանալ այս կոնկրետ օգտագործման դեպքի մեջ: Իմ նպատակն էր տեսնել, թե ինչպես են տարբեր կոդեկները գործում, երբ խոսքը վերաբերում է էկրանի համօգտագործմանը, հատկապես իրական աշխարհի սահմանափակումների դեպքում, ինչպիսիք են բովանդակության տարբեր տեսակները և ցանցի անկանխատեսելի պայմանները:

Դա անելու համար ես նախագծեցի մեթոդ՝ էկրանի համօգտագործման որակը հնարավորինս ճշգրիտ գնահատելու համար՝ ոչ միայն հիմնվելով դրա արտաքին տեսքի վրա, այլ հիմնված ամուր չափումների և տվյալների վրա: Ճանապարհին ես շատ բան սովորեցի այն մասին, թե որ կոդեկներն են ավելի լավ պահպանում և ինչպես կարգավորել իրերը իրական ժամանակի հավելվածներում ավելի լավ կատարման համար:

Մի բան արագ պարզ դարձավ. էկրանի փոխանակման արդյունավետությունը իսկապես կախված է նրանից, թե ինչ եք կիսում: Արագ տեմպերով տեսանյութն իրեն շատ տարբեր է պահում ստատիկ փաստաթղթից կամ վեբ էջի վրա դանդաղ պտտվելուց:

Իրերը արդար և հետևողական պահելու համար ես համոզվեցի, որ յուրաքանչյուր թեստ անցկացվի ճիշտ նույն պայմաններով. նույն լուծումը, նույն ելակետը և նույն տևողությունը: Այդ կերպ ես կարող էի վստահ լինել, որ արդյունքները վերաբերում են կոդեկի աշխատանքին, ոչ թե պատահական փոփոխականին:

Ես ստեղծել եմ երկու տարբեր թեստային դեպքեր՝ իրական կյանքում էկրանի փոխանակման իրավիճակները մոդելավորելու համար.

• Բարձր շարժման տեսահոլովակ . Սա իսկական տեսահոլովակ էր, որտեղ մոտոցիկլավարները արագ են անցնում անտառով: Շատ արագ շարժումներ, մանրամասն դեկորացիա և անընդհատ փոփոխվող տեսողական միջավայր՝ կատարյալ սեղմման սահմանները ճնշելու համար:

• Տեքստի ավտոմատ ոլորում – Ես ստեղծեցի պարզ HTML էջ՝ տեքստով և պատկերներով, այնուհետև օգտագործեցի JavaScript՝ այն կայուն արագությամբ ոլորելու համար: Այն ընդօրինակում է սովորական օգտագործման դեպք, ինչպիսին է փաստաթղթի փոխանակումը կամ վեբ էջից կարդալը:

Այս երկու տեսակի բովանդակությունը ինձ լավ խառնուրդ տվեց՝ ստուգելու, թե ինչպես է յուրաքանչյուր կոդեկ հաղթահարում տարբեր մարտահրավերներ՝ շարժման հետ պահելուց մինչև ավելի ստատիկ տեսարաններում պարզություն պահպանելը:

Ինչպես եմ ամեն ինչ կարգավորել

Կոդեկները ճիշտ փորձարկելու համար ինձ անհրաժեշտ էր ամուր կարգավորում, որը կարող էր ֆիքսել ամեն ինչ ՝ և՛ ուղարկվողը, և՛ ստացվածը: Ես սկսեցի webrtc-sandbox կոչվող գործիքից (Ի դեպ, դուք կարող եք իմանալ այս գործիքի և շատ ավելին իմ մյուս գրառման մեջ. « WebRTC-ի պրակտիկայում սովորելը. լավագույն գործիքներն ու դեմոները »), որը հիանալի է WebRTC-ի ինտերիերը խառնելու համար: Ես ի վերջո մի փոքր շտկեցի այն, որպեսզի ավելի լավ կարգավորեմ էկրանի փոխանակումը և համոզվեմ, որ կարող եմ ձայնագրել ինչպես ելքային, այնպես էլ մուտքային վիդեո հոսքերը: Յուրաքանչյուր թեստային աշխատանք ինձ տալիս էր երկու վիդեո ֆայլ՝ մեկը ուղարկվածի և մեկը ստացվածի համար, որոնք ես հետագայում օգտագործեցի կողք կողքի վերլուծության համար:

Բայց ես չսահմանափակվեցի տեսանյութով. Ես նաև ուզում էի հետևել, թե ինչ է կատարվում գլխարկի տակ: Դրա համար ես քաշեցի մանրամասն WebRTC վիճակագրությունը անմիջապես Chrome բրաուզերից: Այս վիճակագրությունը ինձ պատուհան տվեց, թե ինչպես է գործել յուրաքանչյուր կոդեկ և ինչպես է վարվել մոդելավորված ցանցը յուրաքանչյուր թեստի ժամանակ:

Փազլի մի մեծ մասը CPU-ի օգտագործումն էր, և դա մի փոքր բարդ էր: Chrome-ի սովորական տարբերակը թույլ չի տալիս պլագիններին վերահսկել պրոցեսորի բեռնվածությունը առանձին ներդիրների համար, այնպես որ ես օգտագործեցի զննարկիչի մշակման կառուցվածքը և գրեցի իմ սեփական փլագինը, որպեսզի շրջանցեմ այն:

Ես հատուկ կենտրոնացա CPU-ի օգտագործումը չափելու վրա այն ներդիրից, որն ուղարկում կամ ստանում էր էկրանի համօգտագործումը: Այդ կերպ ես բացառեցի բրաուզերի այլ մասերից անկապ ներկայացման առաջադրանքները: Քանի որ և՛ ուղարկելը, և՛ ստացումը տեղի են ունեցել նույն ներդիրում, իմ ստացած թվերը համակցված տեսք էին, բայց դեռ բավականին մոտ են նրան, ինչ դուք կտեսնեք իրական աշխարհի օգտագործման դեպքում: (Սփոյլեր. կոդավորումը սովորաբար ավելի ուժեղ է հարվածում պրոցեսորին, քան ապակոդավորումը):

Տվյալների հավաքում. 157 թեստային աշխատանք ավելի ուշ...

Երբ կարգավորումը պատրաստ էր, ժամանակն էր իրականացնել իրական փորձերը, և ես դրանցից շատերն անցկացրի: Ես կրկնել եմ թեստերը միևնույն մեքենայի վրա, նորից ու նորից՝ օգտագործելով ցանցի տարբեր պայմաններ և կոդեկի կարգավորումներ՝ տեսնելու, թե ինչպես են ամեն ինչ պահպանվում: Ընդհանուր առմամբ, ես հավաքեցի 157 տվյալների միավոր ՝ համոզվելով, որ թեստի պայմանների յուրաքանչյուր համադրություն լավ ներկայացված է:

Սա ինձ տվեց ամուր տվյալների բազա՝ աշխատելու համար և թույլ տվեց խորը վերլուծություն կատարել այն մասին, թե ինչպես է էկրանի համօգտագործումը վարվում WebRTC-ում տարբեր սցենարների դեպքում: Ահա թե ինչ էի ես հատուկ փորձարկում.

• Տեսանյութի տեսակը .
  Ես օգտագործել եմ երկու տեսակի էկրանի համօգտագործման բովանդակություն՝ ընդհանուր օգտագործման դեպքերը արտացոլելու համար.
  • Բարձր շարժման տեսահոլովակ . տոննա պիքսելներով իրական աշխարհի կադրերը փոխում են յուրաքանչյուր կադր:
  • Ավտոմատ ոլորված տեքստ - Հիմնականում ստատիկ վիզուալներ, բայց պիքսելների դիրքը փոխվում է տեքստի ոլորման ընթացքում:
• Կոդեկ .
  Ես փորձարկել եմ էկրանի փոխանակման չորս ամենատարածված կոդեկները.
  • AV1
  • հ.264
  • VP8
  • VP9
• Ցանցի թողունակություն .
  Քանի որ թողունակությունը հսկայական դեր է խաղում տեսանյութի որակի մեջ (հատկապես տեսազանգերում), ես մոդելավորեցի ցանցի մի շարք պայմաններ՝ տեսնելու, թե յուրաքանչյուր կոդեկ որքան լավ է կառավարում խիտ կամ տատանվող թողունակությունը:

Այս փոփոխականները կառուցվածքային ձևով խառնելով և համապատասխանեցնելով, ես կարողացա ընդօրինակել իրական աշխարհի էկրանի փոխանակման սցենարները, որոնք դուք կհանդիպեիք տեսազանգերի ժամանակ, ուղիղ ցուցադրման ընթացքում կամ համատեղ հեռակառավարվող աշխատաշրջանի ժամանակ:

Սխալների շտկում. ինչպես ես դարձրեցի թեստերն ավելի հուսալի

Ինչպես փորձերի մեծ մասի դեպքում, առաջին մի քանի վազքներն այնքան հարթ չեն անցել, որքան ես ակնկալում էի: Երկու հիմնական խնդիր անմիջապես ի հայտ եկավ.

1. Ձեռնարկի սկիզբ = խառնաշփոթ ժամանակացույց: Սկզբում ես սկսում էի էկրանի փոխանակումը ձեռքով` բառացիորեն սեղմելով կոճակը` գործերը սկսելու համար: Խնդիրը. Գրեթե անհնար էր համաժամեցնել ձայնագրության սկիզբը տեսաբովանդակության սկզբի հետ: Դա նշանակում էր, որ յուրաքանչյուր փորձնական վազք ուներ մի փոքր տարբեր ժամանակներ, ինչը շեղեց համեմատությունները:
2. Ուղարկված ընդդեմ ստացված = Համաժամեցված չէ: Նույնիսկ այն ժամանակ, երբ ճիշտ ժամանակն էր, իրական ժամանակի տեսանյութն ունի իր առանձնահատկությունները: Կոդավորման, վերծանման և ցանցի ուշացումների շնորհիվ ուղարկված և ստացված հոսքերը երբեք կատարյալ չեն դասավորվել: Սա գրեթե անհնարին դարձրեց կադր առ կադր որակի համեմատությունները:

Այս խնդիրները լուծելու համար ես կատարել եմ մի քանի հիմնական բարելավում.

• Ծրագրային համաժամացում . ամեն ինչ ձեռքով սկսելու փոխարեն, ես որոշ կոդ գրեցի՝ տեսանյութի սկիզբը կամ տեքստը պտտելու ձայնագրման գործընթացի հետ համաժամեցնելու համար: Այսպիսով, յուրաքանչյուր փորձնական վազք սկսվեց ճիշտ նույն պահին երկու ծայրերում. խնդիրը լուծվեց:
• QR կոդի շրջանակի համընկնում . ապահամաժամացման խնդրի համար ես ավելացրի QR կոդի փոքր ծածկույթ համօգտագործվող տեսանյութին: Այս փոքրիկ նշիչը գործում էր որպես ժամանակի դրոշմակնիք. այն թույլ տվեց ինձ ճշգրտորեն համապատասխանեցնել շրջանակները ուղարկված և ստացված հոսքերի միջև: Հանկարծ շրջանակ առ կադր վերլուծությունը դարձավ հնարավոր (և ավելի ճշգրիտ):

Եվս մեկ բան պետք է հաշվի առնեի՝ WebRTC-ի հարմարվողական բիթային արագությունը : WebRTC-ի հիանալի առանձնահատկություններից մեկն այն է, որ այն ավտոմատ կերպով կարգավորում է տեսանյութի որակը՝ հիմնվելով հասանելի թողունակության վրա: Բայց այդ կարգավորումն անմիջապես տեղի չի ունենում. կայունանալու համար մի քանի վայրկյան է պահանջվում: Այսպիսով, ես մի փոքր ուշացում ավելացրի նախքան իրական ձայնագրությունը սկսելը: Սա համակարգին ժամանակ տվեց կարգավորելու նպատակային բիթերի արագությունը, այնպես որ արդյունքները կարտացոլեն իրական որակը, որը դուք կստանաք ամեն ինչ հարթելուց հետո:

Այս փոփոխությունները փորձը դարձրին շատ ավելի հուսալի և ինձ վստահություն տվեցին, որ իմ հավաքած տվյալները իրականում արտացոլում են, թե ինչպես է էկրանի համօգտագործումը վարվում իրական աշխարհում:

Ինչ եմ չափել (և ինչու է դա կարևոր)

Այս թեստերի ընթացքում ես հավաքեցի շատ տվյալներ, բայց ամեն ինչ պարզ և համեմատելի լինելու համար, ես կենտրոնացա մի քանի հիմնական չափումների վրա, որոնք իսկապես պատմում են այն մասին, թե ինչպես է յուրաքանչյուր կոդեկ աշխատում էկրանի համօգտագործման սցենարում:

Ահա թե ինչ նայեցի.

• Շրջանակի արագություն
  Սա ինձ ասում է, թե վայրկյանում քանի կադր է իրականում կոդավորվել, ուղարկվել և ստացվել: Դա լավ ցուցանիշ է, թե որքան հարթ է վիդեո հոսքը. ավելի բարձր կադրերի արագությունը սովորաբար նշանակում է ավելի հեղուկ փորձ:
• Բանաձեւ
  Բանաձևն այն է, թե որքան տեսողական մանրամասներ են պահպանվել: Ես հետևում էի յուրաքանչյուր փուլի մեկ կադրի պիքսելների քանակին (ուղարկված և ստացված), որպեսզի տեսնեմ՝ արդյոք կոդեկները պահպանում են պատկերի որակը, թե թողնում են այն՝ խնայելու թողունակությունը:
• Տեսանյութի որակ
  Այստեղ ես օգտագործել եմ մի քանի հիմնական չափումներ.
  • Քվանտացման պարամետր (QP) – Ավելի ցածր QP, ընդհանուր առմամբ, նշանակում է ավելի լավ որակ:
  • Պիկ ազդանշան-աղմուկ հարաբերակցությունը (PSNR) – Սա թվային պատկերացում է տալիս, թե որքանով է ստացված տեսանյութը տարբերվում բնօրինակից: Ավելի բարձր = ավելի լավ:
• CPU-ի օգտագործումը
  Կոդեկի կատարումը ոչ միայն այն է, ինչ տեսնում եք, այլ նաև այն մասին, թե ինչ է անում ձեր մեքենան կուլիսներում: Ես չափեցի, թե պրոցեսորի որքան հզորություն է օգտագործվել կոդավորման և վերծանման համար յուրաքանչյուր թեստի ժամանակ, որը նորմալացվել է ժամանակի ընթացքում, որպեսզի տեսնեմ, թե որ կոդեկներն են թեթև, և որոնք են ռեսուրսային խոզուկները:

Այս ցուցանիշների հետ տարանջատելով՝ ես կարողացա համեմատել կոդեկները ոչ միայն որակի, այլև սահունության, արդյունավետության և պահանջկոտության առումով: Դա օգնեց պարզել, թե որտեղ է յուրաքանչյուր կոդեկ փայլում, և որտեղ է այն պայքարում, իրական աշխարհի էկրանի համօգտագործման պայմաններում:

Վերջապես գալիս ենք Արդյունքներին

Որքանո՞վ է կարևոր բովանդակության տեսակը: Շատ ավելին, քան դուք կմտածեիք

Իմ փորձարկումների ամենազարմանալի արդյունքներից մեկն այն էր, թե որքանով է ձեր կողմից տարածվող բովանդակության տեսակն ազդում էկրանի համօգտագործման աշխատանքի վրա՝ և՛ տեսանյութի որակի, և՛ ռեսուրսների օգտագործման առումով: Եվ սա ճիշտ էր իմ փորձարկած յուրաքանչյուր կոդեկի համար:

Դրա գաղափարը բավականին պարզ է. երբ ավելի շատ պիքսելներ փոխվում են շրջանակից կադր (ինչպես արագ շարժվող տեսանյութում), համակարգը պետք է ավելի շատ աշխատի: Դա նշանակում է, որ անհրաժեշտ է ավելի շատ թողունակություն, և ձեր պրոցեսորը պետք է ավելի շատ աշխատի, որպեսզի հետևի:

Օրինակ վերցրեք AV1-ը : Երբ ես օգտագործում էի այն 1,5 մեգապիքսելանոց էկրանով կիսվելու համար, պահանջվող թողունակությունը շատ էր տարբերվում՝ կախված նրանից, թե ինչ էր կիսվում: Մի դեպքում, որտեղ բովանդակությունն ավելի դինամիկ էր, AV1-ը ստիպված էր զգալիորեն ավելի շատ տվյալներ մղել հոսքը հարթ պահելու համար: Ես սա ֆիքսեցի հետևյալ գրաֆիկում , որը ցույց է տալիս, թե որքան կտրուկ է բովանդակության բարդությունն ազդում թողունակության օգտագործման վրա:

Բայց դա միայն թողունակությունը չէ. ձեր սարքավորումը նույնպես զգում է դա:

Հաջորդ գրաֆիկը ցույց է տալիս, թե ինչպես է փոխվում պրոցեսորի օգտագործումը՝ ելնելով համօգտագործվող բովանդակությունից: Կրկին, օգտագործելով AV1-ը որպես օրինակ, դուք կարող եք հստակ տեսնել, որ ավելի բարդ վիզուալները պահանջում են շատ ավելի շատ պրոցեսորի հզորություն, որպեսզի գործերը աշխատեն նույն կադրերի արագությամբ և լուծաչափով:

Սա նաև միայն AV1 բան չէ: Բոլոր կոդեկները հիմնվում են տեսանյութի կոդավորման և վերծանման նույն հիմնական սկզբունքների վրա, այնպես որ դուք պետք է ակնկալեք, որ նրանք կցուցաբերեն նմանատիպ վարքագիծ, բայց տվյալները այլ պատմություն են պատմում: CPU-ի ծանրաբեռնվածությունը չի փոխվում միայն բովանդակության հետ, այն փոխվում է նաև այն կոդեկի հիման վրա, որը դուք օգտագործում եք:

Որպեսզի դա ավելի հեշտ լինի համեմատել, ես հավաքեցի հետևյալ աղյուսակը , որը ցույց է տալիս, թե յուրաքանչյուր կոդեկ որքան պրոցեսոր է օգտագործում 1,5 մեգապիքսել վիդեո հեռարձակելիս մոտ 24 կադր/վրկ արագությամբ՝ բավականին տիպիկ կարգավորում՝ հարթ էկրանով կիսվելու համար: Արդյունքները ընդգծում են որոշ հիմնական տարբերություններ, թե որքան արդյունավետ է յուրաքանչյուր կոդեկ, երբ խոսքը վերաբերում է ձեր սարքաշարի օգտագործմանը:

Այսպիսով, եթե դուք կառուցում կամ օպտիմիզացնում եք ինչ-որ բան, որը հիմնված է WebRTC էկրանի համօգտագործման վրա, այն պարզ է. կարևոր է և՛ ձեր բովանդակությունը, և՛ կոդեկի ընտրությունը: Շատ.

Codec Showdown. Frame rates, CPU-ի բեռնվածություն և որակի իրական ծախսեր

Երբ խոսքը վերաբերում է էկրանի համօգտագործմանը, առաջին բաներից մեկը, որ դուք նկատում եք, այն է, թե որքան հարթ է (կամ ոչ) տեսանյութը: Հենց այստեղ է ի հայտ գալիս կադրերի արագությունը : Եթե դուք կիսվում եք բարձր շարժման բովանդակությամբ, օրինակ՝ տեսանյութերի նվագարկումով կամ անիմացիաներով, ապա ավելի բարձր կադրերի արագությունը կարևոր է, որպեսզի խուսափեք անկայուն և դժվար դիտվող հոսքերից:

Փորձի այս մասի համար ես կենտրոնացա տարբեր կոդեկների շրջանակների արագության վրա, մինչդեռ մնացած ամեն ինչ անփոփոխ էր՝ նույն լուծաչափը (մոտ 1,5 մեգապիքսել) և նույն բովանդակությունը յուրաքանչյուր թեստի համար: Ես օգտագործեցի contentHint WebRTC կարգավորումը՝ համոզվելու համար, որ լուծումը կողպված է ամբողջ տախտակում:

Հետևյալ նկարում դուք կարող եք տեսնել, թե ինչպես են տարբեր կոդեկներ մշակում բարձր շարժման բովանդակությունը, քանի որ թողունակությունը մեծանում է: X առանցքի վրա՝ բիթային արագություն Մբիթ/վրկ-ով: Y առանցքի վրա՝ կադրերի արագությունը վայրկյանում կադրերով (fps):

Ահա թե ինչն է աչքի ընկել.

• H.264-ը և AV1-ը առաջ են քաշվել մեկ անգամ, երբ թողունակությունը հասել է 2 Մբիթ/վրկ կամ ավելի, երկուսն էլ ապահովելով 20+ կադր/վրկ. սահուն փորձ, որը հասանելի է նույնիսկ պատշաճ 3G կապի դեպքում:
• VP8-ը և VP9-ը նույնպես չեն պահպանվել: Նրանք նույն պայմաններում սավառնում էին կադրերի արագության մոտավորապես կեսի վրա, և իսկապես անհրաժեշտ էր 4 Մբիթ/վրկ կամ ավելի՝ օգտագործելի զգալու համար, ինչը միշտ չէ, որ իրատեսական է ցածր մակարդակի ցանցերում:

Այնուհետև ես տեղափոխվեցի ցածր շարժման բովանդակություն ՝ դանդաղ պտտվող տեքստային էջ՝ տեսնելու, թե ինչպես են աշխատում կոդեկները, երբ շրջանակների միջև շատ բան չի փոխվում:

Զարմանալի չէ, որ և՛ H.264-ը , և՛ AV1-ն ավելի լավ էին գործում այս սցենարում, և AV1-ը դուրս եկավ առաջին տեղում : Դա պայմանավորված է Intra Block Copy կոչվող ֆունկցիայի շնորհիվ, որը թույլ է տալիս AV1-ին բաց թողնել էկրանի չփոփոխված մասերի վերակոդավորումը: Այն աներևակայելի արդյունավետ է ստատիկ կամ կիսաստատիկ էկրանով կիսվելու համար:

Հաջորդ գրաֆիկում դուք կարող եք տեսնել, թե որքան արդյունավետ է AV1-ը կառավարում այս ցածր շարժման իրավիճակները՝ պահպանելով թողունակության օգտագործումը տպավորիչ ցածր՝ պահպանելով բարձր տեսողական որակը:

Բայց… կա փոխզիջում:

AV1-ը կարող է ձեզ ավելի լավ տեսողական պատկերներ և սեղմում տալ, բայց այն նաև ավելի շատ պրոցեսոր է խլում : Հաջորդ նկարը հստակ ցույց է տալիս սա. AV1-ի պրոցեսորի օգտագործումը անշեղորեն բարձրանում է, քանի որ բիթերի արագությունը մեծանում է՝ գերազանցելով H.264-ը երկար կրակոցով: H.264-ն այստեղ մեծ առավելություն ունի՝ շնորհիվ համատարած ապարատային արագացման , որը պահպանում է իր պրոցեսորի ծանրաբեռնվածությունը ցածր և կայուն:

Հետաքրքիր է, որ VP9-ն ավելի շատ պրոցեսոր է օգտագործում, քան AV1-ը՝ հետևելով նմանատիպ միտումին, բայց ավելի բարձր գագաթներով: Թե՛ VP9-ը, և թե՛ AV1-ը հենվում են բարդ ալգորիթմների վրա՝ լավ որակ ապահովելու համար, բայց դա ունի ծախսեր. դրանք մեծ հարվածներ են հասցնում ձեր պրոցեսորին:

Մի շրջադարձ եղավ, երբ ես վերանայեցի ցածր շարժման բովանդակությունը : Այս անգամ VP8-ը և VP9-ն իրականում բավականին արդյունավետ տեսք ունեին՝ օգտագործելով ավելի քիչ պրոցեսոր, քան AV1-ը, ինչպես ցույց է տրված հաջորդ գրաֆիկում :

AV1-ը, չնայած նախագծված էր էկրանի փոխանակման համար, այնուամենայնիվ օգտագործում էր ամենաշատ պրոցեսորը: Ինչո՞ւ։ Բոլոր այն օպտիմիզացիաները, որոնք օգնում են սեղմել բարձր շարժման տեսանյութերը, նաև ավելացնում են ծախսերը, նույնիսկ երբ էկրանին շատ բան չի կատարվում:

Սրա մեծ պատճառ. AV1-ը դեռևս չունի ապարատային կոդավորման լայնածավալ աջակցություն : Թեև ապակոդավորումը համեմատաբար թեթև է, կոդավորումը դեռ հիմնականում կատարվում է ծրագրային ապահովման միջոցով, և դա պրոցեսորային աշխատանք է, հատկապես իրական ժամանակի սցենարներում, ինչպիսիք են էկրանի փոխանակումը, որտեղ և՛ կոդավորումը, և՛ վերծանումը տեղի են ունենում անընդհատ:

Այստեղ է, որ դյուրակիր սարքերի համար, ինչպիսիք են նոութբուքերը և պլանշետները, ամեն ինչ բարդ է դառնում: Առանց ապարատային արագացման, AV1-ի նման կոդեկները կարող են արագ սպառել էներգիան և խոզի ռեսուրսները, ինչը իդեալական չէ, երբ դուք շարժման մեջ եք: Քանի դեռ ավելի լավ ապարատային աջակցությունը դառնում է ավելի տարածված, AV1-ի առաջադեմ գործառույթներն ունեն բավականին նկատելի կատարողական արժեք:

Կոդեկներ և լուծում. ի՞նչ է պատահում, երբ առաջնահերթություն եք տալիս շրջանակի արագությանը:

Մինչ այժմ, արդյունքները, որոնք ես կիսվել եմ, եկել են թեստերից, որոնք թույլ են տվել կայունություն: Երբ թողունակությունը սահմանափակվում էր, համակարգը կպատասխաներ՝ նվազեցնելով կադրերի արագությունը , ինչը իմաստ ունի այնպիսի բաների համար, ինչպիսիք են ստատիկ բովանդակությունը կամ տեքստը: Բայց ի՞նչ, եթե նպատակը ամեն ինչ սահուն ընթացք տալն է, նույնիսկ եթե դա նշանակում է լուծումը զոհաբերել:

Սա ուսումնասիրելու համար ես փորձարկեցի մի նոր շարք, որտեղ WebRTC-ն կազմաձևված էր՝ փոխարենը առաջնահերթություն տալով կադրերի արագությանը : Դա արվել է WebRTC-ում contentHint պարամետրի միջոցով, որը թույլ է տալիս զննարկիչին ասել, թե որն է ավելի կարևոր՝ բարձր լուծաչափը կամ հարթ շարժումը:

Ես նպատակ էի դրել պահպանել կադրերի արագությունը հետևողական 30 կադր/վրկ , որը լայնորեն ճանաչված է որպես հարթ, հարմարավետ դիտման քաղցր կետ: Դրան հետևողականորեն ստանալը դժվար էր. հարմարվողական հոսքը նշանակում է, որ միշտ մի փոքր տատանումներ կան, բայց արդյունքները արժեքավոր պատկերացում տվեցին այն մասին, թե ինչպես է յուրաքանչյուր կոդեկ վարում այս փոխզիջումը:

Այս վարքագիծը վերլուծելու համար ես ներկայացրեցի նոր չափանիշ.

Ուղարկված պիքսելներ վայրկյանում = Կադրերի արագություն × լուծաչափ

Սա ավելի ամբողջական պատկեր է տալիս, քան միայն FPS-ին կամ լուծաչափին նայելը: Այն ցույց է տալիս, թե որքան տեսողական տվյալներ է իրականում կոդեկը փոխանցում վայրկյանում տարբեր պայմաններում:

Բարձր շարժման տեսահոլովակների համար AV1-ը ևս մեկ անգամ հայտնվեց առաջին տեղում և նկատելի տարբերությամբ: Նույնիսկ ավելի ցածր բիթային արագությամբ, այն կարողացավ վայրկյանում զգալիորեն ավելի շատ պիքսել փոխանցել, քան ցանկացած այլ կոդեկ: Սա հստակ ցույց է տալիս, թե որքան լավ է AV1-ը կառավարում դինամիկ բովանդակությունը, երբ համակարգը ճնշման տակ է բարձր կադրերի արագությունը պահպանելու համար: Խնդրում ենք տեսնել հետևյալ գրաֆիկը .

Երբ ես անցա ցածր շարժման բովանդակությանը, օրինակ՝ ոլորող տեքստով վեբ էջին, խաղադաշտը մի փոքր ավելի մակարդակ ստացավ: Բոլոր կոդեկների կատարումը դարձավ ավելի միատեսակ, ինչպես կարող եք գտնել հաջորդ նկարում : Այնուամենայնիվ, AV1-ը դեռևս պահպանել է առաջատարությունը , հատկապես ավելի բարձր բիթային արագությամբ: Նրա սեղմման օպտիմալացումները օգնեցին նրան պահպանել հզոր թողունակություն՝ առանց ռեսուրսների օգտագործման էապես մեծացնելու:

Ի՞նչ է նշանակում այս ամենը գործնականում։

Դե, եթե ձեր օգտագործման դեպքը ներառում է դինամիկ, բարձր շարժման վիզուալներ, ինչպիսիք են վիդեո զննումները, կենդանի անիմացիաները կամ խաղերի հոսքը, առաջնահերթությունը կադրերի արագությունը կարող է մեծ տարբերություն ունենալ , և AV1-ը հատկապես ունակ է այդ միջավայրում:

Նույնիսկ ավելի դանդաղ շարժվող բովանդակության դեպքում AV1-ը շարունակում է ուժ ցույց տալ: Թեև տարբերությունը կարող է ավելի փոքր լինել, այն հետևողականորեն կարողանում է ավելի շատ տեսողական տվյալներ ուղարկել, ինչը նշանակում է ավելի լավ որակ նույն կամ ավելի ցածր թողունակությամբ, շնորհիվ իր առաջադեմ սեղմման ռազմավարությունների:

Երկու դեպքում էլ «ուղարկված պիքսելներ վայրկյանում» չափորոշիչն օգտակար է եղել հասկանալու համար, թե ինչպես են կոդեկները հավասարակշռում լուծաչափը և շրջանակի արագությունը, երբ թողունակությունը սահմանափակ է: Եվ AV1-ի աշխատանքը այս պայմաններում ավելի է ամրացնում այն որպես ամենահզոր տարբերակ՝ պայմանով, որ ձեր համակարգը կարողանա հաղթահարել CPU-ի լրացուցիչ պահանջները:

Որքանո՞վ է մաքուր պատկերը: Եկեք խոսենք PSNR

Կադրերի արագությունից, լուծաչափից և պրոցեսորի օգտագործումից բացի, էկրանի համօգտագործման գլուխկոտրուկի ևս մեկ կարևոր կետ կա. որքանո՞վ է ստացված պատկերը մոտ բնօրինակին: Հենց այստեղ է հայտնվում գագաթնակետային ազդանշան-աղմուկ հարաբերակցությունը (PSNR) :

PSNR-ը լայնորեն օգտագործվող չափիչ է՝ սեղմված տեսանյութի որակը չափելու համար: Այն պատմում է ձեզ, թե որքան աղավաղում կամ «աղմուկ» է ներմուծվել կոդավորման ընթացքում: Այն չափվում է դեցիբելներով (dB) , և հիմնական կանոնը պարզ է՝ որքան բարձր, այնքան լավ : Բարձր PSNR նշանակում է, որ պատկերը գրեթե նույնն է, ինչ բնօրինակը. ցածր միավորը նշանակում է, որ ավելի տեսանելի դեգրադացիա կա:

Դա համատեքստի մեջ դնելու համար ես փորձարկեցի PSNR արժեքները կոդեկների մեջ երկու տարբեր սցենարներով. մեկը, որտեղ լուծումը առաջնահերթություն է, և մյուսը, որտեղ շրջանակի արագությունը առաջատար է: Երկու թեստերն էլ օգտագործեցին նույն բարձր շարժման տեսանյութերի բովանդակությունը ՝ իրերը հետևողական պահելու համար:

Այս կարգավորումներում, որտեղ հստակությունն է ուշադրության կենտրոնում (նույնիսկ եթե տեսանյութն ավարտվում է մի փոքր անկայուն), H.264-ը հատկապես լավ է հանդես գալիս ՝ տրամադրելով սուր վիզուալներ՝ նվազագույն աղավաղմամբ: Դա ուժեղ ընտրություն է, երբ հարթությունը այնքան էլ կարևոր չէ:

Երբ նպատակը տեղափոխվում է հեղուկ շարժման պահպանում, AV1-ն առաջ է գալիս , հատկապես ավելի բարձր բիթային արագությամբ: Այն կարողանում է պահպանել պատկերի որակը նույնիսկ ագրեսիվ սեղմելիս՝ հարվածելու կադրերի արագության թիրախներին:

Թեև կոդեկների միջև PSNR-ի տարբերությունները միշտ չէ, որ դրամատիկ են, դրանք ընդգծում են այն փոխզիջումները, որոնք դուք անում եք կոդեկ ընտրելիս: Ոմանք առաջնահերթություն են տալիս սրությանը. մյուսները նպատակ ունեն հարթ շարժման, և կախված ձեր օգտագործման դեպքից, մեկը կարող է ավելի հարմար լինել, քան մյուսը:

Այնուհետև ես նորից անցկացրի նույն թեստերը, այս անգամ օգտագործելով ոլորված տեքստի բովանդակությունը . մի բան, որն իսկապես ընդգծում է լուծման և հստակության կարևորությունը:

Երբ շարժումը առաջնահերթ է, PSNR արժեքները բոլոր կոդեկներում բավականին նման են: Բովանդակությունը շատ չի փոխվում, ուստի սեղմման ռազմավարության տարբերությունները մեծ ազդեցություն չեն ունենում ընդհանուր պատկերի որակի վրա:

Այստեղ ամեն ինչ հետաքրքիր է դառնում: Որպես առաջնահերթ լուծում ունենալով՝ AV1-ը շատ առաջ է անցնում մյուս կոդեկներից՝ հատկապես ավելի բարձր բիթային արագությամբ: Այստեղ նրա կատարումը բացառիկ է։

Ինչո՞ւ։ AV1-ը ներառում է հատուկ օպտիմալացումներ՝ տեքստի նման ստատիկ, կրկնվող բովանդակության հետ աշխատելու համար: Դրանք թույլ են տալիս պահպանել ավելի բարձր պատկերի հավատարմություն , խուսափել արտեֆակտներից և ավելի արդյունավետ սեղմել: Դա AV1-ը դարձնում է ֆանտաստիկ ընտրություն օգտագործման դեպքերի համար, ինչպիսիք են փաստաթղթերի փոխանակումը կամ կոդերի զննումը՝ ամենուր, որտեղ այդ հստակ, ընթեռնելի մանրամասներն իսկապես կարևոր են :

Մի խոսքով, PSNR-ն օգնում է ընդգծել էկրանի համօգտագործման որակի նուրբ, բայց կարևոր հարթությունը: Անկախ նրանից, թե դուք առաջնահերթություն եք տալիս շարժմանը կամ հստակությանը, հասկանալով, թե ինչպես են կոդեկներն իրենց պահում տարբեր սահմանափակումների ներքո, թույլ է տալիս ընտրել ճիշտը աշխատանքի համար:

Ի՞նչ գործարք կա QP-ի հետ: Հասկանալով սեղմումն ընդդեմ որակի

Մեկ այլ կարևոր գործոն էկրանի համօգտագործման որակի մեջ մի բան է, որը կոչվում է Քվանտացման պարամետր կամ QP : Եթե երբևէ մտածել եք, թե ինչն է վերահսկում, թե որքան մանրուք է կորչում սեղմման ընթացքում, սա է:

Պարզ ասած, QP-ն կոդավորողին ասում է, թե որքան ագրեսիվ կերպով սեղմի տեսանյութը :

• Ցածր QP-ն նշանակում է ավելի քիչ սեղմում և ավելի լավ պատկերի որակ:
• Բարձր QP-ն նշանակում է ավելի շատ սեղմում, ինչը խնայում է թողունակությունը, բայց կարող է վատթարացնել տեսանյութը:

Մինչ PSNR-ը մեզ տալիս է արդյունք՝ որքան պատկերի որակ է պահպանվել, QP-ն մեզ ասում է, թե ինչին էր ուղղված կոդավորիչը : Այսպիսով, ես նայեցի երկուսին:

Այս ուսումնասիրության մեջ.

• QP արժեքները վերցվել են ստանդարտ WebRTC չափիչներից:
• PSNR-ը չափվել է փաստից հետո՝ յուրաքանչյուր օրիգինալ շրջանակ համեմատելով իր ստացված տարբերակի հետ:

Ահա թե որտեղ են իրադարձությունները հետաքրքիր: AV1-ն ուներ լավագույն PSNR միավորները , ինչը նշանակում է, որ այն պահպանում էր պատկերի որակը լավագույնս, բայց նաև ուներ QP արժեքներ մինչև չորս անգամ ավելի բարձր, քան մյուս կոդեկները: Դա առաջին հայացքից հակասական է թվում։

Բայց ահա գրավչությունը. յուրաքանչյուր կոդեկ տարբեր կերպ է սահմանում և մշակում QP-ն , ուստի արժեքներն ուղղակիորեն համեմատելի չեն: 50 QP-ն մի կոդեկում պարտադիր չէ, որ նշանակում է սեղմման նույն մակարդակը, ինչ 50 QP-ն մյուսում:

Այնուամենայնիվ, QP միտումները մեզ օգտակար բան են ասում: Բոլոր կոդեկներում ես նկատեցի, որ երբ թողունակությունը մեծանում է, QP-ն նվազում է : Դա իմաստ ունի. ավելի շատ թողունակության առկայության դեպքում կոդեկները կարող են իրենց թույլ տալ նվազեցնել սեղմումը և բարելավել պատկերի որակը:

Այսպիսով, չնայած մենք չենք կարող շարել QP համարները կողք կողքի կոդեկների միջով, դրանք դեռ ցույց են տալիս, թե ինչպես է յուրաքանչյուր կոդեկ դինամիկ կերպով կարգավորում սեղմումը` հիմնվելով հասանելի ցանցի պայմանների վրա:

Ստորին գիծ. QP-ն որակի գնահատական չէ, դա կարգավորում է : Բայց հետևելը, թե ինչպես է այն փոխվում թողունակության հետ, օգտակար պատկերացում է տալիս այն մասին, թե ինչ է անում կոդավորիչը կուլիսներում: Եվ PSNR-ի հետ համակցված, այն տալիս է կոդեկի վարքագծի ավելի ամբողջական պատկեր:

Վերջնական մտքեր. ինչ է այս ամենը նշանակում WebRTC էկրանի համօգտագործման համար

Այն բանից հետո, երբ խորը սուզվել է, թե ինչպես է WebRTC-ն աշխատում գլխարկի տակ, մի բան պարզ է. ոչ բոլոր կոդեկներն են հավասար ստեղծված , և լավագույն ընտրությունն իսկապես կախված է ձեր առաջնահերթություններից և միջավայրից:

Ահա իմ փորձերի հիմնական ակնարկները.

AV1. Լավագույն որակ, ամենաբարձր արժեքը

AV1-ը հետևողականորեն ապահովում էր տեսողական լավագույն որակը , անկախ նրանից՝ ես կիսվում էի արագ շարժվող տեսանյութով կամ դանդաղ պտտվում տեքստով: Նրա առաջադեմ սեղմումն ու օպտիմալացումն այն դարձնում են աներևակայելի արդյունավետ, բայց դա ունի գին: AV1-ը պրոցեսորի կարիք ունի, և քանի որ ապարատային աջակցությունը դեռ շարունակում է հասնել, այն դեռ իդեալական չէ ցածր էներգիայով կամ շարժական սարքերի համար:

H.264. The Solid All Rounder

Եթե դուք հավասարակշռություն եք փնտրում կատարողականի և արդյունավետության միջև , ապա H.264-ը դեռ հիանալի ընտրություն է: Այն լայնորեն աջակցվում է, ապարատային արագացված է շատ հարթակներում և լավ աշխատանք է կատարում գրեթե բոլոր սցենարներում, հատկապես, երբ մտահոգիչ են համակարգի ռեսուրսները կամ մարտկոցի ժամկետը:

Բովանդակությունը ավելի կարևոր է, քան կարծում եք

Բովանդակության տեսակը, որը դուք կիսում եք, մեծ ազդեցություն ունի կատարողականի վրա: Բարձր շարժման տեսանյութը շատ ավելին է պահանջում ձեր պրոցեսորից և թողունակությունից, քան ստատիկ բովանդակությունը, օրինակ՝ փաստաթղթերը կամ տեքստը: Ձեր բովանդակության համար ճիշտ կոդեկ և ճիշտ կարգավորումներ ընտրելը կարող է հսկայական տարբերություն ունենալ որակի և ռեսուրսների օգտագործման մեջ:

CPU-ի օգտագործումը պարզապես ծանոթագրություն չէ

Շնորհիվ իմ ստեղծած «Chrome» հարմարեցված հավելվածի, ես կարողացա ճշգրիտ չափել պրոցեսորի օգտագործումը էկրանի համօգտագործման ժամանակ: Արդյունքները ցույց տվեցին մեծ տարբերություններ յուրաքանչյուր կոդեկի պահանջկոտության մեջ , ինչը հատկապես կարևոր է դառնում շարժական սարքերում կամ էներգիայի նկատմամբ զգայուն միջավայրերում:

Ի՞նչ է հաջորդը: Ուր կարող է գնալ այս հետազոտությունը

Այս փորձը դուռ բացեց մի քանի հետաքրքիր հաջորդ քայլերի համար: Ահա, որտեղ ես կարծում եմ, որ ապագա աշխատանքը կարող է ավելի մեծ ազդեցություն ունենալ.

Փորձարկում բջջային սարքերի վրա

Մինչ այժմ բոլոր թեստերն արվել են աշխատասեղանի վրա, բայց էկրանի փոխանակումը նույնքան տարածված է (եթե ոչ ավելի) հեռախոսների և պլանշետների վրա: Թեստավորումը, թե ինչպես են այս կոդեկները աշխատում բջջայինում, ավելի ամբողջական պատկերացում կտա, հատկապես արձագանքման և էներգիայի օգտագործման առումով:

Էներգաարդյունավետություն

Խոսելով էներգիայի մասին, կոդեկները ոչ միայն այրում են պրոցեսորը, այլև մարտկոցի կյանքը : Հետագա հետազոտությունները պետք է ուսումնասիրեն, թե որ կոդեկներն են առավել էներգաարդյունավետ , հատկապես շարժական սարքերում էկրանի փոխանակման երկար նիստերի համար:

AI-Powered Codec Tuning

Պատկերացրեք, եթե WebRTC-ն կարողանա ավտոմատ կերպով կարգավորել կոդեկների կարգավորումները՝ հիմնված ձեր ընթացիկ բովանդակության և ցանցի արագության վրա: AI-ն կարող է դա հնարավոր դարձնել ՝ դինամիկ կերպով իրական ժամանակում գտնելով կատարյալ հավասարակշռություն որակի և կատարողականի միջև:

Փաթաթելով այն

Կոդեկի ընտրությունն ավելին է, քան պարզապես տեխնիկական որոշում. այն ուղղակիորեն ազդում է էկրանի փոխանակման ձեր փորձի որակի, սահունության և ռեսուրսների օգտագործման վրա : Անկախ նրանից՝ դուք կառուցում եք տեսահամաժողովի գործիք, համագործակցության հարթակ, թե պարզապես օպտիմիզացնում եք ձեր սեփական աշխատանքային հոսքերը, հասկանալով, թե ինչպես են այս կոդեկներն իրենց պահում տարբեր պայմաններում, կարող է օգնել ձեզ ավելի խելացի և արդյունավետ որոշումներ կայացնել:

Քանի որ WebRTC-ն շարունակում է զարգանալ, դրա շուրջ գործիքներն ու տեխնիկան նույնպես կզարգանան: Հուսով եմ, որ այս խորը սուզումն օգնում է մյուսներին ավելի լավ հասկանալ, թե ինչ է կատարվում կուլիսների հետևում և ինչպես առավելագույն օգուտ քաղել էկրանի համօգտագործման փաթեթից:

Ցանկանու՞մ եք ինքներդ ուսումնասիրել տվյալները:

Եթե դուք հետաքրքրված եք ավելի խորանալ արդյունքների մեջ կամ կատարել ձեր սեփական վերլուծությունը, ես այս ուսումնասիրության ամբողջական տվյալների բազան հասանելի եմ դարձրել այստեղ.

Ներբեռնեք տվյալների հավաքածուն Kaggle-ում

Այն ներառում է կադրերի արագության, լուծաչափի, PSNR-ի, QP-ի, պրոցեսորի օգտագործման և ավելին չմշակված չափումներ՝ բոլորը կազմակերպված են ըստ կոդեկի, բովանդակության տեսակի և թողունակության վիճակի: Ազատորեն օգտագործեք այն ձեր սեփական փորձերի, չափորոշիչների կամ պարզապես ուսումնասիրելու համար, թե ինչպես է WebRTC-ն իրեն պահում տարբեր սցենարներում: