Closed
Bug 961926
Opened 11 years ago
Closed 11 years ago
[RTSP] Seek function does not work for 3GP Video RTSP streams
Categories
(Core :: Audio/Video, defect)
Tracking
()
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.
Reporter | ||
Updated•11 years ago
|
Summary: [RTSP] Seek function does not work for certain sources. → [RTSP] Seek function does not work for certain sources
Updated•11 years ago
|
Whiteboard: [FT:RIL]
Comment 1•11 years ago
|
||
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?
Updated•11 years ago
|
Summary: [RTSP] Seek function does not work for certain sources → [RTSP] Seek function does not work for 3GP Video RTSP streams
Reporter | ||
Updated•11 years ago
|
Assignee: nobody → bechen
Comment 2•11 years ago
|
||
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?
Reporter | ||
Comment 3•11 years ago
|
||
(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?
Comment 4•11 years ago
|
||
(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
Assignee | ||
Comment 5•11 years ago
|
||
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.
Updated•11 years ago
|
Component: General → Video/Audio
Product: Firefox OS → Core
Version: unspecified → Trunk
Updated•11 years ago
|
No longer blocks: b2g-RTSP-2.0
Updated•11 years ago
|
Target Milestone: --- → 1.4 S3 (14mar)
Assignee | ||
Comment 7•11 years ago
|
||
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) → ---
Assignee | ||
Updated•11 years ago
|
Target Milestone: --- → 1.4 S3 (14mar)
Comment 8•11 years ago
|
||
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)
Assignee | ||
Comment 9•11 years ago
|
||
(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.
Comment 10•11 years ago
|
||
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?
Updated•11 years ago
|
blocking-b2g: 1.4? → backlog
Updated•11 years ago
|
Target Milestone: 1.4 S3 (14mar) → ---
Comment 11•11 years ago
|
||
Hi Benjamin, seems like the patch works right? Is there any update on this ticket?
Updated•11 years ago
|
Flags: needinfo?(bechen)
Comment 12•11 years ago
|
||
unagi doesn't have this patch yet:
https://www.codeaurora.org/cgit/quic/la/platform/frameworks/base/tree/media/libstagefright/OMXCodec.cpp?h=ics_chocolate_rb4.2#n2720
hamachi has this path:
https://www.codeaurora.org/cgit/quic/la/platform/frameworks/base/tree/media/libstagefright/OMXCodec.cpp?h=b2g_ics_1.2#n2816
Suppose all gonks above 1.2 have this patch already.
https://github.com/mozilla-b2g/platform_frameworks_av/blob/v1.2/media/libstagefright/OMXCodec.cpp#L1852
https://github.com/mozilla-b2g/platform_frameworks_av/blob/v1.3/media/libstagefright/OMXCodec.cpp#L1852
https://github.com/mozilla-b2g/platform_frameworks_av/blob/v1.4/media/libstagefright/OMXCodec.cpp#L1850
Comment 13•11 years ago
|
||
If this issue only happens on ics_chocolate or unagi, probably we could leave it as WONTFIX. Any comments?
Updated•11 years ago
|
Whiteboard: [FT:RIL]
Reporter | ||
Comment 14•11 years ago
|
||
William, please help to verify the current status of this bug. :)
Flags: needinfo?(whsu)
Comment 15•11 years ago
|
||
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)
Updated•11 years ago
|
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 16•11 years ago
|
||
(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.
Reporter | ||
Updated•11 years ago
|
Whiteboard: [p=1]
Target Milestone: --- → 2.0 S2 (23may)
Updated•10 years ago
|
blocking-b2g: backlog → ---
tracking-b2g:
--- → backlog
You need to log in
before you can comment on or make changes to this bug.
Description
•