Introduction

1. Basic Description

  Polyv Live Streaming originates from the company's years of video technology accumulation. Based on professional cross-platform video codec technology and large-scale video content distribution networks, it provides stable, smooth, low-latency, and high-concurrency real-time audio and video services.

  Polyv Live Java SDK allows you to easily access Polyv Live video cloud services without complex programming, enabling cloud live streaming related video services.

  Polyv Live Java SDK is implemented based on and wraps/optimizes the Polyv Live API. It liberates common tasks for B-end users. The API call logic and exception handling are encapsulated and optimized. B-end users only need to encapsulate the request parameters and hand them over to the Polyv Live Java SDK for processing. After the Polyv Live Java SDK completes processing, it returns the result, and the B-end continues its business logic based on the returned data. Currently, the Polyv Live Java SDK covers most frequently used API operations, including channel management, viewing management, live interaction, chat room, player, etc.

  If you encounter any problems while using the Polyv Live Java SDK, please contact after-sales technical support directly using the Online Customer Service. Please submit the problem's runtime environment, operation steps, error feedback information, and contact information together to facilitate quick problem identification and resolution.

2. SDK Overall Design

1. The B-end administrator creates basic channel information through the SDK, such as channel name, channel viewing password, channel live streaming scenario, and other basic attributes;
2. The B-end administrator performs basic information settings for the channel through the SDK, such as viewing condition settings, basic lecturer information settings, basic course information settings, sharing copy settings, etc.;
3. The B-end lecturer logs into the live channel via a web page, live streaming assistant, or third-party streaming tool to start the live broadcast;
4. The C-end viewer logs into the live channel via a promoted sharing page link or QR code to watch the live content;
5. After the live broadcast ends, the B-end performs replay and transcoding settings, obtains statistical analysis data, and completes the live broadcast business loop;

3. SDK Detailed Design

4. SDK Business Logic Analysis

• Prerequisite: SDK Global Initialization: Global parameters must be configured before calling the SDK. Configurable parameters include account information (appId, userId, appSecret) and HTTP connection pool parameters (timeout, maxClientNum). See Initialization for details.
• SDK Global Parameter Injection: The SDK injects the globally configured parameters into the request object.
• Signature Generation: The SDK uses the MD5 algorithm signature rule to generate the signature.
• Parameter Validity Check: The SDK uses a custom parameter validation tool to check input parameters. If any parameter is invalid, a PloyvSdkException will be thrown. The exception's message includes the specific field information that failed validation. This exception is a runtime exception and must be caught to handle the related business logic.
• Send HTTP Request, Get Return Data: The SDK initializes an HTTP connection pool during the initialization phase. All SDK requests are sent through this connection pool.
• Parse Return Data: Parse the returned data. If the SDK call is successful, the response object is encapsulated and returned normally. If the server returns an error message, the SDK will throw a PloyvSdkException. The exception's message includes the specific server execution error information. This exception is a runtime exception and must be caught to handle the related business logic.

5. Call Flow Template

  The above business flow diagram is parsed into the code level as follows. All calls to the Polyv Live Java SDK can refer to the following call template (Global initialization only needs to be called once globally).

6. Dependency Component Version Description

The common component information used by the latest version of the Polyv Java SDK is as follows.

Recommendations Regarding Jackson Components

If your project also uses Jackson components, there is a potential risk: When Jackson minor versions are inconsistent at runtime (e.g., jackson-databind vs. jackson-core/jackson-annotations different minor versions, or inconsistent with other dependencies in your business), it may trigger:

• NoSuchMethodError
• NoClassDefFoundError
• ClassCastException

Recommendations:

1. Unify the Jackson three-piece version in your project (via jackson-bom or Spring Boot BOM). Ensure jackson-core / jackson-databind / jackson-annotations maintain the same minor version.
2. If your project must use a specific Jackson version (e.g., due to Spring Boot management), you can exclude Jackson when introducing the Polyv SDK, and let your project provide the Jackson version uniformly.

Example: Exclude Jackson transitively from Polyv SDK

<dependency>
  <groupId>net.polyv</groupId>
  <artifactId>polyv-java-live-sdk</artifactId>
  <version>xxx</version>
  <exclusions>
    <exclusion>
      <groupId>com.fasterxml.jackson.core</groupId>
      <artifactId>jackson-core</artifactId>
    </exclusion>
    <exclusion>
      <groupId>com.fasterxml.jackson.core</groupId>
      <artifactId>jackson-databind</artifactId>
    </exclusion>
    <exclusion>
      <groupId>com.fasterxml.jackson.core</groupId>
      <artifactId>jackson-annotations</artifactId>
    </exclusion>
  </exclusions>
</dependency>

<!-- 再由你的项目统一指定 Jackson 版本（示意） -->
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.fasterxml.jackson</groupId>
      <artifactId>jackson-bom</artifactId>
      <version>${jackson.version}</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

Recommendations Regarding Other Common Components

slf4j-api

• Spring Boot 2.x ecosystem typically remains on SLF4J 1.7.x
• Spring Boot 3.x ecosystem upgrades to SLF4J 2.0.x
• Recommendations:
  • When using Spring Boot, prioritize letting the Spring Boot BOM manage logging-related dependency versions; avoid explicitly fixing a version inconsistent with the BOM in your business project.
  • If your project explicitly introduces implementations like slf4j-simple or log4j-slf4j-impl, ensure only one implementation is retained (otherwise "multiple bindings/providers" type issues may occur).

httpclient

• HttpClient 4.x (org.apache.http.*) and HttpClient 5.x (org.apache.hc.*) can coexist, generally without issues, but it is recommended to avoid mixing two versions in the same project.

Recommended Method for Troubleshooting Dependency Conflicts

Execute in your project root directory (Maven):

1. View the final effective version (recommend adding -Dverbose):

mvn dependency:tree -Dverbose

2. Locate a specific component (Example: Jackson / HttpClient):

mvn dependency:tree -Dverbose -Dincludes=com.fasterxml.jackson.core:jackson-databind
mvn dependency:tree -Dverbose -Dincludes=org.apache.httpcomponents:httpclient

3. Determine who introduced a specific version (observe the "nearest-wins" path on the tree), then decide:

• Use dependencyManagement to unify the version
• Or use exclusions at the point of introduction