obs-outputs: Set FLV DTS offset based on first audio or video packet

[derrod]

Description

Ensures that PTS/DTS for audio start at 0 if there by ensuring the DTS offset is based on the first packet that comes in, regardless of whether or not it's video (b-frame delay), or audio (priming sample delay).

Motivation and Context

Fixes #10998

This became necessary due to #10689 and #10690 which fix handling of audio priming samples with negative timestamps. Note that if users have a sufficiently large number of b-frames configured (1 is enough) this currently doesn't actually cause any issues.

How Has This Been Tested?

Logged output packets and ensured the resulting FLV files are playable.

Types of changes

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[Lain-B]

The fact that the first audio packet is 0ms, the second audio packet is -1ms, and the third audio packet is 20ms in the issue report seems a bit concerning, are those three full audio packets or am I misunderstanding something? I know that we merged the code for the encoder delay but is that supposed to be that way? Has it always been that way? I admit I've rarely used/tested CoreAudio personally.

[derrod]

The fact that the first audio packet is 0ms, the second audio packet is -1ms, and the third audio packet is 20ms in the issue report seems a bit concerning, are those three full audio packets or am I misunderstanding something? I know that we merged the code for the encoder delay but is that supposed to be that way? Has it always been that way? I admit I've rarely used/tested CoreAudio personally.

In the issue report they're logging the timestamps of outgoing packets, not incoming ones, so it includes the audio track "header" packet which always has a timestamp of 0. The packets from the actual encoder then start with a negative timestamp.

[tt2468]

It might be a good idea to have a code comment explaining the issue and/or describing the effects. Just so someone in the future can understand why the code exists.

[RytoEX]

Merging as-is based on off-thread discussion. If someone feels the code needs clarified, we can add comments later.