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

Status: RESOLVED WORKSFORME

(Core :: Audio/Video, defect)

Description

[Ethan Tseng [:ethan]]

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.

Comment 1

[Jason Smith [:jsmith]]

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.

Comment 2

[Jason Smith [:jsmith]]

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?

Comment 3

[Ethan Tseng [:ethan]]

(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

[Jason Smith [:jsmith]]

(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.

Comment 5

[Benjamin Chen [:bechen]]

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.

Comment 6

[Ken Chang[:kenkai]]

It blocks 1.4 feature.

Comment 7

[Benjamin Chen [:bechen]]

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

Comment 8

[Bruce Sun [:brsun]]

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.

Comment 9

[Benjamin Chen [:bechen]]

(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

[Jason Smith [:jsmith]]

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.

Comment 11

[howie [:howie]]

Hi Benjamin, seems like the patch works right? Is there any update on this ticket?

Comment 12

[Bruce Sun [:brsun]]

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

[Bruce Sun [:brsun]]

If this issue only happens on ics_chocolate or unagi, probably we could leave it as WONTFIX. Any comments?

Comment 14

[Ethan Tseng [:ethan]]

William, please help to verify the current status of this bug. :)

Comment 15

[William Hsu [: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

Comment 16

[Ethan Tseng [:ethan]]

(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.