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 -> بلغاری
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 -> مجارستانی
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 -> اسلوونیایی
es.fmuser.org -> اسپانیایی
sw.fmuser.org -> سواحیلی
sv.fmuser.org -> سوئدی
th.fmuser.org -> تایلندی
tr.fmuser.org -> ترکی
uk.fmuser.org -> اوکراینی
ur.fmuser.org -> اردو
vi.fmuser.org -> ویتنامی
cy.fmuser.org -> ولزی
yi.fmuser.org -> ییدیش
بررسی اجمالی رسانه جریان:
اصطلاحاً رسانه جریان به قالب رسانه ای گفته می شود که با استفاده از انتقال جریان در اینترنت پخش می شود.
جریان رسانه ای به عنوان رسانه جریان نیز شناخته می شود ، این بدان معنی است که مشاغل از سرور تحویل ویدئو برای ارسال برنامه ها به عنوان بسته داده به شبکه استفاده می کنند.
بعد از اینکه کاربر داده ها را از طریق دستگاه فشرده سازی از حالت فشرده خارج کرد ، برنامه مانند قبل نمایش داده می شود.
جریان رسانه ای با پخش جریانی فایلهای صوتی ، تصویری و چندرسانه ای را در شبکه انتقال می دهد.
قالب فایل جریان رسانه ای یک قالب رسانه ای است که از انتقال و پخش جریانی پشتیبانی می کند.
حالت انتقال جریان برای تقسیم پرونده های چندرسانه ای مانند فیلم و صدا به بسته های فشرده سازی از طریق حالت فشرده سازی خاص ،
انتقال مداوم و در زمان واقعی از سرور به رایانه کاربر. در سیستم پخش جریانی ، کاربران مجبور نیستند مانند عدم پخش مستقیم ، منتظر کل پرونده باشند
فقط پس از اتمام تمام بارگیری ها ، می توانیم محتویات را ببینیم ، اما فقط پس از چند ثانیه یا ده ها ثانیه تأخیر در شروع کار می توانیم از آنها در رایانه کاربر استفاده کنیم
پخش کننده مربوطه ویدیوی فشرده یا صوتی و سایر پرونده های رسانه جریان را پخش می کند و بقیه تا پایان پخش بارگیری می شوند.
RTP: (پروتکل حمل و نقل در زمان واقعی)
RTP یک پروتکل لایه انتقال برای جریان داده های چندرسانه ای در اینترنت است. RTP همراه با RTCP استفاده می شود و براساس پروتکل UDP است
برخلاف HTTP و FTP ، RTP می تواند کل پرونده ویدیویی را به طور کامل بارگیری کند. داده ها را با نرخ ثابت داده در شبکه می فرستد. مشتری همچنین با این سرعت فایل ویدئو را تماشا می کند. چه زمانی
بعد از پخش تصویر فیلم و تلویزیون ، نمی توان دوباره آن را پخش کرد ، مگر اینکه داده دوباره از سرور درخواست شود.
RTCP: پروتکل کنترل حمل و نقل در زمان واقعی یا RTP (پروتکل کنترل یا RTCP)
RTCP یک پروتکل خواهر RTP است
توجه: -: پروتکل RTP و RTCP با هم استفاده می شوند و براساس پروتکل UDP (معمولاً برای کنفرانس ویدیویی استفاده می شود)
RTSP: (پروتکل جریان واقعی)
پروتکل جلسه رسانه جریان مستقیم در زمان واقعی ، SDP (پروتکل توصیف جلسه) ، RTP (پروتکل حمل و نقل در زمان واقعی).
RTSP یک پروتکل پخش چندرسانه ای است که برای کنترل صدا یا فیلم استفاده می شود. RTSP یک چارچوب قابل توسعه را فراهم می کند ، که امکان کنترل و تقاضای داده های زمان واقعی مانند صدا و تصویر را فراهم می کند.
داده های رسانه از پروتکل RTP ، RTCP استفاده می کنند.
به طور کلی ، UDP به عنوان لایه حمل و نقل استفاده می شود. مناسب برای صحنه های IPTV.
منابع داده شامل داده های میدانی و داده های ذخیره شده در کلیپ ها هستند. هدف این پروتکل کنترل چندین اتصال انتقال داده و ارائه راهی برای انتخاب کانالهای انتقال ، مانند UDP ، UDP چندپخشی و TCP است.
همچنین روشی برای انتخاب مکانیزم انتقال بر اساس RTP فراهم می کند
پروتکل شبکه مورد استفاده در انتقال در محدوده تعریف آن نیست. سرور می تواند از TCP یا UDP برای انتقال محتوای جریان استفاده کند که تحمل بیشتری نسبت به تاخیر شبکه دارد
---> بزرگترین تفاوت RTSP با RTP این است که RTSP یک پروتکل انتقال داده در زمان واقعی دو طرفه است ، که به مشتری اجازه می دهد درخواست هایی مانند پخش ، جلو ، عقب و غیره را به سرور ارسال کند. چه زمانی
با این حال ، RTSP می تواند داده ها را بر اساس RTP منتقل کند و همچنین می تواند TCP ، UDP ، UDP چندپخشی و کانالهای دیگر را برای ارسال داده انتخاب کند که مقیاس پذیری خوبی دارد. مشابه پروتکل HTTP است
پروتکل لایه برنامه شبکه
WebRTC:
پروتکل رسانه های جریانی در وب پیاده سازی می شود. هنگامی که گوگل برای اولین بار webrtc را راه اندازی کرد ، غول ها یا سرد نگاه می کردند یا مقاومت می کردند. پروتکل RTP برای انتقال استفاده می شود.
RTMP (پروتکل پیامرسانی در زمان واقعی)
Macromedia مجموعه ای از پروتکل ویدیوی زنده را توسعه داده است و اکنون به Adobe تعلق دارد. مانند HLS ، می توان آن را روی ویدیوی زنده نیز اعمال کرد و براساس TCP از بین نمی رود.
// تفاوت این است که RTMP نمی تواند در مرورگر IOS بر اساس فلش بازی کند ، اما عملکرد آن در زمان واقعی بهتر از HLS است.
پروتکل پیام رسان در زمان واقعی یک پروتکل باز است که توسط Adobe Systems برای انتقال صدا ، تصویر و داده ها بین فلش پلیر و سرور تهیه شده است
// در کد IOS ، RTMP معمولاً برای فشار دادن جریان استفاده می شود. برای فشار دادن جریان می توانید از کتابخانه شخص ثالث librtmp IOS استفاده کنید. Librtmp برخی از API های اصلی را برای فراخوانی کاربران در خود قرار داده است
پروتکل RTMP همچنین به مشتری و سرور نیاز دارد تا اتصال RTMP را از طریق "دست دادن" برقرار کرده و سپس اطلاعات کنترل را بر روی اتصال انتقال دهد. پروتکل RTMP داده ها را هنگام انتقال قالب بندی می کند. به منظور دستیابی بهتر به مالتی پلکس ، پیمانکاری فرعی و انصاف اطلاعات بهتر ، فرستنده پیام را به بخشهایی با شناسه پیام تقسیم می کند و هر قسمت ممکن است یک پیام جداگانه باشد ،
همچنین ممکن است بخشی از پیام باشد. گیرنده با توجه به طول داده ، شناسه پیام و پیام موجود در قطعه ، قطعه را به یک پیام کامل بازیابی می کند تا اطلاعات را ارسال و دریافت کند.
HLS: پخش جریانی مستقیم HTTP (HLS)
این یک پروتکل انتقال جریان جریان مبتنی بر HTTP است که توسط Apple Inc اجرا شده است ،
این می تواند رسانه های جریان مستقیم و درخواستی را که عمدتا در سیستم IOS استفاده می شوند ، تحقق بخشد
برای ارائه راه حل های صوتی و تصویری زنده و درخواستی برای دستگاه های IOS (مانند iPhone و iPad).
HLS در صورت تقاضا در واقع یک HTTP تقسیم تقسیم شده معمول در تقاضا است. تفاوت در این است که بخشهای آن بسیار کوچک هستند.
در مقایسه با پروتکل های رایج جریان مستقیم ، مانند پروتکل RTMP ، پروتکل RTSP ، پروتکل MMS و غیره ، بزرگترین تفاوت جریان مستقیم HLS این است که آنچه مشتری جریانی مستقیم به دست می آورد یک پیام کامل نیست
کل جریان داده
پروتکل HLS جریان داده های زنده را به صورت پرونده های مداوم ، کوتاه مدت و طولانی مدیا (با فرمت mpeg-ts) در سمت سرور ذخیره می کند ، در حالی که سمت مشتری این پرونده های کوچک را بارگیری و پخش می کند ،
از آنجا که سرور همیشه از جدیدترین داده های زنده ، پرونده های کوچک جدیدی تولید می کند ، بنابراین تا زمانی که سرویس گیرنده پرونده های به دست آمده از سرور را به ترتیب پخش کند ، پخش مستقیم محقق می شود.
دیده می شود که اساساً HLS مبتنی بر>> فناوری درخواستی برای دستیابی به <<زنده است. از آنجا که داده ها از طریق پروتکل HTTP منتقل می شوند ، نیازی به در نظر گرفتن فایروال یا پروکسی نیست
علاوه بر این ، طول فایل تقسیم شده بسیار کوتاه است ، بنابراین مشتری می تواند به سرعت نرخ کد را انتخاب و تغییر دهد تا در شرایط پهنای باند مختلف با پخش سازگار شود. با این حال ، این نوع مشخصات فنی HLS پیشرفت آینده آن را تعیین می کند
به طور کلی ، تأخیر همیشه بیشتر از پروتکل پخش مستقیم زنده است.
// هر دو IOS و Android به طور طبیعی از این پروتکل پشتیبانی می کنند و پیکربندی آن ساده است. می توانید مستقیماً از برچسب ویدیو استفاده کنید
*** VLS: نوعی سرور پخش جریانی است که به طور خاص برای حل مشکلات مختلف جریان استفاده می شود. همچنین دارای برخی ویژگی های VLC است. به عنوان یک سرور ، videolan می تواند از جریان های HTTP ، RTP و RTSP خارج شود.
در اصل می توان از RTSP ، RTMP و HTTP برای پخش زنده و درخواستی استفاده كرد ، اما به طور كلی RTSP و RTMP برای پخش زنده و HTTP برای پخش درخواستی استفاده می شود. ما پروتکل RTMP را انتخاب می کنیم.
تأخیر در پروتکل های مختلف و دلایل آن
RTMP و httpflv: داده های این دو پروتکل تقریباً یکسان است ، بنابراین دلایل تأخیر مشابه است. منطقی است که بگوییم تأخیر در پخش مستقیم جریان TCP بسیار کم است. چرا در RTMP و httpflv تأخیر وجود دارد؟ دلیل این امر این است که در h264 ، RTMP و httpflv هر دو برچسب flv منتقل شده هستند. داده های برچسب ویدیو معمولاً داده های H264 هستند. رمزگشایی H264 دارای IBP است. من قاب اصلی است که یک تصویر کامل است. برای رمزگشایی BP زیر ابتدا باید I داشته باشید. تعداد فریم های BP می تواند به همان اندازه که دوست دارید کم باشد ، اما تعداد فریم های I نمی تواند کمتر باشد ، بنابراین فریم های I باید در flv باشند انتقال برچسب انتقال دوم است (اولین انتقال h264spps است). با این حال ، فریم های I در جریان های H264 معمول نیستند. فقط یک قاب عکس پشت سر هم وجود دارد. این فاصله معمولاً با نام GOP شناخته می شود. هنگام رمزگذاری ، GOP بسیار کوتاه تنظیم می شود. با اتصال مشتری ، سرور جدیدترین I-frame را در سریعترین سرعت در جریان پیدا می کند و داده های زنده را از I-frame ارسال می کند. با این حال ، وقتی GOP بسیار طولانی است ، فاصله فریم I بسیار طولانی است ، یا منتظر بمانید که فریم بعدی شروع به ارسال داده به اتصال جدید کند ، یا جدیدترین فریم I را در حافظه پنهان پیدا کنید تا شروع به ارسال کند. این کلید تاخیر در پروتکل های RTMP و HLS است. در سیستم عامل های بزرگ CDN ، آن را "RTMP دوم در زمینه فناوری" می نامند. اصل این است که داده های جریان را دو بار رمزگشایی کرده و یک GOP کوچک تنظیم کنید. به طور کلی ، وقتی GOP روی 1s تنظیم می شود ، صرف نظر از تأخیر لینک انتقال شبکه ، حداکثر تاخیر داده 1s است. خوشبختانه فریم من 0 تاخیر است!
|
ایمیل را وارد کنید تا غافلگیر شوید
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 -> بلغاری
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 -> مجارستانی
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 -> اسلوونیایی
es.fmuser.org -> اسپانیایی
sw.fmuser.org -> سواحیلی
sv.fmuser.org -> سوئدی
th.fmuser.org -> تایلندی
tr.fmuser.org -> ترکی
uk.fmuser.org -> اوکراینی
ur.fmuser.org -> اردو
vi.fmuser.org -> ویتنامی
cy.fmuser.org -> ولزی
yi.fmuser.org -> ییدیش
FMUSER بی سیم ویدئو و صدا را راحت تر انتقال می دهد!
تماس با ما
نشانی:
شماره 305 اتاق HuiLan ساختمان شماره 273 Huanpu Road گوانگژو چین 510620
دسته بندی ها
عضویت در خبرنامه