透過街景服務直接上傳
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
2.1 版
背景
在舊版 API 中，符合 OSC 規定的相機會建立 Wi-Fi 存取點，供 iOS 版和 Android 版的 Google 街景服務應用程式連線。應用程式會指示 OSC 相機拍照及下載相機拍攝的內容，然後發布至 Google 街景服務。為加快內容發布程序，我們推出了新的選用工作流程，讓 OSC 相機直接將內容上傳至街景服務伺服器。這樣一來，系統就不會先將內容從相機傳送到應用程式，再從應用程式傳送到街景服務伺服器，因此造成內容重複傳輸的時間大幅減少。這項措施已新增至 API 級別 2.1，且僅適用於可提供 Wi-Fi 存取點，並連線至可連上網際網路的基礎架構 Wi-Fi 存取點。
總覽
新的上傳工作流程要求相機提供一種方式 (例如專屬的實體按鈕或現有按鈕組合)，讓使用者可在兩種 Wi-Fi 模式之間切換：
- 直接模式：在這個模式下，攝影機會做為存取點，讓行動裝置連線至該裝置。在這個模式下，行動裝置可以控制相機來執行拍照等工作。行動裝置也可以為相機提供 Wi-Fi 存取點憑證，之後相機就能利用這些憑證切換至「網際網路模式」。
- 網際網路模式：在此模式下，相機會連線至可連上網際網路的 Wi-Fi 存取點，這會使用相機先前處於直接模式時，從應用程式提供的存取點 ID 和密碼。行動裝置可以在這個模式下，直接從相機啟動上傳程序至街景服務伺服器。也可以繼續控制相機來執行拍照等工作。
關閉相機後，相機模式應持續開啟並重新開啟。此外，我們強烈建議您讓相機提供訊號 (例如螢幕上的指示燈、聲音或指示燈)，告知使用者目前的 Wi-Fi 模式。
相機也應有實作探索通訊協定 (請參閱探索)，以在相機處於網際網路模式時處理通訊。
網際網路模式設定
- 使用者開啟相機。尚未設定「網際網路模式」，因此會從「直接模式」啟動。
- 行動裝置會連上攝影機的 Wi-Fi。
- 應用程式會產生自行簽署的憑證。
- 應用程式將
switchWifi 指令傳送至相機，其中含有相機所連結基礎架構 Wi-Fi 存取點的 SSID、該存取點的密碼，以及相機稍後用來驗證應用程式的自行簽署憑證。
- 請注意，相機應安全地儲存 Wi-Fi 憑證和應用程式自行簽署的憑證。
- 建議相機可以儲存多個 Wi-Fi 憑證，因為相機可能需要連線至不同的基礎架構 Wi-Fi 存取點。相機至少須儲存最新的 Wi-Fi 憑證。
- 相機會以自行簽署的憑證回應，供應用程式稍後驗證相機。
- 使用者現在可以直接從相機切換「直接模式」和「網際網路模式」(例如使用實體切換按鈕)。
探索廣告活動
OSC 相機的探索功能屬於零 conf 協定。攝影機「必須」實作 IPv4 連結本機位址，並「必須」符合 mDNS (多點傳送 DNS) 和 DNS-SD (DNS 式服務探索) 規格：
服務執行個體名稱
針對 Service Instance Name 的 <Service> 部分，OSC 相機應使用 _osc._tcp。針對 Service Instance Name 的 <Domain> 部分，OSC 相機應使用 local.。請注意，local 後有結尾的 .。
TXT 記錄
我們要求相機在 TXT 記錄中傳送下列鍵/值組合：txtvers、ty 和 id。
文字稿
如要允許日後更新 TXT 版本，請使用鍵/值組合 txtvers=1。
Ty
提供使用者可理解的相機名稱，例如 ty=Google Street View Optimized Spherical Camera Model XYZ。
id
提供相機的專屬 ID，例如 id=A unique id of the camera。id 的值必須與 /osc/info 輸出內容中的 cameraId 相同。
公告事項
在相機啟動或關機時，攝影機「必須」執行 mDNS 規格中所述的公告步驟。至少傳送對應的公告兩次，且間隔至少一秒。
新創公司
在相機啟動時，「必須」執行 mDNS 規格中所述的探測和公告步驟。在這種情況下，應傳送 SRV、PTR 和 TXT 記錄。建議您盡可能將所有記錄歸入一個 DNS 回應。如果不是，建議使用下列順序：SRV、PTR、TXT 記錄。
關機
關閉相機時，請依據 mDNS 說明文件第 10.1 節所述，在 TTL=0 結尾傳送「goodbye 封包」，藉此通知所有相關方。
自行簽署憑證
應用程式和相機可在網際網路模式設定期間共用的自行簽署憑證，以便彼此進行驗證，並使用 SSL 雙向驗證建立安全通道來保護交換資料。
在網際網路模式期間，應用程式會做為 SSL 伺服器和相機做為用戶端。相機會檢查伺服器憑證是否與應用程式的自行簽署憑證相符，應用程式就會檢查用戶端的憑證是否與相機相符。
在網際網路模式期間，任何支援雙向驗證 (例如 OpenSSL) 的 SSL 程式庫都可以用來在應用程式和相機之間建立 SSL 連線。
全新上傳流程
- 如果攝影機未處於「網際網路模式」，使用者會切換至「網際網路模式」。攝影機會使用已儲存的憑證連線到基礎架構 Wi-Fi。
- 行動裝置也會連上基礎架構 Wi-Fi 並尋找攝影機。
- 這需要相機來實作本機探索通訊協定 mDNS/DNS-SD (請參閱探索)。
- 其實作方式並無特別規定 (mDNSResponder 是很好的參考資料)。
- 應用程式和相機都會在設定網際網路模式時產生並共用自行簽署的憑證。在網際網路模式下，應用程式和相機都會透過雙向 SSL 驗證彼此驗證。
- 找到相機後，系統會根據 HTTP 1.1，直接透過區域網路啟用用戶端通訊。資料格式為 JSON。要求可以是 GET 或 POST 要求。
- 應用程式使用
listFiles 指令向相機查詢檔案清單。
- 應用程式會使用
uploadFile 指令啟動上傳，直接從相機將圖片或影片上傳至街景服務伺服器。
- 應用程式使用
status 指令定期輪詢相機，以便上傳進度。
除非另有註明，否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權，程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間：2025-07-25 (世界標準時間)。
[null,null,["上次更新時間：2025-07-25 (世界標準時間)。"],[[["\u003cp\u003eAPI level 2.1 introduces a new workflow enabling OSC cameras to upload content directly to Street View servers, eliminating the need for a mobile intermediary.\u003c/p\u003e\n"],["\u003cp\u003eCameras must support two Wi-Fi modes: Direct mode for initial setup and device control, and Internet mode for direct uploads via an infrastructure Wi-Fi connection.\u003c/p\u003e\n"],["\u003cp\u003eThe setup involves exchanging self-signed certificates between the camera and the mobile app for secure communication and authentication during Internet mode.\u003c/p\u003e\n"],["\u003cp\u003eCameras are required to implement a local discovery protocol (mDNS/DNS-SD) for the mobile app to locate them on the infrastructure Wi-Fi network.\u003c/p\u003e\n"],["\u003cp\u003eThe new upload flow involves discovering the camera, querying for files, initiating uploads directly from the camera, and monitoring progress via status commands.\u003c/p\u003e\n"]]],["OSC cameras with API level 2.1 can use a new workflow to upload content directly to the Street View server. Cameras must support \"Direct mode\" (as an access point) and \"Internet mode\" (connected to Wi-Fi). In \"Internet mode setup\", the app provides Wi-Fi credentials and a self-signed certificate to the camera, and the camera responds with its certificate. In this mode, the camera uses mDNS/DNS-SD for discovery. Content is uploaded using the `uploadFile` command after the app requests the file list, then monitored with the status command.\n"],null,["# Direct Upload via Street View\n\nVersion 2.1\n\nBackground\n----------\n\nIn earlier versions of the API, an OSC compliant camera would create a Wi-Fi\naccess point that the Google Street View iOS and Android apps could connect to.\nThe app would both direct the OSC camera to capture photos and also download the\ncaptured content from the camera to then publish it to Google Street View. To\nexpedite the publication of content, we have introduced a new optional workflow\nthat allows OSC cameras to upload content to the Street View server directly.\nThis eliminates the lengthy double transfer of content first from the\ncamera to the app and then from the app to the Street View server. **This was\nadded in API level 2.1 and is only relevant to OSC cameras that can both provide\na Wi-Fi access point and also connect to an infrastructure Wi-Fi access point\nwith access to the Internet.**\n\nOverview\n--------\n\nThe new upload workflow requires cameras to provide a way (e.g. a dedicated\nphysical button or a combination of existing buttons) to allow users to switch\nbetween two Wi-Fi modes:\n\n- **Direct mode:** In this mode, the camera acts as an access point which allows a mobile device to connect to it. In this mode, mobile devices can control the camera to perform tasks such as capturing photos. Mobile devices can also provide the camera with Wi-Fi access point credentials that the camera can then use to switch to **Internet mode**.\n- **Internet mode:** In this mode, the camera connects to a Wi-Fi access point with Internet access. It will use the access point identifier and password that was provided to it from the app when the camera was previously in **Direct mode**. Mobile devices can initiate uploads from the camera directly to the Street View server in this mode. They can also continue to control the camera to perform tasks such as capturing photos.\n\nThe camera mode should persist across the camera being turned off and being\nturned back on again. Also, it is highly recommended that the camera offer a\nsignal (e.g. light, sound or indicator on a screen) to inform users of the\ncurrent Wi-Fi mode.\n\nThe camera should also have discovery protocols\n(see [Discovery](/streetview/open-spherical-camera/guides/direct-upload#discovery))\nimplemented to handle communication while the camera is in **Internet mode**.\n\nInternet Mode Setup\n-------------------\n\n1. The user turns on the camera. It starts in **Direct mode** since **Internet mode** is not yet set up.\n2. The mobile device connects to camera's Wi-Fi.\n3. The app generates a self-signed certificate.\n4. The app sends the [`switchWifi`](/streetview/open-spherical-camera/reference/camera/switchwifi) command to the camera with the **SSID** of the infrastructure Wi-Fi access point the camera will need to connect to, the **password** for that access point, and its **self-signed certificate** that the camera uses to authenticate the app later.\n - Please note that the camera should store both the Wi-Fi credential and the app's self-signed certificate securely.\n - It is recommended that the camera store multiple Wi-Fi credentials since the camera may need to connect to different infrastructure Wi-Fi access points. The minimum requirement is for the camera to store the most recent Wi-Fi credential.\n5. The camera responds with its self-signed certificate that the app uses to authenticate the camera later.\n6. The user can now switch between **Direct mode** and **Internet mode** directly from the camera, e.g. with a physical toggle button.\n\nDiscovery\n---------\n\nDiscovery for OSC cameras is a zeroconf based protocol. The camera MUST\nimplement IPv4 Link-Local Addressing and MUST comply with the mDNS (Multicast\nDNS) and DNS-SD (DNS-Based Service Discovery) specifications:\n\n- [IPv4 Link-local](http://www.rfc-editor.org/rfc/rfc3927.txt)\n- [mDNS](http://www.rfc-editor.org/rfc/rfc6762.txt)\n- [DNS-SD](http://www.rfc-editor.org/rfc/rfc6763.txt)\n\n### Service Instance Names\n\nFor the `\u003cService\u003e` portion of the Service Instance Name, OSC cameras should use\n`_osc._tcp`. For the `\u003cDomain\u003e` portion of the Service Instance Name, OSC\ncameras should use `local.`. Note that there is a trailing `.` after `local`.\n\n### TXT record\n\nWe require the camera to send the following key/value pairs in the TXT record:\n`txtvers`, `ty`, and `id`.\n\n#### txtvers\n\nTo allow for updates to the TXT version in the future, use the key/value pair\n`txtvers=1`.\n\n#### ty\n\nProvides a user-readable name of the camera, e.g.\n`ty=Google Street View Optimized Spherical Camera Model XYZ`.\n\n#### id\n\nProvides a unique id of the camera, e.g.\n`id=A unique id of the camera`. The value for `id` MUST be the same as the\n`cameraId` in\n[`/osc/info`](/streetview/open-spherical-camera/guides/osc/info#output) output.\n\n### Announcements\n\nOn camera startup or shutdown, the camera MUST perform the announcement step as\ndescribed in the mDNS specification. It SHOULD send the corresponding\nannouncement at least twice with at least a one-second interval between them.\n\n#### Startup\n\nOn camera startup it MUST perform probing and announcing steps as described in\nthe mDNS specification. SRV, PTR and TXT records should be sent in this case. It\nis recommended to group all records into one DNS response if possible. If not,\nthe following order is recommended: SRV, PTR, TXT records.\n\n#### Shutdown\n\nOn camera shutdown it SHOULD try to notify all interested parties by\nsending a \"goodbye packet\" with `TTL=0` as described in section 10.1 of the\nmDNS documentation.\n\nSelf-signed certificate\n-----------------------\n\nThe app and the camera can use the self-signed certificates shared during the\n**Internet mode setup** to authenticate each other and build a secure channel to protect\nexchanged data, using SSL mutual authentication.\n\nDuring the **Internet mode**, the app would act as a SSL server and the camera as a\nclient. The camera would check that the server's certificate matches the app's\nself-signed certificate, and the app would check that the client's certificate\nmatches the camera's.\n\nAny SSL library supporting mutual authentication (e.g. OpenSSL) can be used to\nestablish SSL connection between the app and the camera during the **Internet mode**.\n\nNew Upload Flow\n---------------\n\n1. If the camera is not in **Internet mode** , the user switches it to **Internet mode**. The camera connects to the infrastructure Wi-Fi using stored credentials.\n2. The mobile device also connects to the infrastructure Wi-Fi and discovers the camera.\n - This requires the camera to implement a local discovery protocol mDNS/DNS-SD (see [Discovery](/streetview/open-spherical-camera/guides/direct-upload#discovery)).\n - There is no specific requirement on how it is implemented ([mDNSResponder](https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/NetServices/Articles/faq.html) is a good reference).\n - Both the app and the camera generate and share self-signed certificates during the **Internet mode setup** . During **Internet mode**, both the app and the camera authenticate each other through mutual SSL authentication.\n - After the camera has been discovered, client communication is enabled with it directly over the local network based on HTTP 1.1. Data formats are JSON based. Requests may be GET or POST requests.\n3. The app queries the camera for a list of files with the [`listFiles`](/streetview/open-spherical-camera/reference/camera/listfiles) command.\n4. The app initiates upload with the [`uploadFile`](/streetview/open-spherical-camera/reference/camera/uploadfile) command to upload an image or video directly from the camera to the Street View server.\n5. The app polls the camera periodically for upload progress with the [`status`](/streetview/open-spherical-camera/guides/osc/commands/status) command."]]
