Ցածր ուշացում UDP H.264/H.265 Player SDK Windows x64-ի համար – Պատվերով UDP Demux լուծում Python/Qt հավելվածների համար
Շատ ծրագրավորողներ, որոնք օգտագործում են HDMI/CVBS/UVC դեպի IP կոդավորիչ տախտակներ, ի վերջո բախվում են նույն մարտահրավերին:
RTSP-ի հետաձգումը չափազանց բարձր է.
Պրոֆեսիոնալ իրական ժամանակի ծրագրերի համար, ինչպիսիք են:
- Անօդաչու սարքերի տեսահաղորդում
- Ռոբոտաշինություն
- Արդյունաբերական մոնիտորինգ
- FPV համակարգեր
- AI տեսողության մշակում
- Ցածր հետաձգման հեռարձակում
- Անվտանգության համակարգեր
- Բժշկական պատկերացում
- Պատվերով վիդեո պատեր
նույնիսկ 100ms ուշացումը կարող է արդեն չափազանց շատ լինել.
Վերջերս, մեր հաճախորդներից մեկը կապվեց մեզ հետ՝ շատ պրոֆեսիոնալ պահանջով:
«Մենք մշակում ենք մեր սեփական ցածր լատենտային նվագարկիչի ծրագրակազմը ձեր կոդավորման տախտակի համար. RTSP-ի հետաձգումը չափազանց մեծ է. Մենք ցանկանում ենք ուղղակիորեն ստանալ անհատականացված UDP հոսքը և կառուցել մեր սեփական ապակոդավորիչ/ցուցադրման խողովակաշարը»:
Սա հենց այն վայրն է, որտեղ կարևոր են դառնում SPlayer SDK-ն և հատուկ UDP դեմուքս լուծումը.
Բովանդակություն
Ինչու FFmpeg-ը կամ VLC-ն չեն կարող խաղալ UDP Stream-ը
Ընդհանուր հարց է:
«Ինչու է ffplay udp://xxx-ը չի աշխատում?»
Պատճառը պարզ է:
Կոդավորիչը ՉԻ օգտագործում ստանդարտ MPEG-TS կամ ստանդարտ RTP UDP-ի վրա.
Փոխարեն, սարքն օգտագործում է սեփական/մասնավոր UDP տրանսպորտային արձանագրություն, որն օպտիմիզացված է ծայրահեղ ցածր ուշացման փոխանցման համար.
UDP փաթեթները կարող են պարունակել:
- Մասնավոր վերնագրեր
- Շրջանակի ինդեքս
- Ժամացույց
- Հատված վիդեո փաթեթներ
- Աուդիո տվյալներ
- Սերիական/UART տվյալներ
Սրա պատճառով, ստանդարտ խաղացողներ, ինչպիսիք են:
- VLC
- ffplay
- Գրազ
չի կարող ուղղակիորեն վերծանել հոսքը.
Պահանջվում է հատուկ դեմուքս շերտ.
SPlayer SDK Architecture
SPlayer SDK Windows-ի համար նախատեսված է հատուկ այդ նպատակով.
Տիպիկ ճարտարապետություն:
Encoder
↓
Custom UDP protocol
↓
SPlayer Demux SDK
↓
H.264 / H.265 Elementary Stream
↓
Custom Decoder
↓
Custom Renderer / Display
Ամբողջական ներքին հոսքը սովորաբար:
demux → decode → display → record
SDK-ն հատկապես օգտակար է ծրագրավորողների համար, ովքեր ցանկանում են:
- Կառուցեք իրենց սեփական նվագարկիչի ծրագրակազմը
- Ինտեգրվել Python/Qt-ին
- Օգտագործեք DirectX/OpenGL մատուցում
- Նվազեցնել բուֆերացումը
- Ձեռք բերեք ծայրահեղ ցածր հետաձգման ցուցադրում
RTSP ընդդեմ Custom UDP Latency
Տիպիկ ուշացման համեմատություն:
| Արձանագրություն | Տիպիկ ուշացում |
|---|---|
| RTSP | 150~ 500 մս |
| Ստանդարտ RTP/UDP | 80~ 150 մս |
| Պատվերով UDP արձանագրություն | 20~ 80 մս |
Մեկ հաճախորդ հայտնել է:
- Ընթացիկ ուշացում: ~ 100 մս
- Թիրախային ուշացում: ~ 60 մս
Սա իրատեսական է:
- հարմարեցված նվագարկիչի ծրագրակազմ
- օպտիմիզացված բուֆերավորում
- ուղղակի UDP demux
- ապարատային արագացված վերծանում
Կարո՞ղ ենք խաղացող ստեղծել Python-ում?
այո.
Սա ևս մեկ ընդհանուր հարց է.
Հաճախորդը հարցրեց:
«Ինչպես կարող ենք իրականացնել վիդեո նվագարկիչը Python-ում?»
Կարևոր կետն այն է:
Python-ը պատասխանատու չէ ինքն իրեն պատկանող UDP արձանագրության վերլուծության համար.
Փոխարեն, ճարտարապետությունը սովորաբար այսպիսի տեսք ունի:
Python/Qt UI
↓
ctypes / cffi / pybind11
↓
SPlayer SDK DLL
↓
H264/H265 elementary stream
↓
FFmpeg / PyAV decode
↓
OpenGL / DirectX rendering
Python-ը շատ լավ է աշխատում:
- UI
- վերահսկողության տրամաբանությունը
- AI վերամշակում
- բազմալիքային կառավարում
- ցանցի վերահսկում
մինչդեռ SDK DLL-ն իրականացնում է իրական ժամանակի UDP դեմուքսը.
Ինչ են սովորաբար ծրագրավորողներին անհրաժեշտ SDK-ից
Պրոֆեսիոնալ հաճախորդները սովորաբար հարցնում են:
1. Windows x64 աջակցություն
Ժամանակակից ծրագրակազմը պահանջում է:
- Windows x64 DLL
- x64 LIB
- x64 ցուցադրություն
Շատ հին SDK-ներ աջակցում են միայն Win32/x86, որն այլևս բավարար չէ.
2. H.264 / H.265 Տարրական հոսքի ելք
Ամենակարևոր հատկանիշը:
SDK-ն պետք է բացահայտի:
- հում H264/H265 WAVE
- ժամանակային դրոշմանիշներ
- աուդիո շրջանակներ
- սերիական/UART տվյալներ
Սա թույլ է տալիս ինտեգրվել:
- Ffmpeg
- PyAV
- NVIDIA ապակոդավորիչ
- Intel QuickSync
- հատուկ GPU խողովակաշարեր
3. Callback API
Տիպիկ API-ները ներառում են:
on_video_frame(...)
on_audio_frame(...)
on_serial_data(...)
Սա էական նշանակություն ունի ցածր հետաձգման ծրագրերի համար.
4. Կազմողի համատեղելիություն
Մշակողները սովորաբար հարցնում են:
- Visual Studio տարբերակը?
- MSVC գործարկման ժամանակը?
- x64 աջակցություն?
- ստատիկ կամ դինամիկ գործարկման ժամանակ?
- DLL կամ աղբյուրի կոդը?
Այս մանրամասները կարևոր են պրոֆեսիոնալ ծրագրային ապահովման մեջ ինտեգրվելու համար.
Բնորոշ օգտագործման դեպքեր
SDK-ն սովորաբար օգտագործվում է:
- Անօդաչու թռչող սարքերի / անօդաչու թռչող սարքերի վերգետնյա կայաններ
- Իրական ժամանակի հսկողություն
- Արդյունաբերական տեսախցիկներ
- Բժշկական համակարգեր
- Կենդանի արտադրություն
- AI վիդեո վերլուծություն
- Եզրային հաշվարկ
- Վիդեո ռելե համակարգեր
- Պատվերով NVR ծրագրակազմ
Splayer SDK Ներբեռնում
Մեր ինժեները տրամադրել է SDK փաթեթը գնահատման և երկրորդական զարգացման համար:
SDK Ներբեռնման հղում:
https://drive.google.com/file/d/1ifdJtE50YKH3S9JaAV0LCTKZcZgUtN_b/view?usp=drive_link
SDK-ն նախատեսված է մշակողների համար, ովքեր կարիք ունեն:
- ցածր ուշացման UDP ընդունում
- հարմարեցված խաղացողի զարգացում
- H264/H265 demux
- Windows x64 ինտեգրում
- Python/Qt ինտեգրում
- երկրորդական ծրագրային ապահովման մշակում
Վերջնական նշումներ
Եթե ձեր նախագիծը պահանջում է:
- ավելի ցածր ուշացում, քան RTSP-ն
- հատուկ տեսամշակում
- գույքային UDP տրանսպորտ
- Python/Qt նվագարկչի մշակում
- Windows x64 SDK ինտեգրում
ապա հատուկ UDP demux SDK-ի օգտագործումը ճիշտ մոտեցում է.
Ավանդական VLC կամ ffmpeg նվագարկումը կարող է չաշխատել ցածր լատենտային UDP արձանագրությունների հետ.
Մասնագիտական ցածր ուշացման համակարգերը սովորաբար պահանջում են:
- մաքսային դեմուքս
- օպտիմիզացված բուֆերավորում
- ուղղակի ապակոդավորող խողովակաշար
- GPU արագացված մատուցում
Հաջորդ սերնդի իրական ժամանակի տեսահամակարգեր կառուցող մշակողների համար, այս ճարտարապետությունն ապահովում է շատ ավելի լավ լատենտային կատարում, քան ստանդարտ RTSP աշխատանքային հոսքերը.
Հարց տվեք
Ձեր հաղորդագրությունն ուղարկված է