obsproject
frontend: Add supported_encoders to GoLiveAPI
Description
Adding supported_encoders to the GoLiveAPI for Multi-track config
Motivation and Context
When implementing a custom stream server with multi-track support, its impossible to accurately return the correct encoder type with only the list of supported codecs
Example Values:
"supported_encoders":["obs_qsv11_hevc_soft","obs_qsv11_hevc","obs_qsv11_soft","obs_qsv11_soft_v2","ffmpeg_opus","ffmpeg_pcm_s16le","ffmpeg_pcm_s24le","ffmpeg_vaapi_tex","ffmpeg_aac","ffmpeg_pcm_f32le","ffmpeg_alac","obs_qsv11","ffmpeg_flac","obs_x264","ffmpeg_vaapi","hevc_ffmpeg_vaapi_tex","hevc_ffmpeg_vaapi","obs_qsv11_v2"]
How Has This Been Tested?
Tested the request/response flow for GoLiveApi
Types of changes
- New feature (non-breaking change which adds functionality)
Checklist:
- [x] My code has been run through clang-format.
- [x] I have read the contributing document.
- [ ] My code is not on the master branch.
- [x] The code has been tested.
- [x] All commit messages are properly formatted and commits squashed where appropriate.
- [x] I have included updates to all appropriate documentation.
I'm not a fan of this. Exposing internal codec ids to an external service feels wrong and encourages ossification. A service that for example supports H264 should not care what codec OBS uses to generate the H264 stream.
I'm not a fan of this. Exposing internal codec ids to an external service feels wrong and encourages ossification. A service that for example supports H264 should not care what codec OBS uses to generate the H264 stream.
Services are required to return the internal encoder id in order to produce a valid response, currently that involves guessing the internal encoder id using the GPU/CPU information
A service that for example supports H264 should not care what codec OBS uses to generate the H264 stream
I completely agree.
A service that for example supports H264 should not care what codec OBS uses to generate the H264 stream
I completely agree.
I disagree. Given that the purpose of the GoLiveAPI is to configure the encoder based on the response, it is necessary for it to specify a given encoder. For example, it is not possible to specify a given preset without knowing whether obs will use x264, nvenc, qsv or amf, all of those have different presets, not to talk of other settings that vary ever more between each encoder.
And if it needs to specify a given encoder, then it should be able to know what encoders can be specified.
I somewhat question why OBS needs a 3rd party API involved in the process to tell it what codec and parameters to use. Can't the logic for selecting these parameters be built into the application? Exposing internals to a 3rd party to let it decide what the program should do seems like a rather backwards way of doing it.
Well, the reality is that this API is currently there. So either the conclusion is that it shouldn't be there, in which case it should be scrapped, or that it does have a relevance in which case this change is, imo beneficial.
I don't think the discussion of whether the whole API should be removed from obs have relevance to this PR, which adresses a flaw in its current existing implementation, which makes it harder to use for services that wish to use it.
Can't the logic for selecting these parameters be built into the application?
No, it can't, because OBS isn't determining what parameters to use, the service is. I do not want to maintain a huge matrix of settings that cannot be updated or modified without our intervention, that is counterproductive to the purpose of the GoLiveAPI.
Currently, the service receives basic hardware and driver version (I think?) info, and infers available encoder options and sends the config back. As far as I'm concerned, this is more than sufficient for someone to build out the supported options matrix on their end, and directly returning available encoders seems redundant. Unless you're returning the entire encoder capabilities (which... no.), you still need to reference the device and driver information to make a determination on what settings are available to apply anyway, so this doesn't give you anything you wouldn't already have.
Sending available encoder IDs allows the service to check that the ID it is returning is indeed a correct one, and to adapt, or gracefully fail with a detailed message if it doesn't.
What we currently have is that if the service sends an ID that is nonexistent, which it has no way of knowing for sure, just presumption, obs fail with an obscure, and severly erroneous message.
Unless the internal encoder IDs are made into a stable API that the service can rely on to not be changed, I think it is reasonable to list those ID to the service.
I suppose that's fair. We've raised this internally to Twitch who should provide comment/insight on this thread when they have time to investigate.
Unless the internal encoder IDs are made into a stable API
This would be great, also you wouldn't need to post so much information about the machine if the version info can be included in the encoder list, if the goal is to determine which encoder prams should be set the version/driver info should be all you need