-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace debug
with tslog
#992
Labels
enhancement
New feature or request
Milestone
Comments
steabert
added a commit
that referenced
this issue
Jan 8, 2025
Replace Node.js stream module with Web Streams API. Since the latter is substantially different in some important details regarding stream pipelining, the way pipelines are built are redefined. The component concept as module blocks is removed and instead the components themselves expose streams that can be combined together. The pipelines are then simple stream compositions. Because this is a major (breaking) change, it's done in concert with other planned improvements that are also breaking changes (see section below for details). Improvements: - replacing the Node.js stream module with Web Streams API removes the dependency on the (legacy) stream-browserify package and results in a much smaller library (bundle) size, so there is no longer a need for a separate "light" version - `debug` package replaced by custom internal logging utilities (allowing proper ES module support) Fixes #990, Closes #992 Refactoring: - RTSP session and parser are combined in a single component and the session controller has been rewritten as a request-response flow. An async `start` method starts the streams and returns SDP + range. - RTP depay is combined into a single component that detects the proper format based on payloadType, and allows registering a "peeker" that can inspect messages (instead of having to insert an extra transform stream) - Extended use of TypeScript in areas where this was lacking BREAKING CHANGES: - No support for CommonJS: - Node.js has support for ES modules - Browsers have support for ES modules, but you can also still use the IIFE global variable, or use a bundler (all of which support ES modules) - No distinction between Node.js/Browser: - The library targets mainly Browser, so some things rely on `window` and expect it to be present, however most things work both platforms. - Node-only pipelines are removed, these are trivial to re-implement with Web Streams API if necessary. The CLI player has its own TCP source for that reason (replacing the CliXyz pipelines). - The generic "component" and "pipeline" classes were removed: - Components extend Web Streams API instead - Pipelines rely on `pipeTo`/`pipeThrough` composition and a `start` method to initiate flow of data. - Some public methods on pipelines have been removed (refer to their type for details) in cases where a simple alternative is available, or check the examples to see how to modify usage. There are less pipelines but they are more versatile, with accessible readonly components. In general, promises/async methods are preferred over callbacks.
steabert
added a commit
that referenced
this issue
Jan 8, 2025
Replace Node.js stream module with Web Streams API. Since the latter is substantially different in some important details regarding stream pipelining, the way pipelines are built are redefined. The component concept as module blocks is removed and instead the components themselves expose streams that can be combined together. The pipelines are then simple stream compositions. Because this is a major (breaking) change, it's done in concert with other planned improvements that are also breaking changes (see section below for details). Improvements: - replacing the Node.js stream module with Web Streams API removes the dependency on the (legacy) stream-browserify package and results in a much smaller library (bundle) size, so there is no longer a need for a separate "light" version - `debug` package replaced by custom internal logging utilities (allowing proper ES module support) Fixes #990, Closes #992 Refactoring: - RTSP session and parser are combined in a single component and the session controller has been rewritten as a request-response flow. An async `start` method starts the streams and returns SDP + range. - RTP depay is combined into a single component that detects the proper format based on payloadType, and allows registering a "peeker" that can inspect messages (instead of having to insert an extra transform stream) - Extended use of TypeScript in areas where this was lacking BREAKING CHANGES: - No support for CommonJS: - Node.js has support for ES modules - Browsers have support for ES modules, but you can also still use the IIFE global variable, or use a bundler (all of which support ES modules) - No distinction between Node.js/Browser: - The library targets mainly Browser, so some things rely on `window` and expect it to be present, however most things work both platforms. - Node-only pipelines are removed, these are trivial to re-implement with Web Streams API if necessary. The CLI player has its own TCP source for that reason (replacing the CliXyz pipelines). - The generic "component" and "pipeline" classes were removed: - Components extend Web Streams API instead - Pipelines rely on `pipeTo`/`pipeThrough` composition and a `start` method to initiate flow of data. - Some public methods on pipelines have been removed (refer to their type for details) in cases where a simple alternative is available, or check the examples to see how to modify usage. There are less pipelines but they are more versatile, with accessible readonly components. In general, promises/async methods are preferred over callbacks.
steabert
added a commit
that referenced
this issue
Jan 8, 2025
Replace Node.js stream module with Web Streams API. Since the latter is substantially different in some important details regarding stream pipelining, the way pipelines are built are redefined. The component concept as module blocks is removed and instead the components themselves expose streams that can be combined together. The pipelines are then simple stream compositions. Because this is a major (breaking) change, it's done in concert with other planned improvements that are also breaking changes (see section below for details). Improvements: - replacing the Node.js stream module with Web Streams API removes the dependency on the (legacy) stream-browserify package and results in a much smaller library (bundle) size, so there is no longer a need for a separate "light" version - `debug` package replaced by custom internal logging utilities (allowing proper ES module support) Fixes #990, Closes #992 Refactoring: - RTSP session and parser are combined in a single component and the session controller has been rewritten as a request-response flow. An async `start` method starts the streams and returns SDP + range. - RTP depay is combined into a single component that detects the proper format based on payloadType, and allows registering a "peeker" that can inspect messages (instead of having to insert an extra transform stream) - Extended use of TypeScript in areas where this was lacking BREAKING CHANGES: - No support for CommonJS: - Node.js has support for ES modules - Browsers have support for ES modules, but you can also still use the IIFE global variable, or use a bundler (all of which support ES modules) - No distinction between Node.js/Browser: - The library targets mainly Browser, so some things rely on `window` and expect it to be present, however most things work both platforms. - Node-only pipelines are removed, these are trivial to re-implement with Web Streams API if necessary. The CLI player has its own TCP source for that reason (replacing the CliXyz pipelines). - The generic "component" and "pipeline" classes were removed: - Components extend Web Streams API instead - Pipelines rely on `pipeTo`/`pipeThrough` composition and a `start` method to initiate flow of data. - Some public methods on pipelines have been removed (refer to their type for details) in cases where a simple alternative is available, or check the examples to see how to modify usage. There are less pipelines but they are more versatile, with accessible readonly components. In general, promises/async methods are preferred over callbacks.
steabert
added a commit
that referenced
this issue
Jan 8, 2025
Replace Node.js stream module with Web Streams API. Since the latter is substantially different in some important details regarding stream pipelining, the way pipelines are built are redefined. The component concept as module blocks is removed and instead the components themselves expose streams that can be combined together. The pipelines are then simple stream compositions. Because this is a major (breaking) change, it's done in concert with other planned improvements that are also breaking changes (see section below for details). Improvements: - replacing the Node.js stream module with Web Streams API removes the dependency on the (legacy) stream-browserify package and results in a much smaller library (bundle) size, so there is no longer a need for a separate "light" version - `debug` package replaced by custom internal logging utilities (allowing proper ES module support) Fixes #990, Closes #992 Refactoring: - RTSP session and parser are combined in a single component and the session controller has been rewritten as a request-response flow. An async `start` method starts the streams and returns SDP + range. - RTP depay is combined into a single component that detects the proper format based on payloadType, and allows registering a "peeker" that can inspect messages (instead of having to insert an extra transform stream) - Extended use of TypeScript in areas where this was lacking BREAKING CHANGES: - No support for CommonJS: - Node.js has support for ES modules - Browsers have support for ES modules, but you can also still use the IIFE global variable, or use a bundler (all of which support ES modules) - No distinction between Node.js/Browser: - The library targets mainly Browser, so some things rely on `window` and expect it to be present, however most things work both platforms. - Node-only pipelines are removed, these are trivial to re-implement with Web Streams API if necessary. The CLI player has its own TCP source for that reason (replacing the CliXyz pipelines). - The generic "component" and "pipeline" classes were removed: - Components extend Web Streams API instead - Pipelines rely on `pipeTo`/`pipeThrough` composition and a `start` method to initiate flow of data. - Some public methods on pipelines have been removed (refer to their type for details) in cases where a simple alternative is available, or check the examples to see how to modify usage. There are less pipelines but they are more versatile, with accessible readonly components. In general, promises/async methods are preferred over callbacks.
steabert
added a commit
that referenced
this issue
Jan 8, 2025
Replace Node.js stream module with Web Streams API. Since the latter is substantially different in some important details regarding stream pipelining, the way pipelines are built are redefined. The component concept as module blocks is removed and instead the components themselves expose streams that can be combined together. The pipelines are then simple stream compositions. Because this is a major (breaking) change, it's done in concert with other planned improvements that are also breaking changes (see section below for details). Improvements: - replacing the Node.js stream module with Web Streams API removes the dependency on the (legacy) stream-browserify package and results in a much smaller library (bundle) size, so there is no longer a need for a separate "light" version - `debug` package replaced by custom internal logging utilities (allowing proper ES module support) Fixes #990, Closes #992 Refactoring: - RTSP session and parser are combined in a single component and the session controller has been rewritten as a request-response flow. An async `start` method starts the streams and returns SDP + range. - RTP depay is combined into a single component that detects the proper format based on payloadType, and allows registering a "peeker" that can inspect messages (instead of having to insert an extra transform stream) - Extended use of TypeScript in areas where this was lacking BREAKING CHANGES: - No support for CommonJS: - Node.js has support for ES modules - Browsers have support for ES modules, but you can also still use the IIFE global variable, or use a bundler (all of which support ES modules) - No distinction between Node.js/Browser: - The library targets mainly Browser, so some things rely on `window` and expect it to be present, however most things work both platforms. - Node-only pipelines are removed, these are trivial to re-implement with Web Streams API if necessary. The CLI player has its own TCP source for that reason (replacing the CliXyz pipelines). - The generic "component" and "pipeline" classes were removed: - Components extend Web Streams API instead - Pipelines rely on `pipeTo`/`pipeThrough` composition and a `start` method to initiate flow of data. - Some public methods on pipelines have been removed (refer to their type for details) in cases where a simple alternative is available, or check the examples to see how to modify usage. There are less pipelines but they are more versatile, with accessible readonly components. In general, promises/async methods are preferred over callbacks.
steabert
added a commit
that referenced
this issue
Jan 8, 2025
Replace Node.js stream module with Web Streams API. Since the latter is substantially different in some important details regarding stream pipelining, the way pipelines are built are redefined. The component concept as module blocks is removed and instead the components themselves expose streams that can be combined together. The pipelines are then simple stream compositions. Because this is a major (breaking) change, it's done in concert with other planned improvements that are also breaking changes (see section below for details). Improvements: - replacing the Node.js stream module with Web Streams API removes the dependency on the (legacy) stream-browserify package and results in a much smaller library (bundle) size, so there is no longer a need for a separate "light" version - `debug` package replaced by custom internal logging utilities (allowing proper ES module support) Fixes #990, Closes #992 Refactoring: - RTSP session and parser are combined in a single component and the session controller has been rewritten as a request-response flow. An async `start` method starts the streams and returns SDP + range. - RTP depay is combined into a single component that detects the proper format based on payloadType, and allows registering a "peeker" that can inspect messages (instead of having to insert an extra transform stream) - Extended use of TypeScript in areas where this was lacking BREAKING CHANGES: - No support for CommonJS: - Node.js has support for ES modules - Browsers have support for ES modules, but you can also still use the IIFE global variable, or use a bundler (all of which support ES modules) - No distinction between Node.js/Browser: - The library targets mainly Browser, so some things rely on `window` and expect it to be present, however most things work both platforms. - Node-only pipelines are removed, these are trivial to re-implement with Web Streams API if necessary. The CLI player has its own TCP source for that reason (replacing the CliXyz pipelines). - The generic "component" and "pipeline" classes were removed: - Components extend Web Streams API instead - Pipelines rely on `pipeTo`/`pipeThrough` composition and a `start` method to initiate flow of data. - Some public methods on pipelines have been removed (refer to their type for details) in cases where a simple alternative is available, or check the examples to see how to modify usage. There are less pipelines but they are more versatile, with accessible readonly components. In general, promises/async methods are preferred over callbacks.
steabert
added a commit
that referenced
this issue
Jan 8, 2025
Replace Node.js stream module with Web Streams API. Since the latter is substantially different in some important details regarding stream pipelining, the way pipelines are built are redefined. The component concept as module blocks is removed and instead the components themselves expose streams that can be combined together. The pipelines are then simple stream compositions. Because this is a major (breaking) change, it's done in concert with other planned improvements that are also breaking changes (see section below for details). Improvements: - replacing the Node.js stream module with Web Streams API removes the dependency on the (legacy) stream-browserify package and results in a much smaller library (bundle) size, so there is no longer a need for a separate "light" version - `debug` package replaced by custom internal logging utilities (allowing proper ES module support) Fixes #990, Closes #992 Refactoring: - RTSP session and parser are combined in a single component and the session controller has been rewritten as a request-response flow. An async `start` method starts the streams and returns SDP + range. - RTP depay is combined into a single component that detects the proper format based on payloadType, and allows registering a "peeker" that can inspect messages (instead of having to insert an extra transform stream) - Extended use of TypeScript in areas where this was lacking BREAKING CHANGES: - No support for CommonJS: - Node.js has support for ES modules - Browsers have support for ES modules, but you can also still use the IIFE global variable, or use a bundler (all of which support ES modules) - No distinction between Node.js/Browser: - The library targets mainly Browser, so some things rely on `window` and expect it to be present, however most things work both platforms. - Node-only pipelines are removed, these are trivial to re-implement with Web Streams API if necessary. The CLI player has its own TCP source for that reason (replacing the CliXyz pipelines). - The generic "component" and "pipeline" classes were removed: - Components extend Web Streams API instead - Pipelines rely on `pipeTo`/`pipeThrough` composition and a `start` method to initiate flow of data. - Some public methods on pipelines have been removed (refer to their type for details) in cases where a simple alternative is available, or check the examples to see how to modify usage. There are less pipelines but they are more versatile, with accessible readonly components. In general, promises/async methods are preferred over callbacks.
steabert
added a commit
that referenced
this issue
Jan 8, 2025
Replace Node.js stream module with Web Streams API. Since the latter is substantially different in some important details regarding stream pipelining, the way pipelines are built are redefined. The component concept as module blocks is removed and instead the components themselves expose streams that can be combined together. The pipelines are then simple stream compositions. Because this is a major (breaking) change, it's done in concert with other planned improvements that are also breaking changes (see section below for details). Improvements: - replacing the Node.js stream module with Web Streams API removes the dependency on the (legacy) stream-browserify package and results in a much smaller library (bundle) size, so there is no longer a need for a separate "light" version - `debug` package replaced by custom internal logging utilities (allowing proper ES module support) Fixes #990, Closes #992 Refactoring: - RTSP session and parser are combined in a single component and the session controller has been rewritten as a request-response flow. An async `start` method starts the streams and returns SDP + range. - RTP depay is combined into a single component that detects the proper format based on payloadType, and allows registering a "peeker" that can inspect messages (instead of having to insert an extra transform stream) - Extended use of TypeScript in areas where this was lacking BREAKING CHANGES: - No support for CommonJS: - Node.js has support for ES modules - Browsers have support for ES modules, but you can also still use the IIFE global variable, or use a bundler (all of which support ES modules) - No distinction between Node.js/Browser: - The library targets mainly Browser, so some things rely on `window` and expect it to be present, however most things work both platforms. - Node-only pipelines are removed, these are trivial to re-implement with Web Streams API if necessary. The CLI player has its own TCP source for that reason (replacing the CliXyz pipelines). - The generic "component" and "pipeline" classes were removed: - Components extend Web Streams API instead - Pipelines rely on `pipeTo`/`pipeThrough` composition and a `start` method to initiate flow of data. - Some public methods on pipelines have been removed (refer to their type for details) in cases where a simple alternative is available, or check the examples to see how to modify usage. There are less pipelines but they are more versatile, with accessible readonly components. In general, promises/async methods are preferred over callbacks.
steabert
added a commit
that referenced
this issue
Jan 8, 2025
Replace Node.js stream module with Web Streams API. Since the latter is substantially different in some important details regarding stream pipelining, the way pipelines are built are redefined. The component concept as module blocks is removed and instead the components themselves expose streams that can be combined together. The pipelines are then simple stream compositions. Because this is a major (breaking) change, it's done in concert with other planned improvements that are also breaking changes (see section below for details). Improvements: - replacing the Node.js stream module with Web Streams API removes the dependency on the (legacy) stream-browserify package and results in a much smaller library (bundle) size, so there is no longer a need for a separate "light" version - `debug` package replaced by custom internal logging utilities (allowing proper ES module support) Fixes #990, Closes #992 Refactoring: - RTSP session and parser are combined in a single component and the session controller has been rewritten as a request-response flow. An async `start` method starts the streams and returns SDP + range. - RTP depay is combined into a single component that detects the proper format based on payloadType, and allows registering a "peeker" that can inspect messages (instead of having to insert an extra transform stream) - Extended use of TypeScript in areas where this was lacking BREAKING CHANGES: - No support for CommonJS: - Node.js has support for ES modules - Browsers have support for ES modules, but you can also still use the IIFE global variable, or use a bundler (all of which support ES modules) - No distinction between Node.js/Browser: - The library targets mainly Browser, so some things rely on `window` and expect it to be present, however most things work both platforms. - Node-only pipelines are removed, these are trivial to re-implement with Web Streams API if necessary. The CLI player has its own TCP source for that reason (replacing the CliXyz pipelines). - The generic "component" and "pipeline" classes were removed: - Components extend Web Streams API instead - Pipelines rely on `pipeTo`/`pipeThrough` composition and a `start` method to initiate flow of data. - Some public methods on pipelines have been removed (refer to their type for details) in cases where a simple alternative is available, or check the examples to see how to modify usage. There are less pipelines but they are more versatile, with accessible readonly components. In general, promises/async methods are preferred over callbacks.
steabert
added a commit
that referenced
this issue
Jan 9, 2025
Replace Node.js stream module with Web Streams API. Since the latter is substantially different in some important details regarding stream pipelining, the way pipelines are built are redefined. The component concept as module blocks is removed and instead the components themselves expose streams that can be combined together. The pipelines are then simple stream compositions. Because this is a major (breaking) change, it's done in concert with other planned improvements that are also breaking changes (see section below for details). Improvements: - replacing the Node.js stream module with Web Streams API removes the dependency on the (legacy) stream-browserify package and results in a much smaller library (bundle) size, so there is no longer a need for a separate "light" version - `debug` package replaced by custom internal logging utilities (allowing proper ES module support) Fixes #990, Closes #992 - added audio test signal to the H.264 test Refactoring: - RTSP session and parser are combined in a single component and the session controller has been rewritten as a request-response flow. An async `start` method starts the streams and returns SDP + range. - RTP depay is combined into a single component that detects the proper format based on payloadType, and allows registering a "peeker" that can inspect messages (instead of having to insert an extra transform stream) - Extended use of TypeScript in areas where this was lacking BREAKING CHANGES: - No support for CommonJS: - Node.js has support for ES modules - Browsers have support for ES modules, but you can also still use the IIFE global variable, or use a bundler (all of which support ES modules) - No distinction between Node.js/Browser: - The library targets mainly Browser, so some things rely on `window` and expect it to be present, however most things work both platforms. - Node-only pipelines are removed, these are trivial to re-implement with Web Streams API if necessary. The CLI player has its own TCP source for that reason (replacing the CliXyz pipelines). - The generic "component" and "pipeline" classes were removed: - Components extend Web Streams API instead - Pipelines rely on `pipeTo`/`pipeThrough` composition and a `start` method to initiate flow of data. - Some public methods on pipelines have been removed (refer to their type for details) in cases where a simple alternative is available, or check the examples to see how to modify usage. There are less pipelines but they are more versatile, with accessible readonly components. In general, promises/async methods are preferred over callbacks.
steabert
added a commit
that referenced
this issue
Jan 9, 2025
Replace Node.js stream module with Web Streams API. Since the latter is substantially different in some important details regarding stream pipelining, the way pipelines are built are redefined. The component concept as module blocks is removed and instead the components themselves expose streams that can be combined together. The pipelines are then simple stream compositions. Because this is a major (breaking) change, it's done in concert with other planned improvements that are also breaking changes (see section below for details). Improvements: - replacing the Node.js stream module with Web Streams API removes the dependency on the (legacy) stream-browserify package and results in a much smaller library (bundle) size, so there is no longer a need for a separate "light" version - `debug` package replaced by custom internal logging utilities (allowing proper ES module support) Fixes #990, Closes #992 - added audio test signal to the H.264 test Refactoring: - RTSP session and parser are combined in a single component and the session controller has been rewritten as a request-response flow. An async `start` method starts the streams and returns SDP + range. - RTP depay is combined into a single component that detects the proper format based on payloadType, and allows registering a "peeker" that can inspect messages (instead of having to insert an extra transform stream) - Extended use of TypeScript in areas where this was lacking BREAKING CHANGES: - No support for CommonJS: - Node.js has support for ES modules - Browsers have support for ES modules, but you can also still use the IIFE global variable, or use a bundler (all of which support ES modules) - No distinction between Node.js/Browser: - The library targets mainly Browser, so some things rely on `window` and expect it to be present, however most things work both platforms. - Node-only pipelines are removed, these are trivial to re-implement with Web Streams API if necessary. The CLI player has its own TCP source for that reason (replacing the CliXyz pipelines). - The generic "component" and "pipeline" classes were removed: - Components extend Web Streams API instead - Pipelines rely on `pipeTo`/`pipeThrough` composition and a `start` method to initiate flow of data. - Some public methods on pipelines have been removed (refer to their type for details) in cases where a simple alternative is available, or check the examples to see how to modify usage. There are less pipelines but they are more versatile, with accessible readonly components. In general, promises/async methods are preferred over callbacks.
steabert
added a commit
that referenced
this issue
Jan 9, 2025
Replace Node.js stream module with Web Streams API. Since the latter is substantially different in some important details regarding stream pipelining, the way pipelines are built are redefined. The component concept as module blocks is removed and instead the components themselves expose streams that can be combined together. The pipelines are then simple stream compositions. Because this is a major (breaking) change, it's done in concert with other planned improvements that are also breaking changes (see section below for details). Improvements: - replacing the Node.js stream module with Web Streams API removes the dependency on the (legacy) stream-browserify package and results in a much smaller library (bundle) size, so there is no longer a need for a separate "light" version - `debug` package replaced by custom internal logging utilities (allowing proper ES module support) Fixes #990, Closes #992 - added audio test signal to the H.264 test Refactoring: - RTSP session and parser are combined in a single component and the session controller has been rewritten as a request-response flow. An async `start` method starts the streams and returns SDP + range. - RTP depay is combined into a single component that detects the proper format based on payloadType, and allows registering a "peeker" that can inspect messages (instead of having to insert an extra transform stream) - Extended use of TypeScript in areas where this was lacking BREAKING CHANGES: - No support for CommonJS: - Node.js has support for ES modules - Browsers have support for ES modules, but you can also still use the IIFE global variable, or use a bundler (all of which support ES modules) - No distinction between Node.js/Browser: - The library targets mainly Browser, so some things rely on `window` and expect it to be present, however most things work both platforms. - Node-only pipelines are removed, these are trivial to re-implement with Web Streams API if necessary. The CLI player has its own TCP source for that reason (replacing the CliXyz pipelines). - The generic "component" and "pipeline" classes were removed: - Components extend Web Streams API instead - Pipelines rely on `pipeTo`/`pipeThrough` composition and a `start` method to initiate flow of data. - Some public methods on pipelines have been removed (refer to their type for details) in cases where a simple alternative is available, or check the examples to see how to modify usage. There are less pipelines but they are more versatile, with accessible readonly components. In general, promises/async methods are preferred over callbacks.
steabert
added a commit
that referenced
this issue
Jan 9, 2025
Replace Node.js stream module with Web Streams API. Since the latter is substantially different in some important details regarding stream pipelining, the way pipelines are built are redefined. The component concept as module blocks is removed and instead the components themselves expose streams that can be combined together. The pipelines are then simple stream compositions. Because this is a major (breaking) change, it's done in concert with other planned improvements that are also breaking changes (see section below for details). Improvements: - replacing the Node.js stream module with Web Streams API removes the dependency on the (legacy) stream-browserify package and results in a much smaller library (bundle) size, so there is no longer a need for a separate "light" version - `debug` package replaced by custom internal logging utilities (allowing proper ES module support) Fixes #990, Closes #992 - added audio test signal to the H.264 test Refactoring: - RTSP session and parser are combined in a single component and the session controller has been rewritten as a request-response flow. An async `start` method starts the streams and returns SDP + range. - RTP depay is combined into a single component that detects the proper format based on payloadType, and allows registering a "peeker" that can inspect messages (instead of having to insert an extra transform stream) - Extended use of TypeScript in areas where this was lacking BREAKING CHANGES: - No support for CommonJS: - Node.js has support for ES modules - Browsers have support for ES modules, but you can also still use the IIFE global variable, or use a bundler (all of which support ES modules) - No distinction between Node.js/Browser: - The library targets mainly Browser, so some things rely on `window` and expect it to be present, however most things work both platforms. - Node-only pipelines are removed, these are trivial to re-implement with Web Streams API if necessary. The CLI player has its own TCP source for that reason (replacing the CliXyz pipelines). - The generic "component" and "pipeline" classes were removed: - Components extend Web Streams API instead - Pipelines rely on `pipeTo`/`pipeThrough` composition and a `start` method to initiate flow of data. - Some public methods on pipelines have been removed (refer to their type for details) in cases where a simple alternative is available, or check the examples to see how to modify usage. There are less pipelines but they are more versatile, with accessible readonly components. In general, promises/async methods are preferred over callbacks.
steabert
added a commit
that referenced
this issue
Jan 9, 2025
Replaces use of `Buffer` with `Uint8Array`. The latter is now widely supported and available in Node.js and Browsers. Notable differences: - `Buffer.slice(...)` has been replaced with `Uint8Array.subarray(...)` as that is the actual behaviour of the original method (`Uint8Array.slice(...)` makes a copy). - Converting to and from strings is handled by `TextEncoder`/`TextDecoder` - Converting to and from differently sized big-endian integers is handled by using `DataView` Replaces use of Node.js Stream module with Web Streams API. Since the latter is substantially different in some important details regarding stream pipelining, the way pipelines are built are redefined. The component concept as module blocks is removed and instead the components themselves expose streams that can be combined together. The pipelines are then simple stream compositions. Because this is a major (breaking) change, it's done in concert with other planned improvements that are also breaking changes (see section below for details). Improvements: - replacing the Node.js stream module with Web Streams API removes the dependency on the (legacy) stream-browserify package and results in a much smaller library (bundle) size, so there is no longer a need for a separate "light" version - `debug` package replaced by custom internal logging utilities (allowing proper ES module support) Fixes #990, Closes #992 - added audio test signal to the H.264 test Refactoring: - RTSP session and parser are combined in a single component and the session controller has been rewritten as a request-response flow. An async `start` method starts the streams and returns SDP + range. - RTP depay is combined into a single component that detects the proper format based on payloadType, and allows registering a "peeker" that can inspect messages (instead of having to insert an extra transform stream) - Extended use of TypeScript in areas where this was lacking BREAKING CHANGES: - No support for CommonJS: - Node.js has support for ES modules - Browsers have support for ES modules, but you can also still use the IIFE global variable, or use a bundler (all of which support ES modules) - No distinction between Node.js/Browser: - The library targets mainly Browser, so some things rely on `window` and expect it to be present, however most things work both platforms. - Node-only pipelines are removed, these are trivial to re-implement with Web Streams API if necessary. The CLI player has its own TCP source for that reason (replacing the CliXyz pipelines). - The generic "component" and "pipeline" classes were removed: - Components extend Web Streams API instead - Pipelines rely on `pipeTo`/`pipeThrough` composition and a `start` method to initiate flow of data. - Some public methods on pipelines have been removed (refer to their type for details) in cases where a simple alternative is available, or check the examples to see how to modify usage. There are less pipelines but they are more versatile, with accessible readonly components. In general, promises/async methods are preferred over callbacks. Co-authored-by: Rikard Tegnander <[email protected]>
victoringvarsson
pushed a commit
that referenced
this issue
Jan 10, 2025
Replaces use of `Buffer` with `Uint8Array`. The latter is now widely supported and available in Node.js and Browsers. Notable differences: - `Buffer.slice(...)` has been replaced with `Uint8Array.subarray(...)` as that is the actual behaviour of the original method (`Uint8Array.slice(...)` makes a copy). - Converting to and from strings is handled by `TextEncoder`/`TextDecoder` - Converting to and from differently sized big-endian integers is handled by using `DataView` Replaces use of Node.js Stream module with Web Streams API. Since the latter is substantially different in some important details regarding stream pipelining, the way pipelines are built are redefined. The component concept as module blocks is removed and instead the components themselves expose streams that can be combined together. The pipelines are then simple stream compositions. Because this is a major (breaking) change, it's done in concert with other planned improvements that are also breaking changes (see section below for details). Improvements: - replacing the Node.js stream module with Web Streams API removes the dependency on the (legacy) stream-browserify package and results in a much smaller library (bundle) size, so there is no longer a need for a separate "light" version - `debug` package replaced by custom internal logging utilities (allowing proper ES module support) Fixes #990, Closes #992 - added audio test signal to the H.264 test Refactoring: - RTSP session and parser are combined in a single component and the session controller has been rewritten as a request-response flow. An async `start` method starts the streams and returns SDP + range. - RTP depay is combined into a single component that detects the proper format based on payloadType, and allows registering a "peeker" that can inspect messages (instead of having to insert an extra transform stream) - Extended use of TypeScript in areas where this was lacking BREAKING CHANGES: - No support for CommonJS: - Node.js has support for ES modules - Browsers have support for ES modules, but you can also still use the IIFE global variable, or use a bundler (all of which support ES modules) - No distinction between Node.js/Browser: - The library targets mainly Browser, so some things rely on `window` and expect it to be present, however most things work both platforms. - Node-only pipelines are removed, these are trivial to re-implement with Web Streams API if necessary. The CLI player has its own TCP source for that reason (replacing the CliXyz pipelines). - The generic "component" and "pipeline" classes were removed: - Components extend Web Streams API instead - Pipelines rely on `pipeTo`/`pipeThrough` composition and a `start` method to initiate flow of data. - Some public methods on pipelines have been removed (refer to their type for details) in cases where a simple alternative is available, or check the examples to see how to modify usage. There are less pipelines but they are more versatile, with accessible readonly components. In general, promises/async methods are preferred over callbacks. Co-authored-by: Rikard Tegnander <[email protected]>
steabert
added a commit
that referenced
this issue
Jan 10, 2025
Replaces use of `Buffer` with `Uint8Array`. The latter is now widely supported and available in Node.js and Browsers. Notable differences: - `Buffer.slice(...)` has been replaced with `Uint8Array.subarray(...)` as that is the actual behaviour of the original method (`Uint8Array.slice(...)` makes a copy). - Converting to and from strings is handled by `TextEncoder`/`TextDecoder` - Converting to and from differently sized big-endian integers is handled by using `DataView` Replaces use of Node.js Stream module with Web Streams API. Since the latter is substantially different in some important details regarding stream pipelining, the way pipelines are built are redefined. The component concept as module blocks is removed and instead the components themselves expose streams that can be combined together. The pipelines are then simple stream compositions. Because this is a major (breaking) change, it's done in concert with other planned improvements that are also breaking changes (see section below for details). Improvements: - replacing the Node.js stream module with Web Streams API removes the dependency on the (legacy) stream-browserify package and results in a much smaller library (bundle) size, so there is no longer a need for a separate "light" version - `debug` package replaced by custom internal logging utilities (allowing proper ES module support) Fixes #990, Closes #992 - added audio test signal to the H.264 test Refactoring: - RTSP session and parser are combined in a single component and the session controller has been rewritten as a request-response flow. An async `start` method starts the streams and returns SDP + range. - RTP depay is combined into a single component that detects the proper format based on payloadType, and allows registering a "peeker" that can inspect messages (instead of having to insert an extra transform stream) - Extended use of TypeScript in areas where this was lacking BREAKING CHANGES: - No support for CommonJS: - Node.js has support for ES modules - Browsers have support for ES modules, but you can also still use the IIFE global variable, or use a bundler (all of which support ES modules) - No distinction between Node.js/Browser: - The library targets mainly Browser, so some things rely on `window` and expect it to be present, however most things work both platforms. - Node-only pipelines are removed, these are trivial to re-implement with Web Streams API if necessary. The CLI player has its own TCP source for that reason (replacing the CliXyz pipelines). - The generic "component" and "pipeline" classes were removed: - Components extend Web Streams API instead - Pipelines rely on `pipeTo`/`pipeThrough` composition and a `start` method to initiate flow of data. - Some public methods on pipelines have been removed (refer to their type for details) in cases where a simple alternative is available, or check the examples to see how to modify usage. There are less pipelines but they are more versatile, with accessible readonly components. In general, promises/async methods are preferred over callbacks. Co-authored-by: Rikard Tegnander <[email protected]>
steabert
added a commit
that referenced
this issue
Jan 10, 2025
Replaces use of `Buffer` with `Uint8Array`. The latter is now widely supported and available in Node.js and Browsers. Notable differences: - `Buffer.slice(...)` has been replaced with `Uint8Array.subarray(...)` as that is the actual behaviour of the original method (`Uint8Array.slice(...)` makes a copy). - Converting to and from strings is handled by `TextEncoder`/`TextDecoder` - Converting to and from differently sized big-endian integers is handled by using `DataView` Replaces use of Node.js Stream module with Web Streams API. Since the latter is substantially different in some important details regarding stream pipelining, the way pipelines are built are redefined. The component concept as module blocks is removed and instead the components themselves expose streams that can be combined together. The pipelines are then simple stream compositions. Because this is a major (breaking) change, it's done in concert with other planned improvements that are also breaking changes (see section below for details). Improvements: - replacing the Node.js stream module with Web Streams API removes the dependency on the (legacy) stream-browserify package and results in a much smaller library (bundle) size, so there is no longer a need for a separate "light" version - `debug` package replaced by custom internal logging utilities (allowing proper ES module support) Fixes #990, Closes #992 - added audio test signal to the H.264 test Refactoring: - RTSP session and parser are combined in a single component and the session controller has been rewritten as a request-response flow. An async `start` method starts the streams and returns SDP + range. - RTP depay is combined into a single component that detects the proper format based on payloadType, and allows registering a "peeker" that can inspect messages (instead of having to insert an extra transform stream) - Extended use of TypeScript in areas where this was lacking BREAKING CHANGES: - No support for CommonJS: - Node.js has support for ES modules - Browsers have support for ES modules, but you can also still use the IIFE global variable, or use a bundler (all of which support ES modules) - No distinction between Node.js/Browser: - The library targets mainly Browser, so some things rely on `window` and expect it to be present, however most things work both platforms. - Node-only pipelines are removed, these are trivial to re-implement with Web Streams API if necessary. The CLI player has its own TCP source for that reason (replacing the CliXyz pipelines). - The generic "component" and "pipeline" classes were removed: - Components extend Web Streams API instead - Pipelines rely on `pipeTo`/`pipeThrough` composition and a `start` method to initiate flow of data. - Some public methods on pipelines have been removed (refer to their type for details) in cases where a simple alternative is available, or check the examples to see how to modify usage. There are less pipelines but they are more versatile, with accessible readonly components. In general, promises/async methods are preferred over callbacks. Co-authored-by: Rikard Tegnander <[email protected]> Co-authored-by: Victor Ingvarsson <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The
debug
package still relies on CommonJS (either itself or in its dependencies), which causes issues when generating ESM for e.g. Node.js.We should replace it with either a custom logger or e.g.
tslog
:console
ortslog
to do the actual loggingSolves #990
The text was updated successfully, but these errors were encountered: