DRAFT: Feature/wavpack reader #429
Open
+22,974
−11,415
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The symphonia-format-wav crate is superseded by symphonia-format-riff.
The next_packet call now returns Result<Option<Packet>> instead of Result<Packet>. A return value of Ok(None) indicates when the media ends. Whereas an UnexpectedEof error now always indicates an unexpected end to the media. Fixes pdeljanov#246, pdeljanov#134.
* Scoring The score function is now provided a scoped stream instead of a buffer. * Preference Tiers Allow format and metadata readers registered in Probe to be registered with a preference tier. There are three preference tiers: preferred, standard, and fallback. Symphonia will always register its first-party implementations of readers in the standard tier. Users that prefer to use their own implementations over Symphonia's may register them at the preferred tier. Likewise, if a user would prefer a first-party Symphonia implementation over their own implementation, they may register their implementation in the fallback tier. This capability is particularly important when different implementations may only partially support a format. * Probe Options A probe may now be instantiated with a set of options. The maximum number of bytes probe may scan from the source is now configurable. The maximum number of bytes any particular reader may consume while scoring may also be limited.
Instead, an initial set of metadata may be provided to a format reader upon creation. The reader is expected to use this metadata as the start of its own metadata log. This allows users to access all metadata via. the reader instead of handling metadata found through probing seperately.
Add an explicit lifetime to the `MediaSource` to support non-static media sources. Fixes pdeljanov#117, pdeljanov#171.
Since the fft module now supports SIMD via. RustFFT, MDCT no longer needs a SIMD and non-SIMD implementation.
This crate is intended to contain Symphonia first-party codec and format support code shared by multiple format readers and decoders.
Incrementing the MSRV will be considered a SemVer breaking change.
These formats are not standalone and are embedded into other containers. Therefore, they do not implement the MetadataReader trait and are instead provided as read and/or parse functions.
ID3v1, ID3v2, and iTunes all introduced various defacto-standards used broadly across many different metadata formats. Move the common utilities to handle these standards to the utils module.
Attachments replace and supersede vendor-specific metadata as a method for exporting supplementary data attached to a container.
The ElementIterator could not support recursive elements (elements that can contain nested elements of the same type) since each recursive step would take an additional &mut of the inner reader. This new mutable reference would be considered a new type to the generic Element::read function consuming it, thereby causing an overflow to occur because the compiler would need to instantiate a new implementation of Element::read at each recursive step. The solution to this problem is to not take &mut at each step. To accomplish this, ElementIterator must only take &mut of the inner reader if it owns the inner reader. Typically, this would only be the case for a top-level iterator. For lower-level/child iterators using a borrowed inner reader, the reference must simply be passed along to the next child iterator. This is implemented by abstracting owned vs. borrowed inner readers from ElementIterator via. the ElementReader trait. ElementReader is a trait that only requires DerefMut to be implemented with the constraint Deref::Target implements ReadBytes. The ElementReader trait is implemented by OwnedElementReader<B: ReadBytes> and BorrowedElementReader<B: ReadBytes> for the owning/borrowing cases. In the owning case, Deref(Mut) return a reference to the owned inner reader, while in the borrowing case they return the pre-existing reference. In this way, no matter the depth, ElementIterator will only ever use a reference at-most one indirection deep. Since recursion may run the risk of a runtime stack overflow with malicious or malformed input, a maximum depth limit of 16 is enforced. Excluding nested chapter elements, the maximum expected depth is 7 for MKV files. With a depth limit of 16, up-to 10 levels of nested chapters will be supported.
This brings the byte-oriented AudioBytes trait into alignment with the sample-oriented Audio(Mut) traits.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@pdeljanov As discussed here is the wavpack reader PR. I took a bit of a break since starting it, so i had to puzzle a bit finding the right commit where i cut out experiments with the decoder and other dev code.
It's very out of date because of the break, so first point of action on my side is resolving any conflicts/old things. Let me know what branch i should target
If you have any major concerns/suggestions about the structure we can go through it, but it's best for me to resolve any conflicts meanwhile, so the code is easier to review, hence i marked it draft
As far as i remember i marked branched from dev-0.6 but ill also double check this.