Executive summary
HaishinKit/HaishinKit.swift meets our standard for a template or a sample. It scores 75 out of 100 and is rated Strong, and seven of its eight critical findings are security problems in the build pipeline and in its automatic dependency updates.
Every lens scores high enough to be rated Strong, so no single lens holds the score back. The best first step is adding automated security scanning, worth about 7 points. Keeping a changelog comes next, worth about 5 points.
Five pipeline tools are referenced by a changeable name, so the build pipeline can be tampered with. One automatic update takes new releases before a bad one can be spotted, and one secret can leak from the build pipeline. Pinning each tool to an exact version, setting a waiting period for automatic updates and limiting the secret to its own step would close these risks. The set of files in separate parts that keep changing together needs that dependency made explicit.
The product code is 25,023 lines, about €40,000 to rebuild.
Every lens already scores high enough to be rated Strong, so no single lens holds the score back.
New since the last survey: 2 findings
- Supply-chain Provenance & Signing · REDACTED
- Supply-chain Provenance & Signing · REDACTED
Fixed since the last survey: 2 findings
- Supply-chain Provenance & Signing REDACTED
- Supply-chain Provenance & Signing REDACTED
Rebuild cost: about €40,000 · Estimate
| Cost to rebuild | €13,000 to €67,000, for 223 to 707 hours of work, about 0.3 person-years for one engineer |
|---|---|
| Difficulty of the problem | Standard, judged from the kind of software and how it is built. Code that solves a harder problem, such as payments or medical bookings, costs more per line to write. |
| Quality factor | ×1.1 at a score of 75. Better code takes more work to write, so the factor is ×1.0 at a score of 70, lower below it and higher above it. |
| Size | Medium: 25,023 lines of product code |
| What it is not | Not a quotation: nobody has offered to build it for that. Not a valuation: it says nothing about what the business is worth. Not a certified figure: no professional has signed it as one. |
Top priorities
Diagnosis: what the measurements show together
Architecture — module dependency graph
Architecture: which parts of the code depend on which
| uses → | 1 HaishinKit~Network | 2 MoQTHaishinKit~Extension | 3 RTCHaishinKit~Extension | 4 RTCHaishinKit~SDP | 5 RTCHaishinKit~Util | 6 RTMPHaishinKit~Extension | 7 SRTHaishinKit~Util | 8 HaishinKit~Extension | 9 HaishinKit~Session | 10 HaishinKit~ISO | 11 MoQTHaishinKit~ControlMessage | 12 MoQTHaishinKit~DataStream | 13 MoQTHaishinKit | 14 SRTHaishinKit~TS | 15 SRTHaishinKit~Extension | 16 HaishinKit~Util | 17 RTCHaishinKit~RTP | 18 RTMPHaishinKit~Codec | 19 RTCHaishinKit~RTC | 20 RTMPHaishinKit~AMF | 21 RTMPHaishinKit~Util | 22 RTMPHaishinKit~RTMP | 23 HaishinKit~Stream | 24 HaishinKit~Screen | 25 RTCHaishinKit~HTTP | 26 HaishinKit~Mixer | 27 HaishinKit~Codec | 28 HaishinKit~View | 29 SRTHaishinKit~SRT |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 HaishinKit~Network | |||||||||||||||||||||||||||||
| 2 MoQTHaishinKit~Extension | |||||||||||||||||||||||||||||
| 3 RTCHaishinKit~Extension | |||||||||||||||||||||||||||||
| 4 RTCHaishinKit~SDP | |||||||||||||||||||||||||||||
| 5 RTCHaishinKit~Util | |||||||||||||||||||||||||||||
| 6 RTMPHaishinKit~Extension | |||||||||||||||||||||||||||||
| 7 SRTHaishinKit~Util | |||||||||||||||||||||||||||||
| 8 HaishinKit~Extension | 1 | ||||||||||||||||||||||||||||
| 9 HaishinKit~Session | 1 | 4 | 1 | ||||||||||||||||||||||||||
| 10 HaishinKit~ISO | 7 | 1 | 4 | ||||||||||||||||||||||||||
| 11 MoQTHaishinKit~ControlMessage | 15 | 13 | |||||||||||||||||||||||||||
| 12 MoQTHaishinKit~DataStream | 2 | 2 | |||||||||||||||||||||||||||
| 13 MoQTHaishinKit | 2 | 1 | 3 | 3 | 2 | ||||||||||||||||||||||||
| 14 SRTHaishinKit~TS | 31 | 1 | 3 | 1 | 1 | ||||||||||||||||||||||||
| 15 SRTHaishinKit~Extension | 1 | ||||||||||||||||||||||||||||
| 16 HaishinKit~Util | 8 | 1 | |||||||||||||||||||||||||||
| 17 RTCHaishinKit~RTP | 17 | 1 | 2 | ||||||||||||||||||||||||||
| 18 RTMPHaishinKit~Codec | 3 | 4 | |||||||||||||||||||||||||||
| 19 RTCHaishinKit~RTC | 1 | 1 | 18 | 1 | 4 | 1 | 7 | ||||||||||||||||||||||
| 20 RTMPHaishinKit~AMF | 1 | 3 | |||||||||||||||||||||||||||
| 21 RTMPHaishinKit~Util | 4 | 1 | |||||||||||||||||||||||||||
| 22 RTMPHaishinKit~RTMP | 6 | 5 | 28 | 5 | 3 | 1 | 2 | 1 | 5 | 1 | 3 | ||||||||||||||||||
| 23 HaishinKit~Stream | 3 | 1 | 23 | 3 | 2 | 1 | 1 | 2 | 10 | ||||||||||||||||||||
| 24 HaishinKit~Screen | 3 | 17 | 1 | 2 | 1 | 3 | |||||||||||||||||||||||
| 25 RTCHaishinKit~HTTP | 2 | 6 | 11 | 1 | |||||||||||||||||||||||||
| 26 HaishinKit~Mixer | 50 | 4 | 2 | 2 | |||||||||||||||||||||||||
| 27 HaishinKit~Codec | 8 | 2 | 1 | 1 | |||||||||||||||||||||||||
| 28 HaishinKit~View | 12 | 2 | 2 | 2 | 2 | ||||||||||||||||||||||||
| 29 SRTHaishinKit~SRT | 5 | 4 | 1 | 9 | 5 | 2 | 1 | 5 | 1 | 3 |
8→27 HaishinKit~Extension uses HaishinKit~Codec part of a loop✕
- Connections
- 1 pair of types, where a type in HaishinKit~Extension uses a type in HaishinKit~Codec.
- The types involved
HaishinKit~Extension.AVCaptureDevice→HaishinKit~Codec.Format
- Direction
- HaishinKit~Extension uses HaishinKit~Codec, so a change to HaishinKit~Codec can break HaishinKit~Extension, while a change to HaishinKit~Extension can't break HaishinKit~Codec.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
9→1 HaishinKit~Session uses HaishinKit~Network✕
- Connections
- 1 pair of types, where a type in HaishinKit~Session uses a type in HaishinKit~Network.
- The types involved
HaishinKit~Session.StreamSession→HaishinKit~Network.NetworkConnection
- Direction
- HaishinKit~Session uses HaishinKit~Network, so a change to HaishinKit~Network can break HaishinKit~Session, while a change to HaishinKit~Session can't break HaishinKit~Network.
- Position
- Below the diagonal: HaishinKit~Session uses a module listed above it, which is the healthy direction.
9→6 HaishinKit~Session uses RTMPHaishinKit~Extension✕
- Connections
- 4 pairs of types, where a type in HaishinKit~Session uses a type in RTMPHaishinKit~Extension.
- The types involved
HaishinKit~Session.StreamSession→RTMPHaishinKit~Extension.URLHaishinKit~Session.StreamSessionBuilder→RTMPHaishinKit~Extension.URLHaishinKit~Session.StreamSessionBuilderFactory→RTMPHaishinKit~Extension.URLHaishinKit~Session.StreamSessionFactory→RTMPHaishinKit~Extension.URL
- Direction
- HaishinKit~Session uses RTMPHaishinKit~Extension, so a change to RTMPHaishinKit~Extension can break HaishinKit~Session, while a change to HaishinKit~Session can't break RTMPHaishinKit~Extension.
- Position
- Below the diagonal: HaishinKit~Session uses a module listed above it, which is the healthy direction.
9→23 HaishinKit~Session uses HaishinKit~Stream part of a loop✕
- Connections
- 1 pair of types, where a type in HaishinKit~Session uses a type in HaishinKit~Stream.
- The types involved
HaishinKit~Session.StreamSession→HaishinKit~Stream.StreamConvertible
- Direction
- HaishinKit~Session uses HaishinKit~Stream, so a change to HaishinKit~Stream can break HaishinKit~Session, while a change to HaishinKit~Session can't break HaishinKit~Stream.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
10→8 HaishinKit~ISO uses HaishinKit~Extension✕
- Connections
- 7 pairs of types, where a type in HaishinKit~ISO uses a type in HaishinKit~Extension.
- The types involved
HaishinKit~ISO.AudioSpecificConfig→HaishinKit~Extension.DataHaishinKit~ISO.H264NALUnit→HaishinKit~Extension.DataHaishinKit~ISO.HEVCNALUnit→HaishinKit~Extension.DataHaishinKit~ISO.ISOTypeBufferUtil→HaishinKit~Extension.DataHaishinKit~ISO.NALUnit→HaishinKit~Extension.DataHaishinKit~ISO.NALUnitReader→HaishinKit~Extension.CMSampleBufferHaishinKit~ISO.NALUnitReader→HaishinKit~Extension.Data
- Direction
- HaishinKit~ISO uses HaishinKit~Extension, so a change to HaishinKit~Extension can break HaishinKit~ISO, while a change to HaishinKit~ISO can't break HaishinKit~Extension.
- Position
- Below the diagonal: HaishinKit~ISO uses a module listed above it, which is the healthy direction.
10→14 HaishinKit~ISO uses SRTHaishinKit~TS part of a loop✕
- Connections
- 1 pair of types, where a type in HaishinKit~ISO uses a type in SRTHaishinKit~TS.
- The types involved
HaishinKit~ISO.NALUnitReader→SRTHaishinKit~TS.ESStreamType
- Direction
- HaishinKit~ISO uses SRTHaishinKit~TS, so a change to SRTHaishinKit~TS can break HaishinKit~ISO, while a change to HaishinKit~ISO can't break SRTHaishinKit~TS.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
10→15 HaishinKit~ISO uses SRTHaishinKit~Extension part of a loop✕
- Connections
- 4 pairs of types, where a type in HaishinKit~ISO uses a type in SRTHaishinKit~Extension.
- The types involved
HaishinKit~ISO.AudioSpecificConfig→SRTHaishinKit~Extension.CMFormatDescriptionHaishinKit~ISO.H264NALUnit→SRTHaishinKit~Extension.CMFormatDescriptionHaishinKit~ISO.HEVCNALUnit→SRTHaishinKit~Extension.CMFormatDescriptionHaishinKit~ISO.NALUnitReader→SRTHaishinKit~Extension.CMFormatDescription
- Direction
- HaishinKit~ISO uses SRTHaishinKit~Extension, so a change to SRTHaishinKit~Extension can break HaishinKit~ISO, while a change to HaishinKit~ISO can't break SRTHaishinKit~Extension.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
11→8 MoQTHaishinKit~ControlMessage uses HaishinKit~Extension✕
- Connections
- 15 pairs of types, where a type in MoQTHaishinKit~ControlMessage uses a type in HaishinKit~Extension.
- The types involved
MoQTHaishinKit~ControlMessage.MoQTAnnounce→HaishinKit~Extension.DataMoQTHaishinKit~ControlMessage.MoQTAnnounceError→HaishinKit~Extension.DataMoQTHaishinKit~ControlMessage.MoQTAnnounceOk→HaishinKit~Extension.DataMoQTHaishinKit~ControlMessage.MoQTClientSetup→HaishinKit~Extension.DataMoQTHaishinKit~ControlMessage.MoQTControlMessage→HaishinKit~Extension.DataMoQTHaishinKit~ControlMessage.MoQTGoaway→HaishinKit~Extension.DataMoQTHaishinKit~ControlMessage.MoQTServerSetup→HaishinKit~Extension.DataMoQTHaishinKit~ControlMessage.MoQTSetupParameter→HaishinKit~Extension.DataMoQTHaishinKit~ControlMessage.MoQTSubscribe→HaishinKit~Extension.DataMoQTHaishinKit~ControlMessage.MoQTSubscribeAnnounces→HaishinKit~Extension.DataMoQTHaishinKit~ControlMessage.MoQTSubscribeAnnouncesError→HaishinKit~Extension.DataMoQTHaishinKit~ControlMessage.MoQTSubscribeAnnouncesOk→HaishinKit~Extension.DataMoQTHaishinKit~ControlMessage.MoQTSubscribeError→HaishinKit~Extension.DataMoQTHaishinKit~ControlMessage.MoQTSubscribeOk→HaishinKit~Extension.DataMoQTHaishinKit~ControlMessage.MoQTVersionSpecificParameter→HaishinKit~Extension.Data
- Direction
- MoQTHaishinKit~ControlMessage uses HaishinKit~Extension, so a change to HaishinKit~Extension can break MoQTHaishinKit~ControlMessage, while a change to MoQTHaishinKit~ControlMessage can't break HaishinKit~Extension.
- Position
- Below the diagonal: MoQTHaishinKit~ControlMessage uses a module listed above it, which is the healthy direction.
11→13 MoQTHaishinKit~ControlMessage uses MoQTHaishinKit part of a loop✕
- Connections
- 13 pairs of types, where a type in MoQTHaishinKit~ControlMessage uses a type in MoQTHaishinKit.
- The types involved
MoQTHaishinKit~ControlMessage.MoQTAnnounceError→MoQTHaishinKit.MoQTPayloadMoQTHaishinKit~ControlMessage.MoQTAnnounceOk→MoQTHaishinKit.MoQTPayloadMoQTHaishinKit~ControlMessage.MoQTClientSetup→MoQTHaishinKit.MoQTVersionMoQTHaishinKit~ControlMessage.MoQTGoaway→MoQTHaishinKit.MoQTPayloadMoQTHaishinKit~ControlMessage.MoQTMessageType→MoQTHaishinKit.MoQTPayloadMoQTHaishinKit~ControlMessage.MoQTServerSetup→MoQTHaishinKit.MoQTPayloadMoQTHaishinKit~ControlMessage.MoQTSetupParameter→MoQTHaishinKit.MoQTPayloadMoQTHaishinKit~ControlMessage.MoQTSubscribe→MoQTHaishinKit.MoQTPayloadMoQTHaishinKit~ControlMessage.MoQTSubscribeAnnouncesError→MoQTHaishinKit.MoQTPayloadMoQTHaishinKit~ControlMessage.MoQTSubscribeAnnouncesOk→MoQTHaishinKit.MoQTPayloadMoQTHaishinKit~ControlMessage.MoQTSubscribeError→MoQTHaishinKit.MoQTPayloadMoQTHaishinKit~ControlMessage.MoQTSubscribeOk→MoQTHaishinKit.MoQTPayloadMoQTHaishinKit~ControlMessage.MoQTVersionSpecificParameter→MoQTHaishinKit.MoQTPayload
- Direction
- MoQTHaishinKit~ControlMessage uses MoQTHaishinKit, so a change to MoQTHaishinKit can break MoQTHaishinKit~ControlMessage, while a change to MoQTHaishinKit~ControlMessage can't break MoQTHaishinKit.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
12→8 MoQTHaishinKit~DataStream uses HaishinKit~Extension✕
- Connections
- 2 pairs of types, where a type in MoQTHaishinKit~DataStream uses a type in HaishinKit~Extension.
- The types involved
MoQTHaishinKit~DataStream.MoQTObject→HaishinKit~Extension.DataMoQTHaishinKit~DataStream.MoQTStreamHeaderSubgroup→HaishinKit~Extension.Data
- Direction
- MoQTHaishinKit~DataStream uses HaishinKit~Extension, so a change to HaishinKit~Extension can break MoQTHaishinKit~DataStream, while a change to MoQTHaishinKit~DataStream can't break HaishinKit~Extension.
- Position
- Below the diagonal: MoQTHaishinKit~DataStream uses a module listed above it, which is the healthy direction.
12→13 MoQTHaishinKit~DataStream uses MoQTHaishinKit part of a loop✕
- Connections
- 2 pairs of types, where a type in MoQTHaishinKit~DataStream uses a type in MoQTHaishinKit.
- The types involved
MoQTHaishinKit~DataStream.MoQTObject→MoQTHaishinKit.MoQTPayloadMoQTHaishinKit~DataStream.MoQTStreamHeaderSubgroup→MoQTHaishinKit.MoQTPayload
- Direction
- MoQTHaishinKit~DataStream uses MoQTHaishinKit, so a change to MoQTHaishinKit can break MoQTHaishinKit~DataStream, while a change to MoQTHaishinKit~DataStream can't break MoQTHaishinKit.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
13→1 MoQTHaishinKit uses HaishinKit~Network✕
- Connections
- 2 pairs of types, where a type in MoQTHaishinKit uses a type in HaishinKit~Network.
- The types involved
MoQTHaishinKit.MoQTSocket→HaishinKit~Network.NetworkMonitorMoQTHaishinKit.MoQTSocket→HaishinKit~Network.NetworkTransportReport
- Direction
- MoQTHaishinKit uses HaishinKit~Network, so a change to HaishinKit~Network can break MoQTHaishinKit, while a change to MoQTHaishinKit can't break HaishinKit~Network.
- Position
- Below the diagonal: MoQTHaishinKit uses a module listed above it, which is the healthy direction.
13→2 MoQTHaishinKit uses MoQTHaishinKit~Extension✕
- Connections
- 1 pair of types, where a type in MoQTHaishinKit uses a type in MoQTHaishinKit~Extension.
- The types involved
MoQTHaishinKit.MoQTSocket→MoQTHaishinKit~Extension.Options
- Direction
- MoQTHaishinKit uses MoQTHaishinKit~Extension, so a change to MoQTHaishinKit~Extension can break MoQTHaishinKit, while a change to MoQTHaishinKit can't break MoQTHaishinKit~Extension.
- Position
- Below the diagonal: MoQTHaishinKit uses a module listed above it, which is the healthy direction.
13→8 MoQTHaishinKit uses HaishinKit~Extension✕
- Connections
- 3 pairs of types, where a type in MoQTHaishinKit uses a type in HaishinKit~Extension.
- The types involved
MoQTHaishinKit.MoQTConnection→HaishinKit~Extension.DataMoQTHaishinKit.MoQTPayload→HaishinKit~Extension.DataMoQTHaishinKit.MoQTSocket→HaishinKit~Extension.Data
- Direction
- MoQTHaishinKit uses HaishinKit~Extension, so a change to HaishinKit~Extension can break MoQTHaishinKit, while a change to MoQTHaishinKit can't break HaishinKit~Extension.
- Position
- Below the diagonal: MoQTHaishinKit uses a module listed above it, which is the healthy direction.
13→11 MoQTHaishinKit uses MoQTHaishinKit~ControlMessage✕
- Connections
- 3 pairs of types, where a type in MoQTHaishinKit uses a type in MoQTHaishinKit~ControlMessage.
- The types involved
MoQTHaishinKit.MoQTConnection→MoQTHaishinKit~ControlMessage.MoQTControlMessageMoQTHaishinKit.MoQTConnection→MoQTHaishinKit~ControlMessage.MoQTServerSetupMoQTHaishinKit.MoQTConnection→MoQTHaishinKit~ControlMessage.MoQTSetupRole
- Direction
- MoQTHaishinKit uses MoQTHaishinKit~ControlMessage, so a change to MoQTHaishinKit~ControlMessage can break MoQTHaishinKit, while a change to MoQTHaishinKit can't break MoQTHaishinKit~ControlMessage.
- Position
- Below the diagonal: MoQTHaishinKit uses a module listed above it, which is the healthy direction.
13→12 MoQTHaishinKit uses MoQTHaishinKit~DataStream✕
- Connections
- 2 pairs of types, where a type in MoQTHaishinKit uses a type in MoQTHaishinKit~DataStream.
- The types involved
MoQTHaishinKit.MoQTConnection→MoQTHaishinKit~DataStream.MoQTObjectMoQTHaishinKit.MoQTConnection→MoQTHaishinKit~DataStream.MoQTStreamHeaderSubgroup
- Direction
- MoQTHaishinKit uses MoQTHaishinKit~DataStream, so a change to MoQTHaishinKit~DataStream can break MoQTHaishinKit, while a change to MoQTHaishinKit can't break MoQTHaishinKit~DataStream.
- Position
- Below the diagonal: MoQTHaishinKit uses a module listed above it, which is the healthy direction.
14→8 SRTHaishinKit~TS uses HaishinKit~Extension✕
- Connections
- 31 pairs of types, where a type in SRTHaishinKit~TS uses a type in HaishinKit~Extension. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
SRTHaishinKit~TS.ADTSReader→HaishinKit~Extension.DataSRTHaishinKit~TS.ADTSReaderIterator→HaishinKit~Extension.DataSRTHaishinKit~TS.ByteArray→HaishinKit~Extension.DataSRTHaishinKit~TS.ByteArrayConvertible→HaishinKit~Extension.DataSRTHaishinKit~TS.CRC32→HaishinKit~Extension.DataSRTHaishinKit~TS.ESSpecificData→HaishinKit~Extension.DataSRTHaishinKit~TS.PESOptionalHeader→HaishinKit~Extension.CMTimeSRTHaishinKit~TS.PESOptionalHeader→HaishinKit~Extension.DataSRTHaishinKit~TS.PESPacketHeader→HaishinKit~Extension.DataSRTHaishinKit~TS.PacketizedElementaryStream→HaishinKit~Extension.AVAudioCompressedBufferSRTHaishinKit~TS.PacketizedElementaryStream→HaishinKit~Extension.AVAudioTimeSRTHaishinKit~TS.PacketizedElementaryStream→HaishinKit~Extension.CMSampleBufferSRTHaishinKit~TS.PacketizedElementaryStream→HaishinKit~Extension.CMTimeSRTHaishinKit~TS.PacketizedElementaryStream→HaishinKit~Extension.DataSRTHaishinKit~TS.TSAdaptationExtensionField→HaishinKit~Extension.DataSRTHaishinKit~TS.TSAdaptationField→HaishinKit~Extension.DataSRTHaishinKit~TS.TSPSIPointer→HaishinKit~Extension.DataSRTHaishinKit~TS.TSPSITableSyntax→HaishinKit~Extension.DataSRTHaishinKit~TS.TSPacket→HaishinKit~Extension.DataSRTHaishinKit~TS.TSProgram→HaishinKit~Extension.DataSRTHaishinKit~TS.TSProgramAssociation→HaishinKit~Extension.DataSRTHaishinKit~TS.TSProgramClockReference→HaishinKit~Extension.DataSRTHaishinKit~TS.TSProgramMap→HaishinKit~Extension.DataSRTHaishinKit~TS.TSReader→HaishinKit~Extension.CMSampleBufferSRTHaishinKit~TS.TSReader→HaishinKit~Extension.Data
- Direction
- SRTHaishinKit~TS uses HaishinKit~Extension, so a change to HaishinKit~Extension can break SRTHaishinKit~TS, while a change to SRTHaishinKit~TS can't break HaishinKit~Extension.
- Position
- Below the diagonal: SRTHaishinKit~TS uses a module listed above it, which is the healthy direction.
14→10 SRTHaishinKit~TS uses HaishinKit~ISO✕
- Connections
- 1 pair of types, where a type in SRTHaishinKit~TS uses a type in HaishinKit~ISO.
- The types involved
SRTHaishinKit~TS.TSReader→HaishinKit~ISO.NALUnitReader
- Direction
- SRTHaishinKit~TS uses HaishinKit~ISO, so a change to HaishinKit~ISO can break SRTHaishinKit~TS, while a change to SRTHaishinKit~TS can't break HaishinKit~ISO.
- Position
- Below the diagonal: SRTHaishinKit~TS uses a module listed above it, which is the healthy direction.
14→15 SRTHaishinKit~TS uses SRTHaishinKit~Extension part of a loop✕
- Connections
- 3 pairs of types, where a type in SRTHaishinKit~TS uses a type in SRTHaishinKit~Extension.
- The types involved
SRTHaishinKit~TS.PacketizedElementaryStream→SRTHaishinKit~Extension.CMFormatDescriptionSRTHaishinKit~TS.TSReader→SRTHaishinKit~Extension.CMFormatDescriptionSRTHaishinKit~TS.TSWriter→SRTHaishinKit~Extension.CMFormatDescription
- Direction
- SRTHaishinKit~TS uses SRTHaishinKit~Extension, so a change to SRTHaishinKit~Extension can break SRTHaishinKit~TS, while a change to SRTHaishinKit~TS can't break SRTHaishinKit~Extension.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
14→16 SRTHaishinKit~TS uses HaishinKit~Util part of a loop✕
- Connections
- 1 pair of types, where a type in SRTHaishinKit~TS uses a type in HaishinKit~Util.
- The types involved
SRTHaishinKit~TS.ByteArray→HaishinKit~Util.ByteArrayConvertible
- Direction
- SRTHaishinKit~TS uses HaishinKit~Util, so a change to HaishinKit~Util can break SRTHaishinKit~TS, while a change to SRTHaishinKit~TS can't break HaishinKit~Util.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
14→27 SRTHaishinKit~TS uses HaishinKit~Codec part of a loop✕
- Connections
- 1 pair of types, where a type in SRTHaishinKit~TS uses a type in HaishinKit~Codec.
- The types involved
SRTHaishinKit~TS.ADTSReaderIterator→HaishinKit~Codec.ADTSHeader
- Direction
- SRTHaishinKit~TS uses HaishinKit~Codec, so a change to HaishinKit~Codec can break SRTHaishinKit~TS, while a change to SRTHaishinKit~TS can't break HaishinKit~Codec.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
15→14 SRTHaishinKit~Extension uses SRTHaishinKit~TS✕
- Connections
- 1 pair of types, where a type in SRTHaishinKit~Extension uses a type in SRTHaishinKit~TS.
- The types involved
SRTHaishinKit~Extension.CMFormatDescription→SRTHaishinKit~TS.ESStreamType
- Direction
- SRTHaishinKit~Extension uses SRTHaishinKit~TS, so a change to SRTHaishinKit~TS can break SRTHaishinKit~Extension, while a change to SRTHaishinKit~Extension can't break SRTHaishinKit~TS.
- Position
- Below the diagonal: SRTHaishinKit~Extension uses a module listed above it, which is the healthy direction.
16→8 HaishinKit~Util uses HaishinKit~Extension✕
- Connections
- 8 pairs of types, where a type in HaishinKit~Util uses a type in HaishinKit~Extension.
- The types involved
HaishinKit~Util.AudioTime→HaishinKit~Extension.AVAudioTimeHaishinKit~Util.AudioTime→HaishinKit~Extension.CMTimeHaishinKit~Util.ByteArray→HaishinKit~Extension.DataHaishinKit~Util.ByteArrayConvertible→HaishinKit~Extension.DataHaishinKit~Util.DataConvertible→HaishinKit~Extension.DataHaishinKit~Util.FrameTracker→HaishinKit~Extension.CMTimeHaishinKit~Util.TypedBlockQueue→HaishinKit~Extension.CMSampleBufferHaishinKit~Util.TypedBlockQueue→HaishinKit~Extension.CMTime
- Direction
- HaishinKit~Util uses HaishinKit~Extension, so a change to HaishinKit~Extension can break HaishinKit~Util, while a change to HaishinKit~Util can't break HaishinKit~Extension.
- Position
- Below the diagonal: HaishinKit~Util uses a module listed above it, which is the healthy direction.
16→15 HaishinKit~Util uses SRTHaishinKit~Extension✕
- Connections
- 1 pair of types, where a type in HaishinKit~Util uses a type in SRTHaishinKit~Extension.
- The types involved
HaishinKit~Util.AVAudioUtil→SRTHaishinKit~Extension.CMFormatDescription
- Direction
- HaishinKit~Util uses SRTHaishinKit~Extension, so a change to SRTHaishinKit~Extension can break HaishinKit~Util, while a change to HaishinKit~Util can't break SRTHaishinKit~Extension.
- Position
- Below the diagonal: HaishinKit~Util uses a module listed above it, which is the healthy direction.
17→8 RTCHaishinKit~RTP uses HaishinKit~Extension✕
- Connections
- 17 pairs of types, where a type in RTCHaishinKit~RTP uses a type in HaishinKit~Extension.
- The types involved
RTCHaishinKit~RTP.RTPH264Packetizer→HaishinKit~Extension.AVAudioCompressedBufferRTCHaishinKit~RTP.RTPH264Packetizer→HaishinKit~Extension.AVAudioTimeRTCHaishinKit~RTP.RTPH264Packetizer→HaishinKit~Extension.CMSampleBufferRTCHaishinKit~RTP.RTPH264Packetizer→HaishinKit~Extension.DataRTCHaishinKit~RTP.RTPOpusPacketizer→HaishinKit~Extension.AVAudioCompressedBufferRTCHaishinKit~RTP.RTPOpusPacketizer→HaishinKit~Extension.AVAudioTimeRTCHaishinKit~RTP.RTPOpusPacketizer→HaishinKit~Extension.CMSampleBufferRTCHaishinKit~RTP.RTPPacket→HaishinKit~Extension.AVAudioCompressedBufferRTCHaishinKit~RTP.RTPPacket→HaishinKit~Extension.DataRTCHaishinKit~RTP.RTPPacketizer→HaishinKit~Extension.AVAudioCompressedBufferRTCHaishinKit~RTP.RTPPacketizer→HaishinKit~Extension.AVAudioTimeRTCHaishinKit~RTP.RTPPacketizer→HaishinKit~Extension.CMSampleBufferRTCHaishinKit~RTP.RTPPacketizerDelegate→HaishinKit~Extension.AVAudioCompressedBufferRTCHaishinKit~RTP.RTPPacketizerDelegate→HaishinKit~Extension.AVAudioTimeRTCHaishinKit~RTP.RTPPacketizerDelegate→HaishinKit~Extension.CMSampleBufferRTCHaishinKit~RTP.RTPTimestamp→HaishinKit~Extension.AVAudioTimeRTCHaishinKit~RTP.RTPTimestamp→HaishinKit~Extension.CMTime
- Direction
- RTCHaishinKit~RTP uses HaishinKit~Extension, so a change to HaishinKit~Extension can break RTCHaishinKit~RTP, while a change to RTCHaishinKit~RTP can't break HaishinKit~Extension.
- Position
- Below the diagonal: RTCHaishinKit~RTP uses a module listed above it, which is the healthy direction.
17→10 RTCHaishinKit~RTP uses HaishinKit~ISO✕
- Connections
- 1 pair of types, where a type in RTCHaishinKit~RTP uses a type in HaishinKit~ISO.
- The types involved
RTCHaishinKit~RTP.RTPH264Packetizer→HaishinKit~ISO.NALUnitReader
- Direction
- RTCHaishinKit~RTP uses HaishinKit~ISO, so a change to HaishinKit~ISO can break RTCHaishinKit~RTP, while a change to RTCHaishinKit~RTP can't break HaishinKit~ISO.
- Position
- Below the diagonal: RTCHaishinKit~RTP uses a module listed above it, which is the healthy direction.
17→15 RTCHaishinKit~RTP uses SRTHaishinKit~Extension✕
- Connections
- 2 pairs of types, where a type in RTCHaishinKit~RTP uses a type in SRTHaishinKit~Extension.
- The types involved
RTCHaishinKit~RTP.RTPH264Packetizer→SRTHaishinKit~Extension.CMFormatDescriptionRTCHaishinKit~RTP.RTPOpusPacketizer→SRTHaishinKit~Extension.CMFormatDescription
- Direction
- RTCHaishinKit~RTP uses SRTHaishinKit~Extension, so a change to SRTHaishinKit~Extension can break RTCHaishinKit~RTP, while a change to RTCHaishinKit~RTP can't break SRTHaishinKit~Extension.
- Position
- Below the diagonal: RTCHaishinKit~RTP uses a module listed above it, which is the healthy direction.
18→8 RTMPHaishinKit~Codec uses HaishinKit~Extension✕
- Connections
- 3 pairs of types, where a type in RTMPHaishinKit~Codec uses a type in HaishinKit~Extension.
- The types involved
RTMPHaishinKit~Codec.AVCDecoderConfigurationRecord→HaishinKit~Extension.DataRTMPHaishinKit~Codec.HEVCDecoderConfigurationRecord→HaishinKit~Extension.DataRTMPHaishinKit~Codec.OpusHeaderPacket→HaishinKit~Extension.Data
- Direction
- RTMPHaishinKit~Codec uses HaishinKit~Extension, so a change to HaishinKit~Extension can break RTMPHaishinKit~Codec, while a change to RTMPHaishinKit~Codec can't break HaishinKit~Extension.
- Position
- Below the diagonal: RTMPHaishinKit~Codec uses a module listed above it, which is the healthy direction.
18→15 RTMPHaishinKit~Codec uses SRTHaishinKit~Extension✕
- Connections
- 4 pairs of types, where a type in RTMPHaishinKit~Codec uses a type in SRTHaishinKit~Extension.
- The types involved
RTMPHaishinKit~Codec.AVCDecoderConfigurationRecord→SRTHaishinKit~Extension.CMFormatDescriptionRTMPHaishinKit~Codec.DecoderConfigurationRecord→SRTHaishinKit~Extension.CMFormatDescriptionRTMPHaishinKit~Codec.HEVCDecoderConfigurationRecord→SRTHaishinKit~Extension.CMFormatDescriptionRTMPHaishinKit~Codec.OpusHeaderPacket→SRTHaishinKit~Extension.CMFormatDescription
- Direction
- RTMPHaishinKit~Codec uses SRTHaishinKit~Extension, so a change to SRTHaishinKit~Extension can break RTMPHaishinKit~Codec, while a change to RTMPHaishinKit~Codec can't break SRTHaishinKit~Extension.
- Position
- Below the diagonal: RTMPHaishinKit~Codec uses a module listed above it, which is the healthy direction.
19→1 RTCHaishinKit~RTC uses HaishinKit~Network✕
- Connections
- 1 pair of types, where a type in RTCHaishinKit~RTC uses a type in HaishinKit~Network.
- The types involved
RTCHaishinKit~RTC.RTCStream→HaishinKit~Network.NetworkMonitorEvent
- Direction
- RTCHaishinKit~RTC uses HaishinKit~Network, so a change to HaishinKit~Network can break RTCHaishinKit~RTC, while a change to RTCHaishinKit~RTC can't break HaishinKit~Network.
- Position
- Below the diagonal: RTCHaishinKit~RTC uses a module listed above it, which is the healthy direction.
19→4 RTCHaishinKit~RTC uses RTCHaishinKit~SDP✕
- Connections
- 1 pair of types, where a type in RTCHaishinKit~RTC uses a type in RTCHaishinKit~SDP.
- The types involved
RTCHaishinKit~RTC.RTCPeerConnection→RTCHaishinKit~SDP.SDPSessionDescriptionType
- Direction
- RTCHaishinKit~RTC uses RTCHaishinKit~SDP, so a change to RTCHaishinKit~SDP can break RTCHaishinKit~RTC, while a change to RTCHaishinKit~RTC can't break RTCHaishinKit~SDP.
- Position
- Below the diagonal: RTCHaishinKit~RTC uses a module listed above it, which is the healthy direction.
19→8 RTCHaishinKit~RTC uses HaishinKit~Extension✕
- Connections
- 18 pairs of types, where a type in RTCHaishinKit~RTC uses a type in HaishinKit~Extension.
- The types involved
RTCHaishinKit~RTC.RTCChannel→HaishinKit~Extension.DataRTCHaishinKit~RTC.RTCDataChannel→HaishinKit~Extension.DataRTCHaishinKit~RTC.RTCDataChannelDelegate→HaishinKit~Extension.DataRTCHaishinKit~RTC.RTCSendableStreamTrack→HaishinKit~Extension.AVAudioCompressedBufferRTCHaishinKit~RTC.RTCSendableStreamTrack→HaishinKit~Extension.AVAudioTimeRTCHaishinKit~RTC.RTCSendableStreamTrack→HaishinKit~Extension.CMSampleBufferRTCHaishinKit~RTC.RTCStream→HaishinKit~Extension.AVAudioBufferRTCHaishinKit~RTC.RTCStream→HaishinKit~Extension.AVAudioCompressedBufferRTCHaishinKit~RTC.RTCStream→HaishinKit~Extension.AVAudioPCMBufferRTCHaishinKit~RTC.RTCStream→HaishinKit~Extension.AVAudioTimeRTCHaishinKit~RTC.RTCStream→HaishinKit~Extension.CMSampleBufferRTCHaishinKit~RTC.RTCTrack→HaishinKit~Extension.AVAudioCompressedBufferRTCHaishinKit~RTC.RTCTrack→HaishinKit~Extension.AVAudioTimeRTCHaishinKit~RTC.RTCTrack→HaishinKit~Extension.CMSampleBufferRTCHaishinKit~RTC.RTCTrack→HaishinKit~Extension.DataRTCHaishinKit~RTC.RTCTrackDelegate→HaishinKit~Extension.AVAudioCompressedBufferRTCHaishinKit~RTC.RTCTrackDelegate→HaishinKit~Extension.AVAudioTimeRTCHaishinKit~RTC.RTCTrackDelegate→HaishinKit~Extension.CMSampleBuffer
- Direction
- RTCHaishinKit~RTC uses HaishinKit~Extension, so a change to HaishinKit~Extension can break RTCHaishinKit~RTC, while a change to RTCHaishinKit~RTC can't break HaishinKit~Extension.
- Position
- Below the diagonal: RTCHaishinKit~RTC uses a module listed above it, which is the healthy direction.
19→17 RTCHaishinKit~RTC uses RTCHaishinKit~RTP✕
- Connections
- 1 pair of types, where a type in RTCHaishinKit~RTC uses a type in RTCHaishinKit~RTP.
- The types involved
RTCHaishinKit~RTC.RTCTrack→RTCHaishinKit~RTP.RTPPacketizer
- Direction
- RTCHaishinKit~RTC uses RTCHaishinKit~RTP, so a change to RTCHaishinKit~RTP can break RTCHaishinKit~RTC, while a change to RTCHaishinKit~RTC can't break RTCHaishinKit~RTP.
- Position
- Below the diagonal: RTCHaishinKit~RTC uses a module listed above it, which is the healthy direction.
19→23 RTCHaishinKit~RTC uses HaishinKit~Stream part of a loop✕
- Connections
- 4 pairs of types, where a type in RTCHaishinKit~RTC uses a type in HaishinKit~Stream.
- The types involved
RTCHaishinKit~RTC.RTCStream→HaishinKit~Stream.IncomingStreamRTCHaishinKit~RTC.RTCStream→HaishinKit~Stream.OutgoingStreamRTCHaishinKit~RTC.RTCStream→HaishinKit~Stream.StreamOutputRTCHaishinKit~RTC.RTCStream→HaishinKit~Stream.StreamReadyState
- Direction
- RTCHaishinKit~RTC uses HaishinKit~Stream, so a change to HaishinKit~Stream can break RTCHaishinKit~RTC, while a change to RTCHaishinKit~RTC can't break HaishinKit~Stream.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
19→26 RTCHaishinKit~RTC uses HaishinKit~Mixer part of a loop✕
- Connections
- 1 pair of types, where a type in RTCHaishinKit~RTC uses a type in HaishinKit~Mixer.
- The types involved
RTCHaishinKit~RTC.RTCStream→HaishinKit~Mixer.MediaMixer
- Direction
- RTCHaishinKit~RTC uses HaishinKit~Mixer, so a change to HaishinKit~Mixer can break RTCHaishinKit~RTC, while a change to RTCHaishinKit~RTC can't break HaishinKit~Mixer.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
19→27 RTCHaishinKit~RTC uses HaishinKit~Codec part of a loop✕
- Connections
- 7 pairs of types, where a type in RTCHaishinKit~RTC uses a type in HaishinKit~Codec.
- The types involved
RTCHaishinKit~RTC.AudioStreamTrack→HaishinKit~Codec.AudioCodecSettingsRTCHaishinKit~RTC.RTCStream→HaishinKit~Codec.AudioCodecSettingsRTCHaishinKit~RTC.RTCStream→HaishinKit~Codec.FormatRTCHaishinKit~RTC.RTCStream→HaishinKit~Codec.VideoCodecSettingsRTCHaishinKit~RTC.RTCTrackConfiguration→HaishinKit~Codec.AudioCodecSettingsRTCHaishinKit~RTC.RTCTrackConfiguration→HaishinKit~Codec.VideoCodecSettingsRTCHaishinKit~RTC.VideoStreamTrack→HaishinKit~Codec.VideoCodecSettings
- Direction
- RTCHaishinKit~RTC uses HaishinKit~Codec, so a change to HaishinKit~Codec can break RTCHaishinKit~RTC, while a change to RTCHaishinKit~RTC can't break HaishinKit~Codec.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
20→8 RTMPHaishinKit~AMF uses HaishinKit~Extension✕
- Connections
- 1 pair of types, where a type in RTMPHaishinKit~AMF uses a type in HaishinKit~Extension.
- The types involved
RTMPHaishinKit~AMF.AMF3Serializer→HaishinKit~Extension.Data
- Direction
- RTMPHaishinKit~AMF uses HaishinKit~Extension, so a change to HaishinKit~Extension can break RTMPHaishinKit~AMF, while a change to RTMPHaishinKit~AMF can't break HaishinKit~Extension.
- Position
- Below the diagonal: RTMPHaishinKit~AMF uses a module listed above it, which is the healthy direction.
20→16 RTMPHaishinKit~AMF uses HaishinKit~Util✕
- Connections
- 3 pairs of types, where a type in RTMPHaishinKit~AMF uses a type in HaishinKit~Util.
- The types involved
RTMPHaishinKit~AMF.AMF0Serializer→HaishinKit~Util.ByteArrayRTMPHaishinKit~AMF.AMF3Serializer→HaishinKit~Util.ByteArrayRTMPHaishinKit~AMF.AMFSerializer→HaishinKit~Util.ByteArrayConvertible
- Direction
- RTMPHaishinKit~AMF uses HaishinKit~Util, so a change to HaishinKit~Util can break RTMPHaishinKit~AMF, while a change to RTMPHaishinKit~AMF can't break HaishinKit~Util.
- Position
- Below the diagonal: RTMPHaishinKit~AMF uses a module listed above it, which is the healthy direction.
21→8 RTMPHaishinKit~Util uses HaishinKit~Extension✕
- Connections
- 4 pairs of types, where a type in RTMPHaishinKit~Util uses a type in HaishinKit~Extension.
- The types involved
RTMPHaishinKit~Util.ByteArray→HaishinKit~Extension.DataRTMPHaishinKit~Util.ByteArrayConvertible→HaishinKit~Extension.DataRTMPHaishinKit~Util.Context→HaishinKit~Extension.DataRTMPHaishinKit~Util.MD5→HaishinKit~Extension.Data
- Direction
- RTMPHaishinKit~Util uses HaishinKit~Extension, so a change to HaishinKit~Extension can break RTMPHaishinKit~Util, while a change to RTMPHaishinKit~Util can't break HaishinKit~Extension.
- Position
- Below the diagonal: RTMPHaishinKit~Util uses a module listed above it, which is the healthy direction.
21→16 RTMPHaishinKit~Util uses HaishinKit~Util✕
- Connections
- 1 pair of types, where a type in RTMPHaishinKit~Util uses a type in HaishinKit~Util.
- The types involved
RTMPHaishinKit~Util.ByteArray→HaishinKit~Util.ByteArrayConvertible
- Direction
- RTMPHaishinKit~Util uses HaishinKit~Util, so a change to HaishinKit~Util can break RTMPHaishinKit~Util, while a change to RTMPHaishinKit~Util can't break HaishinKit~Util.
- Position
- Below the diagonal: RTMPHaishinKit~Util uses a module listed above it, which is the healthy direction.
22→1 RTMPHaishinKit~RTMP uses HaishinKit~Network✕
- Connections
- 6 pairs of types, where a type in RTMPHaishinKit~RTMP uses a type in HaishinKit~Network.
- The types involved
RTMPHaishinKit~RTMP.RTMPConnection→HaishinKit~Network.NetworkConnectionRTMPHaishinKit~RTMP.RTMPConnection→HaishinKit~Network.NetworkMonitorRTMPHaishinKit~RTMP.RTMPConnection→HaishinKit~Network.NetworkMonitorEventRTMPHaishinKit~RTMP.RTMPSocket→HaishinKit~Network.NetworkMonitorRTMPHaishinKit~RTMP.RTMPSocket→HaishinKit~Network.NetworkTransportReportRTMPHaishinKit~RTMP.RTMPStream→HaishinKit~Network.NetworkMonitorEvent
- Direction
- RTMPHaishinKit~RTMP uses HaishinKit~Network, so a change to HaishinKit~Network can break RTMPHaishinKit~RTMP, while a change to RTMPHaishinKit~RTMP can't break HaishinKit~Network.
- Position
- Below the diagonal: RTMPHaishinKit~RTMP uses a module listed above it, which is the healthy direction.
22→6 RTMPHaishinKit~RTMP uses RTMPHaishinKit~Extension✕
- Connections
- 5 pairs of types, where a type in RTMPHaishinKit~RTMP uses a type in RTMPHaishinKit~Extension.
- The types involved
RTMPHaishinKit~RTMP.RTMPAuthenticator→RTMPHaishinKit~Extension.URLRTMPHaishinKit~RTMP.RTMPConnection→RTMPHaishinKit~Extension.URLRTMPHaishinKit~RTMP.RTMPSession→RTMPHaishinKit~Extension.URLRTMPHaishinKit~RTMP.RTMPSessionFactory→RTMPHaishinKit~Extension.URLRTMPHaishinKit~RTMP.RTMPURL→RTMPHaishinKit~Extension.URL
- Direction
- RTMPHaishinKit~RTMP uses RTMPHaishinKit~Extension, so a change to RTMPHaishinKit~Extension can break RTMPHaishinKit~RTMP, while a change to RTMPHaishinKit~RTMP can't break RTMPHaishinKit~Extension.
- Position
- Below the diagonal: RTMPHaishinKit~RTMP uses a module listed above it, which is the healthy direction.
22→8 RTMPHaishinKit~RTMP uses HaishinKit~Extension✕
- Connections
- 28 pairs of types, where a type in RTMPHaishinKit~RTMP uses a type in HaishinKit~Extension. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
RTMPHaishinKit~RTMP.RTMPAbortMessge→HaishinKit~Extension.DataRTMPHaishinKit~RTMP.RTMPAcknowledgementMessage→HaishinKit~Extension.DataRTMPHaishinKit~RTMP.RTMPAggregateMessage→HaishinKit~Extension.DataRTMPHaishinKit~RTMP.RTMPAudioCodec→HaishinKit~Extension.DataRTMPHaishinKit~RTMP.RTMPAudioMessage→HaishinKit~Extension.AVAudioCompressedBufferRTMPHaishinKit~RTMP.RTMPAudioMessage→HaishinKit~Extension.DataRTMPHaishinKit~RTMP.RTMPChunkBuffer→HaishinKit~Extension.DataRTMPHaishinKit~RTMP.RTMPChunkMessageHeader→HaishinKit~Extension.DataRTMPHaishinKit~RTMP.RTMPCommandMessage→HaishinKit~Extension.DataRTMPHaishinKit~RTMP.RTMPConnection→HaishinKit~Extension.DataRTMPHaishinKit~RTMP.RTMPDataMessage→HaishinKit~Extension.DataRTMPHaishinKit~RTMP.RTMPHandshake→HaishinKit~Extension.DataRTMPHaishinKit~RTMP.RTMPMessage→HaishinKit~Extension.DataRTMPHaishinKit~RTMP.RTMPSetChunkSizeMessage→HaishinKit~Extension.DataRTMPHaishinKit~RTMP.RTMPSetPeerBandwidthMessage→HaishinKit~Extension.DataRTMPHaishinKit~RTMP.RTMPSharedObjectMessage→HaishinKit~Extension.DataRTMPHaishinKit~RTMP.RTMPSocket→HaishinKit~Extension.DataRTMPHaishinKit~RTMP.RTMPStream→HaishinKit~Extension.AVAudioBufferRTMPHaishinKit~RTMP.RTMPStream→HaishinKit~Extension.AVAudioCompressedBufferRTMPHaishinKit~RTMP.RTMPStream→HaishinKit~Extension.AVAudioPCMBufferRTMPHaishinKit~RTMP.RTMPStream→HaishinKit~Extension.AVAudioTimeRTMPHaishinKit~RTMP.RTMPStream→HaishinKit~Extension.CMSampleBufferRTMPHaishinKit~RTMP.RTMPTimestamp→HaishinKit~Extension.AVAudioTimeRTMPHaishinKit~RTMP.RTMPUserControlMessage→HaishinKit~Extension.DataRTMPHaishinKit~RTMP.RTMPVideoMessage→HaishinKit~Extension.CMSampleBuffer
- Direction
- RTMPHaishinKit~RTMP uses HaishinKit~Extension, so a change to HaishinKit~Extension can break RTMPHaishinKit~RTMP, while a change to RTMPHaishinKit~RTMP can't break HaishinKit~Extension.
- Position
- Below the diagonal: RTMPHaishinKit~RTMP uses a module listed above it, which is the healthy direction.
22→9 RTMPHaishinKit~RTMP uses HaishinKit~Session✕
- Connections
- 5 pairs of types, where a type in RTMPHaishinKit~RTMP uses a type in HaishinKit~Session.
- The types involved
RTMPHaishinKit~RTMP.RTMPSession→HaishinKit~Session.StreamSessionRTMPHaishinKit~RTMP.RTMPSession→HaishinKit~Session.StreamSessionModeRTMPHaishinKit~RTMP.RTMPSessionFactory→HaishinKit~Session.StreamSessionRTMPHaishinKit~RTMP.RTMPSessionFactory→HaishinKit~Session.StreamSessionFactoryRTMPHaishinKit~RTMP.RTMPSessionFactory→HaishinKit~Session.StreamSessionMode
- Direction
- RTMPHaishinKit~RTMP uses HaishinKit~Session, so a change to HaishinKit~Session can break RTMPHaishinKit~RTMP, while a change to RTMPHaishinKit~RTMP can't break HaishinKit~Session.
- Position
- Below the diagonal: RTMPHaishinKit~RTMP uses a module listed above it, which is the healthy direction.
22→15 RTMPHaishinKit~RTMP uses SRTHaishinKit~Extension✕
- Connections
- 3 pairs of types, where a type in RTMPHaishinKit~RTMP uses a type in SRTHaishinKit~Extension.
- The types involved
RTMPHaishinKit~RTMP.RTMPAudioMessage→SRTHaishinKit~Extension.CMFormatDescriptionRTMPHaishinKit~RTMP.RTMPStream→SRTHaishinKit~Extension.CMFormatDescriptionRTMPHaishinKit~RTMP.RTMPVideoMessage→SRTHaishinKit~Extension.CMFormatDescription
- Direction
- RTMPHaishinKit~RTMP uses SRTHaishinKit~Extension, so a change to SRTHaishinKit~Extension can break RTMPHaishinKit~RTMP, while a change to RTMPHaishinKit~RTMP can't break SRTHaishinKit~Extension.
- Position
- Below the diagonal: RTMPHaishinKit~RTMP uses a module listed above it, which is the healthy direction.
22→19 RTMPHaishinKit~RTMP uses RTCHaishinKit~RTC✕
- Connections
- 1 pair of types, where a type in RTMPHaishinKit~RTMP uses a type in RTCHaishinKit~RTC.
- The types involved
RTMPHaishinKit~RTMP.RTMPConnection→RTCHaishinKit~RTC.ReadyState
- Direction
- RTMPHaishinKit~RTMP uses RTCHaishinKit~RTC, so a change to RTCHaishinKit~RTC can break RTMPHaishinKit~RTMP, while a change to RTMPHaishinKit~RTMP can't break RTCHaishinKit~RTC.
- Position
- Below the diagonal: RTMPHaishinKit~RTMP uses a module listed above it, which is the healthy direction.
22→20 RTMPHaishinKit~RTMP uses RTMPHaishinKit~AMF✕
- Connections
- 2 pairs of types, where a type in RTMPHaishinKit~RTMP uses a type in RTMPHaishinKit~AMF.
- The types involved
RTMPHaishinKit~RTMP.RTMPSharedObjectEvent→RTMPHaishinKit~AMF.AMFSerializerRTMPHaishinKit~RTMP.RTMPStream→RTMPHaishinKit~AMF.AMFArray
- Direction
- RTMPHaishinKit~RTMP uses RTMPHaishinKit~AMF, so a change to RTMPHaishinKit~AMF can break RTMPHaishinKit~RTMP, while a change to RTMPHaishinKit~RTMP can't break RTMPHaishinKit~AMF.
- Position
- Below the diagonal: RTMPHaishinKit~RTMP uses a module listed above it, which is the healthy direction.
22→21 RTMPHaishinKit~RTMP uses RTMPHaishinKit~Util✕
- Connections
- 1 pair of types, where a type in RTMPHaishinKit~RTMP uses a type in RTMPHaishinKit~Util.
- The types involved
RTMPHaishinKit~RTMP.RTMPSharedObject→RTMPHaishinKit~Util.HKAtomic
- Direction
- RTMPHaishinKit~RTMP uses RTMPHaishinKit~Util, so a change to RTMPHaishinKit~Util can break RTMPHaishinKit~RTMP, while a change to RTMPHaishinKit~RTMP can't break RTMPHaishinKit~Util.
- Position
- Below the diagonal: RTMPHaishinKit~RTMP uses a module listed above it, which is the healthy direction.
22→23 RTMPHaishinKit~RTMP uses HaishinKit~Stream part of a loop✕
- Connections
- 5 pairs of types, where a type in RTMPHaishinKit~RTMP uses a type in HaishinKit~Stream.
- The types involved
RTMPHaishinKit~RTMP.RTMPSession→HaishinKit~Stream.StreamConvertibleRTMPHaishinKit~RTMP.RTMPStream→HaishinKit~Stream.IncomingStreamRTMPHaishinKit~RTMP.RTMPStream→HaishinKit~Stream.OutgoingStreamRTMPHaishinKit~RTMP.RTMPStream→HaishinKit~Stream.StreamOutputRTMPHaishinKit~RTMP.RTMPStream→HaishinKit~Stream.StreamReadyState
- Direction
- RTMPHaishinKit~RTMP uses HaishinKit~Stream, so a change to HaishinKit~Stream can break RTMPHaishinKit~RTMP, while a change to RTMPHaishinKit~RTMP can't break HaishinKit~Stream.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
22→26 RTMPHaishinKit~RTMP uses HaishinKit~Mixer part of a loop✕
- Connections
- 1 pair of types, where a type in RTMPHaishinKit~RTMP uses a type in HaishinKit~Mixer.
- The types involved
RTMPHaishinKit~RTMP.RTMPStream→HaishinKit~Mixer.MediaMixer
- Direction
- RTMPHaishinKit~RTMP uses HaishinKit~Mixer, so a change to HaishinKit~Mixer can break RTMPHaishinKit~RTMP, while a change to RTMPHaishinKit~RTMP can't break HaishinKit~Mixer.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
22→27 RTMPHaishinKit~RTMP uses HaishinKit~Codec part of a loop✕
- Connections
- 3 pairs of types, where a type in RTMPHaishinKit~RTMP uses a type in HaishinKit~Codec.
- The types involved
RTMPHaishinKit~RTMP.RTMPStream→HaishinKit~Codec.AudioCodecSettingsRTMPHaishinKit~RTMP.RTMPStream→HaishinKit~Codec.FormatRTMPHaishinKit~RTMP.RTMPStream→HaishinKit~Codec.VideoCodecSettings
- Direction
- RTMPHaishinKit~RTMP uses HaishinKit~Codec, so a change to HaishinKit~Codec can break RTMPHaishinKit~RTMP, while a change to RTMPHaishinKit~RTMP can't break HaishinKit~Codec.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
23→1 HaishinKit~Stream uses HaishinKit~Network✕
- Connections
- 3 pairs of types, where a type in HaishinKit~Stream uses a type in HaishinKit~Network.
- The types involved
HaishinKit~Stream.StreamBitRateStrategy→HaishinKit~Network.NetworkMonitorEventHaishinKit~Stream.StreamConvertible→HaishinKit~Network.NetworkMonitorEventHaishinKit~Stream.StreamVideoAdaptiveBitRateStrategy→HaishinKit~Network.NetworkMonitorEvent
- Direction
- HaishinKit~Stream uses HaishinKit~Network, so a change to HaishinKit~Network can break HaishinKit~Stream, while a change to HaishinKit~Stream can't break HaishinKit~Network.
- Position
- Below the diagonal: HaishinKit~Stream uses a module listed above it, which is the healthy direction.
23→6 HaishinKit~Stream uses RTMPHaishinKit~Extension✕
- Connections
- 1 pair of types, where a type in HaishinKit~Stream uses a type in RTMPHaishinKit~Extension.
- The types involved
HaishinKit~Stream.StreamRecorder→RTMPHaishinKit~Extension.URL
- Direction
- HaishinKit~Stream uses RTMPHaishinKit~Extension, so a change to RTMPHaishinKit~Extension can break HaishinKit~Stream, while a change to HaishinKit~Stream can't break RTMPHaishinKit~Extension.
- Position
- Below the diagonal: HaishinKit~Stream uses a module listed above it, which is the healthy direction.
23→8 HaishinKit~Stream uses HaishinKit~Extension✕
- Connections
- 23 pairs of types, where a type in HaishinKit~Stream uses a type in HaishinKit~Extension.
- The types involved
HaishinKit~Stream.AudioPlayerNode→HaishinKit~Extension.AVAudioBufferHaishinKit~Stream.AudioPlayerNode→HaishinKit~Extension.AVAudioTimeHaishinKit~Stream.IncomingStream→HaishinKit~Extension.AVAudioBufferHaishinKit~Stream.IncomingStream→HaishinKit~Extension.AVAudioTimeHaishinKit~Stream.IncomingStream→HaishinKit~Extension.CMSampleBufferHaishinKit~Stream.IncomingStream→HaishinKit~Extension.CMTimeHaishinKit~Stream.MediaLink→HaishinKit~Extension.CMSampleBufferHaishinKit~Stream.MediaLink→HaishinKit~Extension.CMTimeHaishinKit~Stream.OutgoingStream→HaishinKit~Extension.AVAudioBufferHaishinKit~Stream.OutgoingStream→HaishinKit~Extension.AVAudioTimeHaishinKit~Stream.OutgoingStream→HaishinKit~Extension.CMSampleBufferHaishinKit~Stream.StreamConvertible→HaishinKit~Extension.AVAudioBufferHaishinKit~Stream.StreamConvertible→HaishinKit~Extension.AVAudioTimeHaishinKit~Stream.StreamConvertible→HaishinKit~Extension.CMSampleBufferHaishinKit~Stream.StreamOutput→HaishinKit~Extension.AVAudioBufferHaishinKit~Stream.StreamOutput→HaishinKit~Extension.AVAudioTimeHaishinKit~Stream.StreamOutput→HaishinKit~Extension.CMSampleBufferHaishinKit~Stream.StreamRecorder→HaishinKit~Extension.AVAudioBufferHaishinKit~Stream.StreamRecorder→HaishinKit~Extension.AVAudioPCMBufferHaishinKit~Stream.StreamRecorder→HaishinKit~Extension.AVAudioTimeHaishinKit~Stream.StreamRecorder→HaishinKit~Extension.CMSampleBufferHaishinKit~Stream.StreamRecorder→HaishinKit~Extension.CMTimeHaishinKit~Stream.StreamRecorder→HaishinKit~Extension.CMVideoDimensions
- Direction
- HaishinKit~Stream uses HaishinKit~Extension, so a change to HaishinKit~Extension can break HaishinKit~Stream, while a change to HaishinKit~Stream can't break HaishinKit~Extension.
- Position
- Below the diagonal: HaishinKit~Stream uses a module listed above it, which is the healthy direction.
23→15 HaishinKit~Stream uses SRTHaishinKit~Extension✕
- Connections
- 3 pairs of types, where a type in HaishinKit~Stream uses a type in SRTHaishinKit~Extension.
- The types involved
HaishinKit~Stream.IncomingStream→SRTHaishinKit~Extension.CMFormatDescriptionHaishinKit~Stream.OutgoingStream→SRTHaishinKit~Extension.CMFormatDescriptionHaishinKit~Stream.StreamRecorder→SRTHaishinKit~Extension.CMFormatDescription
- Direction
- HaishinKit~Stream uses SRTHaishinKit~Extension, so a change to SRTHaishinKit~Extension can break HaishinKit~Stream, while a change to HaishinKit~Stream can't break SRTHaishinKit~Extension.
- Position
- Below the diagonal: HaishinKit~Stream uses a module listed above it, which is the healthy direction.
23→16 HaishinKit~Stream uses HaishinKit~Util✕
- Connections
- 2 pairs of types, where a type in HaishinKit~Stream uses a type in HaishinKit~Util.
- The types involved
HaishinKit~Stream.AudioPlayerNode→HaishinKit~Util.AudioTimeHaishinKit~Stream.MediaLink→HaishinKit~Util.TypedBlockQueue
- Direction
- HaishinKit~Stream uses HaishinKit~Util, so a change to HaishinKit~Util can break HaishinKit~Stream, while a change to HaishinKit~Stream can't break HaishinKit~Util.
- Position
- Below the diagonal: HaishinKit~Stream uses a module listed above it, which is the healthy direction.
23→22 HaishinKit~Stream uses RTMPHaishinKit~RTMP✕
- Connections
- 1 pair of types, where a type in HaishinKit~Stream uses a type in RTMPHaishinKit~RTMP.
- The types involved
HaishinKit~Stream.IncomingStream→RTMPHaishinKit~RTMP.RTMPVideoMessage
- Direction
- HaishinKit~Stream uses RTMPHaishinKit~RTMP, so a change to RTMPHaishinKit~RTMP can break HaishinKit~Stream, while a change to HaishinKit~Stream can't break RTMPHaishinKit~RTMP.
- Position
- Below the diagonal: HaishinKit~Stream uses a module listed above it, which is the healthy direction.
23→24 HaishinKit~Stream uses HaishinKit~Screen part of a loop✕
- Connections
- 1 pair of types, where a type in HaishinKit~Stream uses a type in HaishinKit~Screen.
- The types involved
HaishinKit~Stream.MediaLink→HaishinKit~Screen.DisplayLinkChoreographer
- Direction
- HaishinKit~Stream uses HaishinKit~Screen, so a change to HaishinKit~Screen can break HaishinKit~Stream, while a change to HaishinKit~Stream can't break HaishinKit~Screen.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
23→26 HaishinKit~Stream uses HaishinKit~Mixer part of a loop✕
- Connections
- 2 pairs of types, where a type in HaishinKit~Stream uses a type in HaishinKit~Mixer.
- The types involved
HaishinKit~Stream.StreamConvertible→HaishinKit~Mixer.MediaMixerOutputHaishinKit~Stream.StreamRecorder→HaishinKit~Mixer.MediaMixer
- Direction
- HaishinKit~Stream uses HaishinKit~Mixer, so a change to HaishinKit~Mixer can break HaishinKit~Stream, while a change to HaishinKit~Stream can't break HaishinKit~Mixer.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
23→27 HaishinKit~Stream uses HaishinKit~Codec part of a loop✕
- Connections
- 10 pairs of types, where a type in HaishinKit~Stream uses a type in HaishinKit~Codec.
- The types involved
HaishinKit~Stream.IncomingStream→HaishinKit~Codec.AudioCodecHaishinKit~Stream.IncomingStream→HaishinKit~Codec.VideoCodecHaishinKit~Stream.OutgoingStream→HaishinKit~Codec.AudioCodecHaishinKit~Stream.OutgoingStream→HaishinKit~Codec.AudioCodecSettingsHaishinKit~Stream.OutgoingStream→HaishinKit~Codec.VideoCodecHaishinKit~Stream.OutgoingStream→HaishinKit~Codec.VideoCodecSettingsHaishinKit~Stream.StreamConvertible→HaishinKit~Codec.AudioCodecSettingsHaishinKit~Stream.StreamConvertible→HaishinKit~Codec.VideoCodecSettingsHaishinKit~Stream._Stream→HaishinKit~Codec.AudioCodecSettingsHaishinKit~Stream._Stream→HaishinKit~Codec.VideoCodecSettings
- Direction
- HaishinKit~Stream uses HaishinKit~Codec, so a change to HaishinKit~Codec can break HaishinKit~Stream, while a change to HaishinKit~Stream can't break HaishinKit~Codec.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
24→6 HaishinKit~Screen uses RTMPHaishinKit~Extension✕
- Connections
- 3 pairs of types, where a type in HaishinKit~Screen uses a type in RTMPHaishinKit~Extension.
- The types involved
HaishinKit~Screen.DataImageSource→RTMPHaishinKit~Extension.URLHaishinKit~Screen.ImageSource→RTMPHaishinKit~Extension.URLHaishinKit~Screen.ImageSourceFactory→RTMPHaishinKit~Extension.URL
- Direction
- HaishinKit~Screen uses RTMPHaishinKit~Extension, so a change to RTMPHaishinKit~Extension can break HaishinKit~Screen, while a change to HaishinKit~Screen can't break RTMPHaishinKit~Extension.
- Position
- Below the diagonal: HaishinKit~Screen uses a module listed above it, which is the healthy direction.
24→8 HaishinKit~Screen uses HaishinKit~Extension✕
- Connections
- 17 pairs of types, where a type in HaishinKit~Screen uses a type in HaishinKit~Extension.
- The types involved
HaishinKit~Screen.AssetScreenObject→HaishinKit~Extension.AVLayerVideoGravityHaishinKit~Screen.AssetScreenObject→HaishinKit~Extension.CMSampleBufferHaishinKit~Screen.AssetScreenObject→HaishinKit~Extension.CMTimeHaishinKit~Screen.Screen→HaishinKit~Extension.CMSampleBufferHaishinKit~Screen.Screen→HaishinKit~Extension.CMTimeHaishinKit~Screen.Screen→HaishinKit~Extension.CVPixelBufferPoolHaishinKit~Screen.ScreenDelegate→HaishinKit~Extension.CMTimeHaishinKit~Screen.ScreenRenderer→HaishinKit~Extension.CMTimeHaishinKit~Screen.ScreenRenderer→HaishinKit~Extension.CVPixelBufferHaishinKit~Screen.ScreenRendererByGPU→HaishinKit~Extension.CMTimeHaishinKit~Screen.ScreenRendererByGPU→HaishinKit~Extension.CVPixelBufferHaishinKit~Screen.StreamScreenObject→HaishinKit~Extension.AVAudioBufferHaishinKit~Screen.StreamScreenObject→HaishinKit~Extension.AVAudioTimeHaishinKit~Screen.StreamScreenObject→HaishinKit~Extension.AVLayerVideoGravityHaishinKit~Screen.StreamScreenObject→HaishinKit~Extension.CMSampleBufferHaishinKit~Screen.VideoScreenObject→HaishinKit~Extension.AVLayerVideoGravityHaishinKit~Screen.VideoScreenObject→HaishinKit~Extension.CMSampleBuffer
- Direction
- HaishinKit~Screen uses HaishinKit~Extension, so a change to HaishinKit~Extension can break HaishinKit~Screen, while a change to HaishinKit~Screen can't break HaishinKit~Extension.
- Position
- Below the diagonal: HaishinKit~Screen uses a module listed above it, which is the healthy direction.
24→15 HaishinKit~Screen uses SRTHaishinKit~Extension✕
- Connections
- 1 pair of types, where a type in HaishinKit~Screen uses a type in SRTHaishinKit~Extension.
- The types involved
HaishinKit~Screen.Screen→SRTHaishinKit~Extension.CMFormatDescription
- Direction
- HaishinKit~Screen uses SRTHaishinKit~Extension, so a change to SRTHaishinKit~Extension can break HaishinKit~Screen, while a change to HaishinKit~Screen can't break SRTHaishinKit~Extension.
- Position
- Below the diagonal: HaishinKit~Screen uses a module listed above it, which is the healthy direction.
24→16 HaishinKit~Screen uses HaishinKit~Util✕
- Connections
- 2 pairs of types, where a type in HaishinKit~Screen uses a type in HaishinKit~Util.
- The types involved
HaishinKit~Screen.VideoScreenObject→HaishinKit~Util.FrameTrackerHaishinKit~Screen.VideoScreenObject→HaishinKit~Util.TypedBlockQueue
- Direction
- HaishinKit~Screen uses HaishinKit~Util, so a change to HaishinKit~Util can break HaishinKit~Screen, while a change to HaishinKit~Screen can't break HaishinKit~Util.
- Position
- Below the diagonal: HaishinKit~Screen uses a module listed above it, which is the healthy direction.
24→23 HaishinKit~Screen uses HaishinKit~Stream✕
- Connections
- 1 pair of types, where a type in HaishinKit~Screen uses a type in HaishinKit~Stream.
- The types involved
HaishinKit~Screen.StreamScreenObject→HaishinKit~Stream.StreamConvertible
- Direction
- HaishinKit~Screen uses HaishinKit~Stream, so a change to HaishinKit~Stream can break HaishinKit~Screen, while a change to HaishinKit~Screen can't break HaishinKit~Stream.
- Position
- Below the diagonal: HaishinKit~Screen uses a module listed above it, which is the healthy direction.
24→26 HaishinKit~Screen uses HaishinKit~Mixer part of a loop✕
- Connections
- 3 pairs of types, where a type in HaishinKit~Screen uses a type in HaishinKit~Mixer.
- The types involved
HaishinKit~Screen.DisplayLink→HaishinKit~Mixer.ModeHaishinKit~Screen.Screen→HaishinKit~Mixer.DynamicRangeModeHaishinKit~Screen.ScreenRendererByGPU→HaishinKit~Mixer.DynamicRangeMode
- Direction
- HaishinKit~Screen uses HaishinKit~Mixer, so a change to HaishinKit~Mixer can break HaishinKit~Screen, while a change to HaishinKit~Screen can't break HaishinKit~Mixer.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
25→6 RTCHaishinKit~HTTP uses RTMPHaishinKit~Extension✕
- Connections
- 2 pairs of types, where a type in RTCHaishinKit~HTTP uses a type in RTMPHaishinKit~Extension.
- The types involved
RTCHaishinKit~HTTP.HTTPSession→RTMPHaishinKit~Extension.URLRTCHaishinKit~HTTP.HTTPSessionFactory→RTMPHaishinKit~Extension.URL
- Direction
- RTCHaishinKit~HTTP uses RTMPHaishinKit~Extension, so a change to RTMPHaishinKit~Extension can break RTCHaishinKit~HTTP, while a change to RTCHaishinKit~HTTP can't break RTMPHaishinKit~Extension.
- Position
- Below the diagonal: RTCHaishinKit~HTTP uses a module listed above it, which is the healthy direction.
25→9 RTCHaishinKit~HTTP uses HaishinKit~Session✕
- Connections
- 6 pairs of types, where a type in RTCHaishinKit~HTTP uses a type in HaishinKit~Session.
- The types involved
RTCHaishinKit~HTTP.HTTPSession→HaishinKit~Session.StreamSessionRTCHaishinKit~HTTP.HTTPSession→HaishinKit~Session.StreamSessionModeRTCHaishinKit~HTTP.HTTPSessionConfiguration→HaishinKit~Session.StreamSessionConfigurationRTCHaishinKit~HTTP.HTTPSessionFactory→HaishinKit~Session.StreamSessionRTCHaishinKit~HTTP.HTTPSessionFactory→HaishinKit~Session.StreamSessionFactoryRTCHaishinKit~HTTP.HTTPSessionFactory→HaishinKit~Session.StreamSessionMode
- Direction
- RTCHaishinKit~HTTP uses HaishinKit~Session, so a change to HaishinKit~Session can break RTCHaishinKit~HTTP, while a change to RTCHaishinKit~HTTP can't break HaishinKit~Session.
- Position
- Below the diagonal: RTCHaishinKit~HTTP uses a module listed above it, which is the healthy direction.
25→19 RTCHaishinKit~HTTP uses RTCHaishinKit~RTC✕
- Connections
- 11 pairs of types, where a type in RTCHaishinKit~HTTP uses a type in RTCHaishinKit~RTC.
- The types involved
RTCHaishinKit~HTTP.HTTPSession→RTCHaishinKit~RTC.ConnectionStateRTCHaishinKit~HTTP.HTTPSession→RTCHaishinKit~RTC.IceConnectionStateRTCHaishinKit~HTTP.HTTPSession→RTCHaishinKit~RTC.IceGatheringStateRTCHaishinKit~HTTP.HTTPSession→RTCHaishinKit~RTC.RTCDataChannelRTCHaishinKit~HTTP.HTTPSession→RTCHaishinKit~RTC.RTCIceCandidateRTCHaishinKit~HTTP.HTTPSession→RTCHaishinKit~RTC.RTCPeerConnectionRTCHaishinKit~HTTP.HTTPSession→RTCHaishinKit~RTC.RTCStreamRTCHaishinKit~HTTP.HTTPSession→RTCHaishinKit~RTC.SignalingStateRTCHaishinKit~HTTP.HTTPSessionConfiguration→RTCHaishinKit~RTC.RTCCertificateTypeRTCHaishinKit~HTTP.HTTPSessionConfiguration→RTCHaishinKit~RTC.RTCConfigurationConvertibleRTCHaishinKit~HTTP.HTTPSessionConfiguration→RTCHaishinKit~RTC.RTCTransportPolicy
- Direction
- RTCHaishinKit~HTTP uses RTCHaishinKit~RTC, so a change to RTCHaishinKit~RTC can break RTCHaishinKit~HTTP, while a change to RTCHaishinKit~HTTP can't break RTCHaishinKit~RTC.
- Position
- Below the diagonal: RTCHaishinKit~HTTP uses a module listed above it, which is the healthy direction.
25→23 RTCHaishinKit~HTTP uses HaishinKit~Stream✕
- Connections
- 1 pair of types, where a type in RTCHaishinKit~HTTP uses a type in HaishinKit~Stream.
- The types involved
RTCHaishinKit~HTTP.HTTPSession→HaishinKit~Stream.StreamConvertible
- Direction
- RTCHaishinKit~HTTP uses HaishinKit~Stream, so a change to HaishinKit~Stream can break RTCHaishinKit~HTTP, while a change to RTCHaishinKit~HTTP can't break HaishinKit~Stream.
- Position
- Below the diagonal: RTCHaishinKit~HTTP uses a module listed above it, which is the healthy direction.
26→8 HaishinKit~Mixer uses HaishinKit~Extension✕
- Connections
- 50 pairs of types, where a type in HaishinKit~Mixer uses a type in HaishinKit~Extension. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
HaishinKit~Mixer.AudioCaptureUnit→HaishinKit~Extension.AVAudioBufferHaishinKit~Mixer.AudioCaptureUnit→HaishinKit~Extension.AVAudioPCMBufferHaishinKit~Mixer.AudioCaptureUnit→HaishinKit~Extension.AVAudioTimeHaishinKit~Mixer.AudioCaptureUnit→HaishinKit~Extension.AVCaptureDeviceHaishinKit~Mixer.AudioCaptureUnit→HaishinKit~Extension.CMSampleBufferHaishinKit~Mixer.AudioDeviceUnit→HaishinKit~Extension.AVCaptureDeviceHaishinKit~Mixer.AudioDeviceUnitDataOutput→HaishinKit~Extension.CMSampleBufferHaishinKit~Mixer.AudioMixer→HaishinKit~Extension.AVAudioPCMBufferHaishinKit~Mixer.AudioMixer→HaishinKit~Extension.AVAudioTimeHaishinKit~Mixer.AudioMixer→HaishinKit~Extension.CMSampleBufferHaishinKit~Mixer.AudioMixerByMultiTrack→HaishinKit~Extension.AVAudioPCMBufferHaishinKit~Mixer.AudioMixerByMultiTrack→HaishinKit~Extension.AVAudioTimeHaishinKit~Mixer.AudioMixerByMultiTrack→HaishinKit~Extension.CMSampleBufferHaishinKit~Mixer.AudioMixerBySingleTrack→HaishinKit~Extension.AVAudioPCMBufferHaishinKit~Mixer.AudioMixerBySingleTrack→HaishinKit~Extension.AVAudioTimeHaishinKit~Mixer.AudioMixerBySingleTrack→HaishinKit~Extension.CMSampleBufferHaishinKit~Mixer.AudioMixerDelegate→HaishinKit~Extension.AVAudioPCMBufferHaishinKit~Mixer.AudioMixerDelegate→HaishinKit~Extension.AVAudioTimeHaishinKit~Mixer.AudioMixerTrack→HaishinKit~Extension.AVAudioPCMBufferHaishinKit~Mixer.AudioMixerTrack→HaishinKit~Extension.AVAudioTimeHaishinKit~Mixer.AudioMixerTrack→HaishinKit~Extension.CMSampleBufferHaishinKit~Mixer.AudioMixerTrackDelegate→HaishinKit~Extension.AVAudioPCMBufferHaishinKit~Mixer.AudioMixerTrackDelegate→HaishinKit~Extension.AVAudioTimeHaishinKit~Mixer.AudioMonitor→HaishinKit~Extension.AVAudioPCMBufferHaishinKit~Mixer.AudioMonitor→HaishinKit~Extension.AVAudioTime
- Direction
- HaishinKit~Mixer uses HaishinKit~Extension, so a change to HaishinKit~Extension can break HaishinKit~Mixer, while a change to HaishinKit~Mixer can't break HaishinKit~Extension.
- Position
- Below the diagonal: HaishinKit~Mixer uses a module listed above it, which is the healthy direction.
26→15 HaishinKit~Mixer uses SRTHaishinKit~Extension✕
- Connections
- 4 pairs of types, where a type in HaishinKit~Mixer uses a type in SRTHaishinKit~Extension.
- The types involved
HaishinKit~Mixer.AudioMixerByMultiTrack→SRTHaishinKit~Extension.CMFormatDescriptionHaishinKit~Mixer.AudioMixerBySingleTrack→SRTHaishinKit~Extension.CMFormatDescriptionHaishinKit~Mixer.AudioMixerSettings→SRTHaishinKit~Extension.CMFormatDescriptionHaishinKit~Mixer.AudioMixerTrack→SRTHaishinKit~Extension.CMFormatDescription
- Direction
- HaishinKit~Mixer uses SRTHaishinKit~Extension, so a change to SRTHaishinKit~Extension can break HaishinKit~Mixer, while a change to HaishinKit~Mixer can't break SRTHaishinKit~Extension.
- Position
- Below the diagonal: HaishinKit~Mixer uses a module listed above it, which is the healthy direction.
26→16 HaishinKit~Mixer uses HaishinKit~Util✕
- Connections
- 2 pairs of types, where a type in HaishinKit~Mixer uses a type in HaishinKit~Util.
- The types involved
HaishinKit~Mixer.AudioMixerTrack→HaishinKit~Util.AudioTimeHaishinKit~Mixer.CaptureSessionConvertible→HaishinKit~Util.Runner
- Direction
- HaishinKit~Mixer uses HaishinKit~Util, so a change to HaishinKit~Util can break HaishinKit~Mixer, while a change to HaishinKit~Mixer can't break HaishinKit~Util.
- Position
- Below the diagonal: HaishinKit~Mixer uses a module listed above it, which is the healthy direction.
26→24 HaishinKit~Mixer uses HaishinKit~Screen✕
- Connections
- 2 pairs of types, where a type in HaishinKit~Mixer uses a type in HaishinKit~Screen.
- The types involved
HaishinKit~Mixer.MediaMixer→HaishinKit~Screen.DisplayLinkChoreographerHaishinKit~Mixer.MediaMixer→HaishinKit~Screen.Screen
- Direction
- HaishinKit~Mixer uses HaishinKit~Screen, so a change to HaishinKit~Screen can break HaishinKit~Mixer, while a change to HaishinKit~Mixer can't break HaishinKit~Screen.
- Position
- Below the diagonal: HaishinKit~Mixer uses a module listed above it, which is the healthy direction.
27→8 HaishinKit~Codec uses HaishinKit~Extension✕
- Connections
- 8 pairs of types, where a type in HaishinKit~Codec uses a type in HaishinKit~Extension.
- The types involved
HaishinKit~Codec.ADTSHeader→HaishinKit~Extension.DataHaishinKit~Codec.AudioCodec→HaishinKit~Extension.AVAudioBufferHaishinKit~Codec.AudioCodec→HaishinKit~Extension.AVAudioTimeHaishinKit~Codec.AudioCodec→HaishinKit~Extension.CMSampleBufferHaishinKit~Codec.Format→HaishinKit~Extension.AVAudioBufferHaishinKit~Codec.VTSessionConvertible→HaishinKit~Extension.CMSampleBufferHaishinKit~Codec.VideoCodec→HaishinKit~Extension.CMSampleBufferHaishinKit~Codec.VideoCodec→HaishinKit~Extension.CMTime
- Direction
- HaishinKit~Codec uses HaishinKit~Extension, so a change to HaishinKit~Extension can break HaishinKit~Codec, while a change to HaishinKit~Codec can't break HaishinKit~Extension.
- Position
- Below the diagonal: HaishinKit~Codec uses a module listed above it, which is the healthy direction.
27→15 HaishinKit~Codec uses SRTHaishinKit~Extension✕
- Connections
- 2 pairs of types, where a type in HaishinKit~Codec uses a type in SRTHaishinKit~Extension.
- The types involved
HaishinKit~Codec.ADTSHeader→SRTHaishinKit~Extension.CMFormatDescriptionHaishinKit~Codec.VideoCodec→SRTHaishinKit~Extension.CMFormatDescription
- Direction
- HaishinKit~Codec uses SRTHaishinKit~Extension, so a change to SRTHaishinKit~Extension can break HaishinKit~Codec, while a change to HaishinKit~Codec can't break SRTHaishinKit~Extension.
- Position
- Below the diagonal: HaishinKit~Codec uses a module listed above it, which is the healthy direction.
27→16 HaishinKit~Codec uses HaishinKit~Util✕
- Connections
- 1 pair of types, where a type in HaishinKit~Codec uses a type in HaishinKit~Util.
- The types involved
HaishinKit~Codec.AudioCodec→HaishinKit~Util.AudioTime
- Direction
- HaishinKit~Codec uses HaishinKit~Util, so a change to HaishinKit~Util can break HaishinKit~Codec, while a change to HaishinKit~Codec can't break HaishinKit~Util.
- Position
- Below the diagonal: HaishinKit~Codec uses a module listed above it, which is the healthy direction.
27→26 HaishinKit~Codec uses HaishinKit~Mixer✕
- Connections
- 1 pair of types, where a type in HaishinKit~Codec uses a type in HaishinKit~Mixer.
- The types involved
HaishinKit~Codec.AudioCodec→HaishinKit~Mixer.AudioRingBuffer
- Direction
- HaishinKit~Codec uses HaishinKit~Mixer, so a change to HaishinKit~Mixer can break HaishinKit~Codec, while a change to HaishinKit~Codec can't break HaishinKit~Mixer.
- Position
- Below the diagonal: HaishinKit~Codec uses a module listed above it, which is the healthy direction.
28→8 HaishinKit~View uses HaishinKit~Extension✕
- Connections
- 12 pairs of types, where a type in HaishinKit~View uses a type in HaishinKit~Extension.
- The types involved
HaishinKit~View.MTHKView→HaishinKit~Extension.AVAudioBufferHaishinKit~View.MTHKView→HaishinKit~Extension.AVAudioPCMBufferHaishinKit~View.MTHKView→HaishinKit~Extension.AVAudioTimeHaishinKit~View.MTHKView→HaishinKit~Extension.AVLayerVideoGravityHaishinKit~View.MTHKView→HaishinKit~Extension.CMSampleBufferHaishinKit~View.MTHKViewRepresentable→HaishinKit~Extension.AVLayerVideoGravityHaishinKit~View.PiPHKView→HaishinKit~Extension.AVAudioBufferHaishinKit~View.PiPHKView→HaishinKit~Extension.AVAudioPCMBufferHaishinKit~View.PiPHKView→HaishinKit~Extension.AVAudioTimeHaishinKit~View.PiPHKView→HaishinKit~Extension.AVLayerVideoGravityHaishinKit~View.PiPHKView→HaishinKit~Extension.CMSampleBufferHaishinKit~View.PiPHKViewRepresentable→HaishinKit~Extension.AVLayerVideoGravity
- Direction
- HaishinKit~View uses HaishinKit~Extension, so a change to HaishinKit~Extension can break HaishinKit~View, while a change to HaishinKit~View can't break HaishinKit~Extension.
- Position
- Below the diagonal: HaishinKit~View uses a module listed above it, which is the healthy direction.
28→21 HaishinKit~View uses RTMPHaishinKit~Util✕
- Connections
- 2 pairs of types, where a type in HaishinKit~View uses a type in RTMPHaishinKit~Util.
- The types involved
HaishinKit~View.MTHKViewRepresentable→RTMPHaishinKit~Util.ContextHaishinKit~View.PiPHKViewRepresentable→RTMPHaishinKit~Util.Context
- Direction
- HaishinKit~View uses RTMPHaishinKit~Util, so a change to RTMPHaishinKit~Util can break HaishinKit~View, while a change to HaishinKit~View can't break RTMPHaishinKit~Util.
- Position
- Below the diagonal: HaishinKit~View uses a module listed above it, which is the healthy direction.
28→23 HaishinKit~View uses HaishinKit~Stream✕
- Connections
- 2 pairs of types, where a type in HaishinKit~View uses a type in HaishinKit~Stream.
- The types involved
HaishinKit~View.MTHKView→HaishinKit~Stream.StreamConvertibleHaishinKit~View.PiPHKView→HaishinKit~Stream.StreamConvertible
- Direction
- HaishinKit~View uses HaishinKit~Stream, so a change to HaishinKit~Stream can break HaishinKit~View, while a change to HaishinKit~View can't break HaishinKit~Stream.
- Position
- Below the diagonal: HaishinKit~View uses a module listed above it, which is the healthy direction.
28→24 HaishinKit~View uses HaishinKit~Screen✕
- Connections
- 2 pairs of types, where a type in HaishinKit~View uses a type in HaishinKit~Screen.
- The types involved
HaishinKit~View.MTHKView→HaishinKit~Screen.VideoEffectHaishinKit~View.PiPHKView→HaishinKit~Screen.UIColor
- Direction
- HaishinKit~View uses HaishinKit~Screen, so a change to HaishinKit~Screen can break HaishinKit~View, while a change to HaishinKit~View can't break HaishinKit~Screen.
- Position
- Below the diagonal: HaishinKit~View uses a module listed above it, which is the healthy direction.
28→26 HaishinKit~View uses HaishinKit~Mixer✕
- Connections
- 2 pairs of types, where a type in HaishinKit~View uses a type in HaishinKit~Mixer.
- The types involved
HaishinKit~View.MTHKView→HaishinKit~Mixer.MediaMixerHaishinKit~View.PiPHKView→HaishinKit~Mixer.MediaMixer
- Direction
- HaishinKit~View uses HaishinKit~Mixer, so a change to HaishinKit~Mixer can break HaishinKit~View, while a change to HaishinKit~View can't break HaishinKit~Mixer.
- Position
- Below the diagonal: HaishinKit~View uses a module listed above it, which is the healthy direction.
29→1 SRTHaishinKit~SRT uses HaishinKit~Network✕
- Connections
- 5 pairs of types, where a type in SRTHaishinKit~SRT uses a type in HaishinKit~Network.
- The types involved
SRTHaishinKit~SRT.SRTConnection→HaishinKit~Network.NetworkConnectionSRTHaishinKit~SRT.SRTConnection→HaishinKit~Network.NetworkMonitorSRTHaishinKit~SRT.SRTSocket→HaishinKit~Network.NetworkMonitorSRTHaishinKit~SRT.SRTSocket→HaishinKit~Network.NetworkTransportReportSRTHaishinKit~SRT.SRTStream→HaishinKit~Network.NetworkMonitorEvent
- Direction
- SRTHaishinKit~SRT uses HaishinKit~Network, so a change to HaishinKit~Network can break SRTHaishinKit~SRT, while a change to SRTHaishinKit~SRT can't break HaishinKit~Network.
- Position
- Below the diagonal: SRTHaishinKit~SRT uses a module listed above it, which is the healthy direction.
29→6 SRTHaishinKit~SRT uses RTMPHaishinKit~Extension✕
- Connections
- 4 pairs of types, where a type in SRTHaishinKit~SRT uses a type in RTMPHaishinKit~Extension.
- The types involved
SRTHaishinKit~SRT.SRTConnection→RTMPHaishinKit~Extension.URLSRTHaishinKit~SRT.SRTSession→RTMPHaishinKit~Extension.URLSRTHaishinKit~SRT.SRTSessionFactory→RTMPHaishinKit~Extension.URLSRTHaishinKit~SRT.SRTSocketURL→RTMPHaishinKit~Extension.URL
- Direction
- SRTHaishinKit~SRT uses RTMPHaishinKit~Extension, so a change to RTMPHaishinKit~Extension can break SRTHaishinKit~SRT, while a change to SRTHaishinKit~SRT can't break RTMPHaishinKit~Extension.
- Position
- Below the diagonal: SRTHaishinKit~SRT uses a module listed above it, which is the healthy direction.
29→7 SRTHaishinKit~SRT uses SRTHaishinKit~Util✕
- Connections
- 1 pair of types, where a type in SRTHaishinKit~SRT uses a type in SRTHaishinKit~Util.
- The types involved
SRTHaishinKit~SRT.SRTSocketURL→SRTHaishinKit~Util.AddrInfo
- Direction
- SRTHaishinKit~SRT uses SRTHaishinKit~Util, so a change to SRTHaishinKit~Util can break SRTHaishinKit~SRT, while a change to SRTHaishinKit~SRT can't break SRTHaishinKit~Util.
- Position
- Below the diagonal: SRTHaishinKit~SRT uses a module listed above it, which is the healthy direction.
29→8 SRTHaishinKit~SRT uses HaishinKit~Extension✕
- Connections
- 9 pairs of types, where a type in SRTHaishinKit~SRT uses a type in HaishinKit~Extension.
- The types involved
SRTHaishinKit~SRT.CType→HaishinKit~Extension.DataSRTHaishinKit~SRT.SRTConnection→HaishinKit~Extension.DataSRTHaishinKit~SRT.SRTSocket→HaishinKit~Extension.DataSRTHaishinKit~SRT.SRTSocketOption→HaishinKit~Extension.DataSRTHaishinKit~SRT.SRTStream→HaishinKit~Extension.AVAudioBufferSRTHaishinKit~SRT.SRTStream→HaishinKit~Extension.AVAudioPCMBufferSRTHaishinKit~SRT.SRTStream→HaishinKit~Extension.AVAudioTimeSRTHaishinKit~SRT.SRTStream→HaishinKit~Extension.CMSampleBufferSRTHaishinKit~SRT.SRTStream→HaishinKit~Extension.Data
- Direction
- SRTHaishinKit~SRT uses HaishinKit~Extension, so a change to HaishinKit~Extension can break SRTHaishinKit~SRT, while a change to SRTHaishinKit~SRT can't break HaishinKit~Extension.
- Position
- Below the diagonal: SRTHaishinKit~SRT uses a module listed above it, which is the healthy direction.
29→9 SRTHaishinKit~SRT uses HaishinKit~Session✕
- Connections
- 5 pairs of types, where a type in SRTHaishinKit~SRT uses a type in HaishinKit~Session.
- The types involved
SRTHaishinKit~SRT.SRTSession→HaishinKit~Session.StreamSessionSRTHaishinKit~SRT.SRTSession→HaishinKit~Session.StreamSessionModeSRTHaishinKit~SRT.SRTSessionFactory→HaishinKit~Session.StreamSessionSRTHaishinKit~SRT.SRTSessionFactory→HaishinKit~Session.StreamSessionFactorySRTHaishinKit~SRT.SRTSessionFactory→HaishinKit~Session.StreamSessionMode
- Direction
- SRTHaishinKit~SRT uses HaishinKit~Session, so a change to HaishinKit~Session can break SRTHaishinKit~SRT, while a change to SRTHaishinKit~SRT can't break HaishinKit~Session.
- Position
- Below the diagonal: SRTHaishinKit~SRT uses a module listed above it, which is the healthy direction.
29→14 SRTHaishinKit~SRT uses SRTHaishinKit~TS✕
- Connections
- 2 pairs of types, where a type in SRTHaishinKit~SRT uses a type in SRTHaishinKit~TS.
- The types involved
SRTHaishinKit~SRT.SRTStream→SRTHaishinKit~TS.TSReaderSRTHaishinKit~SRT.SRTStream→SRTHaishinKit~TS.TSWriter
- Direction
- SRTHaishinKit~SRT uses SRTHaishinKit~TS, so a change to SRTHaishinKit~TS can break SRTHaishinKit~SRT, while a change to SRTHaishinKit~SRT can't break SRTHaishinKit~TS.
- Position
- Below the diagonal: SRTHaishinKit~SRT uses a module listed above it, which is the healthy direction.
29→19 SRTHaishinKit~SRT uses RTCHaishinKit~RTC✕
- Connections
- 1 pair of types, where a type in SRTHaishinKit~SRT uses a type in RTCHaishinKit~RTC.
- The types involved
SRTHaishinKit~SRT.SRTLogger→RTCHaishinKit~RTC.Level
- Direction
- SRTHaishinKit~SRT uses RTCHaishinKit~RTC, so a change to RTCHaishinKit~RTC can break SRTHaishinKit~SRT, while a change to SRTHaishinKit~SRT can't break RTCHaishinKit~RTC.
- Position
- Below the diagonal: SRTHaishinKit~SRT uses a module listed above it, which is the healthy direction.
29→23 SRTHaishinKit~SRT uses HaishinKit~Stream✕
- Connections
- 5 pairs of types, where a type in SRTHaishinKit~SRT uses a type in HaishinKit~Stream.
- The types involved
SRTHaishinKit~SRT.SRTSession→HaishinKit~Stream.StreamConvertibleSRTHaishinKit~SRT.SRTStream→HaishinKit~Stream.IncomingStreamSRTHaishinKit~SRT.SRTStream→HaishinKit~Stream.OutgoingStreamSRTHaishinKit~SRT.SRTStream→HaishinKit~Stream.StreamOutputSRTHaishinKit~SRT.SRTStream→HaishinKit~Stream.StreamReadyState
- Direction
- SRTHaishinKit~SRT uses HaishinKit~Stream, so a change to HaishinKit~Stream can break SRTHaishinKit~SRT, while a change to SRTHaishinKit~SRT can't break HaishinKit~Stream.
- Position
- Below the diagonal: SRTHaishinKit~SRT uses a module listed above it, which is the healthy direction.
29→26 SRTHaishinKit~SRT uses HaishinKit~Mixer✕
- Connections
- 1 pair of types, where a type in SRTHaishinKit~SRT uses a type in HaishinKit~Mixer.
- The types involved
SRTHaishinKit~SRT.SRTStream→HaishinKit~Mixer.MediaMixer
- Direction
- SRTHaishinKit~SRT uses HaishinKit~Mixer, so a change to HaishinKit~Mixer can break SRTHaishinKit~SRT, while a change to SRTHaishinKit~SRT can't break HaishinKit~Mixer.
- Position
- Below the diagonal: SRTHaishinKit~SRT uses a module listed above it, which is the healthy direction.
29→27 SRTHaishinKit~SRT uses HaishinKit~Codec✕
- Connections
- 3 pairs of types, where a type in SRTHaishinKit~SRT uses a type in HaishinKit~Codec.
- The types involved
SRTHaishinKit~SRT.SRTStream→HaishinKit~Codec.AudioCodecSettingsSRTHaishinKit~SRT.SRTStream→HaishinKit~Codec.FormatSRTHaishinKit~SRT.SRTStream→HaishinKit~Codec.VideoCodecSettings
- Direction
- SRTHaishinKit~SRT uses HaishinKit~Codec, so a change to HaishinKit~Codec can break SRTHaishinKit~SRT, while a change to SRTHaishinKit~SRT can't break HaishinKit~Codec.
- Position
- Below the diagonal: SRTHaishinKit~SRT uses a module listed above it, which is the healthy direction.
At a glance — Code Health
At a glance — Architecture
At a glance — Maturity
At a glance — Readiness
At a glance — Security
At a glance — Performance
Security & Compliance — OWASP Top-10 mapping
| OWASP category | Findings | Severity |
|---|---|---|
| A05:2025 — Injection | 7 | High / Critical |
| A03:2025 — Software Supply Chain Failures | 6 | Medium |
Roadmap
First, integrate automated security scanning into the CI pipeline to prevent regressions and maintain a changelog to ensure clear release hygiene. Next, improve test quality by adding assertions to the identified audio-related test files and enforce CI gates that block merges if the test suite fails. Finally, optimize performance by increasing allocation-aware patterns on hot paths to reduce runtime overhead.
| Do this | Helps | Effort | Dimension |
|---|---|---|---|
| Add a SAST step to CI running what this repository's stack ships: CodeQL's Swift pack (Swift/Xcode) — or `semgrep --config=auto`, which runs on any language — so a security regression fails the build instead of landing. | +6.6 pts | Medium | Security & performance tooling |
| Keep a changelog (e.g. Keep-a-Changelog) recording what shipped in each release. | +4.5 pts | Medium | Release Hygiene |
| Resolve the 12 No assertions finding(s) in Test Quality — start with AudioRingBufferTests.swift (4), AudioCodecTests.swift (2), AudioMixerTrackTests.swift (2). | +2.4 pts | Medium | Test Quality |
| Resolve the 1 REDACTED finding(s) in Static Analysis (SAST) — start with REDACTED. | +0.8 pts | Low | Static Analysis (SAST) |
| Resolve the 1 REDACTED finding(s) in Static Analysis (SAST) — start with REDACTED. | +0.8 pts | Low | Static Analysis (SAST) |
| Resolve the 1 REDACTED finding(s) in Supply-chain Provenance & Signing — start with REDACTED. | +0.7 pts | Low | Supply-chain Provenance & Signing |
| Resolve the 1 REDACTED finding(s) in Supply-chain Provenance & Signing. | +0.7 pts | Low | Supply-chain Provenance & Signing |
| Resolve the 1 REDACTED finding(s) in Supply-chain Provenance & Signing — start with REDACTED. | +0.7 pts | Low | Supply-chain Provenance & Signing |
File quality
| File | Score | Band | Worst signal |
|---|---|---|---|
| REDACTED | 3.7 | Mixed | Static Analysis (SAST): High: REDACTED |
| REDACTED | 5.1 | Mixed | Static Analysis (SAST): High: REDACTED |
| REDACTED | 5.8 | Mixed | Static Analysis (SAST): High: REDACTED |
| RTCHaishinKit/Sources/RTC/RTCStream.swift | 5.9 | Mixed | Code Duplication: Duplicated block (16 lines × 2) |
| HaishinKit/Sources/Mixer/AudioCaptureUnit.swift | 6.3 | Near-clean | Code Duplication: Duplicated block (10 lines × 2) |
| HaishinKit/Sources/View/MTHKView.swift | 6.3 | Near-clean | Code Duplication: Duplicated block (10 lines × 2) |
| HaishinKit/Sources/Util/ByteArray.swift | 7.0 | Near-clean | God Classes: TooManyMethods: ByteArray |
| RTMPHaishinKit/Sources/AMF/AMF3Serializer.swift | 7.0 | Near-clean | Code Duplication: Duplicated block (7 lines × 2) |
| RTMPHaishinKit/Sources/RTMP/RTMPStream.swift | 7.1 | Near-clean | Cognitive Complexity: RTMPStream.append (cognitive 35) |
| Examples/iOS/PublishViewModel.swift | 7.1 | Near-clean | Code Duplication: Duplicated block (24–25 lines × 2) |
| RTMPHaishinKit/Sources/RTMP/RTMPConnection.swift | 7.1 | Near-clean | Cyclomatic Complexity: RTMPConnection.connect (cyclomatic 27) |
| MoQTHaishinKit/Sources/MoQTSocket.swift | 7.1 | Near-clean | Code Duplication: Duplicated block (19 lines × 2) |
| HaishinKit/Sources/Stream/StreamRecorder.swift | 7.2 | Near-clean | Cyclomatic Complexity: StreamRecorder.makeWriterInput (cyclomatic 19) |
| HaishinKit/Sources/Mixer/MediaMixer.swift | 7.2 | Near-clean | Cyclomatic Complexity: MediaMixer.startRunning (cyclomatic 17) |
| HaishinKit/Tests/Mixer/AudioRingBufferTests.swift | 7.2 | Near-clean | Test Quality: No assertions: monoAppendSampleBuffer_920 |
| REDACTED | 7.2 | Near-clean | Static Analysis (SAST): High: REDACTED |
| REDACTED | 7.2 | Near-clean | Static Analysis (SAST): High: REDACTED |
| HaishinKit/Sources/Mixer/AudioRingBuffer.swift | 7.4 | Near-clean | Cyclomatic Complexity: AudioRingBuffer.render (cyclomatic 24) |
| RTCHaishinKit/Sources/SDP/SDPMediaDescription.swift | 7.8 | Near-clean | Cyclomatic Complexity: SDPMediaDescription.init (cyclomatic 20) |
| RTCHaishinKit/Sources/RTC/RTCPeerConnection.swift | 7.8 | Near-clean | Cyclomatic Complexity: RTCPeerConnection.init (cyclomatic 18) |
How the grades work
A definite problem that already costs you something and drags the score down: a missing authorisation check, a dependency with a known exploit, a build that does not reproduce. Failure here tends to cause failures elsewhere.
Likely wrong, but not failing yet. It degrades the codebase over a longer horizon and can cause failures elsewhere — not urgent this week, not something to carry for two years either.
Recorded, with no effect on how the codebase functions. Present so the survey is complete, not because it needs doing.
Something this survey could not settle from the outside, and which could be critical or serious. Either a control was required and no positive evidence of it exists in the repository — a backup job that nothing shows was ever restored from proves nothing about restores — or our own analysis could not run over that part of the tree. This is not a clean result. These are excluded from the score rather than awarded a pass, so the number on the cover neither rewards nor penalises them: if you act on this survey without resolving them, you carry that risk yourself. Each one is named under Limitations.
Methodology & how to trust this report
Watchdog is a deep, periodic assessment — run each sprint, monthly, or quarterly, taking the time to go wider and deeper than a quick check and surfacing in one coherent report what you'd otherwise piece together from a dozen separate tools. It scores deterministically: the same commit yields the same score, every run. 40 of 40 evaluated dimensions are computed purely by tools and static analysis (confidence 1.0); none rely on LLM judgement. Overall confidence is 0.8 — the weighted average across measured dimensions; it falls as more of the score leans on LLM-assisted judgement and rises when it's fully tool-backed.
What we checked — 40 dimensions across the health lenses
- Can you open the finding? Real findings cite a repo-relative file and line you can open at the cited line — never an absolute scratch path. Here, 145 of 154 do; the remainder are repo-wide signals — a dimension-level measurement, not a single line.
- Is there a tool behind the number? Every score below names the method that produced it — Roslyn, git, a scanner, or (for a handful of documentation/naming dimensions) an LLM labelled sampled · advisory — not a narrative.
- Does re-running give the same result? Run it again on the same commit and the score — and this report, byte for byte — is identical. A report whose numbers move between runs is describing the run, not the code.
Tools & methods
| Method | Backs | Version | Evaluator |
|---|---|---|---|
| Roslyn static analysis | Complexity, cohesion, coupling, dead code, API surface, layering | 5.3.0 | ✓ deterministic |
| Native secret scanner | Hardcoded secrets / credentials | 1.0.0 | ✓ deterministic |
| Watchdog duplication detector (in-process) | Code duplication | 1.0.0 | ✓ deterministic |
| Coverage (coverlet / dotnet-coverage) | Line & branch coverage | 10.0.400 | ✓ deterministic |
| NuGet / dotnet | Outdated, vulnerable & deprecated dependencies | 10.0.400 | ✓ deterministic |
| git / LibGit2Sharp | Churn hotspots, knowledge concentration, history | 2.43.0 · 0.31.0 | ✓ deterministic |
| gitleaks · semgrep · trivy | Secrets in history, SAST, CVEs, IaC & container, PII / GDPR | 1.86.0 · 0.69.3 | ✓ deterministic |
| LLM (sampled · advisory) | Documentation quality, ADR conformance, naming — sampled over a bounded sample; advisory, never a deterministic measurement | — | ◐ LLM · sampled · advisory |
Run transparency — what happened this run
- D8 Code Coverage — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Coverage NOT MEASURED: the Swift half could not be measured — the Swift suite in . produced no coverage export. Coverage is excluded from the score rather than counted as a near-zero. This is OUR limitation, not a defect in the repo. In the meantime, commit (or publish into the working tree) the lcov/Cobertura report your CI produces and the real number is read on the next scan. You can widen what we reach: optional: commit the lcov/Cobertura report your CI produces, and the real number is read on the next scan.
- D11 Test Reliability — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Test source is present (.swift) and this repository declares a SwiftPM test suite (HaishinKit), but it was not re-run: no test result was produced. Not scored — this is a gap in the analyzer's language coverage, not a finding about this repository.
- D14 License Compliance — measured, with a gap in what it reached — Watchdog measured this, but not all of it. What it did not reach is a gap on our side — a collector, parser or image we have not built yet — so the numbers on that dimension cover less than the repository, and the part left out is not evidence that it would have passed. This repository declares a Swift Package.swift/Package.resolved, but the licence verdict published here was taken over its gem dependencies. Nothing was read about its SwiftPM dependencies' licensing in either direction, and a clean score on this card must not be read as covering them.
- D16 Bus Factor — not measured this run — This is a true statement about the repository that carries nothing for its owner to act on, so it is reported here rather than as a defect in their code. Single-maintainer repository — bus factor is not applicable (89 contributor(s) across 3075 commit(s) sampled, automation and bot accounts excluded). One of them holds 91% of the history; the other 88 hold 0.1% each on average, below the 5% at which there is somebody to hand the work to. That is a single maintainer with drive-by contributors, not a team whose knowledge has concentrated — so the bus factor is not applicable and there is nothing here for the owner to act on.
- D19 Documentation Quality — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This kind did not reach the 95 % precision gate in three adjudicated runs (docs/plans/deterministic-engine/adjudication/D19-sample3-v3.md), so by the pre-registered fallback it publishes no row until a re-measurement shows it does. The candidates are counted here, not reported as findings, and the score does not include them.
- D21 Naming Consistency — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. D21's deterministic naming rules are gated on C# first (docs/plans/deterministic-engine.md, P5): each other language is switched on only after its own concept suite and A/B gate pass. Until then its declarations carry no naming verdict this run — this says nothing about whether its names are consistent.
- D22 Internal API Consistency — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. D22's deterministic call-shape rules are gated on C# first (docs/plans/deterministic-engine.md, P5): each other language is switched on only after its own concept suite and A/B gate pass. This says nothing about whether that surface is consistent.
- D24 Comment Value — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check's reader does not cover the language this repository's product is written in, so it had nothing of the product to read. That is a gap in this analyzer's language reach — not a finding about this repository.
- D27 Navigability — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Navigability is taken over call sites whose callee resolved. For C# that population includes calls into referenced assemblies; for this language only calls declared inside the repository count, so the abstention threshold reads the repository's use of its standard library as a resolution failure. That is a limit of this analyzer, not a build problem in this repository.
- D32 Data Compliance (PII/GDPR) — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. `Examples/iOS/PlaybackView.swift`, `Examples/iOS/PlaybackViewModel.swift`, `Examples/iOS/PreferenceView.swift`, `Examples/iOS/PublishView.swift`, `Examples/iOS/PublishViewModel.swift`, … (+55 more) produced a parse error, so every rule in this engine's `gdpr.yml` was absent there. That absence is NOT a clean result: these rules detect personal data crossing a boundary into a log sink, a URL or browser storage, and a file that was never parsed cannot report any of the three. The rest of the tree analysed normally and its rows above stand; only these files are unaccounted for. You can widen what we reach: fix the syntax error (or exclude the file deliberately) and re-scan to cover it.
- AX1 Captive dependencies — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads Microsoft.Extensions.DependencyInjection registrations in C# and Spring beans in Java/Kotlin only, and this repository defines its own container in HaishinKit/Sources/Session/StreamSessionBuilderFactory.swift, whose lifetimes are not modelled yet, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- AX6 Interface segregation — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is computed over the public interfaces this run's compilations declare, and none was loaded, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- C1 Data Protection — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. These personal data controls are read from declarative annotations, request middleware, entity/column names and guard methods in a C# source model, and none was loaded on this run, so there was nothing to gather. That is a gap in this analyzer's language reach — not a finding that the repository lacks personal data controls.
- C2 Access Controls — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. These authorization controls are read from declarative annotations, request middleware, entity/column names and guard methods in a C# source model, and none was loaded on this run, so there was nothing to gather. That is a gap in this analyzer's language reach — not a finding that the repository lacks authorization controls.
- C3 Audit Trail — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. These audit controls are read from declarative annotations, request middleware, entity/column names and guard methods in a C# source model, and none was loaded on this run, so there was nothing to gather. That is a gap in this analyzer's language reach — not a finding that the repository lacks audit controls.
- GD1 Unfinished & placeholder code — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, F#, JavaScript/TypeScript, Dart, Ruby and Scala source only, and no C#, F#, JavaScript/TypeScript, Dart, Ruby or Scala was found, and this repository's Swift, c is not read yet, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- IC1 Incompleteness & stubs — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, JavaScript/TypeScript, Java, Dart, Ruby and Scala source only, and no C#, JavaScript/TypeScript, Java, Dart, Ruby or Scala was found, and this repository's Swift, c is not read yet, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- P1 CI/CD gates — measured, with a gap in what it reached — Watchdog measured this, but not all of it. What it did not reach is a gap on our side — a collector, parser or image we have not built yet — so the numbers on that dimension cover less than the repository, and the part left out is not evidence that it would have passed. A CI pipeline exists and the word "test" appears, but no explicit test-runner invocation (your stack's test command, or a test job) was matched — so either the gate runs tests through a step this pass could not recognise, or "test" is incidental here (a path, "latest", a reporter). Which of the two it is cannot be settled from this dimension's evidence; the coverage dimensions report whether a suite exists at all. You can widen what we reach: name the test runner explicitly in the pipeline step (your stack's test command, or a job named for the suite) so the gate is unambiguous to a reader and to this pass.
- P5 DR & Backup — not measured this run — This is a true statement about the repository that carries nothing for its owner to act on, so it is reported here rather than as a defect in their code. No backup/snapshot/replication config, RTO/RPO or restore-procedure documentation was found — and no production persistence was detected either (no data-access packages, no data-store services, no database resources), so there is nothing in this repository whose loss a DR control would recover. If this system's data lives in a platform or ops repo we can't see, that's where the DR evidence belongs.
- P8 Schema migrations — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads EF Core usage in C# and the schema tooling its file scan recognises only, and no .NET project was loaded, and this repository's language is not one the scan models, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- S1 Web-Security Posture — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. These web-security controls are read from declarative annotations, request middleware, entity/column names and guard methods in a C# source model, and none was loaded on this run, so there was nothing to gather. That is a gap in this analyzer's language reach — not a finding that the repository lacks web-security controls.
- X1 Async correctness — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and JavaScript/TypeScript, Python, Dart, Ruby, Scala, Rust and Kotlin source only, and no C# was loaded and no JavaScript/TypeScript, Python, Dart, Ruby, Scala, Rust or Kotlin was found in this repository, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X12 Unreachable branch — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and JavaScript/TypeScript, Python, Dart, Ruby, Scala and Kotlin source only, and no C# was loaded and no JavaScript/TypeScript, Python, Dart, Ruby, Scala or Kotlin was found in this repository, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X13 Undrained process stream — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and JavaScript/TypeScript, Python, Dart, Ruby, Scala and Kotlin source only, and no C# was loaded and no JavaScript/TypeScript, Python, Dart, Ruby, Scala or Kotlin was found in this repository, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X15 Unvalidated length from an untrusted reader — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and JavaScript/TypeScript, Java, Kotlin, Scala, PHP, Ruby, Python, Go, Rust and Dart source only, and no C# was loaded and no JavaScript/TypeScript, Java, Kotlin, Scala, PHP, Ruby, Python, Go, Rust or Dart was found in this repository, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X16 Unfloored truncation loop — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and JavaScript/TypeScript, Java, PHP, Dart, Ruby, Scala and Kotlin source only, and no C# was loaded and no JavaScript/TypeScript, Java, PHP, Dart, Ruby, Scala or Kotlin was found in this repository, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X17 Uncapped recursion over a caller-supplied document — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and JavaScript/TypeScript, Python, Dart, Ruby, Scala and Kotlin source only, and no C# was loaded and no JavaScript/TypeScript, Python, Dart, Ruby, Scala or Kotlin was found in this repository, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X18 Disposal-pattern correctness — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and JavaScript/TypeScript, Java, Kotlin, Dart, Ruby, Scala and PHP source only, and no C# was loaded and no JavaScript/TypeScript, Java, Kotlin, Dart, Ruby, Scala or PHP was found in this repository, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X19 Unrestored process-global state — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and JavaScript/TypeScript, Java, Kotlin, Python, Dart, Ruby, Scala and PHP source only, and no C# was loaded and no JavaScript/TypeScript, Java, Kotlin, Python, Dart, Ruby, Scala or PHP was found in this repository, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X2 Cancellation propagation — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and JavaScript/TypeScript, Go, PHP, Dart, Kotlin, Ruby, Scala, Java, Python and Rust source only, and no C# was loaded and no JavaScript/TypeScript, Go, PHP, Dart, Kotlin, Ruby, Scala, Java, Python or Rust was found in this repository, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X22 Contradicted release guard — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and Java, TypeScript/JavaScript, Python, Dart, Ruby, Scala, Kotlin and PHP source only, and no C# was loaded, and this repository's C, Swift is not read yet, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X23 Unguarded diagnostic materialisation — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and JavaScript/TypeScript, Java, F#, Python, Dart, Ruby, Scala, Kotlin and PHP source only, and no C# was loaded and no JavaScript/TypeScript, Java, F#, Python, Dart, Ruby, Scala, Kotlin or PHP was found in this repository, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X24 Document value interpolated into markup unescaped — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and JavaScript/TypeScript, Java, Scala, Ruby and Python source only, and no C# was loaded and no JavaScript/TypeScript, Java, Scala, Ruby or Python was found in this repository, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X25 Inert configuration knob — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and JavaScript/TypeScript, Java, Kotlin, Scala, PHP, Erlang, Python, Dart and Ruby source only, and no C# was loaded and no JavaScript/TypeScript, Java, Kotlin, Scala, PHP, Erlang, Python, Dart or Ruby was found in this repository, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X29 Per-element action decided by a fixed element — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and JavaScript/TypeScript, Java, Rust, Dart, Ruby, Scala and Kotlin source only, and no C# was loaded and no JavaScript/TypeScript, Java, Rust, Dart, Ruby, Scala or Kotlin was found in this repository, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X30 Support guard that admits what it rejects — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and Scala, JavaScript/TypeScript, Java, Kotlin, Python, PHP, Go, Rust, Dart and Ruby source only, and no C# was loaded and no Scala, JavaScript, TypeScript, Java, Kotlin, Python, PHP, Go, Rust, Dart or Ruby was found in this repository, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X4 Structured logging — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax, and JavaScript/TypeScript, Java, Kotlin, Python, PHP, Dart, Ruby, Scala and Rust source only, and no C# was loaded and no JavaScript/TypeScript, Java, Kotlin, Python, PHP, Dart, Ruby, Scala or Rust was found in this repository, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X5 Nullable reference types — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads C# syntax and MSBuild project configuration, TypeScript source and its tsconfig files, Java source and its package and module declarations, PHP source and its PHPStan and Psalm configuration, Dart source and its pubspec language version, Ruby source and its Sorbet and Steep configuration, Scala source and its build's explicit-nulls, WartRemover and Scalafix settings, and Kotlin source only, and no C# was loaded, no TypeScript was found, and this repository's C, Swift is not read yet, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
Limitations & what we did not check
Watchdog assesses the repository exactly as committed, and only the repository. By design it does not reach outside the source tree: the live cloud account, the running CI/CD pipeline, the host's branch-protection and approval rules, the production configuration, or a restore actually exercised against a backup are all out of scope. That boundary is a feature, not a gap — a repo-relative, deterministic scan re-runs identically on any commit and every finding opens at a real file and line, where a live audit can neither be reproduced nor traced. The visible consequence is that controls which leave no in-repo evidence are reported as "not evidenced" and excluded from the score rather than awarded a number a static scan cannot justify.
Per-dimension blind spots
- D1 Cyclomatic Complexity: Cyclomatic complexity counts branches statically — it cannot tell an essential decision tree from accidental tangle, nor see complexity that lives in data or configuration (large switch-case token tables, DSL lexers/parsers, data-as-code rule tables) rather than control flow: a tokenizer's many single-character cases read as high complexity though each branch is trivial.
- D2 Cognitive Complexity: Cognitive-complexity heuristics approximate how hard code is to follow; genuine domain difficulty and well-named intent that eases reading are not captured.
- D3 God Classes: "God class" is sized by members and responsibilities visible in the type — a deliberately broad facade over a coherent subsystem can read the same as an accidental grab-bag. For front-end JS the file-length check is cohesion-aware (a single-responsibility module — one class/IIFE — earns a 3× threshold), but cohesion is approximated from top-level declarations, not true dependency structure.
- D4 Code Duplication: Duplication is token-similarity — an in-process token-stream comparison over sliding windows, with type-aware normalization — so it finds copy-paste, not semantic duplication expressed differently. Committed machine-written code (scaffolded migrations, designer/codegen output, protobuf/OpenAPI stubs, model snapshots) is EXCLUDED — its repetition is the tool's, not the team's — so the score reflects hand-written duplication only.
- D5 Coupling: Coupling is measured between projects/assemblies — runtime coupling through DI, reflection, messaging or shared databases is invisible to a static reference graph.
- D6 Cohesion (LCOM4): LCOM4 cohesion is syntactic — it infers connectivity from which methods touch which fields/methods by name, not from real runtime behaviour or intent.
- D9 Test Distribution: The test-pyramid shape is inferred from project/folder naming and references, with a single test host bucketed per-file by its path tier and content signals — a suite that names tiers unconventionally and gives no per-file signal can still be mis-bucketed.
- D10 Test Quality: Assertion density is structural — it cannot tell a meaningful behavioural assertion from a trivial one, only that an assertion is present.
- D12 Dependency Hygiene: Dependency health reads manifests and lockfiles — a vulnerability in a vendored/copied dependency, or risk from how a dependency is actually used, is outside this view.
- D13 Secret Scanning: Secret detection is signature- and entropy-based on the current tree — a secret that does not match a known pattern, or one already rotated, will not be flagged (a clean scan is "nothing matched", not "no secrets exist").
- D14 License Compliance: License compatibility is checked against declared package metadata and a policy — mislabelled or missing license metadata, and obligations that depend on how you distribute, are not resolved here.
- D15 Churn × Complexity Hotspots: Churn hotspots come from git history — a freshly imported or squashed repository has no churn signal, and recent rewrites can mask a historically risky file.
- D17 Explicit Debt: Acknowledged-debt signals (TODO/FIXME, suppressions, dead code) are textual — undocumented debt that nobody marked, and debt that lives in design rather than annotations, is invisible. Committed machine-written code (scaffolded migrations, designer/codegen output, generated stubs) is excluded — it is never the team's dead code to delete.
- D26 Project Cohesion: Project focus is sized from members/namespaces per project — a project that is broad by deliberate design reads the same as one that has sprawled.
- D28 Secrets (history): Secret-history scanning sweeps the git log for known patterns — a secret that predates the available history, or never matched a signature, is not found (clean means "nothing matched in the history we can see").
- D29 Static Analysis (SAST): SAST findings are pattern-based (semgrep) — it finds classes of bug it has rules for; logic flaws, auth/authorization gaps and issues needing runtime context are out of reach (and clean means "no rule matched").
- D30 Dependency Vulnerabilities: CVE matching depends on accurate package/version metadata and on the advisory databases — a vulnerability with no published advisory, or in code not declared as a dependency, is not seen. Coverage needs a RESOLVED graph: an unpinned requirements.txt, or a pom without a resolved build, yields partial coverage rather than a clean verdict. An ecosystem the analyzer cannot scan is reported as unmeasured, never as clean.
- D34 Knowledge Freshness: Freshness is decayed commit RECENCY, not comprehension — code read often but rarely committed reads as orphaned, and stable code that genuinely needs no changes is penalised the same as forgotten code; bot/squash commits distort it like the bus factor.
- D35 Change Coupling: Change coupling is co-change in COMMITS — files split across separate commits, or coupled only through a shared config/build step, read as uncoupled, and a sweeping commit (rename/format) is excluded so it doesn't couple everything. It shows that files change together, not WHY: a high coupling can be a healthy cohesive pair as readily as a hidden leak.
- D43 Malicious Dependencies: Only packages some vulnerability database has already NAMED as malicious are seen — a compromise published in the last hours, or never reported at all, is invisible here, and this dimension reading 10 is not evidence that a dependency is trustworthy. There is no typosquat or dependency-confusion analysis: a package nobody has reported is simply absent from the feeds. Coverage is the dependency scan's: an ecosystem that could not be scanned is disclosed as unmeasured, never as clean.
- D44 Platform End-of-Life: The support table is FROZEN, so it goes out of date by losing RECALL: a release that ended support after the table was written is missed until the table is refreshed, and this dimension reading 10 is not evidence that a platform is current. Only platforms the repository DECLARES in a place this pass reads are seen — a runtime named only in a Dockerfile (D31's subject), in a CI workflow (D29's), or in a file this pass does not parse (go.mod, a Gemfile ruby directive) is invisible here, which is why a repository declaring none of them abstains rather than scoring. Only frameworks with a PUBLISHED support policy are tracked: React, Flask and Express publish none, so their age cannot be judged and their absence from a report is not a statement that they are supported.
- AX10 Code composition: Role is inferred from namespace/folder convention, not semantics — a domain concept living in a folder named "Services" reads as application, and the split is lines-of-code, not business value. The business-logic-share score is a SOFT, FLOORED signal: it contributes to the Architecture lens but is floored at the Critical gate, so an infrastructure-heavy design (a gateway, an ETL, a driver) is legitimately low without being nuked to zero.
- AX9 CQS / query purity: Handlers are found by interface/name convention — a query handler using neither is not seen. Mutation is a resolved write/publish invocation (SaveChanges/repository/bus), so a write hidden behind a hand-rolled wrapper, reflection, or a string-keyed service locator resolves to a non-persistence type and isn't flagged; it detects that a query writes state, not whether the write is a legitimate read-side cache update. Clean means "no resolved write/publish in a query body", not a proof of CQS purity.
- M4 Documentation accuracy: Onboarding quality is an LLM read of the docs/setup present — it cannot run the onboarding or measure how long a real new joiner takes; the verdict is sampled and advisory.
- P6 Release Hygiene: Rollback/observability controls are inferred from repo artefacts (pipelines, dashboards-as-code) — controls configured in external tooling, with no in-repo trace, cannot be credited.
Dimensions
D1 · Cyclomatic Complexity
8 method(s) exceeded the cyclomatic complexity threshold of 15; the worst was RTMPConnection.connect at 27. A further 11 method(s) were over the threshold but excluded as flat dispatchers (a long switch/match over independent cases: many branches, almost no nesting), the largest being Name.init at 53 — they are counted neither in the figure above nor in this dimension's score. 9 files carry no cyclomatic complexity row at all for this reason — every one of their over-threshold methods was excluded, so the exclusion is disclosed nowhere in the file itself: SRTHaishinKit/Sources/SRT/SRTSocketOption.Name.swift (Name.init at 53), DebugDescription/AVAudioFormat+DebugExtension.swift (AudioFormatID.debugDescription at 40), RTMPHaishinKit/Sources/RTMP/RTMPStream.swift (Code.level at 40), DebugDescription/AudioStreamBasicDescription+DebugExtension.swift (AudioStreamBasicDescription.readableFormatID at 38), DebugDescription/AudioNode+DebugExtension.swift (AudioUnitParameter.unitName at 29), and 4 more not listed here. They are named here because the per-file figures other dimensions report are taken BEFORE this exclusion, so such a file can show a high maximum complexity elsewhere in this report and nothing here, with nothing to reconcile the two.
What to do
- Bring the 8 bodies over 15 down to 15 or less in Cyclomatic Complexity — start with RTMPConnection.connect (cyclomatic 27), AudioRingBuffer.render (cyclomatic 24), SDPMediaDescription.init (cyclomatic 20). — This score is capped by its worst body, so a finding fixed alone moves it by almost nothing — the next one down takes its place. Refactoring these 8 together lifts Cyclomatic Complexity from 8.7 to about 10.0/10, projected with the scoring formula itself and assuming each lands exactly at 15.
- Enforce Cyclomatic Complexity in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
D2 · Cognitive Complexity
22 method(s) exceeded the cognitive complexity threshold of 15; the worst was StreamRecorder.makeWriterInput at 48.
What to do
- Bring the 22 bodies over 15 down to 15 or less in Cognitive Complexity — start with StreamRecorder.makeWriterInput (cognitive 48), RTMPConnection.connect (cognitive 44), SDPMediaDescription.init (cognitive 38). — This score is capped by its worst body, so a finding fixed alone moves it by almost nothing — the next one down takes its place. Refactoring these 22 together lifts Cognitive Complexity from 7.0 to about 10.0/10, projected with the scoring formula itself and assuming each lands exactly at 15.
- Enforce Cognitive Complexity in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
D3 · God Classes
5 god class(es) detected.
What to do
- Resolve the 3 TooManyMethods finding(s) in God Classes — start with ByteArray.swift (3). — One of this dimension's main actionable groups (3 warning-level).
- Resolve the 1 FileTooLong finding(s) in God Classes — start with RTMPStream.swift. — One of this dimension's main actionable groups (1 warning-level).
- Resolve the 1 MethodTooLong finding(s) in God Classes — start with SRTSocketOption.Name.swift. — One of this dimension's main actionable groups (1 warning-level).
- Enforce God Classes in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
D4 · Code Duplication
66 duplicated block group(s) detected. 13 of the 66 are in trees this repository does not ship — vendored, example/demo, project-template, fixture and benchmark code — and are ranked below the shipped groups rather than excluded from them: the duplication there is real and is still counted in this dimension's score. The dimensions that publish a production-file census leave those trees out of theirs, so this count is deliberately drawn over the wider population.
What to do
- Resolve the 10 Duplicated block (7 lines × 3) finding(s) in Code Duplication — start with ByteArray.swift (10). — One of this dimension's main actionable groups (10 warning-level).
- Resolve the 5 Duplicated block (13 lines × 2) finding(s) in Code Duplication — start with AudioMixerByMultiTrack.swift, MoQTSocket.swift, PublishView.swift. — One of this dimension's main actionable groups (5 warning-level).
- Resolve the 5 Duplicated block (10 lines × 2) finding(s) in Code Duplication — start with AudioCaptureUnit.swift (2), HEVCDecoderConfigurationRecord.swift, MTHKView.swift. — One of this dimension's main actionable groups (5 warning-level).
- Enforce Code Duplication in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Verified — provenance only; does not change the score.
D5 · Coupling
5 production modules (SwiftPM), 0 dependency cycle(s), 0 unstable depended-on module(s). Read from the build's own module declarations; 1 module(s) off the main sequence.
What to do
- Resolve the 1 Off the main sequence finding(s) in Coupling. — One of this dimension's main actionable groups (1 warning-level).
- Enforce Coupling in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
D6 · Cohesion (LCOM4)
13 of 88 classes have LCOM4 above 3.
What to do
- Resolve the 13 Low cohesion finding(s) in Cohesion (LCOM4) — start with CaptureSession.swift (2), HTTPSession.swift, MTHKView.swift. — One of this dimension's main actionable groups (13 warning-level).
- Enforce Cohesion (LCOM4) in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Verified — provenance only; does not change the score.
D9 · Test Distribution
140 test methods: 140 unit, 0 integration, 0 BDD, 0 e2e.
D10 · Test Quality
0 skipped, 15 zero-assertion, no mocking-framework packages referenced (hand-written doubles or no mocking) across 140 tests (1 harness-style project(s) excluded from the assertion penalty).
What to do
- Resolve the 12 No assertions finding(s) in Test Quality — start with AudioRingBufferTests.swift (4), AudioCodecTests.swift (2), AudioMixerTrackTests.swift (2). — One of this dimension's main actionable groups (12 warning-level).
- Resolve the 3 No direct assertions finding(s) in Test Quality — start with StreamSessionBuilderFactoryTests.swift (3). — One of this dimension's main actionable groups (3 recommendation-level).
- Enforce Test Quality in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
D12 · Dependency Hygiene
1 outdated direct SwiftPM dependencies, 0 pinning defect(s). SwiftPM has no package registry: a dependency is a repository URL and its releases are that repository's semver tags, so currency is answered by listing tags rather than by querying an index. Only a newer tag on the SAME MAJOR is reported — a `from:` requirement admits everything below the next major and nothing above it, so a major crossing needs a Package.swift edit rather than an update, and naming the update as its remedy would be wrong. Whether any dependency is DEPRECATED or ABANDONED is not graded and cannot be: a repository publishes no such marker, and there is no registry that could carry one. Known CVEs in this dependency graph are D30's question.
D13 · Secret Scanning
Secret scan ran and found no leaked secrets.
D14 · License Compliance
0 of 154 shipped gem(s) use a banned license. Licences were resolved from rubygems.org over the 154 gem(s) a consumer installs — this repository's runtime declarations closed transitively over its committed Gemfile.lock. Development-group and `add_development_dependency` gems are excluded: they are not distributed with this repository. 2 of them publish no licence on rubygems.org; that is missing data, not a violation, and none of them is charged. ★ COVERAGE OF THIS VERDICT: it grades this repository's gem dependencies and nothing else. The repository also declares a Swift Package.swift/Package.resolved, and the licences of those dependencies were NOT read by this pass — a gap in this engine's coverage, not a statement about them. So this result says the graded closure carries no banned licence; it does NOT say this repository's licensing is clear.
D15 · Churn × Complexity Hotspots
No churn × complexity hotspots in the window.
D17 · Explicit Debt
1 deducted task-comment markers across 25023 LoC (0.0/KLoC) → score 10.0. Task comments only: this repository's language is read without a compiler, so D17's suppression, dead-code and commented-out-code arms did not run and this score counts fewer marker kinds than a .NET repository's would.
What to do
- Resolve the 1 TodoComment finding(s) in Explicit Debt — start with RTCTrackConfiguration.swift. — One of this dimension's main actionable groups (1 warning-level).
- Enforce Explicit Debt in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
D26 · Project Cohesion
1 of 1 build units (Bundler) flagged as possibly oversized/incoherent.
What to do
- Resolve the 1 Projects may be oversized for their cohesion finding(s) in Project Cohesion. — One of this dimension's main actionable groups (1 recommendation-level).
D28 · Secrets (history)
gitleaks scanned the full history AND the current working tree and found no secrets.
D29 · Static Analysis (SAST)
7 finding(s): 0 critical, 7 high, 0 medium, 0 low. 5 unpinned-GitHub-Actions row(s) are reported here but scored by D36 (supply-chain provenance), which measures that posture as `pinned_actions` — one pinning decision is charged once, not once per lens. semgrep hit a parse error in 5 file(s) — `Examples/iOS/PublishViewModel.swift`, `HaishinKit/Tests/Asset/SampleVideo_360x240_5mb/001.ts` (line 1), `HaishinKit/Tests/Asset/SampleVideo_360x240_5mb/003.ts` (line 1), `HaishinKit/Tests/Asset/SampleVideo_360x240_5mb/004.ts` (line 1), `HaishinKit/Tests/Asset/SampleVideo_360x240_5mb_2ch.ts` (line 1) — so no absence of findings in the named regions is evidence of anything; rows reported elsewhere in those files are real. Fix the syntax error (or exclude the file deliberately) and re-scan to cover them. Separately, one or more rules could not re-parse an embedded snippet in 1 file(s) (e.g. a workflow `run:` block read as shell). Those files WERE scanned and their other rows are unaffected; only those rules' view of those snippets is missing.
What to do
- Resolve the 1 REDACTED finding(s) in Static Analysis (SAST) — start with REDACTED. — One of this dimension's main actionable groups (1 issue-level).
- Resolve the 1 REDACTED finding(s) in Static Analysis (SAST) — start with REDACTED. — One of this dimension's main actionable groups (1 issue-level).
- No action in Static Analysis (SAST) — all 5 REDACTED finding(s) are reported here at file:line but scored by D36 (supply-chain provenance), so none is charged to this dimension. — One of this dimension's main actionable groups (5 issue-level, 0 of them charged here).
D30 · Dependency Vulnerabilities
No known-vulnerable dependencies in any ecosystem this repository declares.
D34 · Knowledge Freshness
Every significant source file has living knowledge — recently and meaningfully worked. Counted over 102 of the 238 production source files in this repository: the rest are under the ~2,400-byte size floor this dimension measures over.
D35 · Change Coupling
Strongest change-coupling: VTSessionMode.swift↔VideoCodecSettings.swift 71%; MTHKView.swift↔PiPHKView.swift 69%; CaptureUnit.swift↔RTMPStream.swift 56%
What to do
- Resolve the 1 Boundary-crossing change coupling finding(s) in Change Coupling — start with CaptureUnit.swift. — One of this dimension's main actionable groups (1 issue-level).
- Resolve the 3 Change coupling finding(s) in Change Coupling — start with VTSessionMode.swift, MTHKView.swift, DeviceUnit.swift. — One of this dimension's main actionable groups (3 warning-level).
D36 · Supply-chain Provenance & Signing
0/4 supply-chain integrity signals present (provenance, signing, SBOM, pinned actions).
What to do
- Resolve the 1 REDACTED finding(s) in Supply-chain Provenance & Signing. — One of this dimension's main actionable groups (1 warning-level).
- Resolve the 1 REDACTED finding(s) in Supply-chain Provenance & Signing — start with REDACTED. — One of this dimension's main actionable groups (1 warning-level).
- Resolve the 1 REDACTED finding(s) in Supply-chain Provenance & Signing — start with REDACTED. — One of this dimension's main actionable groups (1 warning-level).
D43 · Malicious Dependencies
No dependency in any ecosystem this repository declares is published as malicious.
D44 · Platform End-of-Life
0 end-of-life runtime(s) and 0 end-of-life framework(s), read from 1 platform declaration(s) and 5 dependency declaration(s). This dimension reads what the repository says about ITSELF — a pinned target framework, a version file, a capped requires-python, a Rust toolchain pin, a framework major a constraint cannot move off. A FLOOR is deliberately never charged: `requires-python = ">=3.8"` states what the package SUPPORTS, not what it runs on, and a well-maintained library declares exactly that while running its own CI on a current release. The end-of-life facts are FROZEN and dated, so this dimension needs no network and answers identically inside a closed scan fence; as the table ages it loses recall and never precision, because a statement about support that ended in the past cannot become false. The OS layer of a container image is D31's question and the toolchain a CI workflow installs is D29's; this row is neither.
Frontend & cross-cutting dimensions
AX10 · Code composition
What to do
- The domain core is a small share of production code, but most of the rest matched no layer vocabulary at all — so this is not yet an anemic-domain finding. The namespace/path convention could not place that code, which makes the composition above a statement about the naming, not about the design. Name the layers (or check that the repository's conventions differ from the ones this check knows) before reading a thin domain into it.
AX3 · Project dependency cycles
AX4 · Dependency direction
AX8 · Test isolation
AX9 · CQS / query purity
M1 · Documentation (README)
What to do
- Explain in the README how to run the tests. Add a section called Testing to the README in the repository's top folder, saying how to run the test suite.
- Add an 'Architecture' / 'How it works' section to the root README — the high-level shape.
- Add a README to the 1 of 1 project(s) that lack one — worth up to 2 pts.
M3 · Folder & project structure
M4 · Documentation accuracy
P1 · CI/CD gates
What to do
- Run the test suite in CI via an explicit runner step (`bundle exec rspec` for the toolchain this pipeline already uses) and gate merges on it.
P10 · Library API & versioning
P3 · Security & performance tooling
- No static application security testing detected. For this repository's stack, add CodeQL's Swift pack (Swift/Xcode) (or `semgrep --config=auto`, which runs on any language) as a CI step. What was searched, so you can tell an absence from a miss: the 2215 CI workflow file(s) in this repository, and the scanner and linter configuration checked in beside them. A scan that runs outside CI, one configured in your forge's web UI rather than in a committed file, or a tool whose name is none of those this check carries, is not seen — if that is your case the row is wrong, and saying so is more useful than adding a second scanner.
What to do
- Add a SAST step to CI running what this repository's stack ships: CodeQL's Swift pack (Swift/Xcode) — or `semgrep --config=auto`, which runs on any language — so a security regression fails the build instead of landing.
- Add gitleaks/trufflehog in CI to block PRs that introduce committed secrets.
P6 · Release Hygiene
- No CHANGELOG/HISTORY/RELEASES file — what shipped when isn't easy to reconstruct for support or audit. (Versioning/tagging makes releases traceable, but a changelog records the what.)
What to do
- Keep a changelog (e.g. Keep-a-Changelog) recording what shipped in each release.
PF2 · Allocation hygiene
What to do
- Raise allocation-aware density on the hot paths — currently 38 use(s) across 24,023 production line(s) (~1.6/1k). More of the idioms below on the allocation-heavy paths climbs this toward 10.
- Swift: on hot paths, reserveCapacity before appending, use ContiguousArray for class-element arrays, work in place with withUnsafeBufferPointer/withUnsafeTemporaryAllocation, and make large values ~Copyable with borrowing/consuming parameters.
PF3 · Async & latency hygiene
X14 · Bypassable address classification
X26 · Unsynchronised callback handoff
X28 · Index access outside its own emptiness guard
X3 · Exception handling
Reference — by lens
| Lens | Score | Rating | Impact |
|---|---|---|---|
| Code Health | 93% | Exemplary | Strongest area. |
| Architecture | 89% | Adequate — gated by D26 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Maturity | 88% | Exemplary | Solid. |
| Readiness | 66% | Adequate — gated by P3 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Security | 78% | Adequate — gated by D36 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Performance | 82% | Exemplary | Solid. |
Unscored — 1 check(s) recorded observations but carry no score
- X10 Duplicated predicate — 2 observation(s) recorded · Advisory — this card reports evidence and never carries a score.
Not evidenced — 3 control(s) we could not find positive evidence for
- C3 Audit Trail — Not assessed: these audit controls are read from a source model (declarative annotations, request middleware, entity/column names, guard methods) that was not loaded for this repository — because the repository is written in a language this check does not yet model, or because its projects failed to load. Absence of an idiom this check recognises is NOT evidence that this repository lacks audit controls: it may implement them entirely in its own ecosystem. This is a gap in the analyzer's language coverage, not a finding about this repository.
- P4 Deployment & Rollback — not evidenced — no deploy/rollback/approval signal in the repo; absence of evidence is not evidence of a manual release
- P5 DR & Backup — not evidenced — repo shows no backup/RTO/RPO controls; absence of evidence is not evidence of a working control
Not included — 75 check(s) not relevant to this codebase
- AC1 Text alternatives — No web markup found — accessibility is not applicable to this repository.
- AC2 Forms & labels — No web markup found — accessibility is not applicable to this repository.
- AC3 Page structure — No web markup found — accessibility is not applicable to this repository.
- AC4 Keyboard semantics — No web markup found — accessibility is not applicable to this repository.
- AC5 ARIA correctness — No web markup found — accessibility is not applicable to this repository.
- AC6 Visual & motion safety — No web markup found — accessibility is not applicable to this repository.
- AC7 A11y enforcement — No web markup found — accessibility is not applicable to this repository.
- AX1 Captive dependencies — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- AX2 Stateful singletons — No container singleton was found, so there is no shared instance for concurrent requests to race on. No Swift request handler (a Vapor, Hummingbird, Kitura, Swifter or Perfect route handler, as a method or a registered closure) is declared, so no state is shared between request threads.
- AX5 Architecture & structure — not assessed — architecture style/structure is computed from a project graph (projects, types, module namespaces) that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- AX6 Interface segregation — not assessed — interface segregation is computed over a type surface that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- AX7 Slice cohesion — not applicable — not a vertical-slice architecture
- AXB1 Runtime evidence locked — no reproducible boot — This repository has nothing the runtime tiers could boot or serve — no markup, no UI framework or web-server dependency, no UI component source, no native UI project and no API definition — nothing here is a surface to boot — so runtime a11y/egress/header evidence has no subject here. Not applicable: this is neither a gap in the scan nor a finding about your code.
- C1 Data Protection — Not assessed: these personal data controls are read from a source model (declarative annotations, request middleware, entity/column names, guard methods) that was not loaded for this repository — because the repository is written in a language this check does not yet model, or because its projects failed to load. Absence of an idiom this check recognises is NOT evidence that this repository lacks personal data controls: it may implement them entirely in its own ecosystem. This is a gap in the analyzer's language coverage, not a finding about this repository.
- C2 Access Controls — Not assessed: these authorization controls are read from a source model (declarative annotations, request middleware, entity/column names, guard methods) that was not loaded for this repository — because the repository is written in a language this check does not yet model, or because its projects failed to load. Absence of an idiom this check recognises is NOT evidence that this repository lacks authorization controls: it may implement them entirely in its own ecosystem. This is a gap in the analyzer's language coverage, not a finding about this repository.
- C4 Data Retention — No personal data detected in a persisted data model — no PII-named property (email, firstName, dateOfBirth, phoneNumber, …) or stored credential on a SwiftData @Model, a Core Data, Realm, GRDB or Fluent type, a GRDB or SQLite.swift column, or in a SQL CREATE TABLE or ALTER TABLE — and no database or data-store client (CoreData, SwiftData, GRDB, RealmSwift, SQLite, Firebase, …) imported either, so this repository keeps no personal data whose lifetime a retention limit would bound.
- C5 Data-Subject Rights — No personal data detected in a persisted data model — no PII-named property (email, firstName, dateOfBirth, phoneNumber, …) or stored credential on a SwiftData @Model, a Core Data, Realm, GRDB or Fluent type, a GRDB or SQLite.swift column, or in a SQL CREATE TABLE or ALTER TABLE — and no database or data-store client (CoreData, SwiftData, GRDB, RealmSwift, SQLite, Firebase, …) imported either, so this repository keeps no personal data for a data subject to erase, export or consent over.
- D11 Test Reliability — Test reliability not included — the .swift suite was found but not re-run
- D16 Bus Factor — single-maintainer repository — bus factor is not applicable
- D18 Solution Shape — D18 scores the shape of a .NET solution; this repository has no .NET solution or project files, so the dimension does not apply.
- D19 Documentation Quality — D19 withholds "Documentation: empty section": 1 candidate(s) were measured and not published.
- D20 ADR Quality — N/A — this repo declares itself a template / kata / sample / demo; a formal ADR log is deferred to a real application built from it.
- D21 Naming Consistency — Naming consistency is measured on C# only; Swift not measured.
- D22 Internal API Consistency — API consistency is measured on C# only; the exposed Swift surface was not measured.
- D23 Boundary Type-Coupling — No bounded-context organisation was detected either — neither a context-shaped layout, nor 2+ sibling source directories each declaring an aggregate root, nor 2+ projects each declaring an entity of their own. Declaring this codebase's bounded contexts (≥2) would let cross-boundary type coupling be assessed. Declare them in `.codehealth/config.yaml` at the repository root (create it if absent), mapping each context name to the module-path or namespace prefixes that belong to it — e.g. `architecture:` → `contexts:` → `Billing: ["src/billing", "Acme.Billing"]`, `Catalog: ["src/catalog", "Acme.Catalog"]`.
- D24 Comment Value — D24 reads C# and Visual Basic comments only — this repository's production source is .swift, which was left unread. Not scored: this is a gap in the analyzer, not a verdict about this repository.
- D25 ADR Conformance — no ADRs to check
- D27 Navigability — D27 counts a call into the standard library or a dependency as unresolved for this repository's language (.swift), so too few call sites counted as resolved to assess navigability. Not scored: this is a gap in the analyzer, not a verdict about this repository.
- D31 IaC & Container Security — No Infrastructure-as-Code or container manifests found (Dockerfile, Docker Compose, Terraform, Kubernetes/Helm, CloudFormation, ARM, Bicep, Ansible); nothing to scan.
- D32 Data Compliance (PII/GDPR) — 60 file(s) were not parsed by semgrep — the PII/GDPR ruleset never ran over them
- D37 Vulnerability-disclosure Policy — No vulnerability-disclosure policy file found (SECURITY.md/.markdown/.rst/.txt at root or under .github/.forgejo/.gitea/docs, .well-known/security.txt). A coordinated-disclosure policy may live off-repo, so this is not evidenced rather than failed.
- D39 IL Efficiency — D39 measures the IL emitted by a .NET build; this repository has no .NET solution or project files, so the dimension does not apply.
- D40 Network Egress Confinement — No Kubernetes/orchestration workloads found in the repository manifests; network egress policy is a cluster-native control that may live at the platform/firewall layer, so there is nothing to assess here.
- D41 Kernel & Syscall Confinement — No Kubernetes/orchestration workloads found in the repository manifests; seccomp/AppArmor/SELinux confinement is a workload-level control, so there is nothing to assess here.
- D42 Runtime Threat Enforcement — No Kubernetes/orchestration workloads found in the repository manifests; runtime threat-detection and admission-control policy are cluster-level controls, so there is nothing to assess here.
- D7 Architectural Integrity — no checkable ADRs, and no project-reference graph for the cycle pass to read — so this dimension makes no claim about dependency cycles in either direction (where this repository's language has an import-cycle lens, cycles are reported there). Architectural integrity not assessed
- D8 Code Coverage — Coverage not measured — Swift suite
- DM1 Domain Modelling — not scored — this repository shows none of the 3 signals this lens looks for
- ED2 Event/command shape — not scored — deciding whether a command has more than one competing handler requires resolving the call graph, and this analysis resolves a call's owner only where the receiver's type is written down in the source. Reported as guidance rather than measured
- ED5 Idempotency — no mutating command handlers or message consumers detected — idempotency check not applicable
- ES1 Event Sourcing — not scored — this repository shows none of the 3 signals this lens looks for
- GD1 Unfinished & placeholder code — no source files were read — this check reads C#, F#, JavaScript/TypeScript, Dart, Ruby and Scala, and none was read for this repository's product. That is a limit of the analyzer, not a finding about your code.
- IC1 Incompleteness & stubs — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- M2 Architecture documentation — This repo declares itself a template / kata / sample / demo — formal architecture documentation (ADRs, C4 diagrams) is deferred to a real application built from it, so its absence is not a defect here.
- P12 CI test-gate honesty — Reported, not scored — and nothing was matched here. The coverage check applies to any stack, and the automatic-re-run check to any GitHub-Actions workflow, but the checks for excluded tests, skipped tests and sleep-based synchronisation currently recognise only some ecosystems' test-runner idioms, so on a repository built with another stack the zeros below mean 'not checked', not 'clean'.
- P2 Observability — This repository's Swift source (1 module(s), 238 file(s) read) declares no entry point and bootstraps no server, and nothing here deploys a service — it is a library, run inside whatever hosts it, so production observability (structured logging, tracing/metrics, health checks) is N/A. If it grows a binary or a service, the dimension reactivates.
- P7 Outbound HTTP resilience — not applicable — no HTTP server, API framework or worker entry point was found in the Swift source, so there is no service whose uptime a failing dependency could take down
- P8 Schema migrations — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- P9 Domain vs controller coverage — no coverage report found on disk — produce a coverage report in a standard format (lcov — `swift test --enable-code-coverage` (SwiftPM) or `xcodebuild test -scheme <YourScheme> -enableCodeCoverage YES` (an .xcodeproj/.xcworkspace suite), then `xcrun llvm-cov export -format=lcov`) and commit it — a hosted scan measures a clone of the repository, so a report that exists only in a working tree, a CI runner's or your own, never reaches it; the artefact is commonly gitignored, so `git add -f` that one file (or un-ignore its path) and commit it alongside the code it measures, or wire coverage collection into CI, to enable this cross-layer check
- PF1 Benchmark discipline — Not applicable: no benchmark suite was found. This check searched for tinybench, mitata, benchmark.js, benny or vitest `bench(...)` calls in files that import them (or `*.bench.*` files), or one of those in a package.json, and for a `*benchmark*` script that this repository's CI runs. Benchmarks are credited as a bonus, so their absence is neither scored nor deducted.
- S1 Web-Security Posture — Not assessed: these web-security controls are read from a source model (declarative annotations, request middleware, entity/column names, guard methods) that was not loaded for this repository — because the repository is written in a language this check does not yet model, or because its projects failed to load. Absence of an idiom this check recognises is NOT evidence that this repository lacks web-security controls: it may implement them entirely in its own ecosystem. This is a gap in the analyzer's language coverage, not a finding about this repository.
- X1 Async correctness — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X12 Unreachable branch — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X13 Undrained process stream — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X15 Unvalidated length from an untrusted reader — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X16 Unfloored truncation loop — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X17 Uncapped recursion over a caller-supplied document — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X18 Disposal-pattern correctness — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X19 Unrestored process-global state — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X2 Cancellation propagation — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X20 Mistyped argument guard — This check asks whether an argument guard reports an EMPTY value as a NULL one, which needs a language that throws a null-specific argument exception — .NET's ArgumentNullException, the JVM's NullPointerException, Dart's ArgumentError.notNull. This repository contains none of those languages: the ones it is written in have a single exception for a bad argument, so there is no pair of exceptions to confuse and nothing here for it to assess. Not a gap in the analyzer and not a finding about your code.
- X21 Side-effecting pattern guard — Not applicable: this check looks for a pattern guard or `case` label that increments, decrements or assigns while the switch is deciding whether it matches, and in this repository's languages none can. In C a `case` label must be a constant expression, and a switch has no guards, so no label can change state. Swift has no `++` or `--`, and an assignment yields `()`, which cannot be an operand of `&&`, `||` or `?:` nor the Bool a `case … where` clause needs. Not a gap in the analyzer and not a finding about your code.
- X22 Contradicted release guard — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X23 Unguarded diagnostic materialisation — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X24 Document value interpolated into markup unescaped — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X25 Inert configuration knob — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X27 Collection changed while being enumerated — Not applicable: this check looks for a loop whose body adds to or removes from the very collection the loop is walking, invalidating the enumerator it holds, and in this repository's languages that cannot happen. Swift's `Array`, `Dictionary` and `Set` are values: `for x in items` walks the copy taken when the loop starts, so a body that adds to or removes from `items` changes a different value, nothing is invalidated, and every original element is still visited. This repository's Swift names no Foundation mutable collection (`NSMutableArray` and kin), the one kind a Swift loop can walk by reference. Not a gap in the analyzer and not a finding about your code.
- X29 Per-element action decided by a fixed element — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X30 Support guard that admits what it rejects — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X32 Type resolved by simple name across every loaded assembly — This check is about how a .NET program searches the assemblies loaded into its process for a type, and this repository contains no .NET source, so there is nothing here for it to assess. Not a gap in the analyzer and not a finding about your code.
- X4 Structured logging — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X5 Nullable reference types — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X6 Hand-rolled structured-format parsing — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- X7 Silent fallback defaults — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- X9 Subsumed condition operand — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
Appendix A — Findings (grouped)
Critical — 8 finding(s)
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- Boundary-crossing change coupling: CaptureUnit.swift ↔ RTMPStream.swift HaishinKit/Sources/Mixer/CaptureUnit.swift:1
Serious — 134 finding(s)
- Low cohesion: HTTPSession (LCOM4 7) RTCHaishinKit/Sources/HTTP/HTTPSession.swift:4
- Low cohesion: MTHKView (LCOM4 6) HaishinKit/Sources/View/MTHKView.swift:7
- Low cohesion: AMFReference (LCOM4 6) RTMPHaishinKit/Sources/AMF/AMF3Serializer.swift:3
- Low cohesion: AudioCaptureUnit (LCOM4 5) HaishinKit/Sources/Mixer/AudioCaptureUnit.swift:3
- Low cohesion: MixerNode (LCOM4 5) HaishinKit/Sources/Mixer/AudioNode.swift:129
- Low cohesion: NullCaptureSession (LCOM4 5) HaishinKit/Sources/Mixer/CaptureSession.swift:308
- Low cohesion: ScreenObject (LCOM4 5) HaishinKit/Sources/Screen/ScreenObject.swift:26
- Low cohesion: CaptureSession (LCOM4 4) HaishinKit/Sources/Mixer/CaptureSession.swift:29
- Low cohesion: VideoCaptureUnit (LCOM4 4) HaishinKit/Sources/Mixer/VideoCaptureUnit.swift:4
- Low cohesion: VideoDeviceUnit (LCOM4 4) HaishinKit/Sources/Mixer/VideoDeviceUnit.swift:9
- Low cohesion: PiPHKView (LCOM4 4) HaishinKit/Sources/View/PiPHKView.swift:7
- Low cohesion: RTCStream (LCOM4 4) RTCHaishinKit/Sources/RTC/RTCStream.swift:5
- Low cohesion: RTCTrack (LCOM4 4) RTCHaishinKit/Sources/RTC/RTCTrack.swift:12
- No assertions: aac_44100hz_step_1224 HaishinKit/Tests/Codec/AudioCodecTests.swift:74
- No assertions: test3Channel_withoutCrash HaishinKit/Tests/Codec/AudioCodecTests.swift:108
- No assertions: bytes HaishinKit/Tests/ISO/ADTSHeaderTests.swift:7
- No assertions: keep48000 HaishinKit/Tests/Mixer/AudioMixerTrackTests.swift:32
- No assertions: passthrough48000_44100 HaishinKit/Tests/Mixer/AudioMixerTrackTests.swift:40
- No assertions: monoAppendSampleBuffer_920 HaishinKit/Tests/Mixer/AudioRingBufferTests.swift:8
- No assertions: monoAppendSampleBuffer_1024 HaishinKit/Tests/Mixer/AudioRingBufferTests.swift:12
- No assertions: stereoAppendSampleBuffer_920 HaishinKit/Tests/Mixer/AudioRingBufferTests.swift:49
- No assertions: stereoAppendSampleBuffer_1024 HaishinKit/Tests/Mixer/AudioRingBufferTests.swift:53
- No assertions: startRunning_fileAlreadyExists HaishinKit/Tests/Stream/StreamRecorderTests.swift:38
- No assertions: chunkSize RTMPHaishinKit/Tests/RTMP/RTMPChunkBufferTests.swift:92
- No assertions: streamid_success SRTHaishinKit/Tests/SRT/SRTConnectionTests.swift:24
- Duplicated block (7 lines × 3) HaishinKit/Sources/Util/ByteArray.swift:176
- Duplicated block (7 lines × 3) HaishinKit/Sources/Util/ByteArray.swift:191
- Duplicated block (7 lines × 3) HaishinKit/Sources/Util/ByteArray.swift:206
- Duplicated block (7 lines × 3) HaishinKit/Sources/Util/ByteArray.swift:221
- Duplicated block (7 lines × 3) HaishinKit/Sources/Util/ByteArray.swift:236
- Duplicated block (7 lines × 3) HaishinKit/Sources/Util/ByteArray.swift:257
- Duplicated block (7 lines × 3) HaishinKit/Sources/Util/ByteArray.swift:271
- Duplicated block (7 lines × 3) HaishinKit/Sources/Util/ByteArray.swift:280
- Duplicated block (7 lines × 3) HaishinKit/Sources/Util/ByteArray.swift:295
- Duplicated block (7 lines × 3) HaishinKit/Sources/Util/ByteArray.swift:346
- Duplicated block (13 lines × 2) HaishinKit/Sources/Mixer/AudioMixerByMultiTrack.swift:146
- Duplicated block (13 lines × 2) MoQTHaishinKit/Sources/MoQTSocket.swift:112
- Duplicated block (13 lines × 2) Examples/iOS/PublishView.swift:310
- Duplicated block (13 lines × 2) Examples/iOS/PublishViewModel.swift:271
- Duplicated block (13 lines × 2) Examples/iOS/UVCViewModel.swift:136
- Duplicated block (10 lines × 2) RTMPHaishinKit/Sources/Codec/HEVCDecoderConfigurationRecord.swift:47
- Duplicated block (10 lines × 2) HaishinKit/Sources/Mixer/AudioCaptureUnit.swift:103
- Duplicated block (10 lines × 2) HaishinKit/Sources/Mixer/AudioCaptureUnit.swift:114
- Duplicated block (10 lines × 2) HaishinKit/Sources/View/MTHKView.swift:131
- Duplicated block (10 lines × 2) Examples/macOS/HaishinApp.swift:20
- Duplicated block (6 lines × 2) HaishinKit/Sources/Screen/TextScreenObject.swift:33
- Duplicated block (6 lines × 2) HaishinKit/Sources/View/MTHKViewRepresentable.swift:28
- Duplicated block (6 lines × 2) MoQTHaishinKit/Sources/MoQTSocket.swift:175
- Duplicated block (6 lines × 2) HaishinKit/Sources/Mixer/MediaMixer.swift:358
- Duplicated block (6 lines × 2) Examples/Preference.swift:11
- Duplicated block (7 lines × 2) RTMPHaishinKit/Sources/AMF/AMF3Serializer.swift:255
- Duplicated block (7 lines × 2) HaishinKit/Sources/Screen/VideoScreenObject.swift:76
- Duplicated block (7 lines × 2) HaishinKit/Sources/Screen/VideoScreenObject.swift:85
- Duplicated block (7 lines × 2) Examples/iOS/PublishViewModel.swift:299
- TooManyMethods: ByteArray HaishinKit/Sources/Util/ByteArray.swift:75
- TooManyMethods: ByteArray RTMPHaishinKit/Sources/Util/ByteArray.swift:75
- TooManyMethods: ByteArray SRTHaishinKit/Sources/TS/ByteArray.swift:75
- Change coupling: VTSessionMode.swift ↔ VideoCodecSettings.swift HaishinKit/Sources/Codec/VTSessionMode.swift:1
- Change coupling: MTHKView.swift ↔ PiPHKView.swift HaishinKit/Sources/View/MTHKView.swift:1
- Change coupling: DeviceUnit.swift ↔ MediaMixer.swift HaishinKit/Sources/Mixer/DeviceUnit.swift:1
- Duplicated block (14 lines × 2) HaishinKit/Sources/Screen/ScreenObjectSnapshotFactory.swift:9
- Duplicated block (14 lines × 2) MoQTHaishinKit/Sources/MoQTSocket.swift:140
- Duplicated block (14 lines × 2) RTMPHaishinKit/Sources/RTMP/RTMPStream.swift:371
- Duplicated block (11 lines × 2) MoQTHaishinKit/Sources/MoQTSocket.swift:81
- Duplicated block (11 lines × 2) Examples/iOS/InfoGuideView.swift:75
- Duplicated block (11 lines × 2) Examples/iOS/PublishViewModel.swift:466
- Duplicated block (6 lines × 3) HaishinKit/Sources/Util/ByteArray.swift:373
- Duplicated block (6 lines × 3) RTCHaishinKit/Sources/RTC/RTCStream.swift:81
- Duplicated block (6 lines × 3) RTCHaishinKit/Sources/RTC/RTCStream.swift:88
- Duplicated block (5 lines × 2) HaishinKit/Sources/ISO/ISOTypeBufferUtil.swift:37
- Duplicated block (5 lines × 2) RTMPHaishinKit/Sources/RTMP/RTMPChunk.swift:290
- Duplicated block (5 lines × 2) HaishinKit/Sources/Mixer/MediaMixer.swift:366
- Duplicated block (9 lines × 3) HaishinKit/Sources/Util/ByteArray.swift:142
- Duplicated block (9 lines × 3) HaishinKit/Sources/Util/ByteArray.swift:159
- Duplicated block (9 lines × 3) Examples/iOS/PublishViewModel.swift:138
- Duplicated block (12 lines × 3) RTMPHaishinKit/Sources/RTMP/RTMPStream.swift:311
- Duplicated block (12 lines × 3) RTMPHaishinKit/Sources/RTMP/RTMPStream.swift:340
- Duplicated block (11 lines × 3) HaishinKit/Sources/Util/ByteArray.swift:329
- Duplicated block (11 lines × 3) HaishinKit/Sources/Util/ByteArray.swift:380
- Duplicated block (9 lines × 2) HaishinKit/Sources/Screen/AssetScreenObject.swift:93
- Duplicated block (9 lines × 2) Examples/iOS/UVCView.swift:54
- Duplicated block (10 lines × 4) HaishinKit/Sources/Stream/StreamRecorder.swift:233
- Duplicated block (10 lines × 4) HaishinKit/Sources/Util/ByteArray.swift:112
- RTMPConnection.connect (cyclomatic 27) RTMPHaishinKit/Sources/RTMP/RTMPConnection.swift:313
- AudioRingBuffer.render (cyclomatic 24) HaishinKit/Sources/Mixer/AudioRingBuffer.swift:106
- SDPMediaDescription.init (cyclomatic 20) RTCHaishinKit/Sources/SDP/SDPMediaDescription.swift:30
- StreamRecorder.makeWriterInput (cyclomatic 19) HaishinKit/Sources/Stream/StreamRecorder.swift:297
- RTCPeerConnection.init (cyclomatic 18) RTCHaishinKit/Sources/RTC/RTCPeerConnection.swift:135
- RTMPConnection.dispatch (cyclomatic 18) RTMPHaishinKit/Sources/RTMP/RTMPConnection.swift:516
- MediaMixer.startRunning (cyclomatic 17) HaishinKit/Sources/Mixer/MediaMixer.swift:480
- SRTSocket.open (cyclomatic 16) SRTHaishinKit/Sources/SRT/SRTSocket.swift:122
- TodoComment RTCHaishinKit/Sources/RTC/RTCTrackConfiguration.swift:60
- StreamRecorder.makeWriterInput (cognitive 48) HaishinKit/Sources/Stream/StreamRecorder.swift:297
- RTMPConnection.connect (cognitive 44) RTMPHaishinKit/Sources/RTMP/RTMPConnection.swift:313
- SDPMediaDescription.init (cognitive 38) RTCHaishinKit/Sources/SDP/SDPMediaDescription.swift:30
- RTMPConnection.dispatch (cognitive 38) RTMPHaishinKit/Sources/RTMP/RTMPConnection.swift:516
- AudioRingBuffer.render (cognitive 36) HaishinKit/Sources/Mixer/AudioRingBuffer.swift:106
- RTMPStream.append (cognitive 35) RTMPHaishinKit/Sources/RTMP/RTMPStream.swift:730
- RTCPeerConnection.init (cognitive 33) RTCHaishinKit/Sources/RTC/RTCPeerConnection.swift:135
- RTMPConnection.listen (cognitive 28) RTMPHaishinKit/Sources/RTMP/RTMPConnection.swift:449
- AudioCodec.append (cognitive 24) HaishinKit/Sources/Codec/AudioCodec.swift:83
- AudioNode.description (cognitive 24) DebugDescription/AudioNode+DebugExtension.swift:5
- SRTSocket.open (cognitive 24) SRTHaishinKit/Sources/SRT/SRTSocket.swift:122
- MediaMixer.startRunning (cognitive 22) HaishinKit/Sources/Mixer/MediaMixer.swift:480
- RTMPStream.dispatch (cognitive 20) RTMPHaishinKit/Sources/RTMP/RTMPStream.swift:559
- StreamRecorder.append (cognitive 19) HaishinKit/Sources/Stream/StreamRecorder.swift:257
- CVPixelBuffer.copy (cognitive 18) HaishinKit/Sources/Extension/CVPixelBuffer+Extension.swift:60
- MoQTSubscribe.payload (cognitive 18) MoQTHaishinKit/Sources/ControlMessage/MoQTSubscribe.swift:33
- SRTConnection.connect (cognitive 18) SRTHaishinKit/Sources/SRT/SRTConnection.swift:78
- VideoCodec.append (cognitive 17) HaishinKit/Sources/Codec/VideoCodec.swift:50
- MediaLink.startRunning (cognitive 17) HaishinKit/Sources/Stream/MediaLink.swift:61
- AudioRingBuffer.append (cognitive 16) HaishinKit/Sources/Mixer/AudioRingBuffer.swift:44
- RTPH264Packetizer.append (cognitive 16) RTCHaishinKit/Sources/RTP/RTPH264Packetizer.swift:42
- SRTSession.connect (cognitive 16) SRTHaishinKit/Sources/SRT/SRTSession.swift:43
- FileTooLong: RTMP/RTMPStream.swift RTMPHaishinKit/Sources/RTMP/RTMPStream.swift
- MethodTooLong: Name.init SRTHaishinKit/Sources/SRT/SRTSocketOption.Name.swift:6
- REDACTED
- REDACTED
- REDACTED
- Duplicated block (29 lines × 2) RTMPHaishinKit/Sources/AMF/AMF0Serializer.swift:87
- Duplicated block (22 lines × 2) RTCHaishinKit/Sources/RTP/RTPH264Packetizer.swift:250
- Duplicated block (19 lines × 2) MoQTHaishinKit/Sources/MoQTSocket.swift:155
- Duplicated block (18 lines × 2) HaishinKit/Sources/Screen/TextScreenObject.swift:5
- Duplicated block (16 lines × 2) RTCHaishinKit/Sources/RTC/RTCStream.swift:39
- Duplicated block (15 lines × 3) HaishinKit/Sources/Util/ByteArray.swift:354
- Duplicated block (14 lines × 3) HaishinKit/Sources/Screen/AssetScreenObject.swift:78
- Duplicated block (11–12 lines × 2) HaishinKit/Sources/Extension/CVPixelBuffer+Extension.swift:69
- Duplicated block (15 lines × 2) MoQTHaishinKit/Sources/ControlMessage/MoQTAnnounceOk.swift:9
- Duplicated block (5 lines × 3) HaishinKit/Sources/Util/ByteArray.swift:315
- Duplicated block (10 lines × 3) RTCHaishinKit/Sources/RTC/RTCDataChannel.swift:41
- Duplicated block (24–25 lines × 2) Examples/iOS/PublishViewModel.swift:164
- Duplicated block (18–20 lines × 2) Examples/iOS/PublishViewModel.swift:510
- Duplicated block (12 lines × 2) Examples/iOS/UVCViewModel.swift:205
- Off the main sequence: HaishinKit
Minor — 11 finding(s)
- No direct assertions: rejectsInvalidURL HaishinKit/Tests/Session/StreamSessionBuilderFactoryTests.swift:31
- No direct assertions: unsupportedScheme HaishinKit/Tests/Session/StreamSessionBuilderFactoryTests.swift:44
- No direct assertions: acceptsValidAuthority HaishinKit/Tests/Session/StreamSessionBuilderFactoryTests.swift:56
- Duplicated predicate HaishinKit/Sources/Screen/StreamScreenObject.swift:51
- Duplicated predicate HaishinKit/Sources/ISO/ISOTypeBufferUtil.swift:39
- Projects may be oversized for their cohesion
- REDACTED
- REDACTED
- REDACTED
- No SAST
- No changelog
Minor — 1 finding(s)
- Outdated: swift-docc-plugin
Appendix B — Reproduction & audit trail
| Dimension | Tool | Version | Command | Findings | Raw output |
|---|---|---|---|---|---|
| D28 · Secrets (history) | gitleaks | — | gitleaks detect --no-banner --config /opt/gitleaks-rules/watchdog-gitleaks.toml --report-format json --report-path /tmp/watchdog-gitleaks-c28c3663ecc349479ac1eb3cb040e41d/history.json --exit-code 0 --source . | 0 | artifacts/raw/gitleaks-history.json |
| D28 · Secrets (history) | gitleaks | — | gitleaks detect --no-git --no-banner --config /opt/gitleaks-rules/watchdog-gitleaks.toml --report-format json --report-path /tmp/watchdog-gitleaks-c28c3663ecc349479ac1eb3cb040e41d/tree.json --exit-code 0 --source . | 0 | artifacts/raw/gitleaks-tree.json |
| D29 · Static Analysis (SAST) | semgrep | — | semgrep --config /opt/semgrep-rules/security-audit.yml --config /opt/semgrep-rules/owasp-top-ten.yml --config /opt/semgrep-rules/watchdog-sast.yml --json --quiet --timeout 10 --timeout-threshold 3 --metrics off --exclude *.arrow --exclude *.avro --exclude *.csv --exclude *.dat --exclude *.db --exclude *.feather --exclude *.geojson --exclude *.h5 --exclude *.hdf5 --exclude *.jsonl --exclude *.log --exclude *.ndjson --exclude *.npy --exclude *.npz --exclude *.orc --exclude *.parquet --exclude *.pickle --exclude *.pkl --exclude *.psv --exclude *.sqlite --exclude *.sqlite3 --exclude *.tfrecord --exclude *.tsv --exclude *.txt . | 7 | artifacts/raw/semgrep.json |
| D30 · Dependency Vulnerabilities | osv-scanner | — | osv-scanner --format json --recursive --experimental-disable-plugins transitivedependency/requirements --experimental-disable-plugins dotnet/csproj --experimental-disable-plugins dotnet/nugetcpm . | 0 | artifacts/raw/osv-scanner.json |
| D31 · IaC & Container Security | trivy | — | trivy: not applicable — No Infrastructure-as-Code or container manifests found (Dockerfile, Docker Compose, Terraform, Kubernetes/Helm, CloudFormation, ARM, Bicep, Ansible); nothing to scan. | 0 | — |
| D32 · Data Compliance (PII/GDPR) | semgrep | — | semgrep: not applicable — No personal data was found crossing a boundary the PII/GDPR ruleset checks — nothing written to a log or console sink, placed in a URL or query string, or persisted to browser storage. That is a clean result for the LEAK surface only: this ruleset detects personal data escaping, it does not inventory the personal data a repository holds, so it is not evidence that this repository has no personal-data surface. The personal-data map (Appendix C) and the C1-C5 compliance cards are what speak to that. semgrep could not parse 60 file(s) — `Examples/iOS/PlaybackView.swift`, `Examples/iOS/PlaybackViewModel.swift`, `Examples/iOS/PreferenceView.swift`, `Examples/iOS/PublishView.swift`, `Examples/iOS/PublishViewModel.swift`, … (+55 more) — so the PII/GDPR sweep did not cover the unparsed regions of them; rows reported elsewhere in those files are real. | 0 | — |
| D37 · Vulnerability-disclosure Policy | disclosure | — | disclosure: not applicable — No vulnerability-disclosure policy file found (SECURITY.md/.markdown/.rst/.txt at root or under .github/.forgejo/.gitea/docs, .well-known/security.txt). A coordinated-disclosure policy may live off-repo, so this is not evidenced rather than failed. | 0 | — |
| D40 · Network Egress Confinement | runtime-hardening | — | runtime-hardening: not applicable — No Kubernetes/orchestration workloads found in the repository manifests; network egress policy is a cluster-native control that may live at the platform/firewall layer, so there is nothing to assess here. | 0 | — |
| D41 · Kernel & Syscall Confinement | runtime-hardening | — | runtime-hardening: not applicable — No Kubernetes/orchestration workloads found in the repository manifests; seccomp/AppArmor/SELinux confinement is a workload-level control, so there is nothing to assess here. | 0 | — |
| D42 · Runtime Threat Enforcement | runtime-hardening | — | runtime-hardening: not applicable — No Kubernetes/orchestration workloads found in the repository manifests; runtime threat-detection and admission-control policy are cluster-level controls, so there is nothing to assess here. | 0 | — |
| D43 · Malicious Dependencies | osv-scanner | — | osv-scanner --format json --recursive --experimental-disable-plugins transitivedependency/requirements --experimental-disable-plugins dotnet/csproj --experimental-disable-plugins dotnet/nugetcpm . | 0 | artifacts/raw/osv-scanner.json |