Audio and video codec libraries are among the most complex things there are in the software world, I'd say - even more complex than GPUs because there are only four major GPU vendors/families remaining (AMD, NVIDIA, Intel, PowerVR):
- knowledge about how encoding audio and video works is rare (as it involves a ton of maths 99% of the population won't ever come close to understand), and people not bound by NDAs and thus actually able to work on FOSS projects in that area are even rarer in the first place.
- they have to deal with an absolutely insane amount of different codecs and their "profiles" (aka supported features list) that are all in active use by someone or something (mpeg2 for DVDs and early DVB-T/C/S, h264 for fullhd stuff, h265 for >fullhd, AV1 for YouTube), and all the historical codecs
- almost all of these have some hardware encoders with their own unique quirks which libraries have to take into account to support playback (and maintain that as well), not to mention software encoders in different versions and bugs, or error correction to deal with bitrot or transmission errors
- on top of that, there's a family of container formats - although most have settled on mp4 or (in the piracy world) Matroska, there is still a lot of legacy stuff floating around
- dealing with codecs means walking around on eggshells around laws and patents (DRM, the minefield that are video patents, ...)
- dealing with multimedia files in general means dealing with densely packed and hard-to-parse binary structures, which is a Very Complex Thing To Do on its own and is a constant source of security issues.
- supporting acceleration means even more rare knowledge and dealing with more NDAs or reverse-engineering
- the APIs used to communicate with downstream clients (converters, media players, ...) are decades old grown baggage, and cleaning that up is next to impossible because the ecosystem is all so fractured, which means a ton of effort in implementations and maintenance
Long-term it's infeasible to have more than one open source project... there are simply not enough capable developers around for the workload.
- knowledge about how encoding audio and video works is rare (as it involves a ton of maths 99% of the population won't ever come close to understand), and people not bound by NDAs and thus actually able to work on FOSS projects in that area are even rarer in the first place.
- they have to deal with an absolutely insane amount of different codecs and their "profiles" (aka supported features list) that are all in active use by someone or something (mpeg2 for DVDs and early DVB-T/C/S, h264 for fullhd stuff, h265 for >fullhd, AV1 for YouTube), and all the historical codecs
- almost all of these have some hardware encoders with their own unique quirks which libraries have to take into account to support playback (and maintain that as well), not to mention software encoders in different versions and bugs, or error correction to deal with bitrot or transmission errors
- on top of that, there's a family of container formats - although most have settled on mp4 or (in the piracy world) Matroska, there is still a lot of legacy stuff floating around
- dealing with codecs means walking around on eggshells around laws and patents (DRM, the minefield that are video patents, ...)
- dealing with multimedia files in general means dealing with densely packed and hard-to-parse binary structures, which is a Very Complex Thing To Do on its own and is a constant source of security issues.
- supporting acceleration means even more rare knowledge and dealing with more NDAs or reverse-engineering
- the APIs used to communicate with downstream clients (converters, media players, ...) are decades old grown baggage, and cleaning that up is next to impossible because the ecosystem is all so fractured, which means a ton of effort in implementations and maintenance
Long-term it's infeasible to have more than one open source project... there are simply not enough capable developers around for the workload.