Closed Bug 993924 Opened 10 years ago Closed 10 years ago

[Sora][streaming]Can't play the audio rtsp resource

Categories

(Firefox OS Graveyard :: RTSP, defect, P1)

Product:
Firefox OS Graveyard
Component:
RTSP
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: sync-1, Assigned: ethan, NeedInfo)

Details

(Keywords: reproducible)

Attachments

(8 files)

Beetle Lite FF pic
31.24 KB, image/png
Details
screenshot
988.80 KB, image/png
Details
rtsp log
2.85 MB, application/octet-stream
Details
rtsp-audio-unagi.pcap
5.23 KB, application/octet-stream
Details
rtsp-audio-vlc.pcap
25.23 KB, application/octet-stream
Details
rtsp-audio-sonyxperia.pcap
113.61 KB, application/octet-stream
Details
RTSP error on UDP
247.00 KB, text/plain
Details
RTSP log
4.85 MB, application/octet-stream
Details 
Mozilla build ID:20140323004002
 
 DEFECT DESCRIPTION:
 the prompt should be consistent when play audio rtsp and video rtsp
 
  REPRODUCING PROCEDURES:
 1.Launch browser and go to:HTTP://imps.tcl-ta.com/stream/stream.html;
 2.Select RTSP 3GP or RTSP MP4;
 3.Open one audio rtsp streaming,it prompt 'A network error caused the video failed to download'.Open one video rtsp streaming,it prompt 'Video cannot be played:either because the server or network failed or because the format is not supported'.->KO
 
 Note:Beetle Lite FF prompt 'the adress wasn't understood'.
 
  EXPECTED BEHAVIOUR:
 It can play audio rtst.
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:5/5
 
  For FT PR, Please list reference mobile's behavior:
 
 tel:7557
Cannot access the website HTTP://imps.tcl-ta.com/stream/stream.html, please provide necessary information
Flags: needinfo?(sync-1)
Attached image Beetle Lite FF pic — 

    
    

    
  

      
      
      
      

        Attached image
          
        screenshot
        — 
      

    


  

    
    

    
  
Created an attachment (id=695977)
 rtsp log

    
    

    
  
Created an attachment (id=695977)
 rtsp log

    
    

    
  

      
      
      
      

        Attached file
          
        rtsp log
        — 
      

    


  
Created an attachment (id=695977)
 rtsp log

    
    

    
  
