Closed Bug 1158661 Opened 9 years ago Closed 9 years ago

[FFOS2.0][Woodduck][HOMO] RTSP video in 720 H-264 Plays abnormal which can hear the audio only without the video shows.

Categories

(Firefox OS Graveyard :: Gaia, defect, P2)

Product:
Firefox OS Graveyard
Component:
Gaia
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1151760

People

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

References

Details

Attachments

(12 files, 1 obsolete file)

media resource service died.
1.54 MB, text/x-log
Details
mtklog
4.45 MB, application/octet-stream
Details
Codec information from VLC
100.57 KB, image/png
Details
separate-timer_v2_0m.patch
10.84 KB, patch
Details | Diff | Splinter Review
video playing log
1.99 MB, application/octet-stream
Details
the tcpdump log.part1
8.00 MB, application/x-download
Details
the tcpdump log.part2
2.65 MB, application/x-download
Details
video playing.part2
10.00 MB, application/x-download
Details
video playing.part4
3.75 MB, application/x-download
Details
video playing.part3
10.00 MB, application/x-download
Details
video playing.part1
10.00 MB, application/x-download
Details
separate-timer_v2_0m.patch V3
10.93 KB, patch
Details | Diff | Splinter Review 
DEFECT DESCRIPTION:
 
 when you playing an specific video in AT4 server ,only hear the audio but can't show the video.
 
  REPRODUCING PROCEDURES:
 
 1-Conect the DUT on a Network
 
 2-Open URL:                    http://186.148.57.28/altmp/
 
 3-select the first video to play, can hear the audio without the video shows.
 
  EXPECTED BEHAVIOUR:
 can play the rtsp normal. 
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
 High
 
  REPRODUCING RATE:
 
 5/5
 
  For FT PR, Please list reference mobile's behavior:

    
    

    
  

      
      
      
      

        Attached file
          
        mtklog
        — 
      

    


  

    
    

    
  
Hi Ethan,
Could you please help to check the problem? Thanks!
Blocks: Woodduck, Woodduck_Blocker
Flags: needinfo?(ettseng)
See Also:  → 1155544

    
    

    
  


  
There are four tracks in this clip: two video and two audio tracks.
I am not sure whether this is a clue. Need to investigate it more deeply.

Jonathan, could you help to look into this issue?
Flags: needinfo?(ettseng) → needinfo?(jhao)

    
    

    
  
On 3.0 branch, video will show if we apply the patch of bug 1151760, attachment 8597076 [details] [diff] [review], which is waiting to be checked in.

Although it got stuck at the 5th second for a few seconds, before the video starts to show.

So, I think that patch will solve most of the problem, but there are still some minor issues.

I will also rebase that patch for 2.0 uplift.
Flags: needinfo?(jhao)

    
    

    
  
As you can see in the log in RTSPConnectionHandler::addTimeStamp below, at the 5th second, the mediaTime jumped to 26.17 seconds, even though the rtpTime increased smoothly.

Something must be wrong with the calculation of media time.

04:32:51.588  5570  6102 I ETHAN   : track 0 rtpTime=614000376 mediaTimeUs = 4879866 us (4.88 secs)
04:32:51.678  5570  6102 I ETHAN   : track 0 rtpTime=614004130 mediaTimeUs = 4921577 us (4.92 secs)
04:32:52.108  5570  6102 I ETHAN   : track 0 rtpTime=614007884 mediaTimeUs = 4963288 us (4.96 secs)
04:32:52.388  5570  6102 I ETHAN   : track 0 rtpTime=614011638 mediaTimeUs = 5005000 us (5.00 secs)
04:32:52.548  5570  6102 I ETHAN   : track 0 rtpTime=614015391 mediaTimeUs = 5046700 us (5.05 secs)
04:33:08.918  5570  6102 I ETHAN   : track 0 rtpTime=614019145 mediaTimeUs = 26174411 us (26.17 secs)
04:33:18.598  5570  6102 I ETHAN   : track 0 rtpTime=614049175 mediaTimeUs = 33537077 us (33.54 secs)
04:33:18.598  5570  6102 I ETHAN   : track 0 rtpTime=614075451 mediaTimeUs = 33829033 us (33.83 secs)
04:33:18.618  5570  6102 I ETHAN   : track 0 rtpTime=614079205 mediaTimeUs = 33870744 us (33.87 secs)
04:33:18.638  5570  6102 I ETHAN   : track 0 rtpTime=614082959 mediaTimeUs = 33912455 us (33.91 secs)

    
  
Flags: needinfo?(sync-1)

    
  
Flags: needinfo?(sync-1)

    
    

    
  


  
This patch is the patch in bug 1151760 rebased to 2.0M.
Assignee: nobody → jhao
Status: NEW → ASSIGNED

    
    

    
  
Hi Reporter,
Can you try the patch per comment 7? Thanks!
Flags: needinfo?(sync-1)

    
    

    
  
hi
 
 I have tested the patch from comment 7. The RTSP video can show the video normal , so i think it's ok now .
 
 thanks.

    
    

    
  
sorry, it's strange, i test again, but this time the video still can't show and only hear the voice.. I think there still some little problems.

    
    

    
  
Could you tell me the reproducing rate?

    
    

    
  
video shows normal only the first time after I use the patch . 
 now I tryed a lot of times(about 10 times), but always play abnormal.

    
    

    
  
Hi Reporter,

Can you describe the syndrome of "play abnormal"?

Can you provide new log?
Thanks!

    
    

    
  

      
      
      
      

        Attached patch
          
          
        separate-timer_v2_0m.patch V2 (obsolete)
        — 
          — Splinter Review
      

    


  
Could you try with this patch again? I've enlarged the timeout.

        Attachment #8598435 -
        Attachment is obsolete: true

    
    

    
  
hi
 
 sometimes the video plays normal, but when it plays abnormal, can hear the audio only and the video just shows loading progressbar .

    
    

    
  
Hi Reporter,

Can you provide new log?
Thanks!

    
    

    
      
  

    
    

    
      
  

    
    

    
  

      
      
      
      

        Attached file
          
        video playing log
        — 
      

    


  
Created an attachment (id=1257373)
 video playing log
 
 i think if the first video's rtsp stream from http://186.148.57.28/altmp/ is to slow? so sometimes the video can't play well.
 because when i choose the second video to play ,it can play very well.

    
    

    
  
Hi Jonathan,
Could you please help to check the log per comment 19 again?
Thanks!
Flags: needinfo?(jhao)

    
    

    
  
Hi Reporter,

When I connected to the WiFi hotspot in our office (which is very fast), I could play normally.
But when I connected to one of my colleague's hotspot, the abnormal case happened.

May I ask whether your WiFi network is stable? I wonder if the loading progress bar is because of unstable network connection. Or, maybe as you said, it's because the first stream is too slow.
Flags: needinfo?(jhao)

    
    

    
  
hi
 
 wifi network here is stable, but the network speed is slow.

    
    

    
  
(In reply to sync-1 from comment #22)
> hi
>  wifi network here is stable, but the network speed is slow.

Could you use tcpdump to record RTSP/RTP packets, and attach the pcap file here?
It might be helpful by investigating your captured packets.

    
    

    
  
Also, it would be great if you could record the symptom of "abnormal" playing as a video and upload it for us.

    
    

    
  
Thanks a lot!

    
    

    
      
  

    
    

    
      
  

    
    

    
  

      
      
      
      

        Attached file
          
        the tcpdump log.part1
        — 
      

    


  
Created an attachment (id=1258730)
 the tcpdump log.part1

    
    

    
      
  

    
    

    
      
  

    
    

    
  

      
      
      
      

        Attached file
          
        the tcpdump log.part2
        — 
      

    


  
Created an attachment (id=1258735)
 the tcpdump log.part2

    
    

    
      
  

    
    

    
      
  

    
    

    
  

      
      
      
      

        Attached file
          
        video playing.part2
        — 
      

    


  
Created an attachment (id=1258767)
 video playing.part2

    
    

    
      
  

    
    

    
      
  

    
    

    
  

      
      
      
      

        Attached file
          
        video playing.part4
        — 
      

    


  
Created an attachment (id=1258786)
 video playing.part4
 
 this video shows an abnormal situation..
 sometimes the loading progressbar shows at the start of the video will not disappear and shows all the time.

    
    

    
      
  

    
    

    
      
  

    
    

    
  

      
      
      
      

        Attached file
          
        video playing.part3
        — 
      

    


  
Created an attachment (id=1258768)
 video playing.part3

    
    

    
      
  

    
    

    
      
  

    
    

    
  

      
      
      
      

        Attached file
          
        video playing.part1
        — 
      

    


  
Created an attachment (id=1258766)
 video playing.part1

    
    

    
  
From the video, it looks like the 1-minute timer times out.
When I tried, the gap at 5 seconds only lasts no more than 30 seconds.
However, it seems that your slower network condition could make that gap lasting more than 60 seconds.

You can find this line in the patch,

+static int64_t kAccessUnitTimeoutUs = 60000000ll;

and manually change the 60000000 to a bigger number.

And yet, I don't think making the timeout larger just to solve this bug is a good thing, because that timeout is used to detect server disconnection. In fact, that value is only 10 seconds in the master branch. To make it much larger will make us wait for more than 60 seconds to know that server has disconnect.

Maybe it's not worth it to change that value just to make this video work.

    
    

    
  


  
Hi Reporter,

Thanks very much for your help. I hope this patch will work, but you may have to wait for over a minute while it stuck at the 5th second.

        Attachment #8598522 -
        Attachment is obsolete: true

    
    

    
  
Previously, the video stops because we have a 10-second timeout, which is used to detect server disconnection. The weird thing with this video is that, it may stop sending us video packets for 30 seconds or even a minute. After we assume it's dead, it restarts again, but we have already closed the video track.

With this patch, now we don't close the video track if the gap is more than 10 seconds.
When it timeouts, we check the network status. If the network is disconnected, it closes; otherwise, it waits indefinitely for the server to send us video packets again.

    
    

    
  
hi
 
 I tryed the new patch, and it seems like the same. the video still plays abnormal sometimes. maybe sometimes the rtsp stream send video packets more slow than we think.

    
  

        Attachment #8598435 -
        Attachment is obsolete: false

    
    

    
  
Hi Kai-Zhen,
The problem now is identified as server issue we will try to clarify with operator.

However, the patch is also fixed on master. 

Could you help to land this on 2.0M? Thanks!
Flags: needinfo?(kli)

    
    

    
  
The patch seems not reviewed. Could you find someone review the patch? Thanks!
Flags: needinfo?(kli) → needinfo?(jhao)

    
    

    
  
BTW, patch on master get reviewed is enough.

    
    

    
  
The patch on master was reviewed here: https://bugzilla.mozilla.org/show_bug.cgi?id=1151760#c11
Flags: needinfo?(jhao)

    
  
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Summary: [FFOS2.0][Woodduck][HOMO]RSTP video in 720 H-264 Plays abnormal which can hear the audio only without the video shows. → [FFOS2.0][Woodduck][HOMO] RTSP video in 720 H-264 Plays abnormal which can hear the audio only without the video shows.

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: