Cannot use versions >v11.2.0 in a pure ESM project #990
Assignees
Labels
bug
Something isn't working
Comments
|
For now, our fix is to remove the constraints in our project to be an ES module. This works for us as we currently don't have other dependencies in this project that have the same constraints. |
|
Yes, this is a head-ache for us too, I'll have to have another look at this. I think it might be difficult since we ourselves depend on things that only are CommonJS. So we might by lying to Node.js by saying it's |
steabert
added
bug
|
It looks like it's the debug package, we should probably replace it with a simple utility or something like |
|
For anyone having an issue using Next.js when running import dynamic from "next/dynamic";
// import { MediaStreamLibComponent } from "./";
const MediaStreamLibComponent = dynamic(() => (await import("./")).MediaStreamLibComponent, { ssr: false });
export default const Page = () => {
return (
<MediaStreamLibComponent/>
);
} |
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 <rikardk@axis.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello! We're using the media-stream-library in a NodeJS project that is configured to only allow 'import' syntax. This still allows importing CommonJS modules, and we haven't had any issues with this in the past.
However, if we upgrade the media-stream-library beyond v11.2.0, we get the following error at runtime (This is with v13.1.1):
From what I can tell, there seems to be require syntax in an mjs file that causes the issue.
Any thoughts?
The text was updated successfully, but these errors were encountered: