Tous les projets

ID Projet Ouverte Type Catégorie État Résumé
14263Freebox Player (Revolution / V6)09/02/2014AnomalieServeur de rendu UPnP/DLNAÀ investiguerL'accès RTSP demande un Transport: non standard Description de la tâche

Le Player demande le transport FBXRTP/AVP au lieu de RTP/AVP dans la méthode SETUP, ce qui casse l’interopérabilité avec la plupart des serveurs RTSP. Je vois quatre solutions:

1) Considérer le support RTSP comme purement interne à la Freebox, pour la TV ou le replay (vu dans le debug que c’est du RTP), et cesser d’annoncer rtsp-rtp-udp comme un protocole reconnu pour upnp/av

2) Une variante, continuer d’annoncer le support mais précéder le SETUP par un appel à la méthode OPTIONS:
OPTIONS * RTSP/1.0
CSeq: 6
Require: fbxrtp-transport

Comme ça le but est totalement clair. Voir http://tools.ietf.org/html/rfc2326#page-30

À noter que le Player spamme le serveur rtsp avec des appels à OPTIONS sans payload, je ne vois pas bien à quoi c’est sensé servir.

3) Remplacer la demande FBXRTP/AVP par un réel RTP/AVP

4) Faire un premier SETUP avec Transport: FBXRTP/AVP;... et si la réponse est “461 Unsupported Transport” réessayer en mode “compatible” avec RTP/AVP; une alternative est de détecter le support FBXRTP avec la méthode OPTIONS et choisir après quel transport demander.

Je ne pense pas que les solutions 1) et 2) soient intéressantes hormis qu’elles sont celles qui demandent le moins de travail/maintenance de la part des dev freebox. La 3 est la plus correcte niveau interopérabilité, mais si vous avez un FBXRTP c’est probablement pour avoir des fonctions ad-hoc dedans auquelles vous ne pouvez peut-être pas renoncer.
La 4 représente le meilleur compromis IMHO, avec un système inchangé pour les utilisations existantes (donc pas de maintainance nightmare sur la TV ou autre) et une interopérabilité accrue dans les autres cas.

14260Freebox Player (Revolution / V6)08/02/2014AnomalieClient UPnP AVÀ investiguerLe client RTSP ne respecte pas la bonne directive "a=co... Description de la tâche

Lorsque j’appelle SetAVTransportURI sur l’interface AVTransport du MediaRenderer DLNA du Player, avec CurrentURI valant rtsp://192.168.0.1:8081/stream.ts j’obtiens l’échange suivant:

Envoyé par le Player à 192.168.0.1:8081:

DESCRIBE rtsp://192.168.0.1/stream.ts RTSP/1.0
CSeq: 1
Accept: application/sdp
User-Agent: libfbxrtsp/1.2

Réponse:

RTSP/1.0 200 OK
Server: VLC/2.1.2
Date: Sat, 08 Feb 2014 23:33:24 GMT
Content-Type: application/sdp
Content-Base: rtsp://192.168.0.1:8081/stream.ts
Content-Length: 330
Cache-Control: no-cache
Cseq: 1

v=0
o=- 15465709961248091033 15465709961248091033 IN IP4 atlantis
s=Unnamed
i=N/A
c=IN IP4 0.0.0.0
t=0 0
a=tool:vlc 2.1.2
a=recvonly
a=type:broadcast
a=charset:UTF-8
a=control:rtsp://192.168.0.1:8081/stream.ts
m=video 0 RTP/AVP 33
b=RR:0
a=rtpmap:33 MP2T/90000
a=control:rtsp://192.168.0.1:8081/stream.ts/trackID=0

Envoyé par le Player à 192.168.0.1:8081:

SETUP rtsp://192.168.0.1/stream.ts RTSP/1.0
CSeq: 2
Accept: application/sdp
User-Agent: libfbxrtsp/1.2
Transport: FBXRTP/AVP;unicast;mode=play;ssrc=561072371;client_port=3001-3002
X-Freebox-Capabilities: hd,sd,ld,16_9,ac3
X-Freebox-Model: fbxhd

Et c’est là que le bât blesse, la réponse étant:

RTSP/1.0 459 Aggregate operation not allowed
Server: VLC/2.1.2
Date: Sat, 08 Feb 2014 23:33:24 GMT
Content-Length: 0
Cache-Control: no-cache
Cseq: 2

En effet, l’opération SETUP ne doit pas être effectuée sur l’url de présentation mais sur l’url de contrôle dédiée du flux, et ce pour chaque flux s’il y en a plusieurs. Si le client est VLC, l’opération SETUP s’effectue bien ainsi:

SETUP rtsp://192.168.0.1:8080/stream.ts/trackID=0 RTSP/1.0

Il semble que ou bien libfbxrtsp ignore la directive “a=control:...”, ou bien choisit la première au lieu de prendre en compte celle qui suit la directive “m=video 0...” marquant le début des metadata du premier flux.

Voir http://stackoverflow.com/a/9254673 pour les détails.

Of course, tenter de diriger la box vers rtsp://192.168.0.1:8080/stream.ts/trackID=0 dès le départ ne marche pas, puisque le DESCRIBE est refusé sur les flux eux-mêmes. À remarquer que le serveur RTSP du multiposte utilise la même url pour le flux et pour la présentation, donc le problème ne se présente pas (même si orienter le Player vers une url multiposte ne marche quand même pas, au moins la connexion se fait et le Player affiche le temps qui passe comme s’il recevait qqchose; je pense juste qu’il n’arrive pas à décoder la vidéo).

Tâches 1 - 2 sur 2 Page 1 sur 1

Activer les raccourcis clavier

Liste des tâches

Détails de la tâche

Édition de la tâche