1. Accueil
  2. Question et réponse
  3. Android Chromecast Comportement de recherche - Redémarre la vidéo depuis le début

Android Chromecast Comportement de recherche - Redémarre la vidéo depuis le début

2015-12-16 5 views
0

J'essaie d'implémenter une fonctionnalité de recherche personnalisée (avance/retour) sur Google CastCompanionLibrary-android. Je remarque un comportement étrange où, malgré le fait que l'utilisateur cherche une position seekBar non nulle, la vidéo qui joue sur la distribution est obligée de recommencer depuis le début, ignorant totalement la position de recherche demandée.Android Chromecast Comportement de recherche - Redémarre la vidéo depuis le début

Mon SeekBar de lecteur vidéo d'écoute de la mise en œuvre

@Override 
    public void onStopTrackingTouch(SeekBar seekBar) { 
     int progress = seekBar.getProgress(); 
     if (mPlaybackState == PlaybackState.PLAYING) { 
      // determine local or remote playback 
      switch (mPlaybackLocation) { 
       case PlaybackLocation.LOCAL: 
        mLocalVideoView.seekTo(progress); 
        break; 
       case PlaybackLocation.REMOTE: 
        try { 
         mVideoCastManager.play(progress); 
        } catch (Exception e) { 
         CastUtils.handleException(mParentActivity, e); 
        } 
        break; 
       default: 
        Log.d(TAG, "unknown playback location"); 
        break; 
      } 
     } else if (mPlaybackState != PlaybackState.IDLE) { 
      mLocalVideoView.seekTo(progress); 
     } 


    }

Contrairement à cette autre related question, je suis confiant que notre serveur de streaming fonctionne comme il se doit parce que quand j'utilise la classe par défaut VideoCastControllerActivity, on remarque correcte comportement de recherche . Mais notre objectif n'est pas d'utiliser la classe par défaut car c'est une activité en plein écran qui ne fonctionne pas bien avec notre application. Fondamentalement, nous aimerions exactement la même fonctionnalité que l'application Youtube où la barre de recherche normale contrôle à la fois le lecteur local et le lecteur distant sans avoir à laisser l'écran en cours en plein écran. Le fait est que ma mise en œuvre est très similaire, sinon identique, à l'exemple de référence posté ci-dessous. La ligne de clé est que les deux appellent:

mVideoCastManager.play(progress);

(Et sans succès soit en appelant VideoCastManager.seekAndPlay (int position). En fait, VideoCastControllerActivity appelle en fait le jeu() qui appelle à son tour seekAndPlay())

Joueur Référence (Cast-Vidéos) recherchant implementation

private void play(int position) { 
     startControllersTimer(); 
     switch (mLocation) { 
      case LOCAL: 
       mVideoView.seekTo(position); 
       mVideoView.start(); 
       break; 
      case REMOTE: 
       mPlaybackState = PlaybackState.BUFFERING; 
       updatePlayButton(mPlaybackState); 
       try { 
        mCastManager.play(position); 
       } catch (Exception e) { 
        Utils.handleException(this, e); 
       } 
       break; 
      default: 
       break; 
     } 
     restartTrickplayTimer(); 
    }

d'ailleurs, je remarque que la barre de recherche lorsque le lecteur distant affiche momentanément en place, il ne remplit même pas à la bonne position qui a été demandé, au lieu de remplir jusqu'à environ 10% des le bar entier. Voir l'image ci-jointe où j'avais cherché à 1:10 sur une vidéo 1:29 (~ 80%)

Est-ce un bug avec le CCL ou que ne pourrais-je pas faire correctement?

EDIT: Récepteur & Journaux de l'expéditeur au cours de la recherche

[565.374s] [cast.receiver.IpcChannel] Received message: {"data":"{\"requestId\":7,\"type\":\"SEEK\",\"mediaSessionId\":2,\"currentTime\":0.087,\"resumeState\":\"PLAYBACK_START\"}","namespace":"urn:x-cast:com.google.cast.media","senderId":"14:net.ajplus.beta-19"} 
cast_receiver.js:40 [565.382s] [cast.receiver.CastMessageBus] Dispatching CastMessageBus message 
cast_receiver.js:40 [565.397s] [cast.receiver.MediaManager] MediaManager message received 
cast_receiver.js:40 [565.404s] [cast.receiver.MediaManager] Dispatching MediaManager seek event 
cast_receiver.js:40 [565.409s] [cast.receiver.MediaManager] onSeek: {"requestId":7,"mediaSessionId":2,"currentTime":0.087,"resumeState":"PLAYBACK_START"} 
cast_receiver.js:40 [565.420s] [cast.receiver.MediaManager] Sending broadcast status message 
cast_receiver.js:40 [565.426s] [cast.receiver.IpcChannel] IPC message sent: {"namespace":"urn:x-cast:com.google.cast.media","senderId":"*:*","data":"{\"type\":\"MEDIA_STATUS\",\"status\":[{\"mediaSessionId\":2,\"playbackRate\":1,\"playerState\":\"BUFFERING\",\"currentTime\":0.087,\"supportedMediaCommands\":15,\"volume\":{\"level\":1,\"muted\":false},\"activeTrackIds\":[],\"currentItemId\":2,\"repeatMode\":\"REPEAT_OFF\"}],\"requestId\":7}"} 
player.html:1 Mixed Content: The page at 'https://www.gstatic.com/eureka/player/player.html?skin' was loaded over HTTPS, but requested an insecure video 'http://bc29.domain.me/fms/2848955552001/201512/video.mp4'. This content should also be served over HTTPS. 
cast_receiver.js:40 [568.490s] [cast.receiver.MediaManager] Buffering state changed, isPlayerBuffering: false old time: 0.12 current time: 1.167672 
cast_receiver.js:40 [568.515s] [cast.receiver.MediaManager] Sending broadcast status message 
cast_receiver.js:40 [568.538s] [cast.receiver.IpcChannel] IPC message sent: {"namespace":"urn:x-cast:com.google.cast.media","senderId":"*:*","data":"{\"type\":\"MEDIA_STATUS\",\"status\":[{\"mediaSessionId\":2,\"playbackRate\":1,\"playerState\":\"PLAYING\",\"currentTime\":1.229581,\"supportedMediaCommands\":15,\"volume\":{\"level\":1,\"muted\":false},\"activeTrackIds\":[],\"currentItemId\":2,\"repeatMode\":\"REPEAT_OFF\"}],\"requestId\":0}"}

