亚洲免费av电影一区二区三区,日韩爱爱视频,51精品视频一区二区三区,91视频爱爱,日韩欧美在线播放视频,中文字幕少妇AV,亚洲电影中文字幕,久久久久亚洲av成人网址,久久综合视频网站,国产在线不卡免费播放

        ?

        基于RTMP協(xié)議的流媒體技術(shù)的原理與應(yīng)用

        2013-09-20 05:31:32雷霄驊姜秀華王彩虹
        關(guān)鍵詞:流式消息客戶端

        雷霄驊,姜秀華,王彩虹

        (中國傳媒大學(xué)信息工程學(xué)院,北京100024)

        1 引言

        近年來,隨著網(wǎng)絡(luò)帶寬的提升,以及多媒體壓縮編碼技術(shù)的發(fā)展,流媒體技術(shù)得到了非常廣泛的應(yīng)用。全球的流媒體市場正在以極高的速度向前發(fā)展,并逐步取代了以文本和圖片為主的傳統(tǒng)互聯(lián)網(wǎng)。根據(jù)Cisco的 Visual Networking Index(VNI)統(tǒng)計(jì),2005年流媒體流量僅占全球互聯(lián)網(wǎng)總流量的5%,而到了2011年這一比例已經(jīng)提升到40%,預(yù)計(jì)到2015年這一比例將會進(jìn)一步提升到62%。與此同時(shí),流媒體技術(shù)也已經(jīng)突破了電腦的限制,進(jìn)入了平板電腦和智能手機(jī)等領(lǐng)域,一個(gè)Video Everywhere的時(shí)代即將到來[1]。

        在這種流媒體快速發(fā)展的大環(huán)境下,各個(gè)地方的電視臺,視頻服務(wù)提供商紛紛開始了自己的流媒體業(yè)務(wù)。在搭建業(yè)務(wù)平臺的時(shí)候,如何選取合適自己的流媒體平臺成為一個(gè)至關(guān)重要的問題。中國網(wǎng)絡(luò)電視臺,中國教育電視臺,河南電視臺,深圳電視臺等多家電視臺,以及六間房,奇異網(wǎng),威視網(wǎng)等流媒體服務(wù)商都選擇了Adobe公司的基于Flash平臺的流媒體系統(tǒng)。該系統(tǒng)傳輸數(shù)據(jù)使用的RTMP協(xié)議[2]因此得到了非常廣泛的應(yīng)用。本文將會對其特點(diǎn)進(jìn)行詳細(xì)的分析,并搭建一個(gè)基于RTMP協(xié)議的流媒體直播系統(tǒng)。

        2 流媒體

        當(dāng)前互聯(lián)網(wǎng)中的流媒體服務(wù)從傳輸方式上大體上可以分為兩種方式:順序流式傳輸和實(shí)時(shí)流式傳輸。

        2.1 順序流式傳輸

        順序流式傳輸采用普通的HTTP服務(wù)器作為存儲多媒體文件的服務(wù)器。當(dāng)客戶端發(fā)起連接想要觀看多媒體資源的時(shí)候,直接通過HTTP協(xié)議把文件下載到客戶端本地系統(tǒng)的臨時(shí)文件夾中,再使用播放器播放已經(jīng)下載好的文件。它的與服務(wù)器交互的流程如圖1所示。順序流式傳輸?shù)膶?shí)質(zhì)就是播放本地文件。順序流式傳輸目前得到了十分廣泛的應(yīng)用:YouTube,優(yōu)酷網(wǎng),土豆網(wǎng)等視頻服務(wù)商都采用了該種方式提供多媒體服務(wù)。順序流式傳輸?shù)暮锰幹饕菧p輕了服務(wù)器的壓力,即當(dāng)多媒體文件下載完成后就可以斷開連接,從而節(jié)省出服務(wù)器資源再為其他客戶端服務(wù)。此外,順序流式傳輸使用的是普通的HTTP服務(wù)器,視頻服務(wù)商不必花費(fèi)額外的資金購買流媒體服務(wù)器,從而節(jié)省了一筆經(jīng)費(fèi)。

        圖1 順序流式傳輸

        2.2 實(shí)時(shí)流式傳輸

        實(shí)時(shí)流式傳輸采用專門的流媒體服務(wù)器存儲多媒體文件。當(dāng)客戶端發(fā)起連接想要觀看多媒體資源的時(shí)候,一般通過專有的實(shí)時(shí)流式傳輸協(xié)議把位于流媒體服務(wù)器上的多媒體數(shù)據(jù)直接傳輸給客戶端的播放器,再實(shí)時(shí)播放。他與服務(wù)器交互的流程如圖2所示。實(shí)時(shí)流式傳輸?shù)膽?yīng)用目前還處于發(fā)展階段,主要應(yīng)用于網(wǎng)絡(luò)直播和正版影視的點(diǎn)播。使用實(shí)時(shí)流式傳輸方式觀看多媒體資源的時(shí)候,由于不會把文件下載到本地,可以防止視音頻提供商的內(nèi)容被非法拷貝,從而保護(hù)了視音頻內(nèi)容的版權(quán)。此外,使用實(shí)時(shí)流式傳輸方式觀看多媒體資源的時(shí)候,可以隨意跳轉(zhuǎn)到該視音頻的任何位置,而不必像順序流式傳輸那樣只能觀看已經(jīng)下載過的部分,因此大大增加了觀看時(shí)的自由度。

        圖2 實(shí)時(shí)流式傳輸

        3 實(shí)時(shí)流式傳輸

        流媒體系統(tǒng)中媒體數(shù)據(jù)傳輸需要相應(yīng)的實(shí)時(shí)流式傳輸協(xié)議支持。實(shí)時(shí)流式傳輸協(xié)議屬于互聯(lián)網(wǎng)TCP/IP五層體系結(jié)構(gòu)中應(yīng)用層的協(xié)議。在當(dāng)前的互聯(lián)網(wǎng)中,很多實(shí)時(shí)流式傳輸協(xié)議的標(biāo)準(zhǔn)是公司私有的,因此這些協(xié)議規(guī)范并不公開。目前公開規(guī)范的實(shí)時(shí)流式傳輸協(xié)議有以下幾種:

        3.1 RTSP+RTP

        RTSP是由 IETF(Internet工程任務(wù)組)提出的[3]。RTSP 協(xié)議全稱是 Real Time Streaming Protocol,即實(shí)時(shí)流傳輸協(xié)議,是 IETF的 RFC標(biāo)準(zhǔn)。RTSP用于控制流媒體的傳輸,比如建立連接,播放,暫停等等,但本身并不傳輸多媒體數(shù)據(jù)。多媒體數(shù)據(jù)通常都是使用RTP/RTCP協(xié)議進(jìn)行傳輸。RTP/RTCP協(xié)議全稱是Real-time Transport Protocol/Real-time Transport Control Protocol,即實(shí)時(shí)傳送協(xié)議/實(shí)時(shí)傳送控制協(xié)議,也是IETF的RFC標(biāo)準(zhǔn),專門用于傳輸多媒體數(shù)據(jù)。雖然RTSP+RTP是一個(gè)國際標(biāo)準(zhǔn)的組合,但是在互聯(lián)網(wǎng)世界中卻沒能做到“一統(tǒng)天下”。這與互聯(lián)網(wǎng)的環(huán)境有很大關(guān)系。RTP/RTCP作為傳輸多媒體數(shù)據(jù)的網(wǎng)絡(luò)協(xié)議,一般情況下使用 UDP協(xié)議作為其傳輸層的網(wǎng)絡(luò)協(xié)議[3]。UDP是無連接的,不提供可靠交付,因此在互聯(lián)網(wǎng)上(尤其是廣域網(wǎng))傳輸數(shù)據(jù)的時(shí)候極易產(chǎn)生丟包,時(shí)延,抖動(dòng)等問題。多媒體數(shù)據(jù)對丟包,時(shí)延,抖動(dòng)有很高的要求,一點(diǎn)點(diǎn)小問題就會極大的影響用戶的體驗(yàn)質(zhì)量(QoE)[4]。因此互聯(lián)網(wǎng)上采用RTSP+RTP方式傳輸?shù)牧髅襟w并不是很多。與在因特網(wǎng)上傳輸?shù)牧髅襟w不同,IPTV通常都采用RTSP+RTP的方式傳輸多媒體數(shù)據(jù)[5]。因?yàn)镮PTV通常采用專網(wǎng)傳輸,網(wǎng)絡(luò)狀況較好,極少出現(xiàn)丟包,時(shí)延,抖動(dòng)等問題,而UDP簡單的協(xié)議規(guī)則可以大幅提高傳輸效率,所以可以“放心大膽”的使用RTSP+RTP的方式傳輸。

        3.2 MMS

        MMS是由微軟公司提出的。MMS協(xié)議全稱是Microsoft Media Server protocol,即微軟媒體服務(wù)協(xié)議,用于訪問Windows Media發(fā)布點(diǎn)上的內(nèi)容。

        3.3 HLS

        HLS是由蘋果公司提出的。HLS全稱是HTTP Live Streaming,即基于HTTP的實(shí)時(shí)流式傳輸協(xié)議,可實(shí)現(xiàn)流媒體的直播和點(diǎn)播,主要應(yīng)用在iOS系統(tǒng),為iOS設(shè)備(如iPhone、iPad)提供音視頻直播和點(diǎn)播方案。

        3.4 RTMP

        RTMP是由Adobe公司提出的。RTMP協(xié)議全稱是Real Time Messaging Protocol,即實(shí)時(shí)消息傳送協(xié)議,用于在Flash平臺之間傳遞視音頻以及數(shù)據(jù)。與RTSP+RTP組合提供流媒體服務(wù)的方式不同,RTMP協(xié)議本身既可以傳輸多媒體數(shù)據(jù)也可以控制多媒體播放。RTMP協(xié)議使用TCP協(xié)議作為其傳輸層的網(wǎng)絡(luò)協(xié)議。TCP是面向連接的[3],提供可靠交付的協(xié)議,因此在互聯(lián)網(wǎng)上傳輸時(shí)不會出現(xiàn)丟包情況,從而保證了用戶體驗(yàn)(QoE)。但是TCP協(xié)議提供可靠交付的代價(jià)就是增加了一些額外的開銷,占用了一些帶寬和處理機(jī)資源。隨著網(wǎng)絡(luò)帶寬的提高和計(jì)算機(jī)硬件的發(fā)展,這些開銷會顯得越來越微不足道。因此RTMP協(xié)議在未來有很好的發(fā)展前景。

        4 基于RTMP的系統(tǒng)的特點(diǎn)

        很多網(wǎng)絡(luò)電視臺,流媒體服務(wù)提供商之所以會選擇RTMP協(xié)議作為其提供流媒體服務(wù)的應(yīng)用層協(xié)議,在于它有以下幾個(gè)特點(diǎn):無須安裝客戶端程序,保證了媒體傳輸質(zhì)量。

        4.1 無須安裝客戶端程序

        收看采用RTMP協(xié)議提供的流媒體無需安裝客戶端程序,大大簡化了客戶操作的復(fù)雜度。一般收看流媒體都需要相應(yīng)的客戶端軟件的支持,用戶需要收看流媒體就必須下載相應(yīng)的軟件(或插件)。而支持RTMP協(xié)議的流媒體客戶端可以制作成一個(gè)普通的Flash文件,只要安裝過Flash Player的網(wǎng)頁瀏覽器就可以自動(dòng)下載該文件并運(yùn)行它。而Flash Player是一個(gè)上網(wǎng)必備的插件。據(jù)統(tǒng)計(jì),全世界98% 的網(wǎng)頁瀏覽器都安裝了Flash Player。因此,普通用戶不需要任何操作,只要使用網(wǎng)頁瀏覽器打開播放頁面,就可以收看流媒體[6]。

        4.2 保證了媒體傳輸質(zhì)量

        RTMP協(xié)議有效的保證了媒體傳輸質(zhì)量,使用戶可以觀看到高質(zhì)量的多媒體。RTMP采用TCP協(xié)議作為其在傳輸層的協(xié)議,避免了多媒體數(shù)據(jù)在廣域網(wǎng)傳輸過程中的丟包對質(zhì)量造成的損失。此外RTMP協(xié)議傳輸?shù)腇LV封裝格式支持的H.264視頻編碼方式可以在很低的碼率下顯示質(zhì)量還不錯(cuò)的畫面,非常適合網(wǎng)絡(luò)帶寬不足的情況下收看流媒體。

        5 RTMP的規(guī)范

        5.1 協(xié)議格式[2][7]

        RTMP協(xié)議是一個(gè)互聯(lián)網(wǎng)TCP/IP五層體系結(jié)構(gòu)中應(yīng)用層的協(xié)議。RTMP協(xié)議中基本的數(shù)據(jù)單元稱為消息(Message)。當(dāng)RTMP協(xié)議在互聯(lián)網(wǎng)中傳輸數(shù)據(jù)的時(shí)候,消息會被拆分成更小的單元,稱為消息塊(Chunk)。

        5.1.1 消息

        消息是RTMP協(xié)議中基本的數(shù)據(jù)單元。不同種類的消息包含不同的Message Type ID,代表不同的功能。RTMP協(xié)議中一共規(guī)定了十多種消息類型,分別發(fā)揮著不同的作用。例如,Message Type ID在1-7的消息用于協(xié)議控制,這些消息一般是RTMP協(xié)議自身管理要使用的消息,用戶一般情況下無需操作其中的數(shù)據(jù)。Message Type ID為8,9的消息分別用于傳輸音頻和視頻數(shù)據(jù)。Message Type ID為15-20的消息用于發(fā)送AMF編碼[8]的命令,負(fù)責(zé)用戶與服務(wù)器之間的交互,比如播放,暫停等等。消息首部(Message Header)有四部分組成:標(biāo)志消息類型的Message Type ID,標(biāo)志消息長度的Payload Length,標(biāo)識時(shí)間戳的Timestamp,標(biāo)識消息所屬媒體流的Stream ID。消息的報(bào)文結(jié)構(gòu)如圖3所示。

        圖3 消息

        5.1.2 消息塊

        圖4 消息塊

        5.1.3 消息分塊

        在消息被分割成幾個(gè)消息塊的過程中,消息負(fù)載部分(Message Body)被分割成大小固定的數(shù)據(jù)塊(默認(rèn)是128字節(jié),最后一個(gè)數(shù)據(jù)塊可以小于該固定長度),并在其首部加上消息塊首部(Chunk Header),就組成了相應(yīng)的消息塊。消息分塊過程如圖5所示,一個(gè)大小為307字節(jié)的消息被分割成128字節(jié)的消息塊(除了最后一個(gè))。

        圖5 RTMP分塊

        RTMP傳輸媒體數(shù)據(jù)的過程中,發(fā)送端首先把媒體數(shù)據(jù)封裝成消息,然后把消息分割成消息塊,最后將分割后的消息塊通過TCP協(xié)議發(fā)送出去。接收端在通過TCP協(xié)議收到數(shù)據(jù)后,首先把消息塊重新組合成消息,然后通過對消息進(jìn)行解封裝處理就可以恢復(fù)出媒體數(shù)據(jù)。

        5.2 連接方式[9]

        RTMP協(xié)議規(guī)定,發(fā)布一個(gè)媒體流之前需要?jiǎng)?chuàng)建兩個(gè)邏輯結(jié)構(gòu):第一步,建立一個(gè)網(wǎng)絡(luò)連接(Net-Connection);第二步,基于該網(wǎng)絡(luò)連接建立一個(gè)網(wǎng)絡(luò)流(NetStream)。其中,網(wǎng)絡(luò)連接代表服務(wù)器端和客戶端之間基礎(chǔ)的聯(lián)系;網(wǎng)絡(luò)流代表了發(fā)送多媒體數(shù)據(jù)的通道。服務(wù)器和客戶端之間只能建立一個(gè)網(wǎng)絡(luò)連接,但是基于該連接可以創(chuàng)建很多網(wǎng)絡(luò)流。他們的關(guān)系如圖6所示:

        圖6 RTMP的網(wǎng)絡(luò)連接和網(wǎng)絡(luò)流

        6 基于RTMP的直播系統(tǒng)的搭建[9]

        6.1 系統(tǒng)結(jié)構(gòu)

        本文將會實(shí)現(xiàn)一個(gè)基于RTMP協(xié)議的流媒體直播系統(tǒng)。一個(gè)完整的流媒體直播系統(tǒng)包括以下幾個(gè)部分:視頻源,流媒體服務(wù)器和客戶端,系統(tǒng)的構(gòu)成如圖7所示。視頻源將視頻數(shù)據(jù)經(jīng)過RTMP協(xié)議發(fā)布到流媒體服務(wù)器上;視頻成功發(fā)布以后,客戶端通過RTMP連接到流媒體服務(wù)器,就可以播放相應(yīng)的視頻。其中,視頻源和客戶端都是使用ActionScript語言編寫的Flash程序[10],流媒體服務(wù)器使用Adobe公司的Flash Media Server軟件。

        圖7 系統(tǒng)構(gòu)成圖

        6.2 視頻源

        視頻源是一個(gè)提供視頻流的應(yīng)用程序。本系統(tǒng)中使用一個(gè)ActionScript代碼編寫的Flash程序作為視頻源。該程序采集本機(jī)攝像頭數(shù)據(jù),將數(shù)據(jù)壓縮編碼后使用RTMP協(xié)議將數(shù)據(jù)發(fā)布到流媒體服務(wù)器相應(yīng)的應(yīng)用程序(Application)上面。

        下面簡要介紹一下視頻源部分重要代碼含義:

        //建立一個(gè)RTMP網(wǎng)絡(luò)連接

        柯青,2017年畢業(yè)于南京師范大學(xué),長期研究文學(xué)以及中國哲學(xué)倫理方向。著有散文書籍《濃墨重彩》。現(xiàn)為上海潘言教育科技有限公司創(chuàng)始人。

        var nc:NetConnection=new NetConnection();

        //連接到IP為222.31.64.249的流媒體服務(wù)器上名字為publishlive的應(yīng)用程序

        nc.connect("rtmp://222.31.64.249/publishlive");

        //建立一個(gè)基于該連接的網(wǎng)絡(luò)流

        ns=new NetStream(nc);

        //調(diào)用本機(jī)的攝像頭

        cam=Camera.getCamera();

        //把攝像頭添加到新建的流上

        ns.attachCamera(cam);

        //把一個(gè)多媒體流發(fā)布到服務(wù)器的應(yīng)用程序上,取名為“myCamera”

        ns.publish("myCamera","live");

        6.3 流媒體服務(wù)器

        流媒體服務(wù)器是存儲(或接收)媒體流并且等待客戶端連接的軟件。本系統(tǒng)采用Adobe公司的Flash Media Server作為流媒體服務(wù)器。媒體流必需發(fā)布到已經(jīng)在流媒體服務(wù)器上注冊過的應(yīng)用程序上。在Flash Media Server的安裝目錄的“Application”文件夾下新建一個(gè)“publishlive”文件夾,即可注冊一個(gè)名為“publishlive”的應(yīng)用程序,不需要編寫任何代碼。

        6.4 客戶端

        客戶端是播放視頻流的應(yīng)用程序。本系統(tǒng)采用一個(gè)ActionScript語言編寫的Flash程序作為播放實(shí)時(shí)流的客戶端。使用RTMP協(xié)議從流媒體服務(wù)器獲得視頻數(shù)據(jù)并顯示播放。

        下面簡要介紹一下客戶端的部分關(guān)鍵代碼的含義:

        //建立一個(gè)RTMP網(wǎng)絡(luò)連接

        var nc:NetConnection=new NetConnection();

        //連接到IP為222.31.64.249的流媒體服務(wù)器上名字為publishlive的應(yīng)用程序

        nc.connect("rtmp://222.31.64.249/publishlive");

        //建立一個(gè)基于該連接的多媒體流

        nsPlayer=new NetStream(nc);

        //播放名為“myCamera”的多媒體流

        nsPlayer.play("myCamera");

        //新建一個(gè)Video對象用于顯示視頻

        vidPlayer = new Video(cam.width,cam.height);

        //將多媒體流添加到Video類上

        vidPlayer.attachNetStream(nsPlayer);

        //在Flash舞臺上顯示Video對象

        addChild(vidPlayer);

        7 小結(jié)和展望

        本文分析了流媒體的兩種基本傳輸方式:順序流式傳輸和實(shí)時(shí)流式傳輸?shù)膮^(qū)別。并重點(diǎn)分析了幾種主要的實(shí)時(shí)流式傳輸協(xié)議的特點(diǎn)。以RTMP協(xié)議為基礎(chǔ),分析了它的特點(diǎn)和格式,最后實(shí)現(xiàn)了一個(gè)的基于RTMP協(xié)議的流媒體直播系統(tǒng)。對于全面了解RTMP協(xié)議的原理有很大的幫助,同時(shí)可以為設(shè)計(jì)與實(shí)現(xiàn)更為復(fù)雜的基于RTMP協(xié)議的流媒體系統(tǒng)提供一個(gè)參考。

        今年以來,隨著互聯(lián)網(wǎng)電視(Over-The-Top TV)逐漸興起,流媒體技術(shù)將會隨之迎來一個(gè)大發(fā)展階段??梢灶A(yù)見,以流媒體技術(shù)為支撐的流媒體在未來將會占據(jù)傳統(tǒng)電視的部分市場并獲得相當(dāng)數(shù)量的客戶群。而不需要用戶安裝客戶端,視音頻質(zhì)量良好的基于RTMP協(xié)議的流媒體系統(tǒng),也將會在眾多流媒體系統(tǒng)中凸現(xiàn)出來,獲得很大的市場份額。

        [1]中廣研究,視訊天下.在線視頻平臺白皮書[C].北京:中國標(biāo)準(zhǔn)出版社,2012.

        [2]Adobe Systems Incorporated.RTMP Specification[EB/OL].http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/rtmp/pdf/rtmp_specification_1.0.pdf,2009.

        [3]謝希仁.計(jì)算機(jī)網(wǎng)絡(luò)(第五版)[M].北京:電子工業(yè)出版社,2009.

        [4]蘇佳,姜秀華.IPTV 視頻質(zhì)量評價(jià)介紹[J].電視技術(shù),2011,35(6):78-81.

        [5]萬曉榆,張洪,歐陽春,張溢華.IPTV技術(shù)與運(yùn)營[M].北京:科學(xué)出版社,2010.

        [6]林曉偉 .Flash Player內(nèi)部機(jī)制[EB/OL].http://wenku.baidu.com/view/d4243af3f90f76c66 1371af4.html,2010.

        [7]姜浩然,徐林.基于RTMP的流媒體服務(wù)器的研究[J].計(jì)算機(jī)與數(shù)字工程,2011,39(10):104-108.

        [8]Adobe Systems Incorporated.AMF 3 Specification[EB/OL].http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/amf/pdf/amf-file-format-spec.pdf,2006.

        [9]Adobe Systems Incorporated.Adobe Flash Media Server 4.5 Developer's Guide [EB/OL].http://help.adobe. com/en _ US/flashmediaserver/devguide/flashmediaserver_4.5_dev_guide.pdf,2012.

        [10]Zerlot Ma.Flash Media Server 3.0技術(shù)指南Part1[EB/OL].http://wenku.baidu.com/view/ab293b48c850ad02de80418f.html,2006.

        猜你喜歡
        流式消息客戶端
        輻流式二沉池的結(jié)構(gòu)優(yōu)化研究
        一張圖看5G消息
        縣級臺在突發(fā)事件報(bào)道中如何應(yīng)用手機(jī)客戶端
        傳媒評論(2018年4期)2018-06-27 08:20:24
        孵化垂直頻道:新聞客戶端新策略
        傳媒評論(2018年4期)2018-06-27 08:20:16
        基于Vanconnect的智能家居瘦客戶端的設(shè)計(jì)與實(shí)現(xiàn)
        電子測試(2018年10期)2018-06-26 05:53:34
        微球測速聚類分析的流式液路穩(wěn)定性評估
        自調(diào)流式噴管型ICD的設(shè)計(jì)與數(shù)值驗(yàn)證
        流式在線直播視頻的采集
        河南科技(2015年8期)2015-03-11 16:23:41
        消息
        消息
        久久高潮少妇视频免费| 国产女主播视频一区二区三区| 亚洲一区二区精品在线看| 午夜亚洲精品视频在线| 亚洲一区二区国产激情| 人妻少妇乱子伦精品| 青青草视频免费观看| 广东少妇大战黑人34厘米视频| 日韩亚洲欧美中文高清在线| 谁有在线观看av中文| 白白色福利视频在线观看| 国产成人精品久久二区二区91| 在线观看老湿视频福利| 国产精品美女久久久久久久久| 在线无码精品秘 在线观看| 人妻系列中文字幕av| 亚洲av国产av综合av卡| 中文字幕无线码中文字幕| 97精品国产91久久久久久久| 蜜桃视频免费在线视频| 熟女人妻在线中文字幕| 欧美性xxxxx极品老少| 久久www免费人成精品| 日本少妇被黑人xxxxx| 中文字幕亚洲精品第1页| 在线视频精品少白免费观看| 国产精品免费无遮挡无码永久视频| 无人高清电视剧在线观看| 国产精品久久婷婷六月丁香| 亚洲VR永久无码一区| 人妻少妇av中文字幕乱码| 精品免费久久久久久久| 四虎永久在线精品免费观看地址| 免费看男女啪啪的视频网站| 国产av无码专区亚洲av果冻传媒| 国产日产欧产精品精品| 国产亚洲欧美日韩综合综合二区 | 精品免费人伦一区二区三区蜜桃| 国产无遮挡又黄又爽无VIP| 男奸女永久免费视频网站| 亚洲人成人网站在线观看|