(In reply to comment #1)
 > Comment from Mozilla:Cannot access the website
 > HTTP://imps.tcl-ta.com/stream/stream.html, please provide necessary information
 > 
 
 username: jrd
 password: jrd

    
    

    
  
Why don't reconnect rtsp after switching transports. It's OK when set default network to tcp.

    
    

    
  
Video RTSP isn't supported in 1.3.
Component: Gaia::Browser → RTSP

    
    

    
  
Can someone on the Moz side try to reproduce the audio RTSP bug here on 1.3?
Keywords: qawanted

    
  
Flags: needinfo?(sync-1)

    
    

    
  
I set mTryTCPInterleaving to 'true' in RTSPConnectionHander.h line 136, it's normal. But the voice has some problem: 
 
 acc: trembling, noise
 acc+: noise
 eacc+: noise
 arm_nb/wb: normal.

    
    

    
  
RTSP streaming is mandatory feature for DT.
blocking-b2g: --- → 1.3?

    
    

    
  
ni Wesley here. Hi Wesley, could you help to find someone to check this issue?

Thanks

Vance
Flags: needinfo?(whuang)

    
    

    
  
Just asked Ethan to take a look at this. 
cc Howie as EPM for RTSP.
Flags: needinfo?(whuang)

    
    

    
  
Hi Ethan, can you take a look at it? Thanks.
Assignee: nobody → ettseng

    
    

    
  
(In reply to howie [:howie] from comment #15)
> Hi Ethan, can you take a look at it? Thanks.
Sure. I will look into this bug.

    
    

    
  
Let's block on this but if it ends up being closed WORKSFORME that's no problem.
blocking-b2g: 1.3? → 1.3+

    
    

    
  
(In reply to Jason Smith [:jsmith] from comment #10)
> Can someone on the Moz side try to reproduce the audio RTSP bug here on 1.3?

This issue does reproduce for me (receiving both errors stated) on the 04/10/14 1.3 build on a Buri using the STR from comment 0. 

Device: Buri v1.3 MOZ RIL
BuildID: 20140410004002
Gaia: 62acb4b0e774b6709b8be400d849f807404bb21b
Gecko: 94baf6039462
Version: 28.0
Firmware Version: v1.2-device.cfg
Keywords: qawanted
QA Contact: mvaughan

    
    

    
  
Okay. I can also reproduce this bug on Unagi on both v1.3 and master.
As Jason said in comment 9, RTSP video is not supported in v1.3.
So I will focus on fixing the error of RTSP audio.

In the case of RTSP audio streaming, the RTSP connection was established successfully and we can see the media duration being shown. However, the media content cannot be played and the error occurs after about 10 seconds. I will debug it as soon as possible.
Keywords: reproducible

    
    

    
  

      
      
      
      

        Attached file
          
        rtsp-audio-unagi.pcap
        — 
      

    


  
Captured RTSP/RTCP/RTP packets on Unagi while the video app was trying to play an RTSP audio.

    
    

    
  

      
      
      
      

        Attached file
          
        rtsp-audio-vlc.pcap
        — 
      

    


  
Captured RTSP/RTCP/RTP packets on PC while playing an RTSP audio with VLC player, which can play the media normally.
This is for comparison with B2G.
Whiteboard: [cert]

    
    

    
  
*** Debugging Notes ***

1. RTP/RTCP packets are not received on B2G.
According to the packets captured in attachment 8405268 [details], RTSP session is well established between the FFOX device and the RTSP server.
Our RTSP client sends an RTSP PLAY request and the server replies 200 OK.
But after that, no any RTP/RTCP packet is coming from the server. After around 10 seconds, the client's timeout event is triggered, which tears down the session and reports an error.

We compared with the packets captured on Linux PC when VLC player was playing the same source, and couldn't find any significant difference so far.
Some trivial differences:
- VLC player sends an RTSP OPTIONS request at first. We do not.
  However this request is not mandatory, we don't think it's an issue.
- User-Agent are different.
  We had suspected that some RTSP server might check this field and block some user agents.
  But I tried to make our User-Agent the same as VLC player, it didn't help.
- We send several pairs of PLAY/PAUSE requests in a short time. VLC player didn't.
  Could our behavior influence the server state?
  Not sure about this so far. Need more investigations.

    
    

    
  
*** Debugging Notes ***

2. This bug can also be reproduced on Android phones.
Today I reproduced this bug on two different Android phones: Sony Xperia V and one Samsung phone.
(But the reproduction is not 100%).
Our RTSP module reuse some components from Android framework, mainly the StageFright library.
This result does not prove the root cause must be in the StageFright library. However it might be a clue.

    
    

    
  
comment 23 makes me think this is a site bug, not a bug our side. What do you think? If so, we can invalidate this.
Flags: needinfo?(ettseng)

    
    

    
  
(In reply to Jason Smith [:jsmith] from comment #24)
> comment 23 makes me think this is a site bug, not a bug our side. What do
> you think? If so, we can invalidate this.
It could be.
But,
1. We don't have enough evidence to prove this, and VLC could work well with this site.
2. It could be also a client side bug. We had found a bug in libstagefright before (bug 947928).
I suggest not to make a conclusion so quickly before we find evidence.
Flags: needinfo?(ettseng)

    
    

    
  


  
Packets captured while playing RTSP audio stream on an Android phone.
Device: SonyLT25i
Android: 4.1.2
stagefright: 1.1
The media can be played 10 seconds after we click the link.

    
    

    
  
Attachment 8405986 [details] are the packets captured when an Android phone is playing the same RTSP audio media.
Though it can be played, we still have to wait more than 10 seconds after clicking the play button.

By analyzing the packets, we found the following observations:
1. RTP packets are not received in the first RTSP session as on B2G. The client also tears down the session.
2. The client would create a new RTSP session and specify "RTP transported over TCP" in the SETUP request.
   Transport: RTP/AVP/TCP;interleaved=0-1
   (I guess this is what comment 8 means).
3. Then RTP packets are received over the TCP connection of RTSP. Which means, the RTP delivery is interleaved into the existing TCP connection.

According to the observations so far, I think there are both server side and client side bugs.
Server side:
1. The RTSP server already replies 200 OK to the first SETUP request, which specifies UDP as the transport protocol.
   Why it doesn't send RTP to the client?
   Is there a firewall that blocks UDP packets carrying RTP?
2. Another question is, by looking into attachment 8405269 [details] (packet captured for VLC player), the RTSP server does send "RTP over UDP" to the VLC player. Why can it not do the same thing to mobile-based client?

Client side:
1. Our RTSP client should try "TCP interleaving" (as the 2nd step described above) if no RTP/RTCP packet is received in the first session.
   This is what Android does.
   However, our current code logic would not do this.

    
    

    
  
(In reply to Jason Smith [:jsmith] from comment #24)
> comment 23 makes me think this is a site bug, not a bug our side. What do
> you think? If so, we can invalidate this.
After posting comment 27, I just realize that it may cause confusion by comment 23 and 27.
I want to clarify that, comment 23 said we can reproduce this bug on Android but the reproduction rate is not 100%.
So far I think the reproduction depends on the network environment.
And comment 27 describes the situation when it is NOT reproduced on Android. It analyzes what happened when Android plays the same source successfully.

    
    

    
  
Hi,
As described in comment 27, the Darwin Streaming Server does not send UDP-based RTP packets.
Could you help to clarify the requirement of the server environment?
Is there any reason the server has to send TCP interleaved RTP packets instead of UDP?
Flags: needinfo?(sync-1)

    
    

    
  
(In reply to Ethan Tseng [:ethan] from comment #29)
> Hi,
> As described in comment 27, the Darwin Streaming Server does not send
> UDP-based RTP packets.
> Could you help to clarify the requirement of the server environment?
> Is there any reason the server has to send TCP interleaved RTP packets
> instead of UDP?

Hi Ethan -

I think that is just a test website, so probably it is deliberately use TCP interleaved RTP packets instead of UDP..So we can only work on UDP?

    
    

    
  
(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #30)
> Hi Ethan -
> I think that is just a test website, so probably it is deliberately use TCP
> interleaved RTP packets instead of UDP..So we can only work on UDP?
Yes. I'm afraid so.
As I said in comment 27, our RTSP client does not align to Android's behavior.
Although we use parts of libstagefright, we had refactored some codes to make them connect to Gecko components.
And we lost the "try TCP interleaving" mechanism carelessly during the refactoring.

However, TCP-interleaved RTP is not recommended for streaming because of TCP's overhead and retransmission.
The interleaved TCP stream will end up being jerky as the player continually waits in a buffering state for packets to arrive.
Is it possible to configure the test site to use UDP-based RTP? If so, we don't have to block on this issue.

Of course I still suggest to file a follow-up bug to repair our client's "try TCP interleaving" mechanism in the long run.

    
    

    
  
Hi Vance, we suspect the server has some issues:

1. If played from PC, server sends UDP-based RTP; but if played from mobile (ffos and android), it sends TCP-based RTP. Which TCP-based RTP is not common in real world practice.

2. The server might imposes firewall or blocks some port of UDP stream. Android phone sometimes encounter errors while playing the audio too.


Proposed action items for now:
1. @Vance: Could you ask help from tcl, how do we test UDP stream on mobile? Is there any limitation on server?
2. If UDP stream can be played correctly, we can remove the blocker and open an other TCP-interleaved follow-up bug for future implementation.
Flags: needinfo?(vchen)

    
    

    
  
I try to play the stream generated by live555 on UDP. But occurs error.

    
    

    
  
I filed bug 996765 for follow-up.
Once TCP-interleaved RTP is still required, please mark blockers on that bug.

    
  
Flags: needinfo?(sync-1)

    
    

    
  
(In reply to buri.blff from comment #33)
> I try to play the stream generated by live555 on UDP. But occurs error.

Hi, could you provide logs for error on UDP?

Thanks

Vance
Flags: needinfo?(vchen) → needinfo?(sync-1)

    
    

    
  

      
      
      
      

        Attached file
          
        RTSP error on UDP
        — 
      

    


  

    
    

    
  
Hi Ethan -

The RTSP over UDP fail log is attached, could you kindly help to check what went wrong?

Thanks

Vance
Flags: needinfo?(sync-1) → needinfo?(ettseng)

    
    

    
  
(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #37)
> Hi Ethan -
> The RTSP over UDP fail log is attached, could you kindly help to check what
> went wrong?
From the log I see the same situation as DSS server.
RTSP session was established successfully. Our client sent PLAY, the server replied 200 OK.
But RTP was never received by the client.
I suspect there is an intermediate firewall that blocks RTP packets.

Can anyone help to capture packets on the server and client side to analyze what's going on?
Flags: needinfo?(ettseng)

    
  
Flags: needinfo?(sync-1)
Flags: needinfo?(buri.blff)

    
    

    
  
(In reply to Ethan Tseng [:ethan] from comment #38)
> (In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #37)
> > Hi Ethan -
> > The RTSP over UDP fail log is attached, could you kindly help to check what
> > went wrong?
> From the log I see the same situation as DSS server.
> RTSP session was established successfully. Our client sent PLAY, the server
> replied 200 OK.
> But RTP was never received by the client.
> I suspect there is an intermediate firewall that blocks RTP packets.
> 
> Can anyone help to capture packets on the server and client side to analyze
> what's going on?

OK I will try to ask partner to provide logs, but sometimes it is quite difficult to get server side log...

Really strange that server block RTP but not RTSP...

So we have already verify our Audio streaming over UDP on other test server, right?
Flags: needinfo?(hochang)
Flags: needinfo?(ettseng)

    
    

    
  
(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #39)
> OK I will try to ask partner to provide logs, but sometimes it is quite
> difficult to get server side log...
If we can reach the administrator of the server site, we can ask him/her to filter captured packets that we care, e.g. filter by the IP address of the client-side device. The point is to make sure the server really sends out RTP packets to the network.

> Really strange that server block RTP but not RTSP...
RTSP is transported over TCP, while RTP is over UDP.
It's quite possible only UDP is blocked but not TCP.
You can refer to this information for further detail:
https://bugzilla.mozilla.org/show_bug.cgi?id=996765#c1

> So we have already verify our Audio streaming over UDP on other test server,
> right?
Yes.
QA and developers in Taipei already verified RTSP audio feature.
You can consult William Hsu. He had dedicated to test our RTSP feature.
Flags: needinfo?(ettseng)

    
  
Flags: needinfo?(hochang)

    
    

    
  
de-Nom since this is a server side issue, will ask partner to verify with other streaming server.
blocking-b2g: 1.3+ → ---

    
    

    
  
Invalidating as well, since this is not a gecko bug.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
Whiteboard: [cert]

    
    

    
  
(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #41)
> de-Nom since this is a server side issue, will ask partner to verify with
> other streaming server.

Please provide the server link.
Flags: needinfo?(buri.blff)

    
    

    
  
Hi William -

Could you provide the links of some test servers you use to verify the RTSP functionality?

Thanks for your help

Vance
Flags: needinfo?(whsu)

    
    

    
  
Hi, Vance,

A link which causes this bug has been attached on the comment 0.
Thanks.

* REPRODUCING PROCEDURES:
1.Launch browser and go to:HTTP://imps.tcl-ta.com/stream/stream.html;
2.Select RTSP 3GP or RTSP MP4;
3.Open one audio rtsp streaming,it prompt 'A network error caused the video

----------------------------------------------------
If you need other RTSP links, please refer to the following information.
- http://mozilla.github.io/qa-testcase-data/Video/youtubeRTSPURLSearch.html
- https://rawgithub.com/William-Hsu/TestApp_RTSP/master/index.html
Thanks.
Flags: needinfo?(whsu)

    
    

    
  
(In reply to William Hsu [:whsu] from comment #45)
> Hi, Vance,
> 
> A link which causes this bug has been attached on the comment 0.
> Thanks.
> 
> * REPRODUCING PROCEDURES:
> 1.Launch browser and go to:HTTP://imps.tcl-ta.com/stream/stream.html;
> 2.Select RTSP 3GP or RTSP MP4;
> 3.Open one audio rtsp streaming,it prompt 'A network error caused the video
> 
> ----------------------------------------------------
> If you need other RTSP links, please refer to the following information.
> - http://mozilla.github.io/qa-testcase-data/Video/youtubeRTSPURLSearch.html
> - https://rawgithub.com/William-Hsu/TestApp_RTSP/master/index.html
> Thanks.

Thanks William, https://rawgithub.com/William-Hsu/TestApp_RTSP/master/index.html is exactly what I need~

Hi TCL guys, please use the above link to verify the RTSP functionality.
Flags: needinfo?(sync-1) → needinfo?(buri.blff)

    
    

    
  
No problem. Thanks Vance! :)
If you need further information, please feel free to contact me.
Have a nice day!

    
    

    
  
Created an attachment (id=723296)
 RTSP log
 
 I can't play the rtsp resource on https://rawgit.com/William-Hsu/TestApp_RTSP/master/index.html.

    
    

    
  
Created an attachment (id=723296)
 RTSP log
 
 I can't play the rtsp resource on https://rawgit.com/William-Hsu/TestApp_RTSP/master/index.html.

    
    

    
  

      
      
      
      

        Attached file
          
        RTSP log
        — 
      

    


  
Created an attachment (id=723296)
 RTSP log
 
 I can't play the rtsp resource on https://rawgit.com/William-Hsu/TestApp_RTSP/master/index.html.

    
    

    
  
(In reply to sync-1 from comment #50)
>  I can't play the rtsp resource on
> https://rawgit.com/William-Hsu/TestApp_RTSP/master/index.html.
You are using FFOS v1.3, right?
RTSP video is disabled in v1.3 and 1.4.
And from the log, you were trying to play an RTSP video.
rtsp://r1---sn-o097zuee.c.youtube.com/CiILENy73wIaGQnQO9juZ1WPgBMYESARFEgGUgZ2aWRlb3MM/0/0/0/video.3gp

    
    

    
  
(In reply to comment #48)
 > Comment from Mozilla:(In reply to sync-1 from comment #50)
 > >  I can't play the rtsp resource on
 > > https://rawgit.com/William-Hsu/TestApp_RTSP/master/index.html.
 > You are using FFOS v1.3, right?
 > RTSP video is disabled in v1.3 and 1.4.
 > And from the log, you were trying to play an RTSP video.
 > rtsp://r1---sn-o097zuee.c.youtube.com/CiILENy73wIaGQnQO9juZ1WPgBMYESARFEgGUgZ2aWRlb3MM/0/0/0/video.3gp
 > 
 
 Ok, Thanks. I found there is only one audio test link.

    
    

    
  
(In reply to sync-1 from comment #52)
> (In reply to comment #48)
>  > Comment from Mozilla:(In reply to sync-1 from comment #50)
>  > >  I can't play the rtsp resource on
>  > > https://rawgit.com/William-Hsu/TestApp_RTSP/master/index.html.
>  > You are using FFOS v1.3, right?
>  > RTSP video is disabled in v1.3 and 1.4.
>  > And from the log, you were trying to play an RTSP video.
>  >
> rtsp://r1---sn-o097zuee.c.youtube.com/
> CiILENy73wIaGQnQO9juZ1WPgBMYESARFEgGUgZ2aWRlb3MM/0/0/0/video.3gp
>  > 
>  
>  Ok, Thanks. I found there is only one audio test link.

So everything works OK with Audio Test link?

    
    

    
  
(In reply to comment #50)
 > Comment from Mozilla:(In reply to sync-1 from comment #52)
 > > (In reply to comment #48)
 > >  > Comment from Mozilla:(In reply to sync-1 from comment #50)
 > >  > >  I can't play the rtsp resource on
 > >  > > https://rawgit.com/William-Hsu/TestApp_RTSP/master/index.html.
 > >  > You are using FFOS v1.3, right?
 > >  > RTSP video is disabled in v1.3 and 1.4.
 > >  > And from the log, you were trying to play an RTSP video.
 > >  >
 > > rtsp://r1---sn-o097zuee.c.youtube.com/
 > > CiILENy73wIaGQnQO9juZ1WPgBMYESARFEgGUgZ2aWRlb3MM/0/0/0/video.3gp
 > >  > 
 > >  
 > >  Ok, Thanks. I found there is only one audio test link.
 > 
 > So everything works OK with Audio Test link?
 > 
 
 Yes, It's OK. But I can't play the audio rtsp resource at HTTP://imps.tcl-ta.com/stream/stream.html on FFOS and The Android is ok.

    
    

    
  
(In reply to sync-1 from comment #54)
>  Yes, It's OK. But I can't play the audio rtsp resource at
> HTTP://imps.tcl-ta.com/stream/stream.html on FFOS and The Android is ok.

This is already explained in my previous comments (comment 22, 23, 27).

In brief, RTP-over-UDP packets are somehow blocked in the network path between this streaming server and devices.
Android will fail back to using RTP interleaved in the existing RTSP connection.
FFOS doesn't support this yet. And bug 996765 is filed to track this issue.

I tried to play RTSP at this site with my WIP patch in bug 996765 and it works (the same as Android).
I think we can support TCP-interleaved RTP in v2.0 but not v1.3 and 1.4.

Hope this information helps. :)

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: