2020-12-26 14:12:05 -08:00
|
|
|
// Copyright (c) FIRST and other WPILib contributors.
|
|
|
|
|
// Open Source Software; you can modify and/or share it under the terms of
|
|
|
|
|
// the WPILib BSD license file in the root directory of this project.
|
2016-11-28 00:22:15 -08:00
|
|
|
|
|
|
|
|
#include "HttpCameraImpl.h"
|
|
|
|
|
|
2019-04-27 20:33:08 -07:00
|
|
|
#include <wpi/MemAlloc.h>
|
2021-06-06 16:13:58 -07:00
|
|
|
#include <wpi/StringExtras.h>
|
2018-04-29 23:33:19 -07:00
|
|
|
#include <wpi/timestamp.h>
|
2022-05-07 10:54:14 -07:00
|
|
|
#include <wpinet/TCPConnector.h>
|
2016-11-28 00:22:15 -08:00
|
|
|
|
|
|
|
|
#include "Handle.h"
|
2018-10-31 20:22:58 -07:00
|
|
|
#include "Instance.h"
|
2016-11-28 00:22:15 -08:00
|
|
|
#include "JpegUtil.h"
|
|
|
|
|
#include "Log.h"
|
|
|
|
|
#include "Notifier.h"
|
2018-03-04 21:01:55 -08:00
|
|
|
#include "Telemetry.h"
|
2017-08-25 17:48:06 -07:00
|
|
|
#include "c_util.h"
|
2016-11-28 00:22:15 -08:00
|
|
|
|
|
|
|
|
using namespace cs;
|
|
|
|
|
|
2021-06-06 16:13:58 -07:00
|
|
|
HttpCameraImpl::HttpCameraImpl(std::string_view name, CS_HttpCameraKind kind,
|
2018-10-31 20:22:58 -07:00
|
|
|
wpi::Logger& logger, Notifier& notifier,
|
|
|
|
|
Telemetry& telemetry)
|
|
|
|
|
: SourceImpl{name, logger, notifier, telemetry}, m_kind{kind} {}
|
2016-11-28 00:22:15 -08:00
|
|
|
|
|
|
|
|
HttpCameraImpl::~HttpCameraImpl() {
|
|
|
|
|
m_active = false;
|
|
|
|
|
|
2018-12-29 14:08:45 -08:00
|
|
|
// force wakeup of monitor thread
|
|
|
|
|
m_monitorCond.notify_one();
|
|
|
|
|
|
|
|
|
|
// join monitor thread
|
2020-12-28 12:58:06 -08:00
|
|
|
if (m_monitorThread.joinable()) {
|
|
|
|
|
m_monitorThread.join();
|
|
|
|
|
}
|
2018-12-29 14:08:45 -08:00
|
|
|
|
2016-11-28 00:22:15 -08:00
|
|
|
// Close file if it's open
|
|
|
|
|
{
|
2019-07-08 22:58:39 -07:00
|
|
|
std::scoped_lock lock(m_mutex);
|
2020-12-28 12:58:06 -08:00
|
|
|
if (m_streamConn) {
|
|
|
|
|
m_streamConn->stream->close();
|
|
|
|
|
}
|
|
|
|
|
if (m_settingsConn) {
|
|
|
|
|
m_settingsConn->stream->close();
|
|
|
|
|
}
|
2016-11-28 00:22:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// force wakeup of camera thread in case it's waiting on cv
|
|
|
|
|
m_sinkEnabledCond.notify_one();
|
|
|
|
|
|
|
|
|
|
// join camera thread
|
2020-12-28 12:58:06 -08:00
|
|
|
if (m_streamThread.joinable()) {
|
|
|
|
|
m_streamThread.join();
|
|
|
|
|
}
|
2016-11-28 00:22:15 -08:00
|
|
|
|
|
|
|
|
// force wakeup of settings thread
|
|
|
|
|
m_settingsCond.notify_one();
|
|
|
|
|
|
|
|
|
|
// join settings thread
|
2020-12-28 12:58:06 -08:00
|
|
|
if (m_settingsThread.joinable()) {
|
|
|
|
|
m_settingsThread.join();
|
|
|
|
|
}
|
2016-11-28 00:22:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void HttpCameraImpl::Start() {
|
|
|
|
|
// Kick off the stream and settings threads
|
|
|
|
|
m_streamThread = std::thread(&HttpCameraImpl::StreamThreadMain, this);
|
|
|
|
|
m_settingsThread = std::thread(&HttpCameraImpl::SettingsThreadMain, this);
|
2018-12-29 14:08:45 -08:00
|
|
|
m_monitorThread = std::thread(&HttpCameraImpl::MonitorThreadMain, this);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void HttpCameraImpl::MonitorThreadMain() {
|
|
|
|
|
while (m_active) {
|
2019-07-07 19:17:14 -07:00
|
|
|
std::unique_lock lock(m_mutex);
|
2018-12-29 14:08:45 -08:00
|
|
|
// sleep for 1 second between checks
|
|
|
|
|
m_monitorCond.wait_for(lock, std::chrono::seconds(1),
|
2022-10-15 16:33:14 -07:00
|
|
|
[=, this] { return !m_active; });
|
2018-12-29 14:08:45 -08:00
|
|
|
|
2020-12-28 12:58:06 -08:00
|
|
|
if (!m_active) {
|
|
|
|
|
break;
|
|
|
|
|
}
|
2018-12-29 14:08:45 -08:00
|
|
|
|
|
|
|
|
// check to see if we got any frames, and close the stream if not
|
|
|
|
|
// (this will result in an error at the read point, and ultimately
|
|
|
|
|
// a reconnect attempt)
|
|
|
|
|
if (m_streamConn && m_frameCount == 0) {
|
2022-10-19 10:49:27 -07:00
|
|
|
SWARNING("Monitor detected stream hung, disconnecting");
|
2018-12-29 14:08:45 -08:00
|
|
|
m_streamConn->stream->close();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// reset the frame counter
|
|
|
|
|
m_frameCount = 0;
|
|
|
|
|
}
|
|
|
|
|
|
2022-10-19 10:49:27 -07:00
|
|
|
SDEBUG("Monitor Thread exiting");
|
2016-11-28 00:22:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void HttpCameraImpl::StreamThreadMain() {
|
|
|
|
|
while (m_active) {
|
|
|
|
|
SetConnected(false);
|
|
|
|
|
|
|
|
|
|
// sleep between retries
|
|
|
|
|
std::this_thread::sleep_for(std::chrono::milliseconds(250));
|
|
|
|
|
|
2018-07-29 21:18:45 -07:00
|
|
|
// disconnect if not enabled
|
|
|
|
|
if (!IsEnabled()) {
|
2019-07-07 19:17:14 -07:00
|
|
|
std::unique_lock lock(m_mutex);
|
2020-12-28 12:58:06 -08:00
|
|
|
if (m_streamConn) {
|
|
|
|
|
m_streamConn->stream->close();
|
|
|
|
|
}
|
2018-07-29 21:18:45 -07:00
|
|
|
// Wait for enable
|
2022-10-15 16:33:14 -07:00
|
|
|
m_sinkEnabledCond.wait(lock,
|
|
|
|
|
[=, this] { return !m_active || IsEnabled(); });
|
2020-12-28 12:58:06 -08:00
|
|
|
if (!m_active) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
2016-11-28 00:22:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// connect
|
2018-04-29 23:33:19 -07:00
|
|
|
wpi::SmallString<64> boundary;
|
2017-08-25 18:10:47 -07:00
|
|
|
wpi::HttpConnection* conn = DeviceStreamConnect(boundary);
|
2016-11-28 00:22:15 -08:00
|
|
|
|
2020-12-28 12:58:06 -08:00
|
|
|
if (!m_active) {
|
|
|
|
|
break;
|
|
|
|
|
}
|
2016-11-28 00:22:15 -08:00
|
|
|
|
|
|
|
|
// keep retrying
|
2020-12-28 12:58:06 -08:00
|
|
|
if (!conn) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
2016-11-28 00:22:15 -08:00
|
|
|
|
|
|
|
|
// update connected since we're actually connected
|
|
|
|
|
SetConnected(true);
|
|
|
|
|
|
|
|
|
|
// stream
|
2021-06-06 16:13:58 -07:00
|
|
|
DeviceStream(conn->is, boundary.str());
|
2018-12-29 14:08:45 -08:00
|
|
|
{
|
2019-07-07 19:17:14 -07:00
|
|
|
std::unique_lock lock(m_mutex);
|
2018-12-29 14:08:45 -08:00
|
|
|
m_streamConn = nullptr;
|
|
|
|
|
}
|
2016-11-28 00:22:15 -08:00
|
|
|
}
|
|
|
|
|
|
2022-10-19 10:49:27 -07:00
|
|
|
SDEBUG("Camera Thread exiting");
|
2016-11-28 00:22:15 -08:00
|
|
|
SetConnected(false);
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-25 18:10:47 -07:00
|
|
|
wpi::HttpConnection* HttpCameraImpl::DeviceStreamConnect(
|
2018-04-29 23:33:19 -07:00
|
|
|
wpi::SmallVectorImpl<char>& boundary) {
|
2016-11-28 00:22:15 -08:00
|
|
|
// Build the request
|
2017-08-25 18:10:47 -07:00
|
|
|
wpi::HttpRequest req;
|
2016-11-28 00:22:15 -08:00
|
|
|
{
|
2019-07-08 22:58:39 -07:00
|
|
|
std::scoped_lock lock(m_mutex);
|
2016-11-28 00:22:15 -08:00
|
|
|
if (m_locations.empty()) {
|
2022-10-19 10:49:27 -07:00
|
|
|
SERROR("locations array is empty!?");
|
2016-11-28 00:22:15 -08:00
|
|
|
std::this_thread::sleep_for(std::chrono::seconds(1));
|
|
|
|
|
return nullptr;
|
|
|
|
|
}
|
2020-12-28 12:58:06 -08:00
|
|
|
if (m_nextLocation >= m_locations.size()) {
|
|
|
|
|
m_nextLocation = 0;
|
|
|
|
|
}
|
2017-08-25 18:10:47 -07:00
|
|
|
req = wpi::HttpRequest{m_locations[m_nextLocation++], m_streamSettings};
|
2016-11-28 00:22:15 -08:00
|
|
|
m_streamSettingsUpdated = false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Try to connect
|
2018-10-31 20:22:58 -07:00
|
|
|
auto stream =
|
|
|
|
|
wpi::TCPConnector::connect(req.host.c_str(), req.port, m_logger, 1);
|
2016-11-28 00:22:15 -08:00
|
|
|
|
2020-12-28 12:58:06 -08:00
|
|
|
if (!m_active || !stream) {
|
|
|
|
|
return nullptr;
|
|
|
|
|
}
|
2016-11-28 00:22:15 -08:00
|
|
|
|
2019-07-07 15:44:43 -07:00
|
|
|
auto connPtr = std::make_unique<wpi::HttpConnection>(std::move(stream), 1);
|
2017-08-25 18:10:47 -07:00
|
|
|
wpi::HttpConnection* conn = connPtr.get();
|
2016-11-28 00:22:15 -08:00
|
|
|
|
|
|
|
|
// update m_streamConn
|
|
|
|
|
{
|
2019-07-08 22:58:39 -07:00
|
|
|
std::scoped_lock lock(m_mutex);
|
2018-12-29 14:08:45 -08:00
|
|
|
m_frameCount = 1; // avoid a race with monitor thread
|
2016-11-28 00:22:15 -08:00
|
|
|
m_streamConn = std::move(connPtr);
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-25 18:10:47 -07:00
|
|
|
std::string warn;
|
|
|
|
|
if (!conn->Handshake(req, &warn)) {
|
2021-06-06 16:13:58 -07:00
|
|
|
SWARNING("{}", warn);
|
2019-07-08 22:58:39 -07:00
|
|
|
std::scoped_lock lock(m_mutex);
|
2016-11-28 00:22:15 -08:00
|
|
|
m_streamConn = nullptr;
|
|
|
|
|
return nullptr;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Parse Content-Type header to get the boundary
|
2021-06-06 16:13:58 -07:00
|
|
|
auto [mediaType, contentType] = wpi::split(conn->contentType.str(), ';');
|
|
|
|
|
mediaType = wpi::trim(mediaType);
|
2016-11-28 00:22:15 -08:00
|
|
|
if (mediaType != "multipart/x-mixed-replace") {
|
2023-08-28 15:15:14 -07:00
|
|
|
SWARNING("\"{}\": unrecognized Content-Type \"{}\"", req.host.str(),
|
|
|
|
|
mediaType);
|
2019-07-08 22:58:39 -07:00
|
|
|
std::scoped_lock lock(m_mutex);
|
2016-11-28 00:22:15 -08:00
|
|
|
m_streamConn = nullptr;
|
|
|
|
|
return nullptr;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// media parameters
|
|
|
|
|
boundary.clear();
|
|
|
|
|
while (!contentType.empty()) {
|
2021-06-06 16:13:58 -07:00
|
|
|
std::string_view keyvalue;
|
|
|
|
|
std::tie(keyvalue, contentType) = wpi::split(contentType, ';');
|
|
|
|
|
contentType = wpi::ltrim(contentType);
|
|
|
|
|
auto [key, value] = wpi::split(keyvalue, '=');
|
|
|
|
|
if (wpi::trim(key) == "boundary") {
|
|
|
|
|
value = wpi::trim(wpi::trim(value), '"'); // value may be quoted
|
|
|
|
|
if (wpi::starts_with(value, "--")) {
|
2021-11-27 21:31:40 -08:00
|
|
|
value = wpi::substr(value, 2);
|
2019-03-03 11:20:43 -08:00
|
|
|
}
|
2016-11-28 00:22:15 -08:00
|
|
|
boundary.append(value.begin(), value.end());
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (boundary.empty()) {
|
2023-08-28 15:15:14 -07:00
|
|
|
SWARNING("\"{}\": empty multi-part boundary or no Content-Type",
|
|
|
|
|
req.host.str());
|
2019-07-08 22:58:39 -07:00
|
|
|
std::scoped_lock lock(m_mutex);
|
2016-11-28 00:22:15 -08:00
|
|
|
m_streamConn = nullptr;
|
|
|
|
|
return nullptr;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return conn;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void HttpCameraImpl::DeviceStream(wpi::raw_istream& is,
|
2021-06-06 16:13:58 -07:00
|
|
|
std::string_view boundary) {
|
2016-11-28 00:22:15 -08:00
|
|
|
// Stored here so we reuse it from frame to frame
|
|
|
|
|
std::string imageBuf;
|
|
|
|
|
|
|
|
|
|
// keep track of number of bad images received; if we receive 3 bad images
|
|
|
|
|
// in a row, we reconnect
|
|
|
|
|
int numErrors = 0;
|
|
|
|
|
|
|
|
|
|
// streaming loop
|
2018-07-29 21:18:45 -07:00
|
|
|
while (m_active && !is.has_error() && IsEnabled() && numErrors < 3 &&
|
|
|
|
|
!m_streamSettingsUpdated) {
|
2020-12-28 12:58:06 -08:00
|
|
|
if (!FindMultipartBoundary(is, boundary, nullptr)) {
|
|
|
|
|
break;
|
|
|
|
|
}
|
2016-11-28 00:22:15 -08:00
|
|
|
|
|
|
|
|
// Read the next two characters after the boundary (normally \r\n)
|
2019-03-03 11:20:43 -08:00
|
|
|
// Handle just \n for LabVIEW however
|
2016-11-28 00:22:15 -08:00
|
|
|
char eol[2];
|
2019-03-03 11:20:43 -08:00
|
|
|
is.read(eol, 1);
|
2020-12-28 12:58:06 -08:00
|
|
|
if (!m_active || is.has_error()) {
|
|
|
|
|
break;
|
|
|
|
|
}
|
2019-03-03 11:20:43 -08:00
|
|
|
if (eol[0] != '\n') {
|
|
|
|
|
is.read(eol + 1, 1);
|
2020-12-28 12:58:06 -08:00
|
|
|
if (!m_active || is.has_error()) {
|
|
|
|
|
break;
|
|
|
|
|
}
|
2019-03-03 11:20:43 -08:00
|
|
|
// End-of-stream is indicated with trailing --
|
2020-12-28 12:58:06 -08:00
|
|
|
if (eol[0] == '-' && eol[1] == '-') {
|
|
|
|
|
break;
|
|
|
|
|
}
|
2019-03-03 11:20:43 -08:00
|
|
|
}
|
2016-11-28 00:22:15 -08:00
|
|
|
|
2020-12-28 12:58:06 -08:00
|
|
|
if (!DeviceStreamFrame(is, imageBuf)) {
|
2016-11-28 00:22:15 -08:00
|
|
|
++numErrors;
|
2020-12-28 12:58:06 -08:00
|
|
|
} else {
|
2016-11-28 00:22:15 -08:00
|
|
|
numErrors = 0;
|
2020-12-28 12:58:06 -08:00
|
|
|
}
|
2016-11-28 00:22:15 -08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool HttpCameraImpl::DeviceStreamFrame(wpi::raw_istream& is,
|
|
|
|
|
std::string& imageBuf) {
|
|
|
|
|
// Read the headers
|
2018-04-29 23:33:19 -07:00
|
|
|
wpi::SmallString<64> contentTypeBuf;
|
|
|
|
|
wpi::SmallString<64> contentLengthBuf;
|
2016-11-28 00:22:15 -08:00
|
|
|
if (!ParseHttpHeaders(is, &contentTypeBuf, &contentLengthBuf)) {
|
2022-10-19 10:49:27 -07:00
|
|
|
SWARNING("disconnected during headers");
|
2016-11-28 00:22:15 -08:00
|
|
|
PutError("disconnected during headers", wpi::Now());
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Check the content type (if present)
|
|
|
|
|
if (!contentTypeBuf.str().empty() &&
|
2021-06-06 16:13:58 -07:00
|
|
|
!wpi::starts_with(contentTypeBuf, "image/jpeg")) {
|
2023-08-28 15:15:14 -07:00
|
|
|
auto errMsg = fmt::format("received unknown Content-Type \"{}\"",
|
|
|
|
|
contentTypeBuf.str());
|
2021-06-06 16:13:58 -07:00
|
|
|
SWARNING("{}", errMsg);
|
|
|
|
|
PutError(errMsg, wpi::Now());
|
2016-11-28 00:22:15 -08:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
unsigned int contentLength = 0;
|
2021-06-06 16:13:58 -07:00
|
|
|
if (auto v = wpi::parse_integer<unsigned int>(contentLengthBuf, 10)) {
|
|
|
|
|
contentLength = v.value();
|
|
|
|
|
} else {
|
2016-11-28 00:22:15 -08:00
|
|
|
// Ugh, no Content-Length? Read the blocks of the JPEG file.
|
|
|
|
|
int width, height;
|
|
|
|
|
if (!ReadJpeg(is, imageBuf, &width, &height)) {
|
2022-10-19 10:49:27 -07:00
|
|
|
SWARNING("did not receive a JPEG image");
|
2016-11-28 00:22:15 -08:00
|
|
|
PutError("did not receive a JPEG image", wpi::Now());
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
PutFrame(VideoMode::PixelFormat::kMJPEG, width, height, imageBuf,
|
|
|
|
|
wpi::Now());
|
2018-12-29 14:08:45 -08:00
|
|
|
++m_frameCount;
|
2016-11-28 00:22:15 -08:00
|
|
|
return true;
|
|
|
|
|
}
|
2017-08-14 22:27:07 -07:00
|
|
|
|
2016-11-28 00:22:15 -08:00
|
|
|
// We know how big it is! Just get a frame of the right size and read
|
|
|
|
|
// the data directly into it.
|
|
|
|
|
auto image = AllocImage(VideoMode::PixelFormat::kMJPEG, 0, 0, contentLength);
|
|
|
|
|
is.read(image->data(), contentLength);
|
2020-12-28 12:58:06 -08:00
|
|
|
if (!m_active || is.has_error()) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2016-11-28 00:22:15 -08:00
|
|
|
int width, height;
|
|
|
|
|
if (!GetJpegSize(image->str(), &width, &height)) {
|
2022-10-19 10:49:27 -07:00
|
|
|
SWARNING("did not receive a JPEG image");
|
2016-11-28 00:22:15 -08:00
|
|
|
PutError("did not receive a JPEG image", wpi::Now());
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
image->width = width;
|
|
|
|
|
image->height = height;
|
|
|
|
|
PutFrame(std::move(image), wpi::Now());
|
2018-12-29 14:08:45 -08:00
|
|
|
++m_frameCount;
|
2016-11-28 00:22:15 -08:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void HttpCameraImpl::SettingsThreadMain() {
|
|
|
|
|
for (;;) {
|
2017-08-25 18:10:47 -07:00
|
|
|
wpi::HttpRequest req;
|
2016-11-28 00:22:15 -08:00
|
|
|
{
|
2019-07-07 19:17:14 -07:00
|
|
|
std::unique_lock lock(m_mutex);
|
2022-10-15 16:33:14 -07:00
|
|
|
m_settingsCond.wait(lock, [=, this] {
|
2016-11-28 00:22:15 -08:00
|
|
|
return !m_active || (m_prefLocation != -1 && !m_settings.empty());
|
|
|
|
|
});
|
2020-12-28 12:58:06 -08:00
|
|
|
if (!m_active) {
|
|
|
|
|
break;
|
|
|
|
|
}
|
2016-11-28 00:22:15 -08:00
|
|
|
|
|
|
|
|
// Build the request
|
2017-08-25 18:10:47 -07:00
|
|
|
req = wpi::HttpRequest{m_locations[m_prefLocation], m_settings};
|
2016-11-28 00:22:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
DeviceSendSettings(req);
|
|
|
|
|
}
|
|
|
|
|
|
2022-10-19 10:49:27 -07:00
|
|
|
SDEBUG("Settings Thread exiting");
|
2016-11-28 00:22:15 -08:00
|
|
|
}
|
|
|
|
|
|
2017-08-25 18:10:47 -07:00
|
|
|
void HttpCameraImpl::DeviceSendSettings(wpi::HttpRequest& req) {
|
2016-11-28 00:22:15 -08:00
|
|
|
// Try to connect
|
2018-10-31 20:22:58 -07:00
|
|
|
auto stream =
|
|
|
|
|
wpi::TCPConnector::connect(req.host.c_str(), req.port, m_logger, 1);
|
2016-11-28 00:22:15 -08:00
|
|
|
|
2020-12-28 12:58:06 -08:00
|
|
|
if (!m_active || !stream) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
2016-11-28 00:22:15 -08:00
|
|
|
|
2019-07-07 15:44:43 -07:00
|
|
|
auto connPtr = std::make_unique<wpi::HttpConnection>(std::move(stream), 1);
|
2017-08-25 18:10:47 -07:00
|
|
|
wpi::HttpConnection* conn = connPtr.get();
|
2016-11-28 00:22:15 -08:00
|
|
|
|
|
|
|
|
// update m_settingsConn
|
|
|
|
|
{
|
2019-07-08 22:58:39 -07:00
|
|
|
std::scoped_lock lock(m_mutex);
|
2016-11-28 00:22:15 -08:00
|
|
|
m_settingsConn = std::move(connPtr);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Just need a handshake as settings are sent via GET parameters
|
2017-08-25 18:10:47 -07:00
|
|
|
std::string warn;
|
2020-12-28 12:58:06 -08:00
|
|
|
if (!conn->Handshake(req, &warn)) {
|
2021-06-06 16:13:58 -07:00
|
|
|
SWARNING("{}", warn);
|
2020-12-28 12:58:06 -08:00
|
|
|
}
|
2016-11-28 00:22:15 -08:00
|
|
|
|
|
|
|
|
conn->stream->close();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
CS_HttpCameraKind HttpCameraImpl::GetKind() const {
|
2019-07-08 22:58:39 -07:00
|
|
|
std::scoped_lock lock(m_mutex);
|
2016-11-28 00:22:15 -08:00
|
|
|
return m_kind;
|
|
|
|
|
}
|
|
|
|
|
|
2022-10-15 16:33:14 -07:00
|
|
|
bool HttpCameraImpl::SetUrls(std::span<const std::string> urls,
|
2016-11-28 00:22:15 -08:00
|
|
|
CS_Status* status) {
|
2017-08-25 18:10:47 -07:00
|
|
|
std::vector<wpi::HttpLocation> locations;
|
2016-11-28 00:22:15 -08:00
|
|
|
for (const auto& url : urls) {
|
|
|
|
|
bool error = false;
|
2017-08-25 18:10:47 -07:00
|
|
|
std::string errorMsg;
|
|
|
|
|
locations.emplace_back(url, &error, &errorMsg);
|
2016-11-28 00:22:15 -08:00
|
|
|
if (error) {
|
2021-06-06 16:13:58 -07:00
|
|
|
SERROR("{}", errorMsg);
|
2016-11-28 00:22:15 -08:00
|
|
|
*status = CS_BAD_URL;
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-07-08 22:58:39 -07:00
|
|
|
std::scoped_lock lock(m_mutex);
|
2016-11-28 00:22:15 -08:00
|
|
|
m_locations.swap(locations);
|
|
|
|
|
m_nextLocation = 0;
|
2018-02-28 23:28:49 -08:00
|
|
|
m_streamSettingsUpdated = true;
|
2016-11-28 00:22:15 -08:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
std::vector<std::string> HttpCameraImpl::GetUrls() const {
|
2019-07-08 22:58:39 -07:00
|
|
|
std::scoped_lock lock(m_mutex);
|
2016-11-28 00:22:15 -08:00
|
|
|
std::vector<std::string> urls;
|
2020-12-28 12:58:06 -08:00
|
|
|
for (const auto& loc : m_locations) {
|
|
|
|
|
urls.push_back(loc.url);
|
|
|
|
|
}
|
2016-11-28 00:22:15 -08:00
|
|
|
return urls;
|
|
|
|
|
}
|
|
|
|
|
|
2021-06-06 16:13:58 -07:00
|
|
|
void HttpCameraImpl::CreateProperty(std::string_view name,
|
|
|
|
|
std::string_view httpParam,
|
2018-07-29 12:53:41 -07:00
|
|
|
bool viaSettings, CS_PropertyKind kind,
|
|
|
|
|
int minimum, int maximum, int step,
|
|
|
|
|
int defaultValue, int value) const {
|
2019-07-08 22:58:39 -07:00
|
|
|
std::scoped_lock lock(m_mutex);
|
2019-07-07 15:44:43 -07:00
|
|
|
m_propertyData.emplace_back(std::make_unique<PropertyData>(
|
2016-11-28 00:22:15 -08:00
|
|
|
name, httpParam, viaSettings, kind, minimum, maximum, step, defaultValue,
|
|
|
|
|
value));
|
|
|
|
|
|
2018-10-31 20:22:58 -07:00
|
|
|
m_notifier.NotifySourceProperty(*this, CS_SOURCE_PROPERTY_CREATED, name,
|
2021-06-06 16:13:58 -07:00
|
|
|
m_propertyData.size() + 1, kind, value, {});
|
2016-11-28 00:22:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
template <typename T>
|
|
|
|
|
void HttpCameraImpl::CreateEnumProperty(
|
2021-06-06 16:13:58 -07:00
|
|
|
std::string_view name, std::string_view httpParam, bool viaSettings,
|
2016-11-28 00:22:15 -08:00
|
|
|
int defaultValue, int value, std::initializer_list<T> choices) const {
|
2019-07-08 22:58:39 -07:00
|
|
|
std::scoped_lock lock(m_mutex);
|
2019-07-07 15:44:43 -07:00
|
|
|
m_propertyData.emplace_back(std::make_unique<PropertyData>(
|
2016-11-28 00:22:15 -08:00
|
|
|
name, httpParam, viaSettings, CS_PROP_ENUM, 0, choices.size() - 1, 1,
|
|
|
|
|
defaultValue, value));
|
|
|
|
|
|
|
|
|
|
auto& enumChoices = m_propertyData.back()->enumChoices;
|
|
|
|
|
enumChoices.clear();
|
2020-12-28 12:58:06 -08:00
|
|
|
for (const auto& choice : choices) {
|
|
|
|
|
enumChoices.emplace_back(choice);
|
|
|
|
|
}
|
2016-11-28 00:22:15 -08:00
|
|
|
|
2018-10-31 20:22:58 -07:00
|
|
|
m_notifier.NotifySourceProperty(*this, CS_SOURCE_PROPERTY_CREATED, name,
|
|
|
|
|
m_propertyData.size() + 1, CS_PROP_ENUM,
|
2021-06-06 16:13:58 -07:00
|
|
|
value, {});
|
2018-10-31 20:22:58 -07:00
|
|
|
m_notifier.NotifySourceProperty(*this, CS_SOURCE_PROPERTY_CHOICES_UPDATED,
|
|
|
|
|
name, m_propertyData.size() + 1, CS_PROP_ENUM,
|
2021-06-06 16:13:58 -07:00
|
|
|
value, {});
|
2016-11-28 00:22:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
std::unique_ptr<PropertyImpl> HttpCameraImpl::CreateEmptyProperty(
|
2021-06-06 16:13:58 -07:00
|
|
|
std::string_view name) const {
|
2019-07-07 15:44:43 -07:00
|
|
|
return std::make_unique<PropertyData>(name);
|
2016-11-28 00:22:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool HttpCameraImpl::CacheProperties(CS_Status* status) const {
|
2019-12-14 10:48:19 -08:00
|
|
|
#ifdef _MSC_VER // work around VS2019 16.4.0 bug
|
|
|
|
|
std::scoped_lock<wpi::mutex> lock(m_mutex);
|
|
|
|
|
#else
|
2019-07-08 22:58:39 -07:00
|
|
|
std::scoped_lock lock(m_mutex);
|
2019-12-14 10:48:19 -08:00
|
|
|
#endif
|
2016-11-28 00:22:15 -08:00
|
|
|
|
|
|
|
|
// Pretty typical set of video modes
|
|
|
|
|
m_videoModes.clear();
|
|
|
|
|
m_videoModes.emplace_back(VideoMode::kMJPEG, 640, 480, 30);
|
|
|
|
|
m_videoModes.emplace_back(VideoMode::kMJPEG, 320, 240, 30);
|
|
|
|
|
m_videoModes.emplace_back(VideoMode::kMJPEG, 160, 120, 30);
|
|
|
|
|
|
|
|
|
|
m_properties_cached = true;
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void HttpCameraImpl::SetProperty(int property, int value, CS_Status* status) {
|
|
|
|
|
// TODO
|
|
|
|
|
}
|
|
|
|
|
|
2021-06-06 16:13:58 -07:00
|
|
|
void HttpCameraImpl::SetStringProperty(int property, std::string_view value,
|
2016-11-28 00:22:15 -08:00
|
|
|
CS_Status* status) {
|
|
|
|
|
// TODO
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-01 14:24:13 -08:00
|
|
|
void HttpCameraImpl::SetBrightness(int brightness, CS_Status* status) {
|
|
|
|
|
// TODO
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int HttpCameraImpl::GetBrightness(CS_Status* status) const {
|
|
|
|
|
// TODO
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void HttpCameraImpl::SetWhiteBalanceAuto(CS_Status* status) {
|
|
|
|
|
// TODO
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void HttpCameraImpl::SetWhiteBalanceHoldCurrent(CS_Status* status) {
|
|
|
|
|
// TODO
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void HttpCameraImpl::SetWhiteBalanceManual(int value, CS_Status* status) {
|
|
|
|
|
// TODO
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void HttpCameraImpl::SetExposureAuto(CS_Status* status) {
|
|
|
|
|
// TODO
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void HttpCameraImpl::SetExposureHoldCurrent(CS_Status* status) {
|
|
|
|
|
// TODO
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void HttpCameraImpl::SetExposureManual(int value, CS_Status* status) {
|
|
|
|
|
// TODO
|
|
|
|
|
}
|
|
|
|
|
|
2016-11-28 00:22:15 -08:00
|
|
|
bool HttpCameraImpl::SetVideoMode(const VideoMode& mode, CS_Status* status) {
|
2020-12-28 12:58:06 -08:00
|
|
|
if (mode.pixelFormat != VideoMode::kMJPEG) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2019-07-08 22:58:39 -07:00
|
|
|
std::scoped_lock lock(m_mutex);
|
2016-11-28 00:22:15 -08:00
|
|
|
m_mode = mode;
|
|
|
|
|
m_streamSettingsUpdated = true;
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void HttpCameraImpl::NumSinksChanged() {
|
|
|
|
|
// ignore
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void HttpCameraImpl::NumSinksEnabledChanged() {
|
|
|
|
|
m_sinkEnabledCond.notify_one();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool AxisCameraImpl::CacheProperties(CS_Status* status) const {
|
|
|
|
|
CreateProperty("brightness", "ImageSource.I0.Sensor.Brightness", true,
|
|
|
|
|
CS_PROP_INTEGER, 0, 100, 1, 50, 50);
|
|
|
|
|
CreateEnumProperty("white_balance", "ImageSource.I0.Sensor.WhiteBalance",
|
|
|
|
|
true, 0, 0,
|
|
|
|
|
{"auto", "hold", "fixed_outdoor1", "fixed_outdoor2",
|
|
|
|
|
"fixed_indoor", "fixed_fluor1", "fixed_fluor2"});
|
|
|
|
|
CreateProperty("color_level", "ImageSource.I0.Sensor.ColorLevel", true,
|
|
|
|
|
CS_PROP_INTEGER, 0, 100, 1, 50, 50);
|
|
|
|
|
CreateEnumProperty("exposure", "ImageSource.I0.Sensor.Exposure", true, 0, 0,
|
|
|
|
|
{"auto", "hold", "flickerfree50", "flickerfree60"});
|
|
|
|
|
CreateProperty("exposure_priority", "ImageSource.I0.Sensor.ExposurePriority",
|
|
|
|
|
true, CS_PROP_INTEGER, 0, 100, 1, 50, 50);
|
|
|
|
|
|
|
|
|
|
// TODO: get video modes from device
|
2019-07-08 22:58:39 -07:00
|
|
|
std::scoped_lock lock(m_mutex);
|
2016-11-28 00:22:15 -08:00
|
|
|
m_videoModes.clear();
|
|
|
|
|
m_videoModes.emplace_back(VideoMode::kMJPEG, 640, 480, 30);
|
|
|
|
|
m_videoModes.emplace_back(VideoMode::kMJPEG, 480, 360, 30);
|
|
|
|
|
m_videoModes.emplace_back(VideoMode::kMJPEG, 320, 240, 30);
|
|
|
|
|
m_videoModes.emplace_back(VideoMode::kMJPEG, 240, 180, 30);
|
|
|
|
|
m_videoModes.emplace_back(VideoMode::kMJPEG, 176, 144, 30);
|
|
|
|
|
m_videoModes.emplace_back(VideoMode::kMJPEG, 160, 120, 30);
|
|
|
|
|
|
|
|
|
|
m_properties_cached = true;
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
namespace cs {
|
|
|
|
|
|
2021-06-06 16:13:58 -07:00
|
|
|
CS_Source CreateHttpCamera(std::string_view name, std::string_view url,
|
2016-11-28 00:22:15 -08:00
|
|
|
CS_HttpCameraKind kind, CS_Status* status) {
|
2018-10-31 20:22:58 -07:00
|
|
|
auto& inst = Instance::GetInstance();
|
2016-11-28 00:22:15 -08:00
|
|
|
std::shared_ptr<HttpCameraImpl> source;
|
|
|
|
|
switch (kind) {
|
|
|
|
|
case CS_HTTP_AXIS:
|
2018-10-31 20:22:58 -07:00
|
|
|
source = std::make_shared<AxisCameraImpl>(name, inst.logger,
|
|
|
|
|
inst.notifier, inst.telemetry);
|
2016-11-28 00:22:15 -08:00
|
|
|
break;
|
|
|
|
|
default:
|
2018-10-31 20:22:58 -07:00
|
|
|
source = std::make_shared<HttpCameraImpl>(name, kind, inst.logger,
|
|
|
|
|
inst.notifier, inst.telemetry);
|
2016-11-28 00:22:15 -08:00
|
|
|
break;
|
|
|
|
|
}
|
2021-06-06 19:51:14 -07:00
|
|
|
std::string urlStr{url};
|
2022-10-15 16:33:14 -07:00
|
|
|
if (!source->SetUrls(std::span{&urlStr, 1}, status)) {
|
2020-12-28 12:58:06 -08:00
|
|
|
return 0;
|
|
|
|
|
}
|
2018-11-06 19:42:39 -08:00
|
|
|
return inst.CreateSource(CS_SOURCE_HTTP, source);
|
2016-11-28 00:22:15 -08:00
|
|
|
}
|
|
|
|
|
|
2021-06-06 16:13:58 -07:00
|
|
|
CS_Source CreateHttpCamera(std::string_view name,
|
2022-10-15 16:33:14 -07:00
|
|
|
std::span<const std::string> urls,
|
2016-11-28 00:22:15 -08:00
|
|
|
CS_HttpCameraKind kind, CS_Status* status) {
|
2018-10-31 20:22:58 -07:00
|
|
|
auto& inst = Instance::GetInstance();
|
2016-11-28 00:22:15 -08:00
|
|
|
if (urls.empty()) {
|
|
|
|
|
*status = CS_EMPTY_VALUE;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2018-10-31 20:22:58 -07:00
|
|
|
auto source = std::make_shared<HttpCameraImpl>(name, kind, inst.logger,
|
|
|
|
|
inst.notifier, inst.telemetry);
|
2020-12-28 12:58:06 -08:00
|
|
|
if (!source->SetUrls(urls, status)) {
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2018-11-06 19:42:39 -08:00
|
|
|
return inst.CreateSource(CS_SOURCE_HTTP, source);
|
2016-11-28 00:22:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
CS_HttpCameraKind GetHttpCameraKind(CS_Source source, CS_Status* status) {
|
2018-11-06 19:42:39 -08:00
|
|
|
auto data = Instance::GetInstance().GetSource(source);
|
2016-11-28 00:22:15 -08:00
|
|
|
if (!data || data->kind != CS_SOURCE_HTTP) {
|
|
|
|
|
*status = CS_INVALID_HANDLE;
|
|
|
|
|
return CS_HTTP_UNKNOWN;
|
|
|
|
|
}
|
|
|
|
|
return static_cast<HttpCameraImpl&>(*data->source).GetKind();
|
|
|
|
|
}
|
|
|
|
|
|
2022-10-15 16:33:14 -07:00
|
|
|
void SetHttpCameraUrls(CS_Source source, std::span<const std::string> urls,
|
2016-11-28 00:22:15 -08:00
|
|
|
CS_Status* status) {
|
|
|
|
|
if (urls.empty()) {
|
|
|
|
|
*status = CS_EMPTY_VALUE;
|
|
|
|
|
return;
|
|
|
|
|
}
|
2018-11-06 19:42:39 -08:00
|
|
|
auto data = Instance::GetInstance().GetSource(source);
|
2016-11-28 00:22:15 -08:00
|
|
|
if (!data || data->kind != CS_SOURCE_HTTP) {
|
|
|
|
|
*status = CS_INVALID_HANDLE;
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
static_cast<HttpCameraImpl&>(*data->source).SetUrls(urls, status);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
std::vector<std::string> GetHttpCameraUrls(CS_Source source,
|
|
|
|
|
CS_Status* status) {
|
2018-11-06 19:42:39 -08:00
|
|
|
auto data = Instance::GetInstance().GetSource(source);
|
2016-11-28 00:22:15 -08:00
|
|
|
if (!data || data->kind != CS_SOURCE_HTTP) {
|
|
|
|
|
*status = CS_INVALID_HANDLE;
|
|
|
|
|
return std::vector<std::string>{};
|
|
|
|
|
}
|
|
|
|
|
return static_cast<HttpCameraImpl&>(*data->source).GetUrls();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
} // namespace cs
|
|
|
|
|
|
|
|
|
|
extern "C" {
|
|
|
|
|
|
Change C APIs to a unified string implementation (#6299)
Currently in the entire C API of WPILib we have ~8 different ways of handling strings. The C API actually isn't built for pure C callers (We don't actually have any of those). Instead, they're built for interop between languages like LabVIEW and C# which can talk to C API's directly.
For output parameters, the choice was fairly obvious. An output struct containing a const string pointer and a length makes the most sense. Its easy to use these from most other languages, and doesn't require special null termination handling. Freeing these is also easy, as if you ever receive one of these string structures, theres just a single function call to free it.
Input parameters are a bit more complex. To be used from pure C, and from LabVIEW, a null terminated string is the best in most cases. However, null terminated strings in general have a lot of downsides. Additionally, from LabVIEW there are other considerations around encoding that having a wrapper struct helps make a bit easier. From a language like C#, a wrapper struct is by far the easiest, as custom marshalling can make it trivial to marshal both UTF8 and UTF16 strings down.
The final consideration is its nice to have an identical concept for both input and output. It makes the rules fairly easy to understand.
WPILib will not have any APIs that manipulate a string allocated externally. This means WPI_String can be const, as across the boundary it is always const.
If a WPILib API takes a const WPI_String*, WPILib will not manipulate or attempt to free that string, and that string is treated as an input. It is up to the caller to handle that memory, WPILib will never hold onto that memory longer than the call.
If a WPILib API takes a WPI_String*, that string is an output. WPILib will allocate that API with WPI_AllocateString(), fill in the string, and return to the caller. When the caller is done with the string, they must free it with WPI_FreeString().
If an output struct contains a WPI_String member, that member is considered read only, and should not be explicitly freed. The caller should call the free function for that struct.
If an array of WPI_Strings are returned, each individual string is considered read only, and should not be explicitly freed. The free function for that array should be called by the caller.
If an input struct containing a WPI_String, or an input array of WPI_Strings is passed to WPILib, the individual strings will not be manipulated or freed by WPILib, and the caller owns and should free that memory.
Callbacks also follow these rules. The most common is a callback either getting passed a const WPI_String* or a struct containing a WPI_String. In both of these cases, the callback target should consider these strings read only, and not attempt to free them or manipulate them.
2024-05-13 05:35:14 -07:00
|
|
|
CS_Source CS_CreateHttpCamera(const struct WPI_String* name,
|
|
|
|
|
const struct WPI_String* url,
|
2016-11-28 00:22:15 -08:00
|
|
|
CS_HttpCameraKind kind, CS_Status* status) {
|
Change C APIs to a unified string implementation (#6299)
Currently in the entire C API of WPILib we have ~8 different ways of handling strings. The C API actually isn't built for pure C callers (We don't actually have any of those). Instead, they're built for interop between languages like LabVIEW and C# which can talk to C API's directly.
For output parameters, the choice was fairly obvious. An output struct containing a const string pointer and a length makes the most sense. Its easy to use these from most other languages, and doesn't require special null termination handling. Freeing these is also easy, as if you ever receive one of these string structures, theres just a single function call to free it.
Input parameters are a bit more complex. To be used from pure C, and from LabVIEW, a null terminated string is the best in most cases. However, null terminated strings in general have a lot of downsides. Additionally, from LabVIEW there are other considerations around encoding that having a wrapper struct helps make a bit easier. From a language like C#, a wrapper struct is by far the easiest, as custom marshalling can make it trivial to marshal both UTF8 and UTF16 strings down.
The final consideration is its nice to have an identical concept for both input and output. It makes the rules fairly easy to understand.
WPILib will not have any APIs that manipulate a string allocated externally. This means WPI_String can be const, as across the boundary it is always const.
If a WPILib API takes a const WPI_String*, WPILib will not manipulate or attempt to free that string, and that string is treated as an input. It is up to the caller to handle that memory, WPILib will never hold onto that memory longer than the call.
If a WPILib API takes a WPI_String*, that string is an output. WPILib will allocate that API with WPI_AllocateString(), fill in the string, and return to the caller. When the caller is done with the string, they must free it with WPI_FreeString().
If an output struct contains a WPI_String member, that member is considered read only, and should not be explicitly freed. The caller should call the free function for that struct.
If an array of WPI_Strings are returned, each individual string is considered read only, and should not be explicitly freed. The free function for that array should be called by the caller.
If an input struct containing a WPI_String, or an input array of WPI_Strings is passed to WPILib, the individual strings will not be manipulated or freed by WPILib, and the caller owns and should free that memory.
Callbacks also follow these rules. The most common is a callback either getting passed a const WPI_String* or a struct containing a WPI_String. In both of these cases, the callback target should consider these strings read only, and not attempt to free them or manipulate them.
2024-05-13 05:35:14 -07:00
|
|
|
return cs::CreateHttpCamera(wpi::to_string_view(name),
|
|
|
|
|
wpi::to_string_view(url), kind, status);
|
2016-11-28 00:22:15 -08:00
|
|
|
}
|
|
|
|
|
|
Change C APIs to a unified string implementation (#6299)
Currently in the entire C API of WPILib we have ~8 different ways of handling strings. The C API actually isn't built for pure C callers (We don't actually have any of those). Instead, they're built for interop between languages like LabVIEW and C# which can talk to C API's directly.
For output parameters, the choice was fairly obvious. An output struct containing a const string pointer and a length makes the most sense. Its easy to use these from most other languages, and doesn't require special null termination handling. Freeing these is also easy, as if you ever receive one of these string structures, theres just a single function call to free it.
Input parameters are a bit more complex. To be used from pure C, and from LabVIEW, a null terminated string is the best in most cases. However, null terminated strings in general have a lot of downsides. Additionally, from LabVIEW there are other considerations around encoding that having a wrapper struct helps make a bit easier. From a language like C#, a wrapper struct is by far the easiest, as custom marshalling can make it trivial to marshal both UTF8 and UTF16 strings down.
The final consideration is its nice to have an identical concept for both input and output. It makes the rules fairly easy to understand.
WPILib will not have any APIs that manipulate a string allocated externally. This means WPI_String can be const, as across the boundary it is always const.
If a WPILib API takes a const WPI_String*, WPILib will not manipulate or attempt to free that string, and that string is treated as an input. It is up to the caller to handle that memory, WPILib will never hold onto that memory longer than the call.
If a WPILib API takes a WPI_String*, that string is an output. WPILib will allocate that API with WPI_AllocateString(), fill in the string, and return to the caller. When the caller is done with the string, they must free it with WPI_FreeString().
If an output struct contains a WPI_String member, that member is considered read only, and should not be explicitly freed. The caller should call the free function for that struct.
If an array of WPI_Strings are returned, each individual string is considered read only, and should not be explicitly freed. The free function for that array should be called by the caller.
If an input struct containing a WPI_String, or an input array of WPI_Strings is passed to WPILib, the individual strings will not be manipulated or freed by WPILib, and the caller owns and should free that memory.
Callbacks also follow these rules. The most common is a callback either getting passed a const WPI_String* or a struct containing a WPI_String. In both of these cases, the callback target should consider these strings read only, and not attempt to free them or manipulate them.
2024-05-13 05:35:14 -07:00
|
|
|
CS_Source CS_CreateHttpCameraMulti(const struct WPI_String* name,
|
|
|
|
|
const struct WPI_String* urls, int count,
|
|
|
|
|
CS_HttpCameraKind kind, CS_Status* status) {
|
2018-04-29 23:33:19 -07:00
|
|
|
wpi::SmallVector<std::string, 4> vec;
|
2016-11-28 00:22:15 -08:00
|
|
|
vec.reserve(count);
|
2020-12-28 12:58:06 -08:00
|
|
|
for (int i = 0; i < count; ++i) {
|
Change C APIs to a unified string implementation (#6299)
Currently in the entire C API of WPILib we have ~8 different ways of handling strings. The C API actually isn't built for pure C callers (We don't actually have any of those). Instead, they're built for interop between languages like LabVIEW and C# which can talk to C API's directly.
For output parameters, the choice was fairly obvious. An output struct containing a const string pointer and a length makes the most sense. Its easy to use these from most other languages, and doesn't require special null termination handling. Freeing these is also easy, as if you ever receive one of these string structures, theres just a single function call to free it.
Input parameters are a bit more complex. To be used from pure C, and from LabVIEW, a null terminated string is the best in most cases. However, null terminated strings in general have a lot of downsides. Additionally, from LabVIEW there are other considerations around encoding that having a wrapper struct helps make a bit easier. From a language like C#, a wrapper struct is by far the easiest, as custom marshalling can make it trivial to marshal both UTF8 and UTF16 strings down.
The final consideration is its nice to have an identical concept for both input and output. It makes the rules fairly easy to understand.
WPILib will not have any APIs that manipulate a string allocated externally. This means WPI_String can be const, as across the boundary it is always const.
If a WPILib API takes a const WPI_String*, WPILib will not manipulate or attempt to free that string, and that string is treated as an input. It is up to the caller to handle that memory, WPILib will never hold onto that memory longer than the call.
If a WPILib API takes a WPI_String*, that string is an output. WPILib will allocate that API with WPI_AllocateString(), fill in the string, and return to the caller. When the caller is done with the string, they must free it with WPI_FreeString().
If an output struct contains a WPI_String member, that member is considered read only, and should not be explicitly freed. The caller should call the free function for that struct.
If an array of WPI_Strings are returned, each individual string is considered read only, and should not be explicitly freed. The free function for that array should be called by the caller.
If an input struct containing a WPI_String, or an input array of WPI_Strings is passed to WPILib, the individual strings will not be manipulated or freed by WPILib, and the caller owns and should free that memory.
Callbacks also follow these rules. The most common is a callback either getting passed a const WPI_String* or a struct containing a WPI_String. In both of these cases, the callback target should consider these strings read only, and not attempt to free them or manipulate them.
2024-05-13 05:35:14 -07:00
|
|
|
vec.emplace_back(wpi::to_string_view(&urls[i]));
|
2020-12-28 12:58:06 -08:00
|
|
|
}
|
Change C APIs to a unified string implementation (#6299)
Currently in the entire C API of WPILib we have ~8 different ways of handling strings. The C API actually isn't built for pure C callers (We don't actually have any of those). Instead, they're built for interop between languages like LabVIEW and C# which can talk to C API's directly.
For output parameters, the choice was fairly obvious. An output struct containing a const string pointer and a length makes the most sense. Its easy to use these from most other languages, and doesn't require special null termination handling. Freeing these is also easy, as if you ever receive one of these string structures, theres just a single function call to free it.
Input parameters are a bit more complex. To be used from pure C, and from LabVIEW, a null terminated string is the best in most cases. However, null terminated strings in general have a lot of downsides. Additionally, from LabVIEW there are other considerations around encoding that having a wrapper struct helps make a bit easier. From a language like C#, a wrapper struct is by far the easiest, as custom marshalling can make it trivial to marshal both UTF8 and UTF16 strings down.
The final consideration is its nice to have an identical concept for both input and output. It makes the rules fairly easy to understand.
WPILib will not have any APIs that manipulate a string allocated externally. This means WPI_String can be const, as across the boundary it is always const.
If a WPILib API takes a const WPI_String*, WPILib will not manipulate or attempt to free that string, and that string is treated as an input. It is up to the caller to handle that memory, WPILib will never hold onto that memory longer than the call.
If a WPILib API takes a WPI_String*, that string is an output. WPILib will allocate that API with WPI_AllocateString(), fill in the string, and return to the caller. When the caller is done with the string, they must free it with WPI_FreeString().
If an output struct contains a WPI_String member, that member is considered read only, and should not be explicitly freed. The caller should call the free function for that struct.
If an array of WPI_Strings are returned, each individual string is considered read only, and should not be explicitly freed. The free function for that array should be called by the caller.
If an input struct containing a WPI_String, or an input array of WPI_Strings is passed to WPILib, the individual strings will not be manipulated or freed by WPILib, and the caller owns and should free that memory.
Callbacks also follow these rules. The most common is a callback either getting passed a const WPI_String* or a struct containing a WPI_String. In both of these cases, the callback target should consider these strings read only, and not attempt to free them or manipulate them.
2024-05-13 05:35:14 -07:00
|
|
|
return cs::CreateHttpCamera(wpi::to_string_view(name), vec, kind, status);
|
2016-11-28 00:22:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
CS_HttpCameraKind CS_GetHttpCameraKind(CS_Source source, CS_Status* status) {
|
|
|
|
|
return cs::GetHttpCameraKind(source, status);
|
|
|
|
|
}
|
|
|
|
|
|
Change C APIs to a unified string implementation (#6299)
Currently in the entire C API of WPILib we have ~8 different ways of handling strings. The C API actually isn't built for pure C callers (We don't actually have any of those). Instead, they're built for interop between languages like LabVIEW and C# which can talk to C API's directly.
For output parameters, the choice was fairly obvious. An output struct containing a const string pointer and a length makes the most sense. Its easy to use these from most other languages, and doesn't require special null termination handling. Freeing these is also easy, as if you ever receive one of these string structures, theres just a single function call to free it.
Input parameters are a bit more complex. To be used from pure C, and from LabVIEW, a null terminated string is the best in most cases. However, null terminated strings in general have a lot of downsides. Additionally, from LabVIEW there are other considerations around encoding that having a wrapper struct helps make a bit easier. From a language like C#, a wrapper struct is by far the easiest, as custom marshalling can make it trivial to marshal both UTF8 and UTF16 strings down.
The final consideration is its nice to have an identical concept for both input and output. It makes the rules fairly easy to understand.
WPILib will not have any APIs that manipulate a string allocated externally. This means WPI_String can be const, as across the boundary it is always const.
If a WPILib API takes a const WPI_String*, WPILib will not manipulate or attempt to free that string, and that string is treated as an input. It is up to the caller to handle that memory, WPILib will never hold onto that memory longer than the call.
If a WPILib API takes a WPI_String*, that string is an output. WPILib will allocate that API with WPI_AllocateString(), fill in the string, and return to the caller. When the caller is done with the string, they must free it with WPI_FreeString().
If an output struct contains a WPI_String member, that member is considered read only, and should not be explicitly freed. The caller should call the free function for that struct.
If an array of WPI_Strings are returned, each individual string is considered read only, and should not be explicitly freed. The free function for that array should be called by the caller.
If an input struct containing a WPI_String, or an input array of WPI_Strings is passed to WPILib, the individual strings will not be manipulated or freed by WPILib, and the caller owns and should free that memory.
Callbacks also follow these rules. The most common is a callback either getting passed a const WPI_String* or a struct containing a WPI_String. In both of these cases, the callback target should consider these strings read only, and not attempt to free them or manipulate them.
2024-05-13 05:35:14 -07:00
|
|
|
void CS_SetHttpCameraUrls(CS_Source source, const struct WPI_String* urls,
|
|
|
|
|
int count, CS_Status* status) {
|
2018-04-29 23:33:19 -07:00
|
|
|
wpi::SmallVector<std::string, 4> vec;
|
2016-11-28 00:22:15 -08:00
|
|
|
vec.reserve(count);
|
2020-12-28 12:58:06 -08:00
|
|
|
for (int i = 0; i < count; ++i) {
|
Change C APIs to a unified string implementation (#6299)
Currently in the entire C API of WPILib we have ~8 different ways of handling strings. The C API actually isn't built for pure C callers (We don't actually have any of those). Instead, they're built for interop between languages like LabVIEW and C# which can talk to C API's directly.
For output parameters, the choice was fairly obvious. An output struct containing a const string pointer and a length makes the most sense. Its easy to use these from most other languages, and doesn't require special null termination handling. Freeing these is also easy, as if you ever receive one of these string structures, theres just a single function call to free it.
Input parameters are a bit more complex. To be used from pure C, and from LabVIEW, a null terminated string is the best in most cases. However, null terminated strings in general have a lot of downsides. Additionally, from LabVIEW there are other considerations around encoding that having a wrapper struct helps make a bit easier. From a language like C#, a wrapper struct is by far the easiest, as custom marshalling can make it trivial to marshal both UTF8 and UTF16 strings down.
The final consideration is its nice to have an identical concept for both input and output. It makes the rules fairly easy to understand.
WPILib will not have any APIs that manipulate a string allocated externally. This means WPI_String can be const, as across the boundary it is always const.
If a WPILib API takes a const WPI_String*, WPILib will not manipulate or attempt to free that string, and that string is treated as an input. It is up to the caller to handle that memory, WPILib will never hold onto that memory longer than the call.
If a WPILib API takes a WPI_String*, that string is an output. WPILib will allocate that API with WPI_AllocateString(), fill in the string, and return to the caller. When the caller is done with the string, they must free it with WPI_FreeString().
If an output struct contains a WPI_String member, that member is considered read only, and should not be explicitly freed. The caller should call the free function for that struct.
If an array of WPI_Strings are returned, each individual string is considered read only, and should not be explicitly freed. The free function for that array should be called by the caller.
If an input struct containing a WPI_String, or an input array of WPI_Strings is passed to WPILib, the individual strings will not be manipulated or freed by WPILib, and the caller owns and should free that memory.
Callbacks also follow these rules. The most common is a callback either getting passed a const WPI_String* or a struct containing a WPI_String. In both of these cases, the callback target should consider these strings read only, and not attempt to free them or manipulate them.
2024-05-13 05:35:14 -07:00
|
|
|
vec.emplace_back(wpi::to_string_view(&urls[i]));
|
2020-12-28 12:58:06 -08:00
|
|
|
}
|
2016-11-28 00:22:15 -08:00
|
|
|
cs::SetHttpCameraUrls(source, vec, status);
|
|
|
|
|
}
|
|
|
|
|
|
Change C APIs to a unified string implementation (#6299)
Currently in the entire C API of WPILib we have ~8 different ways of handling strings. The C API actually isn't built for pure C callers (We don't actually have any of those). Instead, they're built for interop between languages like LabVIEW and C# which can talk to C API's directly.
For output parameters, the choice was fairly obvious. An output struct containing a const string pointer and a length makes the most sense. Its easy to use these from most other languages, and doesn't require special null termination handling. Freeing these is also easy, as if you ever receive one of these string structures, theres just a single function call to free it.
Input parameters are a bit more complex. To be used from pure C, and from LabVIEW, a null terminated string is the best in most cases. However, null terminated strings in general have a lot of downsides. Additionally, from LabVIEW there are other considerations around encoding that having a wrapper struct helps make a bit easier. From a language like C#, a wrapper struct is by far the easiest, as custom marshalling can make it trivial to marshal both UTF8 and UTF16 strings down.
The final consideration is its nice to have an identical concept for both input and output. It makes the rules fairly easy to understand.
WPILib will not have any APIs that manipulate a string allocated externally. This means WPI_String can be const, as across the boundary it is always const.
If a WPILib API takes a const WPI_String*, WPILib will not manipulate or attempt to free that string, and that string is treated as an input. It is up to the caller to handle that memory, WPILib will never hold onto that memory longer than the call.
If a WPILib API takes a WPI_String*, that string is an output. WPILib will allocate that API with WPI_AllocateString(), fill in the string, and return to the caller. When the caller is done with the string, they must free it with WPI_FreeString().
If an output struct contains a WPI_String member, that member is considered read only, and should not be explicitly freed. The caller should call the free function for that struct.
If an array of WPI_Strings are returned, each individual string is considered read only, and should not be explicitly freed. The free function for that array should be called by the caller.
If an input struct containing a WPI_String, or an input array of WPI_Strings is passed to WPILib, the individual strings will not be manipulated or freed by WPILib, and the caller owns and should free that memory.
Callbacks also follow these rules. The most common is a callback either getting passed a const WPI_String* or a struct containing a WPI_String. In both of these cases, the callback target should consider these strings read only, and not attempt to free them or manipulate them.
2024-05-13 05:35:14 -07:00
|
|
|
WPI_String* CS_GetHttpCameraUrls(CS_Source source, int* count,
|
|
|
|
|
CS_Status* status) {
|
2016-11-28 00:22:15 -08:00
|
|
|
auto urls = cs::GetHttpCameraUrls(source, status);
|
Change C APIs to a unified string implementation (#6299)
Currently in the entire C API of WPILib we have ~8 different ways of handling strings. The C API actually isn't built for pure C callers (We don't actually have any of those). Instead, they're built for interop between languages like LabVIEW and C# which can talk to C API's directly.
For output parameters, the choice was fairly obvious. An output struct containing a const string pointer and a length makes the most sense. Its easy to use these from most other languages, and doesn't require special null termination handling. Freeing these is also easy, as if you ever receive one of these string structures, theres just a single function call to free it.
Input parameters are a bit more complex. To be used from pure C, and from LabVIEW, a null terminated string is the best in most cases. However, null terminated strings in general have a lot of downsides. Additionally, from LabVIEW there are other considerations around encoding that having a wrapper struct helps make a bit easier. From a language like C#, a wrapper struct is by far the easiest, as custom marshalling can make it trivial to marshal both UTF8 and UTF16 strings down.
The final consideration is its nice to have an identical concept for both input and output. It makes the rules fairly easy to understand.
WPILib will not have any APIs that manipulate a string allocated externally. This means WPI_String can be const, as across the boundary it is always const.
If a WPILib API takes a const WPI_String*, WPILib will not manipulate or attempt to free that string, and that string is treated as an input. It is up to the caller to handle that memory, WPILib will never hold onto that memory longer than the call.
If a WPILib API takes a WPI_String*, that string is an output. WPILib will allocate that API with WPI_AllocateString(), fill in the string, and return to the caller. When the caller is done with the string, they must free it with WPI_FreeString().
If an output struct contains a WPI_String member, that member is considered read only, and should not be explicitly freed. The caller should call the free function for that struct.
If an array of WPI_Strings are returned, each individual string is considered read only, and should not be explicitly freed. The free function for that array should be called by the caller.
If an input struct containing a WPI_String, or an input array of WPI_Strings is passed to WPILib, the individual strings will not be manipulated or freed by WPILib, and the caller owns and should free that memory.
Callbacks also follow these rules. The most common is a callback either getting passed a const WPI_String* or a struct containing a WPI_String. In both of these cases, the callback target should consider these strings read only, and not attempt to free them or manipulate them.
2024-05-13 05:35:14 -07:00
|
|
|
WPI_String* out = WPI_AllocateStringArray(urls.size());
|
2016-11-28 00:22:15 -08:00
|
|
|
*count = urls.size();
|
2020-12-28 12:58:06 -08:00
|
|
|
for (size_t i = 0; i < urls.size(); ++i) {
|
Change C APIs to a unified string implementation (#6299)
Currently in the entire C API of WPILib we have ~8 different ways of handling strings. The C API actually isn't built for pure C callers (We don't actually have any of those). Instead, they're built for interop between languages like LabVIEW and C# which can talk to C API's directly.
For output parameters, the choice was fairly obvious. An output struct containing a const string pointer and a length makes the most sense. Its easy to use these from most other languages, and doesn't require special null termination handling. Freeing these is also easy, as if you ever receive one of these string structures, theres just a single function call to free it.
Input parameters are a bit more complex. To be used from pure C, and from LabVIEW, a null terminated string is the best in most cases. However, null terminated strings in general have a lot of downsides. Additionally, from LabVIEW there are other considerations around encoding that having a wrapper struct helps make a bit easier. From a language like C#, a wrapper struct is by far the easiest, as custom marshalling can make it trivial to marshal both UTF8 and UTF16 strings down.
The final consideration is its nice to have an identical concept for both input and output. It makes the rules fairly easy to understand.
WPILib will not have any APIs that manipulate a string allocated externally. This means WPI_String can be const, as across the boundary it is always const.
If a WPILib API takes a const WPI_String*, WPILib will not manipulate or attempt to free that string, and that string is treated as an input. It is up to the caller to handle that memory, WPILib will never hold onto that memory longer than the call.
If a WPILib API takes a WPI_String*, that string is an output. WPILib will allocate that API with WPI_AllocateString(), fill in the string, and return to the caller. When the caller is done with the string, they must free it with WPI_FreeString().
If an output struct contains a WPI_String member, that member is considered read only, and should not be explicitly freed. The caller should call the free function for that struct.
If an array of WPI_Strings are returned, each individual string is considered read only, and should not be explicitly freed. The free function for that array should be called by the caller.
If an input struct containing a WPI_String, or an input array of WPI_Strings is passed to WPILib, the individual strings will not be manipulated or freed by WPILib, and the caller owns and should free that memory.
Callbacks also follow these rules. The most common is a callback either getting passed a const WPI_String* or a struct containing a WPI_String. In both of these cases, the callback target should consider these strings read only, and not attempt to free them or manipulate them.
2024-05-13 05:35:14 -07:00
|
|
|
cs::ConvertToC(&out[i], urls[i]);
|
2020-12-28 12:58:06 -08:00
|
|
|
}
|
2016-11-28 00:22:15 -08:00
|
|
|
return out;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
} // extern "C"
|