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

Hi Ethan - Ni you since you already discussed this issue with partner in Bug#1110663 Thanks

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!

Lin, I modified the title to make it more succinct. Hope you don't mind.

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

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

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！

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

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?

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

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.

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

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

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

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

(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

The fix already landed in v2.1. https://bugzilla.mozilla.org/show_bug.cgi?id=1086198#c29 Lin, please help to verify it, thanks.

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

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

Lin, please check your build contains this changeset or not. https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/cc9a90b5d66b

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

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

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.

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