Closed Bug 961926 Opened 6 years ago Closed 6 years ago

[RTSP] Seek function does not work for 3GP Video RTSP streams

Categories

(Core :: Audio/Video, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

()

RESOLVED WORKSFORME
2.0 S2 (23may)
tracking-b2g backlog

People

(Reporter: ethan, Assigned: bechen, NeedInfo)

References

Details

(Whiteboard: [p=1])

Reproduction Steps:
1. Open the following URL using browser app.
   http://goo.gl/lE2eE3
2. Click the first link "Video test page" on the page.
   The original URL of this link is:
   rtsp://r5---sn-o097zuel.c.youtube.com/CiILENy73wIaGQm7Ud1Xjqh2fhMYESARFEgGUgZ2aWRlb3MM/0/0/0/video.3gp
3. After the video app is launched and the streaming is being played, slide the scroll bar to perform seek.
4. Then the video app hangs there. The screen keeps showing loading.
   The seek function does not work at all.

Note:
This bug doesn't happen with every streaming source. For example, if we change the URL to the following:
rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mov
The seek function could work normally.
I am not sure that different container format would be a clue or not.
Summary: [RTSP] Seek function does not work for certain sources. → [RTSP] Seek function does not work for certain sources
Blocks: 898866
Whiteboard: [FT:RIL]
3GP is a codec supported in our platform for playback of videos, so if this isn't working in RTSP for seeking, then we probably need to block on this.
blocking-b2g: --- → 1.3?
Summary: [RTSP] Seek function does not work for certain sources → [RTSP] Seek function does not work for 3GP Video RTSP streams
Assignee: nobody → bechen
Product discussed this again in triage - the proposal going forward is throw an error if video content is detected while video is being loaded in the video app given that the quality of video is poor. This would be a blocker for shipping for video RTSP though, so I'm moving this to 1.4?
blocking-b2g: 1.3? → 1.4?
(In reply to Jason Smith [:jsmith] from comment #2)
> Product discussed this again in triage - the proposal going forward is throw
> an error if video content is detected while video is being loaded in the
> video app given that the quality of video is poor. This would be a blocker
> for shipping for video RTSP though, so I'm moving this to 1.4?
Hi Jason, this bug is about seek function. Your comment look likes a comment for bug 964581.
Did I misunderstand your meaning?
(In reply to Ethan Tseng [:ethan] from comment #3)
> (In reply to Jason Smith [:jsmith] from comment #2)
> > Product discussed this again in triage - the proposal going forward is throw
> > an error if video content is detected while video is being loaded in the
> > video app given that the quality of video is poor. This would be a blocker
> > for shipping for video RTSP though, so I'm moving this to 1.4?
> Hi Jason, this bug is about seek function. Your comment look likes a comment
> for bug 964581.
> Did I misunderstand your meaning?

It's a general comment to all RTSP video bugs. To my understanding, this problem occurs on video, not audio, so per a product triage decision, we're retargeting all video bugs to 1.4.
Blocks: b2g-RTSP-2.0
After some tests, we found the seek function fails because the hw video decoder works abnormal. Audio only stream works fine.

Next step:
1. Test the same stream on different hw device.
2. Check the content data feed into hw codec after seek.
Component: General → Video/Audio
Product: Firefox OS → Core
Version: unspecified → Trunk
No longer blocks: b2g-RTSP-2.0
It blocks 1.4 feature.
blocking-b2g: 1.4? → 1.4+
Target Milestone: --- → 1.4 S3 (14mar)
Hi Bruce:
unagi latest build:
rtsp://r5---sn-o097zuel.c.youtube.com/CiILENy73wIaGQm7Ud1Xjqh2fhMYESARFEgGUgZ2aWRlb3MM/0/0/0/video.3gp

When seeking:
E/        ( 3203): error - neither header nor VOP data to decode in MP4Decoder::Decode, 
E/OMXCodec( 5396): [OMX.qcom.video.decoder.mpeg4] Timed out waiting for output buffers: 0/5 (video still can be played)
E/OMXCodec( 5396): [OMX.qcom.video.decoder.mpeg4] Timed out waiting for output buffers: 0/4 (video stuck)
E/OMXCodec( 5396): [OMX.qcom.video.decoder.mpeg4] Timed out waiting for output buffers: 0/4
Flags: needinfo?(brsun)
Target Milestone: 1.4 S3 (14mar) → ---
Target Milestone: --- → 1.4 S3 (14mar)
Hi Benjamin,

Would you mind to try this patch to see if it help?
 - https://bug864230.bugzilla.mozilla.org/attachment.cgi?id=744257

This kind of issue probably has been solved after ics_strawberry on caf.
Flags: needinfo?(brsun)
(In reply to Bruce Sun [:brsun] from comment #8)
> Hi Benjamin,
> 
> Would you mind to try this patch to see if it help?
>  - https://bug864230.bugzilla.mozilla.org/attachment.cgi?id=744257
> 
> This kind of issue probably has been solved after ics_strawberry on caf.
Thanks.
The patch works great on my unagi.
No longer going to block - RTSP video needs to be preffed off in 1.4 per a drivers decision to cut scope to only DSDS & QC required features.
blocking-b2g: 1.4+ → 1.4?
blocking-b2g: 1.4? → backlog
Target Milestone: 1.4 S3 (14mar) → ---
Hi Benjamin, seems like the patch works right? Is there any update on this ticket?
Flags: needinfo?(bechen)
If this issue only happens on ics_chocolate or unagi, probably we could leave it as WONTFIX. Any comments?
Whiteboard: [FT:RIL]
William, please help to verify the current status of this bug. :)
Flags: needinfo?(whsu)
Hi, Ethan,

I cannot reproduce this bug on latest V2.0 build.
Make this bug as "WORKFORME". Thanks.

* Build information:
 - Gaia      c462d9183d294a2d8ecc472f593ea8cfa15bc9de
 - Gecko     https://hg.mozilla.org/mozilla-central/rev/9d8d16695f6a
 - BuildID   20140520160203
 - Version   32.0a1
Flags: needinfo?(whsu)
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
(In reply to William Hsu [:whsu] from comment #15)
> Hi, Ethan, 
> I cannot reproduce this bug on latest V2.0 build.

Thanks, William.
I cannot reproduce this bug on v2.0 build on Unagi either.
Whiteboard: [p=1]
Target Milestone: --- → 2.0 S2 (23may)
blocking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.