bbc
Future maintenance of bmx
I have decided to retire at the end of this month. That means I will no longer be maintaining and updating bmx as I've been doing for the past decade. There have been many welcome contributions over the years but the majority of the contribution review and general maintenance have still been down to me to do. We (now @thomasheritage and BBC R&D) are interested to discuss with the community about the future of the project, how it could be maintained as a minimum and potentially extended in the future.
The intention is to keep the repository as it is now for at least 6 months to allow the discussions to be had and thereafter decide whether the repo should be archived or not. Any bugs or PRs during that period will likely not be processed as it currently stands.
If you have any thoughts on what direction this project should take, how it could be maintained and developed (e.g. creating releases, build system improvements, code review, fixing bugs, testing and developing new features) or potential help you could provide in different aspects of the project then please respond in this issue.
Hi Philip,
I wish you all the best for your retirement and thank you for your great work over the many years!
Many MXF implementers and users rely on your phenomenal BMX library. We hope the project won't be archived and that it won't come to a standstill. I've spoken with some people from ARD, and while they want to contribute, they don't believe they can maintain/take over the project. I'm fairly certain many EBU members use the BMX tools, but most of them don't feel able to take overall responsibility.
Let's hope that a viable solution is in sight. It would be interesting to hear a few more voices on this.
All the best, Richard
ARD/ZDF MXF Expert Group
Many thanks for your input @Richard-Ka -- it would be great to find a way for bmx to continue in some form.
I'm fairly certain many EBU members use the BMX tools, but most of them don't feel able to take overall responsibility.
Perhaps moving the project elsewhere (such as the EBU?) could be one option to consider (I don't know if that would be practical). It would be useful to know which EBU members make use of bmx.
It would be interesting to hear a few more voices on this.
Absolutely, it would be very useful to hear from more people within the bmx community -- please do post on this issue or get in touch directly.
I'd be very happy to discuss any ideas you might have.
Thanks for all your work @philipnbbc. Best wishes for your future.
I'm fairly new to bmx-tool, caused mainly by being involved with ADM now being implemented in MXF.
The options now provided appear very elaborate yet, though I'm not sure if all potential use cases and needs are already included. Therefore likely more efforts will be required with broadcasters incorporating the bmx-tool in ADM based workflows for MXF and IMF.
At the moment I have only a few ideas more related to enhance metadata processing.
-
create MCA labels from given ADM descriptions. It seems like all mca descriptors/labels are also existing in different form in ADM. So this translation process could be automated.
-
the RDD6 XML creator tool could also be used as a blueprint to create an ADM XML generator for 'legacy' track-layout descriptions (EBU R123, ITU-R BS.2102). Using the respective matrix allocations by categories (e.g. "16a"...) or types (e.g. "Stereo Mix", "Encoded 5.1"...) - plus the respective MCA label files.
-
With S-ADM in MXF gaining more importance, too, respective functionalities will likely also be required in bmx-tool (maybe even conversion processes ADM<>S-ADM).
The idea to forward further development on an EBU level seems very consequent. I'll try to second this.
I echo @Richard-Ka and @WernerBleisteiner around EBU. Thank you for all your work @philipnbbc. bmx has been invaluable to me and I would hate to see this project atrophy. I am a novice when it comes to C/C++ but I would love to offer myself as a resource or at least be a fly on the wall during any discussions around the future here.
I am working for a big german public broadcaster (ARD) and we are using bmx a lot in our AV Workflows. I support the idea of moving this project to the responsibility of the EBU and hope it will be maintained there as good as before. Although I like working in open source projects, I'm afraid I can't support here from a technical point of view, as I am more a Java Developer ;-)
Dear @philipnbbc , Thank you for what you have done. I wish you all the best for your retirement.
Many thanks for all the additional comments and input.
If anyone can else is able to offer their support for moving bmx to the EBU, or perhaps can offer some effort towards maintaining bmx in the future, it would be great to hear from you on this issue or directly by email! (please mention any EBU broadcasters you work for/with or that you know use bmx)
Thank you for everything you've done over the years, Philip, to make BMX become not just an mxf muxer but THE MXF Muxer. I've been using it for several years to mux plenty of files and I still am. I've always pointed to BMX as the reference to everyone who asked and wanted to mux/remux mxf files and this amazing project never let me down. Thank you for fixing all the issues reported over the years and for bearing with me both here and on the old sourceforge, honestly, I truly appreciated it. I once told Andrew Dunne that owed you a coffee, but given all those years I think it evolved to more like a thousand coffees and a full English breakfast :P
Jokes aside, on behalf of the wider open source community on Doom9 (the international encoding forum) I wish you a lovely retirement. You, more than anyone else, truly deserve it.
My guess is that all EBU members work with BMX in some way. I know that the largest broadcasters in DACH region and Norway work with it one way or the other. However contribution to FOSS projects is often done by single enthusiasts mostly in their free time but not by the organisation they work for.
Start of october there is an EBU event "MXF Plugfest", i will try to start the discussion about this topic there. As an ffmpeg supporter i would also like to add that we should check what Thomas Härdin/ffmpeg mxf maintainer has to say to the topic. I'll write him a note about it.
@philipnbbc thanks for all the work you did and all the best in the future
After further discussions with colleagues at the BBC, the EBU, and the community, an EBU fork has been created at: https://github.com/ebu/bmx (some of the configuration still needs to be updated e.g. to enable Issues)
This has been made available to the bmx community to continue development of the project. There will need to be further discussions among the community and with the EBU about the best way to manage the project and resource further work on it -- I'm sure contributions from the community will be essential.
there is an EBU event "MXF Plugfest", i will try to start the discussion about this topic there.
I'll provide a brief update about bmx tomorrow (remotely) at the event -- it should be an ideal opportunity for users to discuss bmx.
I'll now update the README to link to the EBU fork and archive this (BBC) repo so that it's still available yet it's clear that it's no longer being actively maintained.
Thanks for all the feedback on the project and Philip's excellent work! I'll make sure Philip is aware of all the updates to this issue.
This is probably the best outcome for the project. Thanks Thomas for keeping us updated. :) Long live BMX!