Closed Bug 1048982 Opened 10 years ago Closed 9 years ago

[RTSP] Cannot play slideshow video over RTSP

Categories

(Firefox OS Graveyard :: RTSP, defect)

Product:
Firefox OS Graveyard
Component:
RTSP
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(b2g-v2.0 affected, b2g-v2.1 affected)

Status:
RESOLVED WONTFIX
Milestone:
2.1 S4 (12sep)
Tracking Flags:
Tracking Status
b2g-v2.0 --- affected
b2g-v2.1 --- affected

People

(Reporter: bhargavg1, Assigned: ethan)

Details

(Whiteboard: [caf priority: p2][CR 704762] [p=5])

Attachments

(1 file)

rtsp_streaming_issue.txt
(deleted), text/plain
Details
Attached file rtsp_streaming_issue.txt (deleted) — 
while trying to play few RTSP streams, we are observing a behavior where playback doesn't start and buffering icon is seen indefinitely
QA Wanted to see if we can reproduce on Flame.
Keywords: qawanted
Component: Gaia::Video → RTSP
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.0?
Whiteboard: [CR 704762] → [caf priority: p2][CR 704762]
Can we please have a link to some of the streams you are testing with?
Flags: needinfo?(bhargavg1)
(In reply to Marcia Knous [:marcia - use needinfo] from comment #3)
> Can we please have a link to some of the streams you are testing with?

Bhavna to help with the same
Flags: needinfo?(bhargavg1) → needinfo?(bbajaj)
(In reply to bhargavg1 from comment #4)
> (In reply to Marcia Knous [:marcia - use needinfo] from comment #3)
> > Can we please have a link to some of the streams you are testing with?
> 
> Bhavna to help with the same

I've sent these to marcia.
Flags: needinfo?(bbajaj)
QA Contact: ddixon
Branch Check

STR:
1.  Access http://goo.gl/BhJd77 and select "Video test page" link.
2. Play video, pause video, lock screen. 
3. After about 1-2 minutes, unlock screen. 
4. Attempt to play video .

Actual Results: 
The RTSP type video displays buffer and fails to resume play after screen has been locked then unlocked. 

Issue DOES occur in Flame 2.1, 2.0 and Buri 2.1, 2.0
Issue is not applicable for the 1.4 branch for Flame and Buri. 

Device: Flame Master
Build ID: 20140805081353
Gaia: e93780f9da8b34f370a4113abd4df9780d58e443
Gecko: b50bb656674e
Version: 34.0a1 (Master)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
---------------------------------------------------------------------------
Device: Flame 2.0
Build ID: 20140805093658
Gaia: 92d2815f3ec3bd9b35c0e2de8dc34cdf5a3bda19
Gecko: b0a276a774bb
Version: 32.0 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
---------------------------------------------------------------------------
Device: Buri Master
Build ID: 20140805124418
Gaia: d85bbae28dd9ab9679b42d8d37c84810059e097c
Version: 34.0a1 (Master)Gecko: 191e834ff32b
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
---------------------------------------------------------------------------
Device: Buri 2.0
Build ID: 20140805134618
Gaia: efa5c34186a5aea4761e0d6d43e743ffa1a5110c
Gecko: 5ec91404c9c7
Version: 32.0 (2.0)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

---------------------------------------------------------------------------
---------------------------------------------------------------------------

Flame 1.4 (Not applicable)

Device: Flame 1.4
Build ID: 20140804095929
Gaia: 9377274b17200a60cebcd2427d489a7756c4cc72
Gecko: 60d3725443a5
Version: 30.0 (1.4)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.0: --- → affected
status-b2g-v2.1: --- → affected
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
This seems like a duplicated of Bug 1045351.
Hi bhargavg1,

We think this is a duplicate of bug 1045351, which is a regression bug in framework.
Once an RTSP streaming is paused, it could no longer be resumed, no matter you lock the screen or not.
We already had a patch in that bug. Could you apply the patch to see if it fix this issue?
Flags: needinfo?(bhargavg1)
Marking this a dupe of bug 1045351. Moving the cc caf meta bug to that bug too.
No longer blocks: CAF-v2.0-CC-metabug
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
blocking-b2g: 2.0? → ---
(In reply to Ethan Tseng [:ethan] from comment #8)
> Hi bhargavg1,
> 
> We think this is a duplicate of bug 1045351, which is a regression bug in
> framework.
> Once an RTSP streaming is paused, it could no longer be resumed, no matter
> you lock the screen or not.
> We already had a patch in that bug. Could you apply the patch to see if it
> fix this issue?

Ethan, did we make sure to test with the clips that were provided to Bhavana and still see to be a duplicate. In KK I guess the issue has been handled correctly, have asked Bruce to confirm the same on Bug 1045351.
Flags: needinfo?(bhargavg1) → needinfo?(ettseng)
(In reply to Duane Dixon [:ddixon] from comment #6)
> Issue DOES occur in Flame 2.1, 2.0 and Buri 2.1, 2.0
> Issue is not applicable for the 1.4 branch for Flame and Buri. 

This issue might not be a duplicated bug of bug 1045351.

In bug 1045351, the root cause is OMXCodec::start() doesn't explicitly call drainInputBuffers() on JB. The problem is caused by the following commit:
 - https://www.codeaurora.org/cgit/quic/la/platform/frameworks/av/commit/media/libstagefright/OMXCodec.cpp?h=b2g_jb_3.2&id=ee0ddcbbfd988ee423b5bc53aae7abbd88e11fec

Since Buri still uses ICS, and the root cause of bug 1045351 is not related to Gecko's version, I don't think these two bugs are relevant.
(In reply to bhargavg1 from comment #10)
> Ethan, did we make sure to test with the clips that were provided to Bhavana
> and still see to be a duplicate. In KK I guess the issue has been handled
> correctly, have asked Bruce to confirm the same on Bug 1045351.

bhargavg1: FYI, both Buri and Flame don't base on KK currently.
(In reply to bhargavg1 from comment #10)
> (In reply to Ethan Tseng [:ethan] from comment #8)
> > Hi bhargavg1,
> > 
> > We think this is a duplicate of bug 1045351, which is a regression bug in
> > framework.
> > Once an RTSP streaming is paused, it could no longer be resumed, no matter
> > you lock the screen or not.
> > We already had a patch in that bug. Could you apply the patch to see if it
> > fix this issue?
> 
> Ethan, did we make sure to test with the clips that were provided to Bhavana
> and still see to be a duplicate. In KK I guess the issue has been handled
> correctly, have asked Bruce to confirm the same on Bug 1045351.

Re-opening the Bug, please continue looking at the issue
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
[Blocking Requested - why for this release]:
Blocks: CAF-v2.0-FC-metabug
Blocks: CAF-v2.0-CC-metabug
No longer blocks: CAF-v2.0-FC-metabug
ethan I've also emailed you the need video clips if you don't have them already.
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.0?
(In reply to bhargavg1 from comment #10)
> Ethan, did we make sure to test with the clips that were provided to Bhavana
> and still see to be a duplicate. In KK I guess the issue has been handled
> correctly, have asked Bruce to confirm the same on Bug 1045351.

No. I didn't test using the clips provided Bhavana.
After reading Bruce's explanations in the comments below, I realize this bug is not a duplicate of bug 1045351. I will dedicate to find the root cause.
Flags: needinfo?(ettseng)
(In reply to bhavana bajaj [:bajaj] from comment #15)
> ethan I've also emailed you the need video clips if you don't have them
> already.

Bhavana,
Yes! I got the video clips already. Thanks.
blocking-b2g: 2.0? → 2.0+
Assignee: nobody → ettseng
Comment 6 could be a misdirection of the original scenario of this bug.
Let me clarify it first.

(In reply to Duane Dixon [:ddixon] from comment #6)
> STR:
> 1.  Access http://goo.gl/BhJd77 and select "Video test page" link.
> 2. Play video, pause video, lock screen. 
> 3. After about 1-2 minutes, unlock screen. 
> 4. Attempt to play video .
> Actual Results: 
> The RTSP type video displays buffer and fails to resume play after screen
> has been locked then unlocked. 

Following these STRs, the video cannot be resumed.
But it's not relevant to lock/unlock screen.
The point is, the video cannot be re-played once it has played to the end of stream.
(But not occurred on all kinds of streaming server, refer to https://bugzilla.mozilla.org/show_bug.cgi?id=1031170#c1).
We had discovered this issue while fixing bug 1021006, and already filed bug 1031170 to track it.

We could treat the STR in comment 6 as the same as bug 1031170, but not this bug.
There are two clips from bhavana for this bug.

One of them is just 1-second long. It can be played but seems not to be re-played on B2G. Since the duration is so short I guess it's not feasible for a real case.
The other clip is 64-seconds long.
Its codecs are:
Stream 0
    Type            Video
    Codec           MPEG-4 Video (mp4v)
    Payload name    MP4V-ES
Stream 1
    Type            Audio
    Codec           MPEG AAC Audio (mp4a)
    Payload name    mpeg4-generic
    Channels        Stereo
    Sample rate     48000 Hz
    AAC extension   SBR

I found this clip is a "video without video" (maybe there is a professional term for this, let me know if anyone knows that).
The video and audio tracks are setup as payload type 96 and 97.
But only 10 RTP packets with payload type 96 are received by the client (within 1 second), then only RTP packets with payload type 97 keep coming.
Which means the video frame is just a static picture.

I tried the same clip on Android phone. Android 4.3 cannot play this kind of video either.
Hi Bhavana and Howie,

Android doesn't support this kind of video either (see comment 21).
Maybe this is not a perfect excuse for us not to support it.
However, the fact is, our RTSP client largely reuses Android's stagefright library and we need more time to work out how to support this type of video.

Is there a reason to block v2.0 on this particular format of video clip?
Flags: needinfo?(hochang)
Flags: needinfo?(bbajaj)
Whiteboard: [caf priority: p2][CR 704762] → [caf priority: p2][CR 704762] [p=5]
Target Milestone: --- → 2.1 S4 (12sep)
(In reply to Ethan Tseng [:ethan] from comment #21)
> I tried the same clip on Android phone. Android 4.3 cannot play this kind of
> video either.

Can we check on Android 4.4.2 (KK), as that is the platform which we are testing on
(In reply to bhargavg1 from comment #23)
> Can we check on Android 4.4.2 (KK), as that is the platform which we are
> testing on

Verified. Android 4.4.2 cannot play this clip either.
This is corner case and both Android 4.3 and 4.4.2 don't support this kind of this video. This is not a blocker, removing blocking tag. I suggest this bug WON'T FIX and remove this from CAF 2.0 list.
blocking-b2g: 2.0+ → ---
Flags: needinfo?(hochang)
bhargav, can you please weigh in here ? I think the assessment on non-blocking this is fair given comment #24, does this match with your testing on android too ?
Flags: needinfo?(bbajaj) → needinfo?(bhargavg1)
add blocking flag back since there's dedicated triage for CAF bugs. thanks.
blocking-b2g: --- → 2.0+
(In reply to Ethan Tseng [:ethan] from comment #21)
> I found this clip is a "video without video" (maybe there is a professional
> term for this, let me know if anyone knows that).

Additional information about this video clip.

Analyzing the XML generated by "MP4Box -diso" command, we can ensure there is only one video frame in the clip.
...
<SampleToChunkBox EntryCount="1">
<BoxInfo Size="28" Type="stsc"/>
<FullBoxInfo Version="0" Flags="0"/>
<SampleToChunkEntry FirstChunk="1" SamplesPerChunk="1" SampleDescriptionIndex="1"/>
</SampleToChunkBox>
<SampleSizeBox SampleCount="1" ConstantSampleSize="12876">
<BoxInfo Size="20" Type="stsz"/>
<FullBoxInfo Version="0" Flags="0"/>
</SampleSizeBox>
...

This is the so-called "slideshow video".
There is a valid test case that covers this issue: https://moztrap.mozilla.org/manage/case/11043/
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: in-moztrap?(dharris)
(In reply to Derek Harris (:DerekH) from comment #29)
> There is a valid test case that covers this issue:
> https://moztrap.mozilla.org/manage/case/11043/

Hi, Derek,

Thanks for your help!

The test files you listed here are supported streaming.
But, we are talking about a different case(different video format) as Ethan mentioned on Comment 28.

After I looked into previous test cases, we didn't have related test case(slideshow video).
Thanks.

--- -- - --- -- - --- -- - --- -- - --- -- -
Hi, everyone,

Please make a decision to see if we need to support this kind video format.
If so, please needinfo QA to prepare related test cases.
Thanks.
Based on the feedback here and offline discussions with test teams and product requirements, moving it to 2.1
Blocks: CAF-v2.1-FC-metabug
No longer blocks: CAF-v2.0-CC-metabug
blocking-b2g: 2.0+ → 2.1?
Flags: needinfo?(bhargavg1)
The RTSP requirement never includes supporting slideshow video. If we want to support this in 2.1, it would be a very late product requirement. ni product manager Marvin also Bhavana: are we confirmed to support slideshow video as late 2.1 requirement in last sprint before FL?
Flags: needinfo?(mkhoo)
Flags: needinfo?(bbajaj)
(In reply to howie [:howie] from comment #32)
> The RTSP requirement never includes supporting slideshow video. If we want
> to support this in 2.1, it would be a very late product requirement. ni
> product manager Marvin also Bhavana: are we confirmed to support slideshow
> video as late 2.1 requirement in last sprint before FL?

I agree with you and think that's a product call here and us setting the right expectations to partner(CAF) requesting support. So i'll wait for :marvin to respond here to comment if we have to fix this in which next future release.
Flags: needinfo?(bbajaj)
Sideshow video playback is not in scope. This is not in 2.0 and 2.1 either, hence, please remove 2.1? nom. please send by mail to mkhoo@mozilla.com for RTSP request. thanks!
Flags: needinfo?(mkhoo)
Summary: Video playback doesn't start and buffering icon is seen forever → [RTSP] Cannot play slideshow video over RTSP
Hi Bhavana, based on Marvin's Comment 34, I think we can remove this from CAF meta list also the blocking nom?
Flags: needinfo?(bbajaj)
Flags: needinfo?(ktucker)
No test case added in moztrap based upon comment 34.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Flags: in-moztrap?(dharris)
Flags: in-moztrap-
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
(In reply to howie [:howie] from comment #35)
> Hi Bhavana, based on Marvin's Comment 34, I think we can remove this from
> CAF meta list also the blocking nom?

Communicated this to CAF today and we can remove the blocking now.
blocking-b2g: 2.1? → ---
Flags: needinfo?(bbajaj)
Blocks: CAF-v2.2-metabug
No longer blocks: CAF-v2.1-FC-metabug
No one is actually working on RTSP for FxOS right now.
Status: REOPENED → RESOLVED
Closed: 10 years ago → 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: