ffmpeg.js
ffmpeg.js copied to clipboard
Kagami
Enable Vorbis for WebM build
Didn't know about that. My concern is based on
https://wiki.xiph.org/OpusFAQ#Will_Opus_replace_Vorbis_in_video_files.3F
For WebM video files, the convention is to use the VP9 video codec when using Opus as an audio codec.
It's not some requirement of course, but in my experience people use VP8 with Vorbis most of the time.
There is a multitude of requirements which will result in a very different set of codecs needed. Why not make a standard ffmpeg build with everything included for easier development and the instruction for everyone at the end of the readme to generate a specialized production build optimized for their needs. Bugs like #90 are much easier to circumvent as everything will work when you are just testing the library and if it does not work for the specialized build they need to change the codecs/muxers/filters.
Why not make a standard ffmpeg build with everything included for easier development
Yes, I have issue for that: #26.
as everything will work when you are just testing the library
Maybe it should be the default one.
What about MP4/WebM builds with only H.264/VP8 encoders included so they're much lighter? Do you think they're not necessary too?
Thanks for feedback.
What about MP4/WebM builds with only H.264/VP8 encoders included so they're much lighter? Do you think they're not necessary too?
I can imagine people missing anything in a reduced build and you are always asked to add this codec or filter because they need it. But i can imagine another smaller subset which would be useful and has a fix limitation on support: include anything at least one of the major browsers has support for, so an „browser“ build which is a polyfill to ensure every browser has the same codec support. This would include the typical video/audio codecs and image formats (including e.g. apng because firefox supports it).
This would include the typical video/audio codecs and image formats (including e.g. apng
I'm afraid that build with a lot of encoders/decoders would be too huge, 20MB+. I've saved ~4MB just by removing few decoders.
I'm not sure what is the best option for ffmpeg.js:
- Provide small builds hoping they're sufficient for the most of users, without any additional steps
- Provide huge build and suggest to rebuild for use in production
Cons of first option is that it might be hard or even impossible to come with that set of features to make everyone happy, or at least most of the users.
Cons of second option is that you basically always require rebuild because big build is simply not practical, and it would be a crime to force site visitors to download it. I've made rebuild guide as simple as I could, but I realize most of the users won't bother with it, simply because they're not used to compilation.
Thoughts?
Yeah it's a complicated topic and i don't know a solution too. But maybe compiling a special build could be done for all the folks who have never compiled anything by abstracting the complete building step?
I am thinking on maybe the building could be improved that you place a .ffmpeg-configuration.json5 in a folder specifying all the codecs you want to be activated or deactivated and then you simply run node build-ffmpeg.js which is using docker to make reproducible builds and the user does not need to install any package (and building would work on windows too).
Maybe the configuration file could be a json5 file provided by the project (with every option set to false) like this where you simply toggle options and dont need to research the options:
{
"presets": {
"webm": false,
"h264": false,
// ...
},
"decoders": {
"h264": false,
"mpeg2": false,
// ...
},
"muxers": {
"concat": false
// ...
},
// ...
}
The real advantage is you could checkin the ffmpeg .ffmpeg-configuration.json5 to your repository and you can later easily rebuild it because you have documented what you need, and with json5 you could add comments to every option why you activated it. An information which is in my experience most often lost after months because people dont do this for large compile parameters.
Nice idea, thanks. The only cons is that it's a pretty long process (~15-30 minutes), but maybe it's not that critical.
Yeah it‘s taking really a long time. But for development purposes there would be a pre-built really large full build. And a 30min build process when you‘re finished prototyping is not that bad.
Why not make a standard ffmpeg build with everything included for easier development
I was thinking about it a bit more. Separate webm/mp4 builds would be redundant, because a lot of features (decoders/filters) are the same in all builds and it doesn't make sense to compile the same thing 3 times. But at the same time almost everyone who was fine with the current build will have to recompile.
Maybe it's better to provide relatively small builds by default and ask to recompile if someone needs some additional filter/decoder? Of course current builds should be extended, at least provide 20 more common filters and few more decoders/encoders. But the build size still should be sane and most people should be fine with the features included.
Why not make a standard ffmpeg build with everything included for easier development
I was thinking about it a bit more. Separate webm/mp4 builds would be redundant, because a lot of features (decoders/filters) are the same in all builds and it doesn't make sense to compile the same thing 3 times. But at the same time almost everyone who was fine with the current build will have to recompile.
Maybe it's better to provide relatively small builds by default and ask to recompile if someone needs some additional filter/decoder? Of course current builds should be extended, at least provide 20 more common filters and few more decoders/encoders. But the build size still should be sane and most people should be fine with the features included.
I think this is better than seperating two modules.
