Tuỳ chỉnh

Giao diện Player là cốt lõi của thư viện ExoPlayer. Player hiển thị chức năng trình phát nội dung đa phương tiện cấp cao truyền thống, chẳng hạn như khả năng lưu nội dung đa phương tiện vào bộ đệm, phát, tạm dừng và tua. Phương thức triển khai mặc định ExoPlayer được thiết kế để đưa ra một số giả định về (và do đó áp đặt một số hạn chế đối với) loại nội dung nghe nhìn đang phát, cách thức và vị trí lưu trữ nội dung nghe nhìn cũng như cách hiển thị nội dung nghe nhìn. Thay vì triển khai trực tiếp việc tải và hiển thị nội dung đa phương tiện, các hoạt động triển khai ExoPlayer sẽ uỷ quyền công việc này cho các thành phần được chèn khi tạo trình phát hoặc khi truyền nguồn nội dung đa phương tiện mới đến trình phát. Các thành phần phổ biến cho tất cả các cách triển khai ExoPlayer là:

• Các thực thể MediaSource xác định nội dung đa phương tiện cần phát, tải nội dung đa phương tiện và nơi có thể đọc nội dung đa phương tiện đã tải. Một thực thể MediaSource được tạo từ MediaItem bằng MediaSource.Factory bên trong trình phát. Bạn cũng có thể chuyển trực tiếp các danh sách phát này đến trình phát bằng cách sử dụng API danh sách phát dựa trên nguồn nội dung nghe nhìn.
• Một thực thể MediaSource.Factory chuyển đổi MediaItem thành MediaSource. MediaSource.Factory được chèn khi tạo trình phát.
• Các thực thể Renderer hiển thị từng thành phần của nội dung nghe nhìn. Các thành phần này được chèn khi tạo trình phát.
• TrackSelector chọn các bản nhạc do MediaSource cung cấp để mỗi Renderer có sẵn sử dụng. TrackSelector được chèn vào khi tạo trình phát.
• LoadControl kiểm soát thời điểm MediaSource lưu nội dung nghe nhìn vào bộ đệm và lượng nội dung nghe nhìn được lưu vào bộ đệm. LoadControl được chèn khi tạo trình phát.
• LivePlaybackSpeedControl kiểm soát tốc độ phát trong quá trình phát trực tiếp để cho phép trình phát gần với độ lệch trực tiếp đã định cấu hình. LivePlaybackSpeedControl được chèn khi tạo trình phát.

Khái niệm chèn các thành phần triển khai các phần chức năng của người chơi có trong toàn bộ thư viện. Việc triển khai mặc định của một số thành phần sẽ uỷ quyền công việc cho các thành phần được chèn thêm. Điều này cho phép nhiều thành phần phụ được thay thế riêng lẻ bằng các phương thức triển khai được định cấu hình theo cách tuỳ chỉnh.

Tuỳ chỉnh người chơi

Dưới đây là một số ví dụ phổ biến về cách tuỳ chỉnh trình phát bằng cách chèn các thành phần.

Định cấu hình ngăn xếp mạng

Chúng tôi có một trang về cách tuỳ chỉnh ngăn xếp mạng mà ExoPlayer sử dụng.

Lưu dữ liệu được tải từ mạng vào bộ nhớ đệm

Hãy xem hướng dẫn về cách lưu vào bộ nhớ đệm tạm thời khi đang di chuyển và tải nội dung nghe nhìn xuống.

Tuỳ chỉnh hoạt động tương tác với máy chủ

Một số ứng dụng có thể muốn chặn yêu cầu và phản hồi HTTP. Bạn có thể muốn chèn tiêu đề yêu cầu tuỳ chỉnh, đọc tiêu đề phản hồi của máy chủ, sửa đổi URI của yêu cầu, v.v. Ví dụ: ứng dụng của bạn có thể tự xác thực bằng cách chèn mã thông báo dưới dạng tiêu đề khi yêu cầu các phân đoạn nội dung nghe nhìn.

Ví dụ sau đây minh hoạ cách triển khai các hành vi này bằng cách chèn một DataSource.Factory tuỳ chỉnh vào DefaultMediaSourceFactory:

Kotlin

val dataSourceFactory =
  DataSource.Factory {
    val dataSource = httpDataSourceFactory.createDataSource()
    // Set a custom authentication request header.
    dataSource.setRequestProperty("Header", "Value")
    dataSource
  }
val player =
  ExoPlayer.Builder(context)
    .setMediaSourceFactory(
      DefaultMediaSourceFactory(context).setDataSourceFactory(dataSourceFactory)
    )
    .build()

Java

DataSource.Factory dataSourceFactory =
    () -> {
      HttpDataSource dataSource = httpDataSourceFactory.createDataSource();
      // Set a custom authentication request header.
      dataSource.setRequestProperty("Header", "Value");
      return dataSource;
    };

ExoPlayer player =
    new ExoPlayer.Builder(context)
        .setMediaSourceFactory(
            new DefaultMediaSourceFactory(context).setDataSourceFactory(dataSourceFactory))
        .build();

Trong đoạn mã ở trên, HttpDataSource được chèn bao gồm tiêu đề "Header: Value" trong mọi yêu cầu HTTP. Hành vi này được khắc phục đối với mọi lượt tương tác với nguồn HTTP.

Để có phương pháp chi tiết hơn, bạn có thể chèn hành vi đúng lúc bằng cách sử dụng ResolvingDataSource. Đoạn mã sau đây cho biết cách chèn tiêu đề yêu cầu ngay trước khi tương tác với nguồn HTTP:

Kotlin

val dataSourceFactory: DataSource.Factory =
  ResolvingDataSource.Factory(httpDataSourceFactory) { dataSpec: DataSpec ->
    // Provide just-in-time request headers.
    dataSpec.withRequestHeaders(getCustomHeaders(dataSpec.uri))
  }

Java

    DataSource.Factory dataSourceFactory =
        new ResolvingDataSource.Factory(
            httpDataSourceFactory,
            // Provide just-in-time request headers.
            dataSpec -> dataSpec.withRequestHeaders(getCustomHeaders(dataSpec.uri)));

Bạn cũng có thể sử dụng ResolvingDataSource để thực hiện các sửa đổi kịp thời đối với URI, như trong đoạn mã sau:

Kotlin

val dataSourceFactory: DataSource.Factory =
  ResolvingDataSource.Factory(httpDataSourceFactory) { dataSpec: DataSpec ->
    // Provide just-in-time URI resolution logic.
    dataSpec.withUri(resolveUri(dataSpec.uri))
  }

Java

DataSource.Factory dataSourceFactory =
    new ResolvingDataSource.Factory(
        httpDataSourceFactory,
        // Provide just-in-time URI resolution logic.
        dataSpec -> dataSpec.withUri(resolveUri(dataSpec.uri)));

Tuỳ chỉnh cách xử lý lỗi

Việc triển khai LoadErrorHandlingPolicy tuỳ chỉnh cho phép các ứng dụng tuỳ chỉnh cách ExoPlayer phản ứng với lỗi tải. Ví dụ: ứng dụng có thể muốn nhanh chóng báo lỗi thay vì thử lại nhiều lần, hoặc có thể muốn tuỳ chỉnh logic thời gian đợi để kiểm soát khoảng thời gian người chơi chờ giữa mỗi lần thử lại. Đoạn mã sau đây cho biết cách triển khai logic thời gian đợi tuỳ chỉnh:

Kotlin

val loadErrorHandlingPolicy: LoadErrorHandlingPolicy =
  object : DefaultLoadErrorHandlingPolicy() {
    override fun getRetryDelayMsFor(loadErrorInfo: LoadErrorInfo): Long {
      // Implement custom back-off logic here.
      return 0
    }
  }
val player =
  ExoPlayer.Builder(context)
    .setMediaSourceFactory(
      DefaultMediaSourceFactory(context).setLoadErrorHandlingPolicy(loadErrorHandlingPolicy)
    )
    .build()

Java

LoadErrorHandlingPolicy loadErrorHandlingPolicy =
    new DefaultLoadErrorHandlingPolicy() {
      @Override
      public long getRetryDelayMsFor(LoadErrorInfo loadErrorInfo) {
        // Implement custom back-off logic here.
        return 0;
      }
    };

ExoPlayer player =
    new ExoPlayer.Builder(context)
        .setMediaSourceFactory(
            new DefaultMediaSourceFactory(context)
                .setLoadErrorHandlingPolicy(loadErrorHandlingPolicy))
        .build();

Đối số LoadErrorInfo chứa thêm thông tin về lượt tải không thành công để tuỳ chỉnh logic dựa trên loại lỗi hoặc yêu cầu không thành công.

Tuỳ chỉnh cờ trình trích xuất

Bạn có thể sử dụng cờ trình trích xuất để tuỳ chỉnh cách trích xuất từng định dạng từ nội dung nghe nhìn tăng tiến. Bạn có thể đặt các giá trị này trên DefaultExtractorsFactory được cung cấp cho DefaultMediaSourceFactory. Ví dụ sau đây truyền một cờ cho phép tìm kiếm dựa trên chỉ mục cho luồng MP3.

Kotlin

val extractorsFactory =
  DefaultExtractorsFactory().setMp3ExtractorFlags(Mp3Extractor.FLAG_ENABLE_INDEX_SEEKING)
val player =
  ExoPlayer.Builder(context)
    .setMediaSourceFactory(DefaultMediaSourceFactory(context, extractorsFactory))
    .build()

Java

DefaultExtractorsFactory extractorsFactory =
    new DefaultExtractorsFactory().setMp3ExtractorFlags(Mp3Extractor.FLAG_ENABLE_INDEX_SEEKING);

ExoPlayer player =
    new ExoPlayer.Builder(context)
        .setMediaSourceFactory(new DefaultMediaSourceFactory(context, extractorsFactory))
        .build();

Bật tính năng tìm kiếm tốc độ bit không đổi

Đối với các luồng MP3, ADTS và AMR, bạn có thể bật tính năng tua gần đúng bằng cách giả định tốc độ bit không đổi với cờ FLAG_ENABLE_CONSTANT_BITRATE_SEEKING. Bạn có thể đặt các cờ này cho từng trình trích xuất bằng cách sử dụng các phương thức DefaultExtractorsFactory.setXyzExtractorFlags riêng lẻ như mô tả ở trên. Để bật tính năng tìm kiếm tốc độ bit không đổi cho tất cả trình trích xuất hỗ trợ tính năng này, hãy sử dụng DefaultExtractorsFactory.setConstantBitrateSeekingEnabled.

Kotlin

val extractorsFactory = DefaultExtractorsFactory().setConstantBitrateSeekingEnabled(true)

Java

DefaultExtractorsFactory extractorsFactory =
    new DefaultExtractorsFactory().setConstantBitrateSeekingEnabled(true);

Sau đó, bạn có thể chèn ExtractorsFactory thông qua DefaultMediaSourceFactory như mô tả để tuỳ chỉnh cờ trình trích xuất ở trên.

Bật tính năng xếp hàng bộ đệm không đồng bộ

Việc xếp hàng vùng đệm không đồng bộ là một điểm cải tiến trong quy trình kết xuất của ExoPlayer. Quy trình này hoạt động các thực thể MediaCodec ở chế độ không đồng bộ và sử dụng các luồng bổ sung để lên lịch giải mã và kết xuất dữ liệu. Việc bật tính năng này có thể giảm tình trạng bị rớt khung hình và âm thanh bị thiếu.

Tính năng xếp hàng bộ đệm không đồng bộ được bật theo mặc định trên các thiết bị chạy Android 12 (API cấp 31) trở lên và có thể được bật theo cách thủ công kể từ Android 6.0 (API cấp 23). Hãy cân nhắc bật tính năng này cho các thiết bị cụ thể mà bạn nhận thấy bị rớt khung hình hoặc âm thanh bị thiếu, đặc biệt là khi phát nội dung được bảo vệ bằng DRM hoặc nội dung có tốc độ khung hình cao.

Trong trường hợp đơn giản nhất, bạn cần chèn DefaultRenderersFactory vào trình phát như sau:

Kotlin

val renderersFactory = 
  DefaultRenderersFactory(context).forceEnableMediaCodecAsynchronousQueueing()
val exoPlayer = ExoPlayer.Builder(context, renderersFactory).build()

Java

DefaultRenderersFactory renderersFactory =
    new DefaultRenderersFactory(context).forceEnableMediaCodecAsynchronousQueueing();
ExoPlayer exoPlayer = new ExoPlayer.Builder(context, renderersFactory).build();

Nếu bạn đang tạo bản sao trực tiếp cho trình kết xuất, hãy truyền AsynchronousMediaCodecAdapter.Factory đến hàm khởi tạo MediaCodecVideoRenderer và MediaCodecAudioRenderer.

Tuỳ chỉnh các thao tác bằng ForwardingSimpleBasePlayer

Bạn có thể tuỳ chỉnh một số hành vi của thực thể Player bằng cách gói thực thể đó trong một lớp con của ForwardingSimpleBasePlayer. Lớp này cho phép bạn chặn các "toán tử" cụ thể, thay vì phải trực tiếp triển khai các phương thức Player. Điều này đảm bảo hành vi nhất quán của các lớp, chẳng hạn như play(), pause() và setPlayWhenReady(boolean). Phương thức này cũng đảm bảo tất cả các thay đổi về trạng thái được truyền đúng cách đến các thực thể Player.Listener đã đăng ký. Đối với hầu hết các trường hợp sử dụng tuỳ chỉnh, bạn nên ưu tiên ForwardingSimpleBasePlayer hơn ForwardingPlayer dễ gặp lỗi hơn do các đảm bảo về tính nhất quán này.

Ví dụ: để thêm một số logic tuỳ chỉnh khi bắt đầu hoặc dừng phát:

Kotlin

class PlayerWithCustomPlay(player: Player) : ForwardingSimpleBasePlayer(player) {
  override fun handleSetPlayWhenReady(playWhenReady: Boolean): ListenableFuture<*> {
    // Add custom logic
    return super.handleSetPlayWhenReady(playWhenReady)
  }
}

Java

class PlayerWithCustomPlay extends ForwardingSimpleBasePlayer {

  public PlayerWithCustomPlay(Player player) {
    super(player);
  }

  @Override
  protected ListenableFuture<?> handleSetPlayWhenReady(boolean playWhenReady) {
    // Add custom logic
    return super.handleSetPlayWhenReady(playWhenReady);
  }
}

Hoặc để không cho phép lệnh SEEK_TO_NEXT (và đảm bảo Player.seekToNext không hoạt động):

Kotlin

class PlayerWithoutSeekToNext(player: Player) : ForwardingSimpleBasePlayer(player) {
  override fun getState(): State {
    val state = super.getState()
    return state
      .buildUpon()
      .setAvailableCommands(
        state.availableCommands.buildUpon().remove(COMMAND_SEEK_TO_NEXT).build()
      )
      .build()
  }

  // We don't need to override handleSeek, because it is guaranteed not to be called for
  // COMMAND_SEEK_TO_NEXT since we've marked that command unavailable.
}

Java

class PlayerWithoutSeekToNext extends ForwardingSimpleBasePlayer {

  public PlayerWithoutSeekToNext(Player player) {
    super(player);
  }

  @Override
  protected State getState() {
    State state = super.getState();
    return state
        .buildUpon()
        .setAvailableCommands(
            state.availableCommands.buildUpon().remove(COMMAND_SEEK_TO_NEXT).build())
        .build();
  }

  // We don't need to override handleSeek, because it is guaranteed not to be called for
  // COMMAND_SEEK_TO_NEXT since we've marked that command unavailable.
}

Tuỳ chỉnh MediaSource

Các ví dụ ở trên chèn các thành phần tuỳ chỉnh để sử dụng trong quá trình phát của tất cả đối tượng MediaItem được truyền đến trình phát. Trong trường hợp cần tuỳ chỉnh chi tiết, bạn cũng có thể chèn các thành phần tuỳ chỉnh vào từng thực thể MediaSource. Các thành phần này có thể được truyền trực tiếp đến trình phát. Ví dụ dưới đây cho biết cách tuỳ chỉnh ProgressiveMediaSource để sử dụng DataSource.Factory, ExtractorsFactory và LoadErrorHandlingPolicy tuỳ chỉnh:

Kotlin

val mediaSource =
  ProgressiveMediaSource.Factory(customDataSourceFactory, customExtractorsFactory)
    .setLoadErrorHandlingPolicy(customLoadErrorHandlingPolicy)
    .createMediaSource(MediaItem.fromUri(streamUri))

Java

ProgressiveMediaSource mediaSource =
    new ProgressiveMediaSource.Factory(customDataSourceFactory, customExtractorsFactory)
        .setLoadErrorHandlingPolicy(customLoadErrorHandlingPolicy)
        .createMediaSource(MediaItem.fromUri(streamUri));

Tạo thành phần tuỳ chỉnh

Thư viện này cung cấp các phương thức triển khai mặc định của các thành phần được liệt kê ở đầu trang này cho các trường hợp sử dụng phổ biến. ExoPlayer có thể sử dụng các thành phần này, nhưng cũng có thể được tạo để sử dụng các phương thức triển khai tuỳ chỉnh nếu cần các hành vi không chuẩn. Sau đây là một số trường hợp sử dụng cho cách triển khai tuỳ chỉnh:

• Renderer – Bạn nên triển khai Renderer tuỳ chỉnh để xử lý loại nội dung nghe nhìn không được hỗ trợ theo các phương thức triển khai mặc định do thư viện cung cấp.
• TrackSelector – Việc triển khai TrackSelector tuỳ chỉnh cho phép nhà phát triển ứng dụng thay đổi cách các kênh do MediaSource hiển thị được chọn để sử dụng cho từng Renderer có sẵn.
• LoadControl – Việc triển khai LoadControl tuỳ chỉnh cho phép nhà phát triển ứng dụng thay đổi chính sách lưu vào bộ đệm của trình phát.
• Extractor – Nếu bạn cần hỗ trợ một định dạng vùng chứa hiện không được thư viện hỗ trợ, hãy cân nhắc triển khai một lớp Extractor tuỳ chỉnh.
• MediaSource – Bạn nên triển khai lớp MediaSource tuỳ chỉnh nếu muốn lấy các mẫu nội dung nghe nhìn để cung cấp cho trình kết xuất theo cách tuỳ chỉnh hoặc nếu muốn triển khai hành vi kết hợp MediaSource tuỳ chỉnh.
• MediaSource.Factory – Việc triển khai MediaSource.Factory tuỳ chỉnh cho phép ứng dụng tuỳ chỉnh cách tạo MediaSource từ MediaItem.
• DataSource – Gói cấp trên của ExoPlayer đã chứa một số cách triển khai DataSource cho nhiều trường hợp sử dụng. Bạn nên triển khai lớp DataSource của riêng mình để tải dữ liệu theo cách khác, chẳng hạn như qua giao thức tuỳ chỉnh, sử dụng ngăn xếp HTTP tuỳ chỉnh hoặc từ bộ nhớ đệm cố định tuỳ chỉnh.

Khi tạo thành phần tuỳ chỉnh, bạn nên làm như sau:

• Nếu một thành phần tuỳ chỉnh cần báo cáo sự kiện trở lại ứng dụng, bạn nên thực hiện việc này bằng cách sử dụng cùng một mô hình với các thành phần ExoPlayer hiện có, chẳng hạn như sử dụng các lớp EventDispatcher hoặc truyền Handler cùng với trình nghe đến hàm khởi tạo của thành phần.
• Bạn nên sử dụng cùng một mô hình cho các thành phần tuỳ chỉnh như các thành phần ExoPlayer hiện có để cho phép ứng dụng định cấu hình lại trong khi phát. Để thực hiện việc này, các thành phần tuỳ chỉnh phải triển khai PlayerMessage.Target và nhận các thay đổi về cấu hình trong phương thức handleMessage. Mã ứng dụng phải truyền các thay đổi về cấu hình bằng cách gọi phương thức createMessage của ExoPlayer, định cấu hình thông báo và gửi thông báo đó đến thành phần bằng PlayerMessage.send. Việc gửi thông báo để phân phối trên luồng phát đảm bảo rằng các thông báo đó được thực thi theo thứ tự với mọi thao tác khác đang được thực hiện trên trình phát.