The commit 2fc13540f implemented to copy a video frame into a different
line-size video frame.
However, when the line-size was different, the frame was not correctly
copied.
The existing caption insertion implementation is to add H.264 specific
SEI NALs, because of this we will skip caption insertion unless the
video stream is H.264. This prevents corruption of AV1/HEVC/etc.
We will now keep a per track list of caption data. When caption
insertion is triggered we will add that to the list for each actively
encoding video track. When doing interleaved send, we pull the data
from the caption data for the corresponding video. This ensures that
captions get copied to all video tracks.
Rewrites the `struct video_frame` implementation, resolving a few
hidden bugs, and improving memory alignment reliability. Should also
make it much easier to implement and maintain texture formats in this
part of the codebase.
This is one of the few remaining actions in this repo that was still
using node16. Updating will remove the associated warnings. Also, pin to
the v0.5.0 commit.
Adds the `whip_output_audio` and `whip_output_video` output kinds,
which selectively advertise only video or only audio support.
To use these types, it is effectively the same as with the AV
version. Just create the output, assign your video or audio encoder,
and you're good.
libobs does not have support for "optional" outputs. With an AV output,
if you only assign a video or audio encoder, start will fail.
We used to swap in a buffer with (0,0,0,1) for all vertex colors for
drop shadows and outlines. However, this vertex buffer couldn't be
uploaded separately from the vertex data in OBS, so we were reuploading
the text vertices every frame.
Instead, let's use a uniform for this uniform data and save 500us (or
more when handles are visible), a significant portion of my test scenes
render time.
Pass down texture/host memory choice for fallback encoders. During
fallback we don't (can't) initialize a shared texture pool and should
use the regular host memory path.
This fixes usage on multi-GPU systems, and enables texture encoders.
Calling `set_higher_ts` before offsets are known pollutes
`highest_video_ts` with timestamps that are out of range of actual
timestamps. They're generally somewhere high above 0 until an
offset for all streams is found, where they are then reset to 0 or
slightly below 0 in the presence of b-frames.
`highest_video_ts` also needs to start below 0 for the same reason.
Even with timestamps being reset to close to 0, b-frames will
cause initial DTS to drop below 0, thus we need a value that should
"always" be below any "real" timestamps observed.
`highest_video_ts` tracking now only starts once all input streams
are ready, and is computed based on all buffered packets at that
point.
We had these advances laying around but didn't use them here. Loading
the glyphs from the fonts is extremely slow, so let's avoid that since
we take the time to cache these already.
NV12 and P010 device functions were not exported on all platforms.
Windows was exporting from C files instead. After CMake 3.0 we started
hiding symbols and resolution failed.
These comments do not actually match the color values here:
* (0xff, 0xff, 0xff) is white
* (0xcc, 0xcc, 0xcc) is light gray
Instead of just fixing the comments, use the values from the System
theme and also correct the comments.
Effectively revert 743117f080.
This action began failing recently. Updating the Dockerfile per the
action's repo did not fix this. Unpinning Sphinx fixed it.
We now support the new, modern CMake path on all platforms. Encourage
everyone to migrate by deprecating the legacy CMake path. The legacy
CMake path will be removed in a future update.