Replies: 1 comment
-
This is very interesting, and probably needed going forward. The current testing strategy of mine involves running my personal media library through Note, we also have a similar issues regarding benchmarking.
I don't see anything technically infeasible here. The biggest challenge will be hosting and automation which are going to cost money. For now, it'd be possible for me to host a small set of copyright and royalty-free test vectors on my server, however, that will not scale long-term. Tests would also need to be manually run by developers on their local systems.
This is tough. The Internet Archive is one option, however, I do believe they re-encode files so we won't be getting a truly diverse set of samples. One benefit of using my personal library was that it was built over 2 decades and therefore contains many quirky files from long-dead encoders, etc. Maybe using FFmpeg's test vectors is a good first start?
For demuxer tests, a known-good YAML description like you have is sufficient. As for decoding, a known-good WAVE decoding could also accompany each audio test vector. We should also add fuzzer generated test vectors that have previously broken Symphonia. |
Beta Was this translation helpful? Give feedback.
-
Proposal: Regression Pack Framework for Symphonia
Hi, I’ve been thinking about how a media library can ensure that optimizations and refactorings do not introduce regressions. To address this, I propose a regression pack framework that serves as the foundation for such a test suite.
Inspiration
This concept is not new—the FFmpeg project is a well-established leader in this area. It employs the FATE test suite alongside a collection of media files derived from bug reports: FATE media suite. Additionally, FFmpeg uses descriptive metadata files for assertions, such as this example.
Unfortunately, I haven’t found the corresponding media file for this specific meta description in their GitHub repository.
Proposal for Symphonia
For Symphonia, I propose adopting a similar approach:
Why Not symphonia-check?
The existing symphonia-check crate is useful, but it doesn’t address scenarios where reference decoders (such as FFmpeg or MediaInfo) produce inconsistent results. For instance:
During the implementation of PTS in Symphonia, I observed that
Key Challenges
The main challenge is determining:
Example Media File Description
Here’s an example YAML description for Symphonia, listing non-None values from the FormatReader. In the future, packet lists could be added for better demuxer coverage. This approach would also allow validation of basic behaviors such as seeking forward and backward, streamed parsing, etc.
Draft Implementation
A draft implementation is available here, but you will not be able to run it due to the absence of media files.
Test run example:
Failed test run example:
Feedback Requested
I’d love your feedback on:
Beta Was this translation helpful? Give feedback.
All reactions