Closed dreirund closed 2 years ago
So far I have hard coded the formats for simplicity. Allowing the user to select own combinations of codecs is possible, but limited: The output format must be suitable for on-the-fly creation. Files can be accessed while still being transcoded. This does not work for mpeg, for example. You cannot recode a file to mpeg and access it before the process is finished.
So the container formats would be limited to MP4, WEBM, OGV (probably others like FLV could be added, though). Codecs would be limited to those that create streamable files. V8/9 or MPEG-4 work, maybe AV1 as well (have to check that).
I had the feature already on my list, silently, so maybe I'll add it. Although it sounds easy it will be quite some work.
* be able to specify output container and output codec seperately (having a WebM container, do we want VP9 or AV1 video, for example? Having an MP4 container, do we want MP3 or AAC audio, for example?), and
This would be possible. I could add an option to select the video and/or audio codec out of those supported by the container format. Like said, this was hardcoded just for simplicity. If this option is not specified, the default would be used as of now.
* to be able to choose all output containers and codecs supported by `ffmpeg` (what is with MKV container?), and
This is simply impossible. Most container formats are not suitable for live streaming, and this is what FFmpegfs actually does. All formats implemented so far were selected because this is possible. MP4, on the other hand, actually was not streamable, but there have been extensions added to allow that. With the drawback that not all playback softwares support these extensions. As a result I had to add many profiles that need to be set to allow specific players. Not really nice.
So I can add more formats, but this has to be done one after the other.
* to be able to specify all coding options that can be specified manually to `ffmpeg` for fine tuning.
That sounds like a good idea, But this would be hard to do.
I think the second and third only make sense if there would be a way to pass the options that
ffmpeg
understands directly toffmpeg
without having them to be parsed and translated byffmpegfs
.
This would be a big change. I do not use the ffmpeg binary, to have its options available, I would have to add the whole parser code. This is next to impossible, I mean, this would end up finding me in a nuthouse :)
* be able to specify output container and output codec seperately (having a WebM container, do we want VP9 or AV1 video, for example? Having an MP4 container, do we want MP3 or AAC audio, for example?), and
This would be possible. I could add an option to select the video and/or audio codec out of those supported by the container format. Like said, this was hardcoded just for simplicity. If this option is not specified, the default would be used as of now.
Will implement this part only, removed "; support all targets that ffmpeg
supports; suport all codec options that ffmpeg
supports." from subject.
The first part of the change has been committed. Error checking has only been partly implemented, will be added soon.
Some new codec combinations are now possible (the default codecs in bold): | Formats | Audio Codecs | Video Codecs |
---|---|---|---|
MP4 | AAC, MP3 | H264, H265, MPEG1, MPEG2 | |
WebM | OPUS, VORBIS | VP9, VP8, AV1 | |
MOV | AAC, AC3, MP3 | H264, H265, MPEG1, MPEG2 | |
TS, HLS | AAC, AC3, MP3 | H264, H265, MPEG1, MPEG2 |
The audio codec can be selected with --audiocodec, for videos use --videocodec. Without these parameters, FFmpegfs will use the codecs as before (no change). Currently there is no check made if a codec can be used with the selected format, creating invalid result files or error messages. This will be added later. Please note that hardware acceleration might not work, e.g., my hardware encoder supports H264 but not H265. So even though H265 creates much smaller files it takes 10 times longer to transcode.
I have three feature requests (or, mode like: The first requests seem to me to be subsets of the latter requests),
ffmpeg
(what is with MKV container?), andffmpeg
for fine tuning.I think the second and third only make sense if there would be a way to pass the options that
ffmpeg
understands directly toffmpeg
without having them to be parsed and translated byffmpegfs
. If something is unsupported the errors are thrown byffmpeg
and must be handled. There might be options where only at transcode time the error might occur, this is then a drawback of the flexibility and should clearly be stated in the documentation, that if those options are used then there might be transcoding failures at runtime which cannot be checked for beforehand.