Since no new issues were reported and no crashes were detected, the Open Beta has now been promoted to Production.
This release contains:
I am happy to see active development on the Mapillary app for Android. Since Mapillary has now fully adopted the GoPro MAX2 and the camera comes with the Open GoPro remote control protocol, can we expect to see Open GoPro integration with the Mapillary app?
Although for now the GoPro Connect SDK for Android mentions HERO13 Black as the only SDK supported camera, MAX2 could nevertheless be made controllable via Bluetooth or HTTP over Wi-Fi already. I would be eager to have MAX2 Bluetooth remote control in the Mapillary app. Should you consider to implement Open GoPro for MAX2 then please do not use Wi-Fi for remote control despite it perhaps looking easier to implement at first glance because Wi-Fi is horribly energy inefficient for this task compared to BLE. 
Wi-Fi has been designed for high throughput and low latency over medium distances in buildings, not for energy efficiency like Bluetooth. Thanks!
@GITNE what type of integration do you expect? I was developing my own android app to work with old 2019 Max. It doesn’t have Open GoPro, but http and ble requests were working fine.
I was asking for Mapillary API to upload, but since there are no plans for it, I was using mapillary_tools to upload
Basically, functional equivalence with a phone’s camera. Simply put, the GoPro Quik app has no map nor an option to upload to Mapillary. The Mapillary app has a map and upload functionality but does not control the camera nor pulls images and videos from the camera (correct me if I am wrong on the latter). It would also be nice to have features like stop detection controlled by the Mapillary app which could trigger a new sequence. MAX and MAX2 have really cool visual (IMU augmented) motion detection built-in but the camera does not signal it externally, which is a missed opportunity on GoPro’s side for adding a potentially useful feature to the Open GoPro protocol. Thus, an external app has to do stop detection and control the camera.
I have not actually verified whether MAX supports Open GoPro. However, like you say, it can be controlled via the GoPro Quik app which means that it should de facto support Open GoPro, especially since it received firmware updates since the camera’s release.
Yes, this is an ever since gripe of mine too, mainly because mapillary_tools is incredibly slow and somewhat cumbersome to use. I have also advocated for an open upload protocol to enable the community to build custom, better, or integrated workflow implementations but apparently we have to suffer. You know, open protocols, the way things should be done on the Internet… Apparently, corporations have their own philosophy (just look at the instant messenger mess). 
Sure, one can sort of reverse engineer mapillary_tools’ upload implementation and then try to replicate it but this is not how good software engineering should generally be done. 
So, we are stuck with what we have.
I do not think that replicating the Mapillary app’s functionality per se makes much sense, especially as long as there is no open upload protocol.
While I’d agree that corporations do have a tendancy to prefere propriatory solutons, as this provides leverage to extrac value from the users. However I don’t think we can acuse the Mapillary of doing so in this case, as they have published mapillary_tools as Open Source, including the uppload protocol.
One known source of frustrations, are the limitations of the TCP protocol and specificly HTTP/2.0 built on top. Thus my guess is that most non-standard parts if the protocol attempt by Meta to address those issues, this as mappilary seems be using Metas upload infrastructure. (Quite a few attempt were made over the years, so let’s hope that HTTP/3 will make more of the fade-away in favor of standard implications.)
Last but not least, I would also like to have the option to remote control my camera through the app, as it seem this could add a significant conveiance. Thou given the number of vendors an models, maintenance can appear dunting…
You confuse open source with a protocol specification. A specification outlines requirements. Open source is a code licensing model and can also be a collaboration paradigm. Open source code is NOT a specification.
By your logic, standards bodies and the documents they produce are useless bureaucracy because some open source implementations exist that try to implement standards. The world does not work this way.
You are missing the point. This has nothing to do with TCP or HTTP. The core issue in designing an upload protocol for Mapillary would be to make it
Any such open upload protocol has to fit and be built on existing (Meta) infrastructure. Meta’s infrastructure was initially never built for ingesting huge amounts of binary data in the way that Mapillary needs. Currently, things are rather held together with bubblegum and duct tape. Mapillary integrators should expect something like YouTube Data API.