[dolphin][FFOS7715 v2.1][RTSP video][Browser] Duration is a large random number in the initial loading phase

RESOLVED DUPLICATE of bug 1086198

Status

Firefox OS
RTSP
P1
normal
RESOLVED DUPLICATE of bug 1086198
4 years ago
4 years ago

People

(Reporter: lin.hui@spreadtrum.com, Assigned: ethan)

Tracking

unspecified
x86_64
Linux

Firefox Tracking Flags

(b2g-v2.1 affected)

Details

(Whiteboard: [SPRD 382375])

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
DEFECT DESCRIPTION:
  playing RTSP video in website, the video's duration is a big random value.

Steps to reproduce:
----------------------------------------------------
1.open the website "114.30.40.60:8800"
2.select "index.html"
3.select "video streaming test", click the RTSP video to play.

Expected result:
--------------------------------------- 
The RTSP video's duration should be 0 during loading time.

Additional info:
--------------------------------------
Reproduce rate:  5/5
(Reporter)

Updated

4 years ago
status-b2g-v2.1: --- → affected
Whiteboard: [SPRD 382375]
Hi Ethan -

Ni you since you already discussed this issue with partner in Bug#1110663

Thanks
Flags: needinfo?(ettseng)
(Reporter)

Comment 2

4 years ago
Hi Ethan:

How about this issue?

In my opinion, in function "PRtspControllerChild::OnMessageReceived"
>  if ((!(Read((&(meta)), (&(__msg)), (&(__iter)))))) {
>     FatalError("Error deserializing 'nsTArray'");
>     return MsgValueError;
>  }

call Read((&(meta)), (&(__msg)), (&(__iter))))) to obtain the RTSP video metadata info, then pass it to function "RtspMetaData::DeserializeRtspMetaData(const InfallibleTArray<RtspMetadataParam>& metaArray)"

in "DeserializeRtspMetaData" :
> else if(name.EqualsLiteral("DURATION")) {
>     rv = SetDuration(value);
ps: "value" is the messy random value, and the slider bar displayed this value. we shoule displaying "0" to the slider bar.

please help to check it.

Thanks!
(Assignee)

Comment 3

4 years ago
Lin, I modified the title to make it more succinct. Hope you don't mind.
Assignee: nobody → ettseng
Summary: [dolphin][FFOS7715 v2.1][RTSP video][Browser] Go browser, playing RTSP video, during video loaded, the duration of video is a very large value. → [dolphin][FFOS7715 v2.1][RTSP video][Browser] Duration is a large random number in the initial loading phase
(Assignee)

Comment 4

4 years ago
(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #1)
> Hi Ethan -
> Ni you since you already discussed this issue with partner in Bug#1110663
I will take this bug.
Flags: needinfo?(ettseng)
(Assignee)

Comment 5

4 years ago
(In reply to lin.hui@spreadtrum.com from comment #2)
> In my opinion, in function "PRtspControllerChild::OnMessageReceived"
> >  if ((!(Read((&(meta)), (&(__msg)), (&(__iter)))))) {
> >     FatalError("Error deserializing 'nsTArray'");
> >     return MsgValueError;
> >  }
> call Read((&(meta)), (&(__msg)), (&(__iter))))) to obtain the RTSP video
> metadata info, then pass it to function
> "RtspMetaData::DeserializeRtspMetaData(const
> InfallibleTArray<RtspMetadataParam>& metaArray)"
> 
> in "DeserializeRtspMetaData" :
> > else if(name.EqualsLiteral("DURATION")) {
> >     rv = SetDuration(value);
> ps: "value" is the messy random value, and the slider bar displayed this
> value. we shoule displaying "0" to the slider bar.

After a little debugging work, the root cause is not in these places.
RtspControllerChild/Parent get the correct duration when RTSP connection is established.
(Reporter)

Comment 6

4 years ago
Hi Ethan:
By using GDB debugging the code, I captured the following info:
When breakpoint on "mozilla::net::RtspMetaData::DeserializeRtspMetaData", this time it will deserialize video meta data:

>RtspMetaData::DeserializeRtspMetaData(const InfallibleTArray<RtspMetadataParam>& metaArray)
>{
>  nsresult rv;
>  // Deserialize meta data.
>  for (uint32_t i = 0; i < metaArray.Length(); i++) {
>  const RtspMetaValue& value = metaArray[i].value();
>  const nsCString& name = metaArray[i].name();
>
>   if (name.EqualsLiteral("FRAMETYPE")) {
>     rv = SetFrameType(value);
>     NS_ENSURE_SUCCESS(rv, NS_ERROR_FAILURE);
>   } else if (name.EqualsLiteral("TIMESTAMP")) {
>     rv = SetTimeStamp(value);
>     NS_ENSURE_SUCCESS(rv, NS_ERROR_FAILURE);
>   } else if (name.EqualsLiteral("TRACKS")) {
>     rv = SetTotalTracks(value);
>     NS_ENSURE_SUCCESS(rv, NS_ERROR_FAILURE);
>   } else if(name.EqualsLiteral("MIMETYPE")) {
>     rv = SetMimeType(value);                      //"video/3gpp"
>     NS_ENSURE_SUCCESS(rv, NS_ERROR_FAILURE);
>   } else if (name.EqualsLiteral("WIDTH")) {
>     rv = SetWidth(value);                         //value = RTSP video width  "176"
>     NS_ENSURE_SUCCESS(rv, NS_ERROR_FAILURE);
>   } else if (name.EqualsLiteral("HEIGHT")) {
>     rv = SetHeight(value);                        //value = RTSP video height "144"
>     NS_ENSURE_SUCCESS(rv, NS_ERROR_FAILURE);
>   } else if (name.EqualsLiteral("SAMPLERATE")) {
>     rv = SetSampleRate(value);
>     NS_ENSURE_SUCCESS(rv, NS_ERROR_FAILURE);
>   } else if(name.EqualsLiteral("DURATION")) {
>     rv = SetDuration(value);                     //value = a large random number  "244479995"
>     NS_ENSURE_SUCCESS(rv, NS_ERROR_FAILURE);
>   }
> }

then continue, it will also breakpoint on "mozilla::net::RtspMetaData::DeserializeRtspMetaData", this time it will deserialize audio meta data:

>RtspMetaData::DeserializeRtspMetaData(const InfallibleTArray<RtspMetadataParam>& metaArray)
>{
>  nsresult rv;
>  // Deserialize meta data.
>  for (uint32_t i = 0; i < metaArray.Length(); i++) {
>  const RtspMetaValue& value = metaArray[i].value();
>  const nsCString& name = metaArray[i].name();
>
>   if (name.EqualsLiteral("FRAMETYPE")) {
>     rv = SetFrameType(value);
>     NS_ENSURE_SUCCESS(rv, NS_ERROR_FAILURE);
>   } else if (name.EqualsLiteral("TIMESTAMP")) {
>     rv = SetTimeStamp(value);
>     NS_ENSURE_SUCCESS(rv, NS_ERROR_FAILURE);
>   } else if (name.EqualsLiteral("TRACKS")) {
>     rv = SetTotalTracks(value);
>     NS_ENSURE_SUCCESS(rv, NS_ERROR_FAILURE);
>   } else if(name.EqualsLiteral("MIMETYPE")) {
>     rv = SetMimeType(value);                      //value = "audio/mp4a-latm"
>     NS_ENSURE_SUCCESS(rv, NS_ERROR_FAILURE);
>   } else if (name.EqualsLiteral("WIDTH")) {
>     rv = SetWidth(value);                         //value = 0
>     NS_ENSURE_SUCCESS(rv, NS_ERROR_FAILURE);
>   } else if (name.EqualsLiteral("HEIGHT")) {
>     rv = SetHeight(value);                        //value = 0
>     NS_ENSURE_SUCCESS(rv, NS_ERROR_FAILURE);
>   } else if (name.EqualsLiteral("SAMPLERATE")) {
>     rv = SetSampleRate(value);
>     NS_ENSURE_SUCCESS(rv, NS_ERROR_FAILURE);
>   } else if(name.EqualsLiteral("DURATION")) {
>     rv = SetDuration(value);                     //value = a large random number  "244479995"
>     NS_ENSURE_SUCCESS(rv, NS_ERROR_FAILURE);
>   }
> }

According to the above information,if video's width & height are parse currectly, why the video's duration is a large random number? I think it shoule be the video's currectly duration too.

Can you help to find the root cause?

Thanks!
(Reporter)

Comment 7

4 years ago
(In reply to Ethan Tseng [:ethan] from comment #5)
> RtspControllerChild/Parent get the correct duration when RTSP connection is
> established.

If RTSP connection is establish not completed, we should display "0" to the slider bar.

I'm sorry that I try to find the code logical to modify it, but I failed.

Look forward to your help.
(Assignee)

Comment 8

4 years ago
Created attachment 8537755 [details] [diff] [review]
Fix the unit of argument to Decoder::SetDuration()

Lin,

I recall that we had fixed a duration bug in v2.2 (incorrect units of duration).
We didn't uplift the fix to v2.1 because we found the bug in an internal test,
and the duration displayed to the user is never a random value.
(It's either 0 or a correct number).

I am not 100% sure this patch could resolve the random duration issue.
(Because I cannot reproduce it on my Flame v2.1).
Could you help to apply the patch and give it a try?
Flags: needinfo?(lin.hui)
(Reporter)

Comment 9

4 years ago
(In reply to Ethan Tseng [:ethan] from comment #8)
> I am not 100% sure this patch could resolve the random duration issue.
> (Because I cannot reproduce it on my Flame v2.1).
> Could you help to apply the patch and give it a try?

I am very glad to tell you, after applying the patch to v2.1, the RTSP video's duration isn't a large random value nolonger, and it's the video's acturally duration, and the patch doesn't bring side effects.

I will applying this patch in our branches.

Thanks for your help.
Flags: needinfo?(lin.hui)
(Reporter)

Comment 10

4 years ago
Dear Ethan:

The root cause is that the duration is the microsecond, and we didn't throuth a correct conversion, after convert it to seconds, the large random number "244479995" is 4:04 min, it's the actural duration about the RTSP video.

>// Number of microseconds per second. 1e6.
>static const int64_t USECS_PER_S = 1000000;

Thanks for your help.
(Assignee)

Comment 11

4 years ago
(In reply to lin.hui@spreadtrum.com from comment #9)
> I am very glad to tell you, after applying the patch to v2.1, the RTSP
> video's duration isn't a large random value no longer, and it's the video's
> actual duration, and the patch doesn't bring side effects.

Glad to know the patch resolves your problem. :)

So, this bug is the same as bug 1086198 ([RTSP] The unit of property duration of media element 
is not in seconds). Mark it as duplicate.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1086198
(Assignee)

Comment 12

4 years ago
(In reply to lin.hui@spreadtrum.com from comment #9)
> I will applying this patch in our branches.
> Thanks for your help.

I guess you mean we don't need to uplift the fix to v2.1 in Mozilla code base.
However, I still uploaded the v2.1 patch to bug 1086198.
If necessary, we can uplift the fix in that bug.
(Assignee)

Comment 13

4 years ago
*** Work note ***
In our RTSP client implementation, RTSP media duration is set two times through two different methods
of MediaDecoder.

1. The first time: In RtspMediaResource::OnConnected().
   When RTSP connection is established, OnConnected message is propagated from RtspController to
   RtpMediaResource.
   RtspMediaResource::OnConnected() calls MediaDecoder::SetDuration().

2. The second time: In MediaOmxReader::ReadMetadata().
   When RTSP client starts to receive RTP stream packets, OnDataAvailable messages are propagated from
   RtspController to media decoder.
   The media decoder would invoke MediaOmxReader::ReadMetadata(), which calls
   MediaDecoder::SetMediaDuration().

The bug was in RtspMediaResource::OnConnected().
We hadn't noticed the incorrect duration because the 2nd time setup is correct and might overwrite
the 1st time setup.
(Reporter)

Comment 14

4 years ago
(In reply to Ethan Tseng [:ethan] from comment #12)
> I guess you mean we don't need to uplift the fix to v2.1 in Mozilla code
> base.
> However, I still uploaded the v2.1 patch to bug 1086198.
> If necessary, we can uplift the fix in that bug.
Dear Ethan:

After some discussion with my teammates, we think it's still better to uplift the patch of this bug to v2.1 in mozilla code base in order to reduce confusion and maintenance trouble in the future.

Hope for your reply.
Flags: needinfo?(ettseng)
(Assignee)

Comment 15

4 years ago
(In reply to lin.hui@spreadtrum.com from comment #14)
> After some discussion with my teammates, we think it's still better to
> uplift the patch of this bug to v2.1 in mozilla code base in order to reduce
> confusion and maintenance trouble in the future.
> Hope for your reply.

Already raised the request flag.
https://bugzilla.mozilla.org/show_bug.cgi?id=1086198#c26
Flags: needinfo?(ettseng)
(Assignee)

Comment 16

4 years ago
The fix already landed in v2.1.
https://bugzilla.mozilla.org/show_bug.cgi?id=1086198#c29

Lin, please help to verify it, thanks.
(Reporter)

Comment 17

4 years ago
Dear Ethan:

I verify the newest code,but issue still existed, maybe the fix dosen't landed in v2.1.

Thanks.
(Reporter)

Comment 18

4 years ago
(In reply to Ethan Tseng [:ethan] from comment #16)
> The fix already landed in v2.1.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1086198#c29
> 
> Lin, please help to verify it, thanks.

Issue still existed in newest version, are you ensure the fix already landed in v2.1?

Please help to verify the patch has already applied in v2.1.

Thanks a lot.
Flags: needinfo?(ettseng)
(Assignee)

Comment 19

4 years ago
Lin, please check your build contains this changeset or not.
https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/cc9a90b5d66b
Flags: needinfo?(ettseng)
(Reporter)

Comment 20

4 years ago
(In reply to Ethan Tseng [:ethan] from comment #19)
> Lin, please check your build contains this changeset or not.
> https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/cc9a90b5d66b

I checked this again and again, I couldn't find the changeset in v2.1.

But our build contains this changeset:
> Bug 1045062 - [RTSP] Replace CHECK assertions by NS_ASSERTION or graceful assertions

So the system crash is fixed, but the random duration issue not.
Flags: needinfo?(ettseng)
(Assignee)

Comment 21

4 years ago
(In reply to lin.hui@spreadtrum.com from comment #20)
> I checked this again and again, I couldn't find the changeset in v2.1.
Sorry I don't know how often your build is updated from Mozilla code base.
From our point of view, the changeset already landed to our v2.1 repository (mozilla-b2g34_v2_1).
Flags: needinfo?(ettseng)
(Reporter)

Comment 22

4 years ago
Dear Ethan:

I‘m so sorry, because of our server has something error, so cause we can not visit the remote branch which named "mozillaorg/v2.1", but now they are repaired, and the changeset already landed in v2.1.

Thanks.
(Assignee)

Comment 23

4 years ago
(In reply to lin.hui@spreadtrum.com from comment #22)
> Dear Ethan:
> I‘m so sorry, because of our server has something error, so cause we can not
> visit the remote branch which named "mozillaorg/v2.1", but now they are
> repaired, and the changeset already landed in v2.1.
> Thanks.

Never mind.
Glad to know you got the fix.
You need to log in before you can comment on or make changes to this bug.