expéditeur

12-17 15:19:55.803 5639-5639/net.domain.android D/ccl_VideoCastManager: [v2.5.1] attempting to play media at position 87 seconds 
12-17 15:19:55.803 5639-5639/net.domain.android D/ccl_VideoCastManager: [v2.5.1] attempting to seek media 
12-17 15:19:55.902 5639-5639/net.domain.android D/ccl_VideoCastManager: [v2.5.1] RemoteMediaPlayer::onStatusUpdated() is reached 
12-17 15:19:55.902 5639-5639/net.domain.android D/ccl_VideoCastManager: [v2.5.1] onRemoteMediaPlayerStatusUpdated() reached 
12-17 15:19:55.902 5639-5639/net.domain.android D/ccl_VideoCastManager: [v2.5.1] onQueueUpdated() reached 
12-17 15:19:55.902 5639-5639/net.domain.android D/ccl_VideoCastManager: [v2.5.1] Queue Items size: 1, Item: [email protected], Repeat Mode: 0, Shuffle: false 
12-17 15:19:55.902 5639-5639/net.domain.android D/QueueDataProvider: Queue is updated with a list of size: 1 
12-17 15:19:55.902 5639-5639/net.domain.android D/QueueDataProvider: Queue was updated 
12-17 15:19:55.905 5639-5639/net.domain.android D/ccl_VideoCastManager: [v2.5.1] [queue] Queue Item is: {"media":{"contentId":"http://bc29.domain.me/fms/2848955552001/201512/video.mp4","streamType":"BUFFERED","contentType":"video\/mp4","metadata":{"metadataType":1,"images":[{"url":"http:\/\/bc29.ajmn.me\/pd\/2848955552001\/201512\/1316\/2848955552001_4663173896001_RT-60-GOPCNN-TECHNOLOGYSECURITY-151215-FINAL-SUB-thumbnail.jpg?pubId=2848955552001","width":0,"height":0},{"url":"http:\/\/api.domain.net\/pictures\/video_image\/video_Still004.jpg","width":0,"height":0}],"title":"When the GOP geeks out on surveillance technologies","subtitle":"During the fifth GOP debate, candidates went on and on how technologies could prevent the next “terrorist attack.”\r\n"},"duration":89.931},"itemId":2,"autoplay":true,"startTime":0,"preloadTime":20} 
12-17 15:19:55.905 5639-5639/net.domain.android D/ccl_VideoCastManager: [v2.5.1] onRemoteMediaPlayerStatusUpdated(): Player status = buffering 
12-17 15:19:55.905 5639-5639/net.domain.android D/ccl_VideoCastManager: [v2.5.1] updateMiniControllersVisibility() reached with visibility: true 
12-17 15:19:55.905 5639-5639/net.domain.android D/AJPBaseActivity: onRemoteMediaPlayerStatusUpdated() 
12-17 15:19:55.905 5639-5639/net.domain.android D/ccl_VideoCastNotificat: [v2.5.1] onRemoteMediaPlayerStatusUpdated() reached with status: 4 
12-17 15:19:59.123 5639-5639/net.domain.android D/ccl_VideoCastManager: [v2.5.1] RemoteMediaPlayer::onStatusUpdated() is reached 
12-17 15:19:59.123 5639-5639/net.domain.android D/ccl_VideoCastManager: [v2.5.1] onRemoteMediaPlayerStatusUpdated() reached 
12-17 15:19:59.124 5639-5639/net.domain.android D/ccl_VideoCastManager: [v2.5.1] onQueueUpdated() reached 
12-17 15:19:59.124 5639-5639/net.domain.android D/ccl_VideoCastManager: [v2.5.1] Queue Items size: 1, Item: [email protected], Repeat Mode: 0, Shuffle: false 
12-17 15:19:59.124 5639-5639/net.domain.android D/QueueDataProvider: Queue is updated with a list of size: 1 
12-17 15:19:59.124 5639-5639/net.domain.android D/QueueDataProvider: Queue was updated 
12-17 15:19:59.124 5639-5639/net.domain.android D/ccl_VideoCastManager: [v2.5.1] [queue] Queue Item is: {"media":{"contentId":"http://bc29.domain.me/fms/2848955552001/201512/video.mp4","streamType":"BUFFERED","contentType":"video\/mp4","metadata":{"metadataType":1,"images":[{"url":"http://bc29.domain.me/fms/2848955552001/201512/video_thumbnail.jpg?pubId=2848955552001","width":0,"height":0},{"url":"http://bc29.domain.me/fms/2848955552001/201512/video_Still004.jpg","width":0,"height":0}],"title":"When the GOP geeks out on surveillance technologies","subtitle":"During the fifth GOP debate, candidates went on and on how technologies could prevent the next “terrorist attack.”\r\n"},"duration":89.931},"itemId":2,"autoplay":true,"startTime":0,"preloadTime":20} 
12-17 15:19:59.124 5639-5639/net.domain.android D/ccl_VideoCastManager: [v2.5.1] onRemoteMediaPlayerStatusUpdated(): Player status = playing 
12-17 15:19:59.125 5639-5639/net.domain.android D/ccl_BaseCastManager: [v2.5.1] startReconnectionService() for media length lef = 88700 
12-17 15:19:59.127 5639-5639/net.domain.android D/ccl_VideoCastManager: [v2.5.1] startNotificationService() 
12-17 15:19:59.129 5639-5639/net.domain.android D/ccl_VideoCastManager: [v2.5.1] updateMiniControllersVisibility() reached with visibility: true 
12-17 15:19:59.129 5639-5639/net.domain.android D/AJPBaseActivity: onRemoteMediaPlayerStatusUpdated() 
12-17 15:19:59.129 5639-5639/net.domain.android D/ccl_VideoCastNotificat: [v2.5.1] onRemoteMediaPlayerStatusUpdated() reached with status: 2 
12-17 15:19:59.129 5639-5639/net.domain.android D/ccl_ReconnectionService: [v2.5.1] onStartCommand() is called 
12-17 15:19:59.129 5639-5639/net.domain.android D/ccl_ReconnectionService: [v2.5.1] setUpEndTimer(): setting up a timer for the end of current media 
12-17 15:19:59.139 5639-5639/net.domain.android D/ccl_VideoCastNotificat: [v2.5.1] onStartCommand 
12-17 15:19:59.139 5639-5639/net.domain.android D/ccl_VideoCastNotificat: [v2.5.1] onStartCommand(): Action: ACTION_VISIBILITY false

Seek fails to show requested position on Remote cast player

Source

2015-12-16 kip2

+0

Pouvez-vous activer la connexion sur votre récepteur et fournir le journal lorsque vous émettez la commande de recherche? En outre, activez la connexion dans CCL et faites la même chose (remplacez DEBUG par true dans LogUtils.java). –

+0

J'ai posté ici les journaux sur le récepteur et l'expéditeur pendant l'heure de recherche, montrant une demande de chercher à la 87e seconde. Peut également lier les journaux complets montrant l'interaction de la session entière de la lecture initiale à la fin – kip2

+0

Si utile, veuillez trouver les journaux complets ici: https://docs.google.com/document/d/1eQI71EIWpqwskmRD5C5kOqftWmLWaWFsXrfLcbRd10M/modifier? usp = partage et https://docs.google.com/document/d/1PJ9J4_DqrSV5PqaTTZD2tdWrMYFg3qyJUHblYJiuHOQ/edit?usp=sharing Merci à l'avance! – kip2

Répondre

4

Le temps que vous passez à "jouer (position)" devrait être en millisecondes, mais en fonction de vos journaux, vous êtes passant en secondes, donc si vous voulez chercher à 87 secondes, vous devez passer 87000 à cette méthode (voir le javadoc sur cette méthode). L'instruction de journal dans CCL devrait être corrigée pour refléter cela (corrigera dans la prochaine mise à jour) mais le JavaDoc est correct.

Source

2015-12-17 15:37:56

+0

Wow. Miss incroyable par moi;) Merci beaucoup !! – kip2

+0

Salut @Ali Naddaf est-il possible d'obtenir la position de recherche quand Chromecast déconnecté, de sorte que lorsque la prochaine fois il se connectera à nouveau, je veux déplacer le chercher à cette position sur Chromecast. – Min2

+0

Lorsque vous êtes déconnecté, vous ne pouvez pas obtenir la position; Cependant, vous pouvez avoir une variable locale qui est mise à jour toutes les secondes et qui peut rester synchronisée avec la position actuelle. Lorsque vous êtes déconnecté, votre variable locale pointe vers la dernière position et vous pouvez persister ou faire ce que vous souhaitez. –

 Questions connexes

  • Aucun problème connexe^_^