Rec. 2020 is really an SDR spec, but I think HDR10 made it okay to slap
PQ on it, call it an HDR spec. Rec. 2100 came along after and formally
allowed the use of PQ/HLG, so we should use 2100 instead.
Status output related to OBS configuration is prefixed with the string
"OBS" and added padding for enabled and disabled features. This padding
was not aligned between platforms.
By moving the padding and prefix decoration into its own function,
both elements are controlled in a single place. CMake scripts were
changed to use this new function `obs_status` instead of using CMake's
`message` function directly.
sizeof(AVPacket) being a part of the public ABI is deprecated. once
av_init_packet() is removed, new packets will only be able to be
allocated with av_packet_alloc().
In ffmpeg-mux, ffmpeg-vaapi, and obs-ffmpeg-nvenc, AVPacket is allocated
at the initialization to avoid frequent allocation of AVPacket.
Includes changes to win-dshow.
This reverts commit 4b0767741ab7f3c10d95c96c17a9ac0c0f726ca3,
3f3f9ed7e60a8dbe8c904b234a8b715841df880f,
0e7c17bd6e2f17a6002556ef8229f0b7e2124e91, and
865eecb7396841ccf4b4154b79253f5c8f1a1b76.
Apparently the testing that was done was not sufficient enough or did
not check all test cases, so resolution/fps does not get set properly on
the virtualcam.
This causes the thread to only start when the IMediaFilter::Run/Pause
calls have been made, and stop whenever either the IMediaFilter::Stop
call has been made, or on destruction, whichever comes first.
This potentially will work around a suspected race condition that
appears to be in the WebRTC library where the filter's library will be
released while the filter is in the process of being destroyed, which
can take longer than usual if the join takes too long. Basically, fixes
a reported crash (that doesn't appear to technically be our fault) when
the filter is used with browsers when the virtualcam is deactivating in
web browsers.
This may have been the issue behind the reported firefox crashes, but
strangely, the thread should always be joinable here because it's
explicitly always created in the constructor and joined in the
destructor.
This updates the libdshowcapture submodule to the latest commit.
This also changes win-dshow CMakeList to ensure compatibility.
Full commit list:
- Add support of RGB24 format
- CMake: Add Win32 libs instead of pragma directives.
- Implement FindPin
- Simplify error handling
- Fix log level of DebugHR
- Use default constructor instead of empty function
- Use std::move instead of copy where appropriate
- Mark some strings as const
AVFrame.pkt_pts was deprecated in FFmpeg commit 32c8359093d1 dated June
21, 2016 for lavc 57.24.0 (FFmpeg 3.2). AVFrame.pkt_pts was replaced by
AVFrame.pts, and it was removed in FFmpeg commit 6e30b35b85b8 [2] on
April 27, 2021. Ubuntu 18.04 has the oldest FFmpeg version we support,
FFmpeg 3.4. We should be able to safely migrate from AVFrame.pkt_pts to
AVFrame.pts.
[1]: 32c8359093
[2]: 6e30b35b85
My previous commits would rescale the placeholder for output on every
frame which was not CPU efficient. Now we store a copy of the scaled
placeholder and update it any time the resolution / FPS / format
changes.
A new function GetOutputBufferSize was added to allow calculating the
output size when needed. The existing code assumed a 12-bit format if
the placeholder didn't load, which could cause grey / green output.
An optimization was made to only load and scale the placeholder once
the virtual output starts, as many applications load and unload the
filter multiple times during enumeration of devices.
Various comments were also added to help clarify how the filter works.
The scaler assumed the placeholder was the same size as the camera which
caused crashes if the user replaced the placeholder with a smaller
resolution image (or if the camera was potentially running at > 1080p).
This adds a separate scaler for the placeholder and uses the resolution
of the virtual camera instead of defaulting to 1080p.
Per MSDN: Do not call this function from a DLL that is linked to the static C
run-time library (CRT). The static CRT requires DLL_THREAD_ATTACH and
DLL_THREAD_DETATCH notifications to function properly.
