This gives much better information to the UI layer, getting rid of a
whole troubleshooting guide entry. See #119#132#218#219
I also restructured the code in anticipation of a new WebSocket event
stream (#40).
I was struggling to upgrade the version of mui stuff (material and date
picker). I'm hoping getting rid of the deprecated stuff eases this a
bit.
I don't love that I can't just use sx on plain HTML stuff and have to
wrap it in Box, but oh well. Looks like I'm not alone, fwiw.
https://github.com/mui/material-ui/issues/23220
This requires a bunch of package name changes. See
[https://mui.com/blog/material-ui-is-now-mui/] for their rationale.
[https://mui.com/guides/migration-v4/] lists the changes:
```
@material-ui/core -> @mui/material
@material-ui/system -> @mui/system
@material-ui/unstyled -> @mui/core
@material-ui/styles -> @mui/styles
@material-ui/icons -> @mui/icons-material
@material-ui/lab -> @mui/lab
@material-ui/types -> @mui/types
@material-ui/styled-engine -> @mui/styled-engine
@material-ui/styled-engine-sc ->@mui/styled-engine-sc
@material-ui/private-theming -> @mui/private-theming
@material-ui/codemod -> @mui/codemod
@material-ui/docs -> @mui/docs
@material-ui/envinfo -> @mui/envinfo
```
We only use a few of these.
When you select the first camera in the drop-down on a grid square
that isn't the top left, then select a camera in the top-left, it
behaves strangely.
The root cause is that I had a dumb mistake in how I assigned React
keys. I used the camera index when a camera is selected, and the
inverse of the selected index when one is. But 0 == -0!
As written in the changelog: Live streams formerly worked around a
Firefox pixel aspect ratio bug by forcing all videos to 16:9, which
dramatically distorted 9:16 camera views. Playback didn't, so anamorphic
videos looked correct on Chrome but slightly stretched on Firefox. Now
both live streams and playback are fully correct on all browsers.
* run node 12, 14, and 16 (next to be supported) on CI. This will catch
node version-specific problems like that solved in dad9bdc.
* mention 12 and 14 in build instructions and link to instructions for
installing that version.
* follow this in Dockerfile, installing version 14. This addresses
a "Cannot find module 'worker_threads'" error introduced in
39a63e0, which (inadvisedly) upgraded gzipper 4->5 in addition to
the material-ui upgrade.
* use utf-8 encoding rather than ascii in live part parser. Those
builds apparently don't support ascii. iThey must use "small-icu" or
have ICU disabled, as described here:
https://nodejs.org/api/util.html#util_encodings_supported_when_node_js_is_built_with_the_small_icu_option
This is a surprisingly complex upgrade. Some relevant changes from
[their CHANGELOG](https://github.com/mui-org/material-ui/blob/v5.0.0-beta.3/CHANGELOG.md):
* @material-ui/core/styles no longer re-exports some stuff from
@material-ui/styles
* there's no more defaultTheme, so tests need to provide one
* select's onChange has a new type; match that. I haven't actually
tried that the string form (apparently from autofill) works correctly.
* checkboxes no longer default to the secondary color; explicitly
request this in some places.
* checkbox no longer has a checked argument; use event.target.checked
instead.
* date pickers have switched to the new style system, so I had to
redo how I was overridding their spacing for desktop.
* LoadingButton now has a loading property, not pending
* createMuiTheme is no createTheme
* don't error out on websocket error message. The close message has
more useful info. (Unfortunately though, for security reasons it
doesn't give too much to the script on initial connection failure.)
* restore normal (non-error/waiting) state when switching cameras.
* prefix all log messages with the camera name
* When the MediaSource is in error state (or busy, I think),
endOfStream throws an exception. This prevented the error from being
properly displayed in the UI. We don't really need to call
endOfStream, I guess.
* including an Event in a format string just said [Object object],
at least on Safari. Use the type instead, which I think is the
only useful info in the event anyway.
It's a start. It can display several streams at once, which is nice.
There are lots of opportunities for improvement:
* it doesn't keep the videos approximately in sync.
* it accumulates extra buffering, drifting behind live. This is
particularly noticeable when it's paused and played again; it can
be several seconds before it jumps to after the break.
* it always uses the sub stream rather main. I'd prefer it support
"auto" (use main if the viewport is larger than the sub stream and
there's sufficient bandwidth), "main", or "sub".
* it has a kludgy heuristic where it throws away everything buffered 5
seconds before the current timestamp. It should throw away
everything before the current GOP instead, but I need to alter the
API so it can easily know when that is.
* it can't tell you when a camera connection is down. This needs an
API change also.
* it'd be nice to quickly double-click on a stream to view only it,
then double-click again to go back to the multi-pane view.
* it doesn't allow you to zoom in on part of the video. This would be
nice particularly when viewing 4k video streams on small screens.
* it has only four preconfigured layouts that subdivide a 16x9
viewport. You have to choose every camera every time. It'd be nice
to both allow more flexibility and have more memory.
React prototype: #111
live stream: #59
