To improve reliability of live streams (#59) on Safari.
Safari was dropping the cookie from websocket update requests.
(But it worked sometimes. I don't get why.) I saw folks on the Internet
thinking this related to HttpOnly:
* https://developer.apple.com/forums/thread/104488
* https://stackoverflow.com/q/47742807/23584
but I still see this behavior without HttpOnly. SameSite=Strict vs
SameSite=Lax appears to make a difference. Try that instead.
SameSite=Strict is pointless for us anyway as noted in a new comment.
Turning off HttpOnly would be more unfortunate security-wise.
* 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
This reverts commit d273a99f83.
This accidentally increased the density by making my global CSS
overrides ineffective. I'm struggling to achieve both, and I'd rather
have my desired sizing.
Looks like material-ui's `<Select variant="outlined">` needs a redundant
label property to make the layout correct.
https://next.material-ui.com/api/outlined-input/#main-content
"The label of the input. It is only used for layout. The actual
labelling is handled by InputLabel. If specified labelWidth is ignored."
* 1-hour videos are a bit faster to render server-side and don't
require so much index data to be transferred before play starts
* the timestamp tracks might be causing a lot of excess data transfer
in some cases. They're currently not interleaved by ascending
timestamp, and I wonder if they should be. Chrome might be pulling
all the bytes between the current position in the two tracks, which
can be excessive. I'll have to consider interleaving when I add
audio anyway. But for now, just make the default UI display
snappier. Chrome doesn't display the timestamp track anyway, so
don't let it slow things down.
Once I have more than one area of the UI (e.g., adding config, live
video, or a scrub bar prototype), I'll use this for a pull-down menu to
go between them, and maybe add a filter icon to do what this does. But
this works for now and most closely matches the old UI.
I tried to use a Collapse or Slide transition, but I had trouble getting
it to work on both desktop and mobile. In particular, the way I used the
flex wrap to display the selectors on the left/above doesn't seem
compatible with picking an orientation. If I pick the wrong orientation,
the list views won't fill the empty space.
* hide the end day selector away when it's not in use.
It was confusing, especially since it seemed to have
a purely black circle over the selected date when disabled.
* add a "Time" label to the time selectors. On desktop,
this isn't entirely necessary because they have clock icons
and "hh:mm:ss" annotations. But on mobile, they were entirely blank,
so it was unclear what they were for.
It worked fine on my laptop with node.js v14.15.4, but not on my
new workstation with node.js v12.18.2 (as comes with Ubuntu 20.10).
It would print "Unexpected token '?'" without any clue what file the
error is in. I'm trying to fix that here:
https://github.com/facebook/create-react-app/pull/10652
(and various other lockfile upgrades. "npm audit" is clean.)
The date picker to use with 4.0 is unmaintained, and the new one is
apparently quite different.
Given that 5.0 is expected to be released this quarter, I prefer to
jump straight to the new one and get things working with it, even if
it means using an alpha in the short-term.
This eases build setup. Where Yarn requires a separate package
repository, npm is available in the standard one.
yarn's package repository signature was recently expired, and apparently
will expire again in a year. Avoid dealing with that.
Fixes#110.
Besides being more clear about what belongs to which, this helps with
docker caching. The server and ui parts are only rebuilt when their
respective subdirectories change.
Extend this a bit further by making the webpack build not depend on
the target architecture. And adding cache dirs so parts of the server
and ui build process can be reused when layer-wide caching fails.
* make "yarn build" cmd work on first run.
(it was installing a hardlinked file where the dir should go, yuck)
* remove an obsolete ui/index.html; it's ui-src/index.html now
The Javascript is pretty amateurish I'm sure but at least it's something to
iterate from. It's already much more pleasant for browsing through videos in
several ways:
* more responsive to load only a day at a time rather than 90+ days
* much easier to see the same time segment on several cameras
* more pleasant to have the videos load as a popup rather than a link
that blows away your position in an enormous list
* exposes the fancier .mp4 generation options: splitting at lengths
other than the default, trimming to an arbitrary start and end time,
including a subtitle track with timestamps.
There's a slight regression in functionality: I didn't match the former
top-level page which showed how much camera used of its disk allocation and
the total duration of video. This is exposed in the JSON API, so it shouldn't
be too hard to add back.
