Implements a parsing mechanism similar to that of an FFmpeg on the command line. Instead of separating options by ';' (key=value;key=value) the custom settings now take things as '-key=value -key=value -key="value with space"'.
A partial escaping of characters is also supported, however it does not modify the actual string. Proper support for escaping may land in a future update.
Fixes#5
Related #12
The function video_output_get_info does not contain rescaling information from the output tab, so by replacing it with obs_encoder_get_width/height we can actually use the scaled resolution.
* Updated the libOBS dependency to 24.0.0. You will need to use OBS Studio 24.0.0 or newer in order to run the plugin.
* Implemented full hardware encoding for all GPU capable encoders (NVENC H264, NVENC H265). This should be perform identical to the OBS included full hardware encoders.
* Reduced the latency for some encoders to be as low as 1 frame, if settings allow. For NVENC, latency is tied to (B-Frames + 1) and Lookahead Frames, whichever is bigger.
* Further improved performance by throwing even less memory away every frame. Almost all memory is now re-used if possible and only released when the encoding is stopped by any means.
* Apple ProRes encoded files should now be remuxable when stored in Matroska (MKV) and survive at least one remuxing. This bug was already fixed in current master FFmpeg, and thanks for discovering this bug go to FRANKIEonPC.
* All color metadata is now set for encoders that support this, such as NVENC. Video players and editors that support this kind of metadata should see an improvement in color quality, especially with 10-bit or higher output.
* Framerate is now set to be fixed, further improving compatibility with players. It was previously left to be guessed by the video player through the timing information.
* Settings are now output to the log file for easier debugging. Please remember to send a log file with any issue you have with the plugin.
The lag in frames is not dictated by the number of threads being used by some encoders. At least for hardware encoders, the expected frame lag in real time encoding is 1 + the number of bframes
This is the last step towards truly efficient encoding on AMD, Nvidia and Intel GPUs. With this we have no software overhead and can directly encode the content that OBS gives us, without going through any intermediate CPU layer. This is effectively what @jp9000 did for the OBS-integrated nvenc, but thanks to FFmpeg it works on all encoders that support D3D11VA acceleration.
With the change, the encoding should now work flawlessly even in very constrained situations (unless OBS itself is being starved of resources). Especially people streaming and recording Ubisoft games will likely see a drastic increase in encoding capability, and thanks to the new options will also be able to get a much higher quality stream and recording with the same hardware.
In current FFmpeg, whenever Matroska with ProRes is demuxed it creates an atom that is just 8 bytes short of the true size necessary.
We can work around this by padding the actual packet by 8 0x00 bytes, which should result in older FFmpeg versions working fine.
An FFmpeg patch is available: http://ffmpeg.org/pipermail/ffmpeg-devel/2019-September/250724.html
Correctly sets all color settings for the context and frames, which should result in better playback in players that support these. Unfortunately it does not fix the bug that VLC and MPC-HC incorrectly assume that the ProRes encoded content is in Partial range, however most editing software does correctly detect it.
Allows overriding color format, encoder info, importing and exporting from/to ffmpeg command line and most importantly logging actual settings to the log file.
Breaks more than intended, and this way is better anyway as the error that used to show up gave no indication as to what went wrong. With this reverted it now shows that starting encoding failed.
Adds support for the full on-GPU encoding path for texture encoding, which just needs to be actually implemented.
In addition this commit also ensures better stability by catching all C/C++ exceptions that could leak to C code which can't handle this at all.
Integrates Github Actions which is much much faster than AppVeyor in all areas, and even supports multiple workflows instead of forcing everything into just one workflow like AppVeyor does. Plus we get 20 parallel builds that nearly instantly finish, which results in much faster feedback without having to run our own Jenkins CI.
The builder and packager scripts have been adjusted to add support for both Windows and Linux, and both AppVeyor and Github Actions. Additionally to that, the builder script now correctly executes x32 and x64 steps in a chain, instead of waiting for the other architecture to finish first. This further reduces build times.
Cristobal E