Closed Bug 1372687 Opened 7 years ago Closed 7 years ago

[Mdm2] Intermittent test_peerConnection_basicVideoRemoteHwEncoder.html | java-exception org.mozilla.gecko.mozglue.GeckoLoader$AbortException: abort() called from :0xdd6216d9 () at org.mozilla.gecko.mozglue.GeckoLoader.abort(GeckoLoader.java:532)

Categories

(Core :: WebRTC, defect, P1)

Product:
Core
Component:
WebRTC
Platform:
Unspecified
Android
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla56
Tracking Flags:
Tracking Status
firefox-esr52 --- unaffected
firefox54 --- unaffected
firefox55 --- unaffected
firefox56 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: mchiang)

References

(Blocks 1 open bug)

Details

(Keywords: crash, intermittent-failure, Whiteboard: [stockwell fixed:product])

Attachments

(1 file)

Bug 1372687 - replace timestamp() (90kHz) with inputImage.render_time_ms() (Milliseconds).
59 bytes, text/x-review-board-request
jesup
: review+
Details
Rank: 25
OS: Unspecified → Android
Priority: -- → P2
this is autophone specifc and started around June 12th.  Given the high failure rate I would like to look into this and resolve this failure (fix, reduce, disable) in the next 2 weeks.

:bc - who is your best point of contact for dom-media tests?  (I see :bechen working on a av/playback bug, but this looks like webrtc).
Flags: needinfo?(bob)
Whiteboard: [stockwell needswork]
Al, I know you have been working on Mdm1 to get it back running. Could you look into this one as well?
Blocks: autophone-Mdm
Flags: needinfo?(bob) → needinfo?(alwu)
Summary: Intermittent test_peerConnection_basicVideoRemoteHwEncoder.html | java-exception org.mozilla.gecko.mozglue.GeckoLoader$AbortException: abort() called from :0xdd6216d9 () at org.mozilla.gecko.mozglue.GeckoLoader.abort(GeckoLoader.java:532) → [Mdm2] Intermittent test_peerConnection_basicVideoRemoteHwEncoder.html | java-exception org.mozilla.gecko.mozglue.GeckoLoader$AbortException: abort() called from :0xdd6216d9 () at org.mozilla.gecko.mozglue.GeckoLoader.abort(GeckoLoader.java:532)
Hi, Munro,
Could you help me take a look about it?
It seems related with WebRTC.
Thanks!
Flags: needinfo?(alwu) → needinfo?(mchiang)
Assignee: nobody → mchiang
Flags: needinfo?(mchiang)
:mchiang- do you think this will be fixed before or during the all hands next week?  The failure rate is pretty high and I would like to temporarily disable this if we don't have a short term plan for a fix.
Flags: needinfo?(mchiang)
Rank: 25 → 18
Priority: P2 → P1
(In reply to Joel Maher ( :jmaher) from comment #10)
> :mchiang- do you think this will be fixed before or during the all hands
> next week?  The failure rate is pretty high and I would like to temporarily
> disable this if we don't have a short term plan for a fix.

Sorry to response late. I am heading to SF.
This bug is my first priority during the all hands.
Flags: needinfo?(mchiang)
Regresion window show that this bug is caused by bug 1341285
Dan - regression from the 57 landing on android - coordinate with munro
Munro, let me know if there is anything I can do to help!
Looks like an invalid rtp_time:

6-13 11:15:28.927 E/rtc     ( 8594): #
2017-06-13 08:16:51,506      nexus-6p-5 INFO     UnitTestJob mozilla-inbound 20170613140230 debug api-23 android-api-15 mochitest-dom-media-tests 06-13 11:15:28.927 E/rtc     ( 8594): # Fatal error in /home/worker/workspace/build/src/media/webrtc/trunk/webrtc/modules/rtp_rtcp/source/rtp_header_extensions.cc, line 106
2017-06-13 08:16:51,506      nexus-6p-5 INFO     UnitTestJob mozilla-inbound 20170613140230 debug api-23 android-api-15 mochitest-dom-media-tests 06-13 11:15:28.927 E/rtc     ( 8594): # last system error: 22
2017-06-13 08:16:51,507      nexus-6p-5 INFO     UnitTestJob mozilla-inbound 20170613140230 debug api-23 android-api-15 mochitest-dom-media-tests 06-13 11:15:28.927 E/rtc     ( 8594): # Check failed: rtp_time <= 0x00ffffff (752870786 vs. 16777215)
2017-06-13 08:16:51,507      nexus-6p-5 INFO     UnitTestJob mozilla-inbound 20170613140230 debug api-23 android-api-15 mochitest-dom-media-tests 06-13 11:15:28.927 E/rtc     ( 8594): #
2017-06-13 08:16:51,507      nexus-6p-5 INFO     UnitTestJob mozilla-inbound 20170613140230 debug api-23 android-api-15 mochitest-dom-media-tests 06-13 11:15:28.927 E/rtc     ( 8594): #
2017-06-13 08:16:51,507      nexus-6p-5 INFO     UnitTestJob mozilla-inbound 20170613140230 debug api-23 android-api-15 mochitest-dom-media-tests 06-13 11:15:28.927 E/Gecko   ( 8594): mozalloc_abort: abort() called from :0xdd6216d9 ()
This check is added in 57 release.
Does rtp_time come from encoder?
See rtp_sender.cc:

    if (capture_time_ms > 0) {
      padding_packet->SetExtension<TransmissionOffset>(
          (now_ms - capture_time_ms) * kTimestampTicksPerMs);
    }

  int64_t capture_time_ms = packet->capture_time_ms();
...
  int64_t diff_ms = now_ms - capture_time_ms;
  packet_to_send->SetExtension<TransmissionOffset>(kTimestampTicksPerMs *
                                                   diff_ms);

  if (packet->capture_time_ms() > 0) {
    packet->SetExtension<TransmissionOffset>(
        kTimestampTicksPerMs * (now_ms - packet->capture_time_ms()));
  }

So since 'now' is unlikely to be bad, either the capture_time_ms is bad, or maybe it's 0 -- note that one of these doesn't check for 0
This bug is similar to bug 1030112.
We should feed android native encoder with timestamp in millisecond (inputImage.render_time_ms()), not in 90kHz format (inputImage.timestamp()).
Attachment #8882092 - Flags: review?(jib) → review?(rjesup)
Lgtm, but lateraling to jesup.
Comment on attachment 8882092 [details]
Bug 1372687 - replace timestamp() (90kHz) with inputImage.render_time_ms() (Milliseconds).

https://reviewboard.mozilla.org/r/153192/#review158440

from looking at the patch, it appears the changes is us vs ms, not 90K vs ms.   If this was the intention, r+ with a commit message change.  Else, please check and re-submit
Attachment #8882092 - Flags: review?(rjesup) → review+
Comment on attachment 8882092 [details]
Bug 1372687 - replace timestamp() (90kHz) with inputImage.render_time_ms() (Milliseconds).

https://reviewboard.mozilla.org/r/153192/#review158492

::: media/webrtc/signaling/src/media-conduit/WebrtcMediaCodecVP8VideoCodec.cpp:108
(Diff revision 1)
>  
>        int64_t presentationTimeUs;
>        ok = NS_SUCCEEDED(info->PresentationTimeUs(&presentationTimeUs));
>        MOZ_RELEASE_ASSERT(ok);
>  
> -      mEncodedImage._timeStamp = presentationTimeUs;
> +      mEncodedImage._timeStamp = presentationTimeUs / PR_USEC_PER_MSEC;

us -> ms

::: media/webrtc/signaling/src/media-conduit/WebrtcMediaCodecVP8VideoCodec.cpp:1079
(Diff revision 1)
> -    bufferInfo->Set(0, size, inputImage.timestamp(), MediaCodec::BUFFER_FLAG_SYNC_FRAME);
> +    bufferInfo->Set(0, size, inputImage.render_time_ms() * PR_USEC_PER_MSEC, MediaCodec::BUFFER_FLAG_SYNC_FRAME);
>    } else {
> -    bufferInfo->Set(0, size, inputImage.timestamp(), 0);
> +    bufferInfo->Set(0, size, inputImage.render_time_ms() * PR_USEC_PER_MSEC, 0);

timestamp() returns timestamp in 90kHz format
http://searchfox.org/mozilla-central/rev/152c0296f8a10f81185ee88dfb4114ec3882b4c6/media/webrtc/trunk/webrtc/api/video/video_frame.h#74-75

render_time_ms() returns timestamp in ms format
http://searchfox.org/mozilla-central/rev/152c0296f8a10f81185ee88dfb4114ec3882b4c6/media/webrtc/trunk/webrtc/api/video/video_frame.cc#62-64
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/6ec07b1cf721
replace timestamp() (90kHz) with inputImage.render_time_ms() (Milliseconds). r=jesup
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/6ec07b1cf721
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox56: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
Whiteboard: [stockwell needswork] → [stockwell fixed]
Whiteboard: [stockwell fixed] → [stockwell fixed:product]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: