खिलाड़ी से जुड़े इवेंट

वीडियो चलाने के इवेंट की जानकारी सुनना

स्थिति में बदलाव और वीडियो चलाने में होने वाली गड़बड़ियों जैसे इवेंट को रजिस्टर किए गए इवेंट के तौर पर रिपोर्ट किया जाता है Player.Listener इंस्टेंस. लिसनर को रजिस्टर करने के लिए, इवेंट:

Kotlin

// Add a listener to receive events from the player.
player.addListener(listener)

Java

// Add a listener to receive events from the player.
player.addListener(listener);

Player.Listener में खाली डिफ़ॉल्ट तरीके नहीं हैं, इसलिए आपको सिर्फ़ इन्हें लागू करना होगा अपनी पसंद का तरीका बताएं. इसकी पूरी जानकारी के लिए, Javadoc पर जाएं उन्हें कॉल करने का तरीक़ा क्या है और उन्हें कब कॉल किया जाता है. सबसे ज़रूरी तरीकों में से कुछ हैं: नीचे ज़्यादा जानकारी दी गई है.

लोगों के पास अलग-अलग इवेंट कॉलबैक लागू करने या सामान्य onEvents कॉलबैक, जिसे एक या उससे ज़्यादा इवेंट होने के बाद कॉल किया जाता है हैं बेमिसाल. किस वजह से, यह जानने के लिए Individual callbacks vs onEvents पर जाएं को अलग-अलग कामों में इस्तेमाल किया जाना चाहिए.

वीडियो चलाने की स्थिति में बदलाव

खिलाड़ी की स्थिति में बदलाव लागू करके रजिस्टर की गई सूची में मौजूद onPlaybackStateChanged(@State int state) Player.Listener. प्लेयर की स्थिति, इन चार में से किसी एक स्थिति में हो सकती है:

  • Player.STATE_IDLE: यह प्लेयर की शुरुआती स्थिति होती है. यह वह स्थिति होती है जब प्लेयर और जब प्लेबैक विफल हो जाए. खिलाड़ी के पास सीमित संसाधन ही रहेंगे दर्ज करें.
  • Player.STATE_BUFFERING: खिलाड़ी इससे तुरंत नहीं खेल सकता मौजूदा स्थिति. ऐसा अक्सर इसलिए होता है, क्योंकि ज़्यादा डेटा लोड करना पड़ता है.
  • Player.STATE_READY: खिलाड़ी अपने मौजूदा डिवाइस से तुरंत खेल सकता है स्थिति.
  • Player.STATE_ENDED: प्लेयर ने सभी मीडिया चला लिए.

इन स्थितियों के अलावा, खिलाड़ी के पास यह बताने के लिए playWhenReady फ़्लैग होता है जो उपयोगकर्ता को ऐसे विज्ञापन दिखानी हो. इस फ़्लैग में किए गए बदलावों को लागू करके onPlayWhenReadyChanged(playWhenReady, @PlayWhenReadyChangeReason int reason).

जब कोई खिलाड़ी चल रहा हो, तब उसकी पोज़िशन बेहतर हो रही हो और मीडिया उपयोगकर्ता को दिखाया जाता है) जब ये तीनों शर्तें पूरी होती हों:

  • खिलाड़ी की स्थिति Player.STATE_READY है
  • playWhenReady true है
  • इसके ज़रिए वापस करने की वजह से, वीडियो चलाने की प्रोसेस रोकी नहीं गई Player.getPlaybackSuppressionReason अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

इन प्रॉपर्टी की अलग-अलग जांच करने के बजाय, Player.isPlaying कॉल किया जा सकता है. इस स्थिति में बदलाव करने के लिए, onIsPlayingChanged(boolean isPlaying):

Kotlin

player.addListener(
  object : Player.Listener {
    override fun onIsPlayingChanged(isPlaying: Boolean) {
      if (isPlaying) {
        // Active playback.
      } else {
        // Not playing because playback is paused, ended, suppressed, or the player
        // is buffering, stopped or failed. Check player.playWhenReady,
        // player.playbackState, player.playbackSuppressionReason and
        // player.playerError for details.
      }
    }
  }
)

Java

player.addListener(
    new Player.Listener() {
      @Override
      public void onIsPlayingChanged(boolean isPlaying) {
        if (isPlaying) {
          // Active playback.
        } else {
          // Not playing because playback is paused, ended, suppressed, or the player
          // is buffering, stopped or failed. Check player.getPlayWhenReady,
          // player.getPlaybackState, player.getPlaybackSuppressionReason and
          // player.getPlaybackError for details.
        }
      }
    });

प्‍लेबैक त्रुटियां

जिन गड़बड़ियों की वजह से वीडियो नहीं चल पाता है उनका पता लगाने के लिए, रजिस्टर की गई सूची में मौजूद onPlayerError(PlaybackException error) Player.Listener. कोई गड़बड़ी होने पर, इस तरीके को कॉल किया जाएगा वीडियो चलाने की स्थिति के Player.STATE_IDLE में बदलने से ठीक पहले. जिन वीडियो को रोका गया है या नहीं चलाया जा सकता उन्हें ExoPlayer.prepare पर कॉल करके फिर से वीडियो चलाने की कोशिश की जा सकती है.

ध्यान दें कि कुछ Player लागू करने पर, इस तरह की सब-क्लास के इंस्टेंस पास हो जाते हैं PlaybackException. इसके लिए उदाहरण, ExoPlayer पास ExoPlaybackException है, जिसमें type, rendererIndex, और अन्य ExoPlayer फ़ील्ड.

नीचे दिए गए उदाहरण में, यह पता लगाने का तरीका बताया गया है कि एचटीटीपी नेटवर्किंग समस्या:

Kotlin

player.addListener(
  object : Player.Listener {
    override fun onPlayerError(error: PlaybackException) {
      val cause = error.cause
      if (cause is HttpDataSourceException) {
        // An HTTP error occurred.
        val httpError = cause
        // It's possible to find out more about the error both by casting and by querying
        // the cause.
        if (httpError is InvalidResponseCodeException) {
          // Cast to InvalidResponseCodeException and retrieve the response code, message
          // and headers.
        } else {
          // Try calling httpError.getCause() to retrieve the underlying cause, although
          // note that it may be null.
        }
      }
    }
  }
)

Java

player.addListener(
    new Player.Listener() {
      @Override
      public void onPlayerError(PlaybackException error) {
        @Nullable Throwable cause = error.getCause();
        if (cause instanceof HttpDataSourceException) {
          // An HTTP error occurred.
          HttpDataSourceException httpError = (HttpDataSourceException) cause;
          // It's possible to find out more about the error both by casting and by querying
          // the cause.
          if (httpError instanceof HttpDataSource.InvalidResponseCodeException) {
            // Cast to InvalidResponseCodeException and retrieve the response code, message
            // and headers.
          } else {
            // Try calling httpError.getCause() to retrieve the underlying cause, although
            // note that it may be null.
          }
        }
      }
    });

प्लेलिस्ट ट्रांज़िशन

जब प्लेयर, प्लेलिस्ट में कोई नया मीडिया आइटम बदलता है onMediaItemTransition(MediaItem mediaItem, @MediaItemTransitionReason int reason) को रजिस्टर किए जाने पर कॉल किया गया Player.Listener ऑब्जेक्ट. वजह से पता चलता है कि यह ऑटोमैटिक ट्रांज़िशन, सीक (उदाहरण के लिए, player.next() को कॉल करने के बाद) का दोहराव एक ही आइटम या किसी प्लेलिस्ट में बदलाव की वजह से हो सकता है (उदाहरण के लिए, अगर चल रहा आइटम निकाला जाता है).

मेटाडेटा

player.getCurrentMediaMetadata() से लौटाए गए मेटाडेटा में कई वजहों से बदलाव हो सकता है वजहें: प्लेलिस्ट के ट्रांज़िशन, इन-स्ट्रीम मेटाडेटा के अपडेट या मौजूदा MediaItem मिड-प्लेबैक.

अगर आपको मेटाडेटा में बदलाव करने हैं, जैसे कि ऐसा यूज़र इंटरफ़ेस (यूआई) अपडेट करना जो मौजूदा टाइटल, onMediaMetadataChanged को सुना जा सकता है.

वीडियो नियंत्रण चालू है

Player.seekTo तरीकों को कॉल करने पर, रजिस्टर किए गए नंबर पर कॉलबैक की एक सीरीज़ बनती है Player.Listener इंस्टेंस:

  1. onPositionDiscontinuity में reason=DISCONTINUITY_REASON_SEEK की सदस्यता लें. यह है Player.seekTo को कॉल करने का सीधा नतीजा है. कॉलबैक में PositionInfo है सीक के पहले और बाद की जगह के लिए फ़ील्ड.
  2. वीडियो में आगे/पीछे जाने की कार्रवाई से जुड़ी किसी भी मौजूदा स्थिति के साथ onPlaybackStateChanged. ध्यान दें कि हो सकता है कि ऐसा कोई बदलाव न हो.

अलग-अलग कॉलबैक बनाम onEvents

लिसनर अलग-अलग कॉलबैक लागू करने का विकल्प चुन सकते हैं, जैसे onIsPlayingChanged(boolean isPlaying) और जेनरिक onEvents(Player player, Events events) कॉलबैक. सामान्य कॉलबैक से मिलता है Player ऑब्जेक्ट को ऐक्सेस करता है और events के उस सेट की जानकारी देता है जो हैं बेमिसाल. इस कॉलबैक को हमेशा इससे संबंधित कॉलबैक के बाद कॉल किया जाता है अलग-अलग इवेंट में शामिल हो सकते हैं.

Kotlin

override fun onEvents(player: Player, events: Player.Events) {
  if (
    events.contains(Player.EVENT_PLAYBACK_STATE_CHANGED) ||
      events.contains(Player.EVENT_PLAY_WHEN_READY_CHANGED)
  ) {
    uiModule.updateUi(player)
  }
}

Java

@Override
public void onEvents(Player player, Events events) {
  if (events.contains(Player.EVENT_PLAYBACK_STATE_CHANGED)
      || events.contains(Player.EVENT_PLAY_WHEN_READY_CHANGED)) {
    uiModule.updateUi(player);
  }
}

नीचे दिए गए मामलों में, अलग-अलग इवेंट को प्राथमिकता दी जानी चाहिए:

  • श्रोताओं की दिलचस्पी बदलावों की वजहों में है. उदाहरण के लिए, onPlayWhenReadyChanged या onMediaItemTransition के लिए बताई गई वजहें.
  • लिसनर सिर्फ़ कॉलबैक पैरामीटर के ज़रिए दी गई नई वैल्यू पर काम करता है या कुछ ऐसा ट्रिगर करता है जो कॉलबैक पैरामीटर पर निर्भर नहीं होता.
  • लिसनर लागू करने पर, साफ़ तौर पर यह बताया जाता है कि ने मेथड के नाम में इवेंट को ट्रिगर किया.
  • लिसनर एक ऐसे ऐनलिटिक्स सिस्टम को रिपोर्ट करता है जिसे आपके काम की सभी अलग-अलग इवेंट और स्थिति में होने वाले बदलाव.

सामान्य onEvents(Player player, Events events) को इसमें प्राथमिकता दी जानी चाहिए ये मामले:

  • लिसनर कई इवेंट के लिए एक ही लॉजिक ट्रिगर करना चाहता है. इसके लिए उदाहरण के लिए, onPlaybackStateChanged और, दोनों के लिए यूज़र इंटरफ़ेस (यूआई) अपडेट करना onPlayWhenReadyChanged.
  • आगे के इवेंट ट्रिगर करने के लिए, लिसनर को Player ऑब्जेक्ट का ऐक्सेस चाहिए, उदाहरण के लिए, किसी मीडिया आइटम ट्रांज़िशन के बाद.
  • लिसनर, रिपोर्ट की गई एक से ज़्यादा स्टेट वैल्यू का इस्तेमाल करना चाहता है एक साथ अलग-अलग कॉलबैक के ज़रिए या Player गैटर के साथ मिलाकर तरीकों का इस्तेमाल करना होगा. उदाहरण के लिए, Player.getCurrentWindowIndex() का इस्तेमाल onTimelineChanged में दिया गया Timeline, सिर्फ़ onEvents कॉलबैक.
  • सुनने वाले की दिलचस्पी इस बात में होती है कि क्या इवेंट एक साथ सही तरीके से हुए हैं. इसके लिए उदाहरण, onPlaybackStateChanged से STATE_BUFFERING में, एक मीडिया आइटम की वजह से ट्रांज़िशन है.

कुछ मामलों में, लिसनर को अलग-अलग कॉलबैक को जेनरिक onEvents कॉलबैक. उदाहरण के लिए, मीडिया आइटम में बदलाव की वजहों को रिकॉर्ड करने के लिए onMediaItemTransition के साथ, लेकिन सभी राज्य बदलावों का इस्तेमाल करने के बाद ही काम करें onEvents में एक साथ.

AnalyticsListener का इस्तेमाल करना

ExoPlayer का इस्तेमाल करने पर, प्लेयर के साथ AnalyticsListener को रजिस्टर किया जा सकता है addAnalyticsListener पर कॉल करके. AnalyticsListener लागू करने की सुविधा ज़्यादा जानकारी वाले इवेंट को सुनने के लिए, जो आंकड़ों और लॉगिन करने के लिए काम के हो सकते हैं के मकसद से बनाया गया है. ज़्यादा जानकारी के लिए, कृपया Analytics का पेज देखें.

EventLogger का इस्तेमाल करना

EventLogger एक AnalyticsListener है, जिसे सीधे लाइब्रेरी ने इसके लिए उपलब्ध कराया है का इस्तेमाल नहीं किया जा सकता. यह जानने के लिए कि उपयोगी है या नहीं, EventLogger को ExoPlayer में जोड़ें एक लाइन की मदद से अतिरिक्त डेटा लॉग करें:

Kotlin

player.addAnalyticsListener(EventLogger())

Java

player.addAnalyticsListener(new EventLogger());

ज़्यादा जानकारी के लिए, डीबग लॉगिंग पेज देखें.

वीडियो चलाने की तय जगहों पर इवेंट चालू करना

इस्तेमाल के कुछ उदाहरणों में, वीडियो चलाने की कुछ खास स्थितियों पर इवेंट ट्रिगर करना ज़रूरी होता है. यह है PlayerMessage का इस्तेमाल करके काम करता है. PlayerMessage को इनका इस्तेमाल करके बनाया जा सकता है ExoPlayer.createMessage. वीडियो चलाने की वह स्थिति जहां इसे चलाया जाना चाहिए को PlayerMessage.setPosition का इस्तेमाल करके सेट किया जा सकता है. मैसेज इस डिवाइस पर एक्ज़ीक्यूट किए जाते हैं डिफ़ॉल्ट रूप से प्लेबैक थ्रेड, लेकिन इसे कस्टमाइज़ किया जा सकता है PlayerMessage.setLooper. PlayerMessage.setDeleteAfterDelivery का इस्तेमाल किया जा सकता है यह कंट्रोल करने के लिए कि तय किए गए समय में एक उपयोगकर्ता के तौर पर, हर बार मैसेज भेजा जाएगा या नहीं वीडियो चलाने की जगह मिली है (वीडियो चलाने की वजह से ऐसा कई बार हो सकता है बार-बार दिखाने की सुविधा चालू करें) या सिर्फ़ पहली बार. PlayerMessage होने के बाद कॉन्फ़िगर किया है, तो इसे PlayerMessage.send का इस्तेमाल करके शेड्यूल किया जा सकता है.

Kotlin

player
  .createMessage { messageType: Int, payload: Any? -> }
  .setLooper(Looper.getMainLooper())
  .setPosition(/* mediaItemIndex= */ 0, /* positionMs= */ 120000)
  .setPayload(customPayloadData)
  .setDeleteAfterDelivery(false)
  .send()

Java

player
    .createMessage(
        (messageType, payload) -> {
          // Do something at the specified playback position.
        })
    .setLooper(Looper.getMainLooper())
    .setPosition(/* mediaItemIndex= */ 0, /* positionMs= */ 120_000)
    .setPayload(customPayloadData)
    .setDeleteAfterDelivery(false)
    .send();