[Matroska-devel] standardization goal
dave at dericed.com
Fri May 1 13:58:25 CEST 2015
Responding to Moritz’s request for discussion about our goal, I’m starting a new thread to detail this. From a larger perspective there are likely two goals here though I hope they overlap well. One goal is from the Matroska perspective, the direction of the development of version 4, ongoing documentation maintenance of Matroska, etc. The other goal is that the FP7-ICT EU project known as PREFORMA (PREservation FORMAts) selected Matroska as an open file format to focus on. They sought bids and MediaArea was selected to work on Matroska (as well as FFV1 and LPCM). The work will develop four utilities that will work together: conformance checker (test file against spec), policy checker (test file against expected use), metadata fixer (add, edit tags, crc, attachments, correct conformance issues, etc) and a reporter. The whole MediaArea plan submitted to PREFORMA (all ~140 pages of it is) is posted here: https://github.com/MediaArea/MediaConch/releases <https://github.com/MediaArea/MediaConch/releases> and you can see the associated commits and history that developed this. One part of our planning was to acknowledge the challenges in developing conformance checkers for formats (MKV and FFV1) that do not have a specification that went through an external standards process, so we made a plan for this which was accepted, the details of the standardization part of the project are here: https://github.com/MediaArea/MediaConch/releases/download/2015.03.14/MediaAreaConch_Appendix_Standardization.pdf <https://github.com/MediaArea/MediaConch/releases/download/2015.03.14/MediaAreaConch_Appendix_Standardization.pdf>.
Thus on the MediaArea side we have me, Jerome, Tessa, Ashley, Guillaume, and Erik working on this project through this year and next (though hopefully the standardization effort doesn’t take that long).
Earlier discussion on standardizing FFV1 made reference to the IETF as a potential body and after reviewing open format standardizing organizations the IETF seemed a good fit for the two formats. The next IETF is IETF93 in July in Prague (anyone want to go?). From our team Tessa and Jerome will attend (if our BoF application is successful). By June 5th we must complete and submit our BoF application. At that point I’d like for both the specs for FFV1 and MKV (and EBML) to be a good shape. We’re waiting on advice regarding what specific shape we should be in at the point of the application deadline and the conference.
For the documentation itself, I agree that keeping multiple versions in sync is a challenge (such as one RFC and one human-readable website version). This is seen in the matroska-devel list where there’s occasional messages pointing out discrepancies between the RFC draft, online spec, and other resources. I think we should have one formal and technical authoritative document as the center. One for EBML and one for Matroska.
When discussing this process with FFmpeg there was concern about sending draft specs to IETF where they may refine or change the spec prior to standardization which would result in the published spec contradicting existing implementation that have been made. Thus we’re hoping to publish specs up to the current version as informational standards (not up for modification by IETF) and then use for more formal, involved process for Matroska version 4 (and FFV1 version 4). OAuth went a similar route where their version 1 was published as an informational standard and version 2 had much more vetting and change to become a more formal standard.
Because the RFC draft claims to be a draft but the EBML spec doesn’t, I’ve been considering the EBML spec as the central document for us to work on. I’d like to merge the two parts of it (index.html and spec.html) and continue to selectively consider what parts of the RFC draft should be evaluated and pulled into the main spec. Following that we can review the EBML spec in its entirety, ensuring that it is complete enough to implement an EBML muxer/demuxer and work to convert the web presentation of the spec to RFC style. At a later point then we may come back to figure out how to complete version 4. For now I’d propose that our work on the spec not change the intended meaning of the spec (except with bugs as discussed on the irc) but work to make it more clear and authoritative.
Hopefully this gives some context. We’re still learning about the IETF processes themselves so the priorities may change as we learn, but am hoping that MKV gets standardized soon. :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Matroska-devel