* switch to query param based Auth
* remove some changes commited by mistake.
* fixed tslint issues
* change the dash to authorization header
* remove credentials headers
* prev/next segment button features
* make the functions code more concise
* remove prefilled form in sample.html
* this.currentSegment.startSeconds === lastSegmentStartSeconds
* prev/next day buttons features
* fix test bugs-1
* change function name
* remove return null and add last year case for selectNextDay and selectPrevDay functions
CR: (pull request).
Changes
1) Today, setting the debug Boolean in
IAvaPlayerConfig/IWidgetBaseConfig to true will instruct widget
components to produce console logs. Piggybacking on this setting to also
instruct shaka-player to produce (more) logs. We chose to set
shaka-player’s log level to INFO if the debug Boolean is false,
otherwise we choose V1. Additionally, it has been discovered that if
needed, shaka-player has been exposed as a global variable, so we can
change this as needed in the console.
2) Examples/sample.html had some old calls to setLoggingOutput and
setNpmDebug which have not worked for a long time now. Removed.
Testing Procedure
1) Npm run sample, browse to http://localhost:8081/examples/sample.html
(either via independent browser or F5 with VS Code Edge Debugger
extension). Look at console logs and confirm that you see shaka log
messages. Test with IAvaPlayerConfig.debug both true and false, confirm
you see a difference in volume of logging.
2) Verify the ability to modify the shaka log level in-flight. First,
check the current log level by typing shaka.log.currentLevel, which
will return an integer value (3 is INFO, 5 is V1). To modify in-flight,
shaka.log.setLevel(shaka.log.Level.xxx) where xxx = INFO, DEBUG, V1, V2,
etc.
3) Inside of Portal is more complicated to change in-flight due to
sandboxing. In Dev Tools (F12 or Ctrl-Shift-I), Elements tab, Select
an Element tool (Ctrl-Shift-C), choose the video box, go up a few parent
elements until you reach the media-player node and left-click to select
it, then issue your shaka.log.* commands and confirm that they have an
effect.
* Do not display NaN in wallclock when RTCP SR is missing.
Wait till the wallclock time is available before updating the timestamp offset.
Update to the latest @azure/video-analyzer-player for the 'wallclock' event.
Update shaka.ts to expose the required shaka definitions.
* Fix RTSP playback when setSource on widget is called.
Including authorization token in query string when token is present.
* Show an error message when connection limit is reached.
Show the shaka error message along with generic error message.
Change the event to click instead of mouseup to simplify the code.
* Remove the infinite retries for network error and report error after few tries
Instead of infinite retries limit the number of retries to 5 times.
If the player doesn't succeed after 5 pass the error message to the user and user can retry.
Reset the error count if the player is able to play successfully.
* Improve drift correction behavior
* Revert package-lock.json
* Fix lint errors
* Set trickplay speed to 2x, check that player is not buffering, add a flat additional catchup amount
* Add a log to indicate return to normal playback rate
* show switch to dash when RTSP fails
* fix a few styles, and await on destroy
* add conditional statements, so fix exceptions for older inferences without tracking ID
* switch to dash should not show if no-archive
* fix-boundingbox-disappear-new-branch
* change name clickCallBack
* use event listener at player-component
* fix-test-bug
* code clean up
* resolve conflicts and rename updateFullScreen
* Do not display NaN in wallclock when RTCP SR is missing.
Wait till the wallclock time is available before updating the timestamp offset.
Update to the latest @azure/video-analyzer-player for the 'wallclock' event.
Update shaka.ts to expose the required shaka definitions.
* Fix RTSP playback when setSource on widget is called.
Including authorization token in query string when token is present.
* Show an error message when connection limit is reached.
Show the shaka error message along with generic error message.
Change the event to click instead of mouseup to simplify the code.
* change the zoom behaviour
* Fix for Bug 10544003 : [Widget] timeline bar is blocking/overlaying part of active video
* go back to the last day after click livebutton (#20), part 2. (#25)
The part 1 commit broke npm run lint, fixed (whitespace-only change)
* FEAT 10619548: Handle MSE errors by resetting source, part 1. (#26)
CR: See pull request.
The long-term home for this retry logic will be in the AvaPlayer class
of the ShakaRTSP repo, but until AvaWidgets moves to AvaPlayer, the code
which will go there needs to temporarily go in here first. We therefore
expect a part 2 commit which will undo this one.
Changes
1) When we receive a Shaka error callback, if we are playing live and
the error code is 3016 (VIDEO_ERROR, which we are commonly seeing as
VDA Error/PIPELINE_ERROR_DECODE, we will re-load the Shaka player up to
10 times within a three-minute window. This is generally enough to keep
going for quite some time, even in the face of continual decode
errors (I was able to go 25 minutes, for instance). The danger is if
buffering times are long (> 18 seconds), then 10 times in 3 minutes
could end up meaning infinite retry. We do not retry when playing
on-demand and for any other error codes than 3016.
2) As part of the error handling, we had to suppress further propagation
of the error event by calling stopImmediatePropagation (otherwise,
for example, the upper layers would stop playback and display an error
message). Extended the shaka.ts declarations to allow for this.
Long-term we should delete this file and use the declarations which ship
with Shaka.
Testing Procedure
1) Set up AVA endpoint against a b-frame camera stream (eg. Bosch). If
possible, modify the ShakaRTSP/media-stream-library to under-profile
the AVC1 codec to increase the chances of decode error. Run sample.html
against the AVA endpoint and confirm from console logs that we will
retry up to 10 times in a 3-minute window, and if we exceed this, we
stop trying and allow the error event to propagate, resulting in
playback stoppage and error message display.
* change the zoom behaviour
* remove unused logger
* add timeline autoscroll
* update the reset SVG
* remove unused code
Co-authored-by: Raymond Cheng <raych@microsoft.com>
* mute the widget by default
Mute the widget by default to allow auto-play on modern browsers.
* first commit
* Add mute configuration -muted by default
* remove seekbar in live mode
* RTSP-setSource
* go back to the last day after click livebutton
* Fixed live button async problem and clean code for RTSP
* code cleanup
* Combine RTSP plugin to widget bundle
* remove rtsp script from html file.
* fix datepicker problem after click live button
* fix datepicker problem after click live button
* fix datepicker problem after click live button
* add overflow menu for meta data
* Add TrackingLine, Add color
* make the rectangle bigger
* fix SA widget test bugs-1
* fix SA widget test bugs-2
* SA widget October 8
* move speed to bottom
* remove prefilled form
* add comments and use const variable to indicate position
* fix SA widget test bugs-3
Co-authored-by: giakas <giakas@microsoft.com>
CR: (pull request).
Add validation to pull requests in Widgets repo.
Changes
1) Add .github/workflows/webpack.yml to run lint, build and test on pull
requests, for Node 12.x, 14.x and 16.x.
2) Node 12.x and 14.x worked fine out of the box, but Node 16.x needed
tweaking. Specifically:
3) Node 16.x has a new lockfileVersion of 2 and did not work with the
existing package-lock.json (I was getting E401 authentication
failures, even though we were just using the public registry, which
should not have needed any authentication). The only way I could get
past this was to delete package-lock.json and regenerate it.
4) Unfortunately, this resulted in upgrades of various packages. I ended
up having to roll some of these back. Specifically:
5) When Typescript upgraded from 4.2.4 to 4.4.3, we got build errors
because the catch block in try-catch now assigns a type of "unknown"
instead of "any". After I fixed this, it built fine, but then test
failed during the typescript compilation phase in test, because of the
@microsoft/fast-foundation, fast-element, etc. typescript typings. An
example complaint was, "error TS2320: Interface 'Anchor' cannot
simultaneously extend types 'HTMLElement & FASTElement' and
'DelegatesARIALink'. Named property 'ariaAtomic' of types 'HTMLElement &
FASTElement' and 'DelegatesARIALink' are not identical.". I did try
rolling the @microsoft/fast* packages back, but the problem persisted. I
gave up and rolled Typescript back to 4.2.4.
6) Despite rolling Typescript back, I am keeping the fixes for the catch
blocks.
Known Issues
1) On my Windows dev box with WSL2, Node 16.x, npm run test fails for me
because of @web/test-runner-playwright. Not sure if the earlier Node
12.x and 14.x would have passed, I normally use Windows and Node 12.x.
The GitHub machines are probably running native Linux, and npm run
test seems to succeed there.
Testing Procedure
1) Submit a PR which you know will break in install, lint, build or test
(preferably each one separately). Confirm PR shows validation
failure. Note that I didn't try this and I also don't know if the
policies are set to reject the PR if validation fails.
CR: See pull request.
Originally, I had intended to have Widgets call ShakaRTSP's error
handler/reconnect logic, which was added in PBI # 11064018. It turns
out, this would have been the first time that Widgets had made calls
into ShakaRTSP, and a number of blocking issues arose. Since these
issues will take time to resolve, the quick fix is to simply paste the
code into player.class.ts, and then remove it later when we have
resolved the blocking issues.
Changes
1) Paste the "part 2" version of PBI # 11064018's error handler and
reconnect logic into player.class.ts. During the course of
integration, it was discovered that the return value of
shakaErrorHandler.onShakaError was not useful (it would return true to
indicate that the error was recognized). What we really needed was to
know that it was handled, which is now true with the part 2 change. As
part of this, had to update definitions in shaka.ts. Additionally, had
to modify the code to meet the different lint requirements in this repo.
2) Note that his commit relies on ShakaRTSP version 1.0.4 in order to
receive the newer shaka errors being emitted from
rtspManifestParser.ts.
Testing Procedure
1) Play against b-frame AVA endpoint on Chrome with hardware
acceleration. Filter console log for 3016 (decode error). Confirm
that after 3016, we reconnect and keep playing. This was still true
prior to this change, but re-testing is to confirm that we have not
regressed.
2) Play until server disconnects (or induce temporary network failure).
Restore network. Confirm that we reconnect and keep playing. Prior to
this change, we did not automatically reconnect. Note that this differs
from failure during initial websocket connection: this change does not
modify that. If we encounter failure during initial websocket connection
(bad credentials, bad hostname, bad IP, etc), regardless of this commit,
we will retry 5 times before giving up.
Wait till the wallclock time is available before updating the timestamp offset.
Update to the latest @azure/video-analyzer-player for the 'wallclock' event.
Update shaka.ts to expose the required shaka definitions.
* mute the widget by default
Mute the widget by default to allow auto-play on modern browsers.
* first commit
* Add mute configuration -muted by default
* remove seekbar in live mode
* RTSP-setSource
* go back to the last day after click livebutton
* Fixed live button async problem and clean code for RTSP
* code cleanup
* Combine RTSP plugin to widget bundle
* remove rtsp script from html file.
* fix datepicker problem after click live button
* fix datepicker problem after click live button
* fix datepicker problem after click live button
* add overflow menu for meta data
* first commit in branch fix-date-picker
* first-commit at branch date-picker-fix
* fix the date picker
* fix the date picker
Co-authored-by: giakas <giakas@microsoft.com>
CR: (pull request)
We are not currently passing an RTSP Url to the websocket proxy. In
these cases, the media-stream-library defaults to
rtsp://localhost/axis-media/media.amp.
Changes
1) Hard-code the RTSP Url to rtsp://localhost, rather than leaving it
undefined. The way it is plumbed is by appending a query to the wss
URL, with a key of 'rtsp' and a value which is the URL encoded RTSP Url.
It was done this way because the component which starts playback does
not have access to the RTSP plugin, only to Shaka, and so the only means
of communication is the URL.
2) In future, if we no longer use a hard-coded value of
rtsp://localhost, it is expected that the getVideo API would return
the RTSP Url which needs to be used. Where we hard-code rtsp://localhost
was selected with this in mind.
Testing Procedure
1) Npm run sample, browse to sample.html, fill in the fields and play a
video which has RTSP. Confirm via console logs that we now specify
rtsp://localhost instead of rtsp://localhost/axis-media/media.amp.
Verify that we can play RTSP successfully.
CR: See pull request.
The long-term home for this retry logic will be in the AvaPlayer class
of the ShakaRTSP repo, but until AvaWidgets moves to AvaPlayer, the code
which will go there needs to temporarily go in here first. We therefore
expect a part 2 commit which will undo this one.
Changes
1) When we receive a Shaka error callback, if we are playing live and
the error code is 3016 (VIDEO_ERROR, which we are commonly seeing as
VDA Error/PIPELINE_ERROR_DECODE, we will re-load the Shaka player up to
10 times within a three-minute window. This is generally enough to keep
going for quite some time, even in the face of continual decode
errors (I was able to go 25 minutes, for instance). The danger is if
buffering times are long (> 18 seconds), then 10 times in 3 minutes
could end up meaning infinite retry. We do not retry when playing
on-demand and for any other error codes than 3016.
2) As part of the error handling, we had to suppress further propagation
of the error event by calling stopImmediatePropagation (otherwise,
for example, the upper layers would stop playback and display an error
message). Extended the shaka.ts declarations to allow for this.
Long-term we should delete this file and use the declarations which ship
with Shaka.
Testing Procedure
1) Set up AVA endpoint against a b-frame camera stream (eg. Bosch). If
possible, modify the ShakaRTSP/media-stream-library to under-profile
the AVC1 codec to increase the chances of decode error. Run sample.html
against the AVA endpoint and confirm from console logs that we will
retry up to 10 times in a 3-minute window, and if we exceed this, we
stop trying and allow the error event to propagate, resulting in
playback stoppage and error message display.
sxian0613
giakas
Andy Zhang
Raymond Cheng
Prakash Duggaraju
Andy Zhang