精品国产人成在线_亚洲高清无码在线观看_国产在线视频国产永久2021_国产AV综合第一页一个的一区免费影院黑人_最近中文字幕MV高清在线视频

0
  • 聊天消息
  • 系統消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發帖/加入社區
會員中心
創作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

智能貓眼的實現是采用流媒體協議RTSP

OpenAtom OpenHarmony ? 來源:OpenAtom OpenHarmony ? 作者:OpenAtom OpenHarmony ? 2022-05-16 09:20 ? 次閱讀

前言

智能貓眼是一種家居安防產品。是安裝在防盜門上的一種嵌入式設備,可以通過攝像頭獲取圖像顯示至手機應用中,這樣老人或者小孩就可以看清門外的情況。

智能貓眼的實現是采用流媒體協議 RTSP。該協議定義了程序如何通過 IP 網絡傳送多媒體數據。RTSP 多用于安防攝像頭、車載監控、網絡直播等場景應用。本文檔旨在講解在 OpenAtom OpenHarmony(以下簡稱“OpenHarmony") 1.0.1 release 下將 Hi3518EV300 編碼后的 H.265 視頻格式(H.265 是一種視頻編碼格式,可以由 OpenHarmony 媒體子系統產生),通過 RTSP 傳輸顯示到手機的應用中。

cc8c790e-d2bd-11ec-bce3-dac502259ad0.jpg

注:Hi3518EV300是 潤和Hi3518 HiSpark IPC AI攝像頭開發板套件

如上圖片:Hi3518EV300 設備將捕獲到的圖像通過 RTSP 發送到手機應用中并顯示出來。

開發流程

RTSP 采用 Server/Client 模式,在本樣例場景中 Hi3518EV300為RTSP Server,手機應用為 RTSP Client。在 RTSP 體系結構包含 RTSP和RTP(實時傳輸協議)兩種協議,其中 RTSP 協議用于建立連接與傳輸多媒體控制命令(開始、暫停、結束等),RTP 協議用來傳輸多媒體數據(音頻、視頻)。

RTSP Server 的實現分為如下幾步:

●設置 Wi-Fi:將手機與 Hi3518EV300 在同一網絡中;

環形緩存區:將媒體子系統中編碼出的 H.265 數據存入環形緩存中;

●RTSP:RTSP Server 通過 RTSP 與 RTSP Client 交互控制信息

●RTP :RTSP Server 收到PLAY命令后從環形緩存中獲取 H.265 數據并使用 RTP 協議發送。

如下圖所示:

ccbad592-d2bd-11ec-bce3-dac502259ad0.jpg

如何運行 RTSP Server 可以參考文章智能貓眼 3518 開發樣例,下面根據該文章講解 RTSP Server 的實現流程。

代碼結構:


├── smart_door_viewer_3518│   ├── BUILD.gn                                      // 編譯構建│   ├── include│   │   ├── camera_sample.h                   // 攝像頭操作頭文件│   │   ├── rtp.h                                         // rtp協議傳輸頭文件│   │   ├── rtsp_log.h                                // 打印調試頭文件│   │   └── rtsp_server.h                           // rtsp頭文件│   └── src│       ├── camera_sample.cpp                 // 攝像頭實現│       ├── main.cpp                                   // 主函數│       ├── rtp.cpp                                       // rtp協議實現│       └── rtsp_server.cpp                         // rtsp協議實現├── foundation              │   └── multimedia│       └── media_lite│           ├── frameworks│           │   └── recorder_lite │           │       ├── recorder.cpp                //增加獲取攝像頭H.265數據實現類接口│           │       ├── recorder_impl.cpp       //增加獲取攝像頭H.265數據實現│           │       └── recorder_impl.h           //增加獲取攝像頭H.265數據實現定義│           └── interfaces│               └── kits│                   └── recorder_lite│└──recorder.h//增加應用層獲取攝像頭H.265數據實現類接口定義

設置Wi-Fi

設置 Wi-Fi 連接熱點 ssid 為“Smedia”psk為“12345678”。

在文件 wpa_supplicant.conf 中修改如下:


country=GBctrl_interface=udpnetwork={    ssid="SMedia"    psk="12345678"}

設備啟動后輸入:


./bin/wpa_supplicant -iwlan0 -c/etc/wpa_supplicant.conf

輸入 ifconfig 可查看到連接成功后的 IP 地址:

ccd7c4ae-d2bd-11ec-bce3-dac502259ad0.jpg

環形緩存區

在媒體子系統中,為了同步 RTSP Server 應用獲取 H.265 數據須設計一個環形緩沖區。緩沖區總大小為 16*256K 長度的數組。put 為媒體子系統存放緩沖區的偏移值,get 為 RTSP Server(Hi3518EV300)線程獲取緩沖區的偏移值,緩存區定義在文件 recorder_impl.h 下。


constexpr uint32_t RING_BUFF_MAX_CNT = 16;constexpruint32_tRING_BUFF_SIZE=256*1024;

具體實現如下:

初始情況下偏移值 put 與 get 的位置均在開頭。

cd0b6048-d2bd-11ec-bce3-dac502259ad0.jpg

當 RTSP Server 啟動后媒體子系統填充 buff,偏移值 put 向前移。

cd415892-d2bd-11ec-bce3-dac502259ad0.jpg

RTSP Server 通過偏移值 get 獲取到視頻編碼數據后釋放 buff,偏移值 get 向前移。

cd606f8e-d2bd-11ec-bce3-dac502259ad0.jpg

當 put 與 get 偏移超過 16 時重新置 1 因此形象地稱為環形緩沖區,其中 get 永遠在 put 后且間距不會超過 3 個 buff,實現是在 rtsp Server 中設置同步時間。

cd7e62f0-d2bd-11ec-bce3-dac502259ad0.jpg

代碼實現邏輯:當 RTSP Server 運行到 RTP 時才會往緩沖區存放數據(ringStatus 標志位設置為 true)。存入緩沖區的首幀是從關鍵幀(幀頭為 0x40 與 0x01 與 startFramFlag 標志位為 true)開始,后續所有幀都會保存到緩沖區中(saveFlag 標志位設置為 true,startFramFlag 標志位為 false),在函數 VideoSourceProcess 下實現。


if ((iNumber < RING_BUFF_MAX_CNT) && (ringStatus == true)) {    if((startFramFlag == true) &&(buffer.dataAddr[4]==0x40)        && (buffer.dataAddr[5]==0x01)) {        if (memcpy_s(ringFifo[iPut].buffer, RING_BUFF_SIZE, buffer.dataAddr, buffer.dataLen) != EOK) {            MEDIA_INFO_LOG("[Error] memcpy_s");         } else {            ringFifo[iPut].size = buffer.dataLen;            iPut = addring(iPut);            iNumber++;            startFramFlag = false;            saveFlag = true;        }     } else {         if(saveFlag == true) {             if (memcpy_s(ringFifo[iPut].buffer, RING_BUFF_SIZE, buffer.dataAddr, buffer.dataLen) != EOK) {                MEDIA_INFO_LOG("[Error] memcpy_s");              } else {                 ringFifo[iPut].size = buffer.dataLen;                 iPut = addring(iPut);                 iNumber++;                       }          }      }}

RTSP

RTSP Server 與 RTSP Client 通過 RTSP 協議收發控制命令,其基本流程如下:

●OPTION:首先 Client 連接到 Server 并發送 OPTION 命令,Server 立刻返回所支持的命令(OPTION、DESCRIBE、SETUP、PLAY、TEARDOWN);

●DESCRIBE:Client 發送描述命令(DESCRIBE),Server 通過一個 SDP 描述來進行反饋,反饋信息包括流數量、媒體類型等信息;

●SETUP:Client 分析 SDP 描述,并為會話中發送建立命令(SETUP),告訴 Server 用于接收媒體數據的端口

●PLAY:連接建立完成后,Client 發送一個播放命令(PLAY),Server 就開始在 UDP 上傳送媒體流(RTP包)到 Client;

●TERADOWN:最后 Client 可發送一個終止命令(TERADOWN)來結束流媒體會話。

其交互流程如下所示:

cd98e788-d2bd-11ec-bce3-dac502259ad0.jpg

在文件 rtsp_server.cpp 中,RTSP Server 收到 OPTION 后回復服務器提供的可用命令(OPTION、DESCRIBE、SETUP、PLAY、TEARDOWN)。

函數實現如下:


static void RtspOptions(char* sendBuff, RtspClientInfo &rtspCliInfo){    sprintf(sendBuff, "RTSP/1.0 200 OK
"                    "CSeq: %d
"                    "Public: OPTIONS, DESCRIBE, SETUP, PLAY, TEARDOWN
"                    "
",                    rtspCliInfo.rtspCseq);}

RTSP Server 收到 DESCRIBE 后回復 SDP (SDP 信息為會話名稱和目的、會話持續時間、媒體類(音頻、視頻等)、傳輸協議(RTP/UDP/IP等)、媒體編碼格式(H.264、H.265 等)、接收媒體的相關信息端口和格式等。)信息。

函數實現如下:


static void RtspDescribe(char* sendBuff, RtspClientInfo &rtspCliInfo){    char sdp[512];
    memset(sdp, 0, sizeof(sdp));    sprintf(sdp, "v=0
"                 "o=- 973 1 IN IP4 192.168.1.103
"                 "t=0 0
"                 "a=control:*
"                 "m=video 0 RTP/AVP 96
"                 "a=rtpmap:96 H265/90000
"                 "a=control:track0

");    sprintf(sendBuff, "RTSP/1.0 200 OK
CSeq: %d
"                    "Content-Base: %s
"                    "Content-type: application/sdp
"                    "Content-length: %d

"                    "%s",                    rtspCliInfo.rtspCseq,                    "rtsp://192.168.1.127:8554/test.264",                    strlen(sdp),                    sdp);}

RTSP Server 收到 SETUP 后回復傳輸模式(采用 RTP 傳輸)、端口號信息準備 play。

函數實現如下:


static void RtspStep(char* sendBuff, RtspClientInfo &rtspCliInfo){    sprintf(sendBuff,             "RTSP/1.0 200 OK
"            "CSeq: %d
"            "Transport: RTP/AVP;unicast;client_port=55532-55532;"            "server_port=%d-%d
"            "Session: 66334873
"            "
",            rtspCliInfo.rtspCseq, rtspCliInfo.clientPort, rtspCliInfo.clientPort + 1);}

RTSP Server 收到 PLAY 后回復 Range 的值為"npt=0.0000-",表示從開始播放,默認一直播放!隨后發送視頻流數據。


static void RtspPlay(char* sendBuff, RtspClientInfo &rtspCliInfo){    sprintf(sendBuff, "RTSP/1.0 200 OK
"                "CSeq: %d
"                "Range: npt=0.000-
"                "Session: 66334873; timeout=60

",                rtspCliInfo.rtspCseq);}

程序運行后使用 wireshark 抓取報文如下:

cdb83886-d2bd-11ec-bce3-dac502259ad0.jpg

RTP

RTSP 會話進行到 PLAY 后就可啟動 RTP 發送視頻流數據,RTP 包分為 RtpHeader(Rtp 頭)加 payload(負載數據),在文件 rtp.cpp 下的 UdpSendFrame 函數中。

RtpHeader

csrcLen csrc 計數,在沒有 RTP 混頻器的情況下通常為 0

●extension 擴展名,必須為 0

●padding 填充位,不得使用填充,默認為 0

●version 版本號為 2

●payloadType 數據幀類型 96(H.265)

●marker 將一幀分片時區分頭片

●seq 序列號為了以每片為單位

●timestamp 時間戳以每幀為單位

●ssrc 數據信源號


rtpPacket.rtpHeader.csrcLen = 0;rtpPacket.rtpHeader.extension = 0;rtpPacket.rtpHeader.padding = 0;rtpPacket.rtpHeader.version = 2;
rtpPacket.rtpHeader.payloadType = 96;
rtpPacket.rtpHeader.ssrc = 10;
rtpPacket.rtpHeader.timestamp = timestamp;timestamp+=90000/25;

payload

RTP 包最大為 1400 個字節,因此打包分為兩種:

1.若 H.265 幀小于 1400 個字節時可放至一個 rtp 包中;

2.若 H.265 幀大于 1400 個字節時,則需要分片打包在多個 rtp 中;

當文件小于 1400 時直接放到 pyahload 中發送。


if (s32NalBufSize <= RTP_MAX_PKT_SIZE) {      if (memcpy_s(rtpPacket.payload, s32NalBufSize, pNalBuf, s32NalBufSize) != EOK){        SAMPLE_INFO("memcpy_s");    return -1;    }    rtpPacket.rtpHeader.marker   = 1;    rtpPacket.rtpHeader.seq = seq++;    ret = UdpSendPacket(&rtpPacket, s32NalBufSize);    sendBytes += ret;    SAMPLE_INFO("sendBytes->%d", sendBytes);}

若 H.265 幀大于 1400 個字節時就必須進行分片封包處理。則要設置 PayloadHdr、FU(Fragmentation Units)、DONL 暫不涉及可以省略,其中 PayloadHdr 固定為 49。


   0                   1                   2                   3    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |    PayloadHdr (Type=49)       |   FU header   | DONL (cond)   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|   | DONL (cond)   |                                               |   |-+-+-+-+-+-+-+-+                                               ||FUpayload|

FUheader 格式為:S 置 1 表示起始片,E 置 1 表示最后片,FuType 就是實際的 Nal type 類型。


  +---------------+  |0|1|2|3|4|5|6|7|  +-+-+-+-+-+-+-+-+  |S|E|  FuType   |+---------------+

函數中實現如下:


int pktNum = s32NalBufSize / RTP_MAX_PKT_SIZE;         int remainPktSize = s32NalBufSize % RTP_MAX_PKT_SIZE;    int i, pos, head_len;    head_len = 2;    pos = head_len;     for(i = 0; i < pktNum; i++)    {      rtpPacket.rtpHeader.seq = seq++;            rtpPacket.payload[0] = 49 << 1;      rtpPacket.payload[1] = 1;      rtpPacket.payload[2] = (naluType & 0x7E)>>1;      if (i == 0) {         rtpPacket.rtpHeader.marker = 1;        rtpPacket.payload[2] |= 0x80; // start      }      else if (remainPktSize == 0 && i == (pktNum - 1)){        rtpPacket.rtpHeader.marker = 0;        rtpPacket.payload[2] |= 0x40; // end      }      if (memcpy_s(rtpPacket.payload + head_len + 1, RTP_MAX_PKT_SIZE, pNalBuf+pos, RTP_MAX_PKT_SIZE) != EOK) {        SAMPLE_INFO("memcpy_s");          return -1;      }            ret = UdpSendPacket(&rtpPacket, RTP_MAX_PKT_SIZE + head_len + 1);      if (ret < 0) {        SAMPLE_ERROR("rtpSendPacket is error");        goto cleanup;      }      sendBytes += ret;      pos += RTP_MAX_PKT_SIZE;    }    if (remainPktSize > 0)    {      {        rtpPacket.payload[0] = 49 << 1;        rtpPacket.payload[1] = 1;        rtpPacket.payload[2] = (naluType & 0x7E)>>1;        rtpPacket.payload[2] |= 0x40; // end      }      if (memcpy_s(rtpPacket.payload + head_len + 1, remainPktSize, pNalBuf+pos, remainPktSize) != EOK) {        SAMPLE_INFO("memcpy_s");          return -1;      }      rtpPacket.rtpHeader.seq = seq++;      ret = UdpSendPacket(&rtpPacket, remainPktSize+head_len+1);      if(ret < 0)      {        SAMPLE_ERROR("rtpSendPacket is error");        goto cleanup;      }      sendBytes += ret;    }

程序運行后使用 wireshark 抓取報文如下:

cdeaf3d4-d2bd-11ec-bce3-dac502259ad0.jpg

RTSP Client

RTSP Client 實現使用手機 APP”完美播放器“。

準備一臺手機,在手機應用市場中搜索”完美播放器“并下載安裝。

ce17673e-d2bd-11ec-bce3-dac502259ad0.jpg

打開菜單選擇網址播放。

ce3e9674-d2bd-11ec-bce3-dac502259ad0.jpg

輸入 rtsp 播放地址,其中 ip 地址 10.42.0.54為Hi3518EV300中Wi-Fi 的地址。

ce604102-d2bd-11ec-bce3-dac502259ad0.jpg

總結

豐富多樣的 OpenHarmony 開發樣例離不開廣大合作伙伴和開發者的貢獻,如果你也想把自己開發的樣例分享出來,歡迎把樣例提交到 OpenHarmony 知識體系 SIG 倉來,共建開發樣例請參考如何共建開發樣例。

審核編輯 :李倩



聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人,不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規問題,請聯系本站處理。 舉報投訴
  • 數據
    +關注

    關注

    8

    文章

    6898

    瀏覽量

    88838
  • 視頻編碼
    +關注

    關注

    2

    文章

    112

    瀏覽量

    21011
  • OpenHarmony
    +關注

    關注

    25

    文章

    3661

    瀏覽量

    16159

原文標題:基于OpenHarmony實現智能貓眼

文章出處:【微信號:gh_e4f28cfa3159,微信公眾號:OpenAtom OpenHarmony】歡迎添加關注!文章轉載請注明出處。

收藏 人收藏

    評論

    相關推薦

    流媒體后視鏡市場份額連續6年稱霸全國,新產品即將上市

    日前,來自佐思汽研的《2024年全球及中國電子后視鏡行業研究報告》新鮮出爐。 數據顯示,2024年1-4月,流媒體后視鏡裝配量完成15.9萬輛,同比增長33.8%。從供應商層面來看,遠峰科技仍處于
    的頭像 發表于 09-29 09:50 ?294次閱讀
    <b class='flag-5'>流媒體</b>后視鏡市場份額連續6年稱霸全國,新產品即將上市

    ElfBoard技術貼|如何在ELF 1開發板上搭建流媒體服務器

    流媒體服務器是一種專門用于傳輸實時數據流的服務器軟件,廣泛用于視頻直播、視頻會議、音頻播放等應用場景。在嵌入式開發領域,將流媒體服務器部署到開發板上可以實現諸如視頻監控、實時數據傳輸等功能。本文將介紹如何利用nginx和其rtm
    的頭像 發表于 08-20 14:48 ?522次閱讀
    ElfBoard技術貼|如何在ELF 1開發板上搭建<b class='flag-5'>流媒體</b>服務器

    貿澤開售AMD / Xilinx Alveo MA35D媒體加速器 為流媒體、游戲、遠程醫療和在線學習應用提供支持

    。 ? AMD / Xilinx Alveo MA35D 媒體加速器采用基于特定應用集成電路的視頻處理單元,專為高密度、超低延遲流媒體而設計。每款器件(每張卡 2個)
    發表于 07-12 10:44 ?535次閱讀

    亞馬遜擬收購印度流媒體MX Player部分資產

    近日,亞馬遜與印度知名視頻流媒體服務MX Player達成了一項引人注目的收購協議。據悉,亞馬遜將收購MX Player的部分資產,而此次交易的估值不到1億美元,遠低于市場對該公司的預期。
    的頭像 發表于 06-07 15:56 ?501次閱讀

    智能后視鏡定制_行車記錄儀|流媒體ADAS輔助駕駛定制開發方案

    行車記錄儀方案采用了聯發科MTK6761四核高性能處理器,從根本上解決了過去死機問題,大幅度提升了視頻壓縮效率和畫面穩定性,帶來更加可靠和清晰的行車記錄體驗。采用1080P流媒體后視系統,搭載安卓11系統,大幅升級系統流暢度,使
    的頭像 發表于 05-27 19:51 ?453次閱讀
    <b class='flag-5'>智能</b>后視鏡定制_行車記錄儀|<b class='flag-5'>流媒體</b>ADAS輔助駕駛定制開發方案

    ?PLC設備通過智能網關采用HTTP協議JSON文件對接MES、ERP等系統平臺

    運行。 本文例采用西門子S7-1500PLC(IP:192.168.2.11)與IGT-DSER智能網關以太網通訊,實現HTTP協議JSON文件通訊。先用過
    發表于 05-13 12:04

    【RTC程序設計:實時音視頻權威指南】信令與媒體協

    簡單的rtc系統,至少包含了九個基本信令,從登錄信令開始,登入系統后可以發布媒體流,也可以訂閱其他用戶的媒體流,用戶在房間內的操作都是通過信令來實現的。 在信令傳輸內容中最重要的載體就是
    發表于 04-29 17:24

    OpenHarmony鴻蒙南向開發案例:【智能貓眼(基于Hi3518開發板)】

    基于Hi3518開發板,使用開源OpenHarmony開發的RTSP協議流媒體應用。達到將Hi3518開發板中攝像頭獲取的數據通過RTSP協議
    的頭像 發表于 04-22 15:46 ?1934次閱讀
    OpenHarmony鴻蒙南向開發案例:【<b class='flag-5'>智能</b><b class='flag-5'>貓眼</b>(基于Hi3518開發板)】

    OpenHarmony鴻蒙南向開發案例:【智能貓眼(基于3516開發板)】

    基于Hi3516開發板,使用開源OpenHarmony開發的RTSP協議流媒體應用。達到將Hi3516開發板中攝像頭獲取的數據通過RTSP協議
    的頭像 發表于 04-19 22:01 ?550次閱讀
    OpenHarmony鴻蒙南向開發案例:【<b class='flag-5'>智能</b><b class='flag-5'>貓眼</b>(基于3516開發板)】

    車載智能后視鏡_流媒體云鏡_行車記錄儀主板方案定制

    流媒體后視鏡搭載聯發科MT6761處理器,采用12nm工藝制造,集成四核A53 CPU主頻達2.0GHz。這一高速處理器確保了后視鏡的快速響應和順暢運行,畫面質量不打折,無論白天黑夜都能清晰捕捉影像。流媒體云鏡運行安卓11.0系
    的頭像 發表于 04-08 20:01 ?732次閱讀
    車載<b class='flag-5'>智能</b>后視鏡_<b class='flag-5'>流媒體</b>云鏡_行車記錄儀主板方案定制

    音視頻解碼生成與流媒體傳輸的結合

    音視頻解碼生成與流媒體傳輸是現代數字媒體技術中兩個不可或缺的部分,它們的結合為用戶提供了高質量、實時性的多媒體體驗。 1. 解碼生成與流媒體傳輸的關系 解碼生成是
    的頭像 發表于 02-21 14:36 ?367次閱讀

    歐盟將首次就音樂流媒體對蘋果處以罰款

    近日,據多個消息來源透露,歐盟委員會預計將對美國科技巨頭蘋果公司處以約5億歐元的罰款。這一罰款是針對蘋果公司在音樂流媒體服務方面的行為,違反了歐盟的反壟斷法規。如果這一決定最終得以實施,這將是歐盟歷史上對科技公司的最大罰款之一,同時也是蘋果首次在歐盟面臨此類處罰。
    的頭像 發表于 02-20 14:31 ?567次閱讀

    編解碼一體機在流媒體傳輸中的核心作用

    傳輸帶寬的需求,還能降低存儲空間的使用。 實時傳輸:編解碼一體機支持實時傳輸協議,能夠實現音視頻流的實時傳輸,保證流媒體服務的實時性和流暢性。 協議轉換:編解碼一體機能夠
    的頭像 發表于 01-31 14:20 ?409次閱讀
    編解碼一體機在<b class='flag-5'>流媒體</b>傳輸中的核心作用

    智能貓眼門鈴,雷達感應模組應用

    智能貓眼門鈴初期時,產品功能相對單一,包括門鈴和貓眼兩個部分。門鈴的基本功能是在室外有人呼叫時,室內可以接到信息。隨著技術的進步,電子貓眼經歷了幾個發展階段:首先是帶屏顯示,可拍照報警
    的頭像 發表于 12-12 16:34 ?435次閱讀
    <b class='flag-5'>智能</b><b class='flag-5'>貓眼</b>門鈴,雷達感應模組應用

    毫米波雷達模組在智能貓眼門鈴中的應用

    智能貓眼門鈴初期時,產品功能相對單一,包括門鈴和貓眼兩個部分。門鈴的基本功能是在室外有人呼叫時,室內可以接到信息。隨著技術的進步,電子貓眼經歷了幾個發展階段:首先是帶屏顯示,可拍照報警
    的頭像 發表于 12-11 11:29 ?874次閱讀
    毫米波雷達模組在<b class='flag-5'>智能</b><b class='flag-5'>貓眼</b>門鈴中的應用