📢 Version 0.6 Development Status

[pdeljanov]

Hey all,

As some may have noticed, most of the development activity on Symphonia is occurring in the dev-0.6 branch. This is because I believe the 0.5.x series has reached a developmental dead-end where it is not possible to satisfactorily fix many of Symphonia's issues due to API constraints. Therefore, I've decided to focus my limited time on completing version 0.6 instead.

Version 0.6 includes many breaking changes to support popular requests such as making it easier to get audio out of Symphonia, or returning None when the end of the media is reached, but it also includes forward looking enhancements such as stubbing out video and subtitle decoding support.

Development Plan

My development plan is as follows:

1. For the time being, I will be keeping 0.6 development in the dev-0.6 branch until there are no more breaking changes being made.
2. Once the APIs are stabilised, I will cut a final 0.5.5 release from the mainline branch that includes some fixes for annoyances people have had.
3. Once 0.5.5 is released, I will merge the 0.6 development branch into mainline and begin more thorough testing.
4. Once 0.6 has been tested (including some fuzzing time), it will be released.

Timeline

I am hopeful for an early 2025 release, but some help from the community would improve the odds!

Help Wanted

You can help the development and release of version 0.6 by picking up any of these tasks:

• Add fuzz testing harnesses to each format and codec crate.
• Begin playing around with version 0.6 and submitting feedback and suggestions on the new APIs. Note: At this time, some of the new APIs are still in flux, but you can still get an idea, and different perspectives will be helpful to me.
• Read, critique, fix, or update documentation.
• Any help fixing decode or demuxing issues are always welcome.

I will add to this list over time...

Thanks all!

[crutchcorn]

Hey! I'm using the 0.6 branch against my very very very small Tauri application, since it fixes many issues with FLAC currently

Just wanted to say that you're crushing it and I'm extremely happy as a downstream consumer of this package and that the API changes to 0.6 were pretty easy to adapt to

I'm still extremely green to Rust in general, so might not be a huge help, but if I end up with some spare cycles and find something critically blocking I'm happy to jump in

[caass]

One thing that could help with no_std support (which seems to have stalled) would be to move the core API away from std::io traits; for example, the tokio project has the bytes crate which provides APIs similar to ReadBytes.

If you'd like to maintain the fallibility of the API (bytes panics implicitly instead), we could instead be generic over the error type, since Error has been stabilized in core for a couple releases now.

Unfortunately, the Read and Write (and Seek) traits are probably not going to get moved to core any time soon, and I saw here that it's impossible to copy those traits over due to licensing issues.

[sscobici]

Adding some points that would be good to address or consider before the 0.6 release:

1. Packet's Track ID: This is a unique identifier for the track. Previously, it was used as an index for the tracks array, but this is no longer the case, at least for MP4. Should we add a track_num field to the Packet structure?

2. Packet PTS/DTS: The introduction of Packet Presentation Time Stamp (PTS) and Decode Time Stamp (DTS) fields is needed.

3. Packet Struct Design: Should we keep the Packet struct for all types of packets (Audio, Video, Subtitles), or should we switch to an Enum, similar to how CodecParameters is structured?

4. Track Metadata: The Track struct currently lacks a TrackType field and a default flag. While analyzing CodecParams can be an alternative, it is not always convenient. Including a default flag would also provide useful information for users.