This PR is in part a huge waste of time for in the end what may be a less stable transmuxer, but it might be worth it in the future.
The idea was that:
Transmuxing (the act of converting from a media container incompatible with the current environment, mainly mpeg-ts and acc, to a compatible one, here fmp4) is a complex step which I may want to have more control on. For example to have more information on the segments's real presentation timestamps - on in the contrary to influence them.
It is a relatively lengthy step. On my PC, 10 seconds segments may take several hundreds of milliseconds (!) to be transmuxed.
I did not understand much how it all worked and, well, this project is also mainly to learn
So I decided that I had to get a full grasp of how that step works, even, in my most daring dreams, thinking about writing a faster WASM alternative (though the idea that this would be faster, is not a given).
Turns out it's pretty complex, who would have guessed?
I started by forking videojs's mux.js repository (still kept their - permissive - licence). The code was Event-based, and organized through "streams" which communicate the output of a "stream" to the input of another etc. (kind of an usual architecture in media utils) from one to another.
As my goals were:
To understand that code
To better type it so I can make easier updates without fear of breaking everything
Potentially "Rewrite It In Rust" (TM). In all seriousness, it may improve performance for something that may be sensitive for low-latency contents, or not, or it may even be worse in WASM, to test.
I decided to rewrite it in a more procedural manner, removing partial segments management (that I may have to re-add to better handle some low-latency HLS contents!). Basically, the great majority of the code is still theirs (I mean I already did my share of binary data parsing to know that it's not THAT fun to rewrite, so I left that code the way it was) but the way it is architectured and glued together is different.
I probably broke things, I even saw by hashing the outputed segments that even if the first transmuxed segment appears to be the same one than with the original muxjs's transmuxer, the following ones are not. Yet, well, it plays :D, so who cares about bugs if it works on my machine/content.
Also I'm kind of sad that this may raise the percentage of TS code displayed by GitHub and thus lower the Rust one, where the fact that this was mostly rust gave me more street cred in the case I communicate about this project, but well, such is life.
I did lose many hours of my life for what should be a worse transmuxer than before, yet I'm happy to have done it, weird.
This PR is in part a huge waste of time for in the end what may be a less stable transmuxer, but it might be worth it in the future.
The idea was that:
So I decided that I had to get a full grasp of how that step works, even, in my most daring dreams, thinking about writing a faster WASM alternative (though the idea that this would be faster, is not a given). Turns out it's pretty complex, who would have guessed?
I started by forking videojs's mux.js repository (still kept their - permissive - licence). The code was Event-based, and organized through "streams" which communicate the output of a "stream" to the input of another etc. (kind of an usual architecture in media utils) from one to another.
As my goals were:
I decided to rewrite it in a more procedural manner, removing partial segments management (that I may have to re-add to better handle some low-latency HLS contents!). Basically, the great majority of the code is still theirs (I mean I already did my share of binary data parsing to know that it's not THAT fun to rewrite, so I left that code the way it was) but the way it is architectured and glued together is different.
I probably broke things, I even saw by hashing the outputed segments that even if the first transmuxed segment appears to be the same one than with the original muxjs's transmuxer, the following ones are not. Yet, well, it plays :D, so who cares about bugs if it works on my machine/content. Also I'm kind of sad that this may raise the percentage of TS code displayed by GitHub and thus lower the Rust one, where the fact that this was mostly rust gave me more street cred in the case I communicate about this project, but well, such is life.
I did lose many hours of my life for what should be a worse transmuxer than before, yet I'm happy to have done it, weird.