Closed
Bug 1496529
Opened 6 years ago
Closed 6 years ago
[webrtc]H264 video decoding cause a crash/failure when using playback decoder.
Categories
(Core :: WebRTC: Audio/Video, enhancement, P3)
Core
WebRTC: Audio/Video
Tracking
()
RESOLVED
FIXED
mozilla64
Tracking | Status | |
---|---|---|
firefox64 | --- | fixed |
People
(Reporter: jya, Assigned: jya)
References
Details
Attachments
(9 files, 1 obsolete file)
46 bytes,
text/x-phabricator-request
|
Details | Review | |
46 bytes,
text/x-phabricator-request
|
Details | Review | |
46 bytes,
text/x-phabricator-request
|
Details | Review | |
46 bytes,
text/x-phabricator-request
|
Details | Review | |
46 bytes,
text/x-phabricator-request
|
Details | Review | |
46 bytes,
text/x-phabricator-request
|
Details | Review | |
46 bytes,
text/x-phabricator-request
|
Details | Review | |
46 bytes,
text/x-phabricator-request
|
Details | Review | |
46 bytes,
text/x-phabricator-request
|
Details | Review |
It crashes there: https://searchfox.org/mozilla-central/rev/924e3d96d81a40d2f0eec1db5f74fc6594337128/dom/media/platforms/wrappers/H264Converter.cpp#334 mDecoder->Init() ->Then( AbstractThread::GetCurrent()->AsTaskQueue(), When called from webrtc.org, the current thread isn't a TaskQueue (nor nsIEventTarget) As such, dispatching will fail (and assert on debug build) Either we need to write a TaskQueue using a webrtc.org thread, or modify the H264Convert to use the decoder's taskqueue. The later seems easier.
Updated•6 years ago
|
Rank: 25
Priority: -- → P3
QA Contact: jib
Assignee | ||
Comment 1•6 years ago
|
||
Assignee | ||
Comment 2•6 years ago
|
||
The H264Converter can be used on a thread that isn't a nsThread or a TaskQueue, so having the H264Converter dispatching tasks isn't going to work So instead we run all the code on the decoder's taskqueue using promise chaining. All internal methods are made to assert that they are running on the task queue accordingly Depends on D7860
Assignee | ||
Comment 3•6 years ago
|
||
When used with the LowLatency option, we guarantee that the stream will contain no B-frame, as such we can reduce the re-ordering queue to zero. The apple VT decoder already returns frames in decode order making this change trivial. Depends on D7861
Assignee | ||
Comment 4•6 years ago
|
||
TaskQueue no longer requires explicit shutdown Depends on D7862
Assignee | ||
Comment 5•6 years ago
|
||
Depends on D7864
Assignee | ||
Comment 6•6 years ago
|
||
P2 changed the way the H264Converter would be calling the decoder. The assumption in the EMEDecryptor was pretty incorrect to start with. Depends on D7865
Assignee | ||
Comment 7•6 years ago
|
||
Depends on D7882
Updated•6 years ago
|
Attachment #9014802 -
Attachment description: Bug 1496529 - P6. Alwats run EMEDecryptor on the decoder's taskqueue. → Bug 1496529 - P6. Always run EMEDecryptor on the decoder's taskqueue.
Assignee | ||
Comment 8•6 years ago
|
||
For now, the H264 decoding support is rather sturdy. It handles change of resolution and content smoothly thanks to the H264Converter. The VP8/VP9 one however, not so much. So we make a preference to only enable H264 for now. Depends on D7895
Assignee | ||
Comment 9•6 years ago
|
||
Depends on D7908
Updated•6 years ago
|
QA Contact: jib
Assignee | ||
Comment 10•6 years ago
|
||
Depends on D7909
Updated•6 years ago
|
Attachment #9014904 -
Attachment description: Bug 1496529 - P9. Add to libvpx decoder low latency mode. → Bug 1496529 - P10. Add to libvpx decoder low latency mode.
Assignee | ||
Updated•6 years ago
|
Summary: H264 video decoding cause a crash/failure when using playback decoder. → [webrtc]H264 video decoding cause a crash/failure when using playback decoder.
Updated•6 years ago
|
Attachment #9014774 -
Attachment is obsolete: true
Comment 11•6 years ago
|
||
Pushed by jyavenard@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/f2b367bc188a P2. Make H264Converter use provided decoder's TaskQueue. r=bryce https://hg.mozilla.org/integration/autoland/rev/19cdb829699f P3. Make the Apple H264 decoder provide 0 latency option. r=bryce https://hg.mozilla.org/integration/autoland/rev/b76ae0d758d9 P4. Remove unnecessary code. r=bryce https://hg.mozilla.org/integration/autoland/rev/93312ff3f180 P5. Don't unnecessarily wait on decoder to shutdown r=bryce https://hg.mozilla.org/integration/autoland/rev/40f7fbd43f51 P6. Always run EMEDecryptor on the decoder's taskqueue. r=bryce https://hg.mozilla.org/integration/autoland/rev/970b4aaccd35 P7. Pass full range of CreateDecoderParam::Option to RemoteVideoDecoder r=bryce https://hg.mozilla.org/integration/autoland/rev/357d4762fa8f P8. Add media.navigator.mediadatadecoder_h264_enabled preference. r=drno https://hg.mozilla.org/integration/autoland/rev/ea2cd3e66c56 P9. Enable low latency decoding on Windows. r=bryce https://hg.mozilla.org/integration/autoland/rev/b3a1baa85807 P10. Add to libvpx decoder low latency mode. r=bryce
Comment 12•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/f2b367bc188a https://hg.mozilla.org/mozilla-central/rev/19cdb829699f https://hg.mozilla.org/mozilla-central/rev/b76ae0d758d9 https://hg.mozilla.org/mozilla-central/rev/93312ff3f180 https://hg.mozilla.org/mozilla-central/rev/40f7fbd43f51 https://hg.mozilla.org/mozilla-central/rev/970b4aaccd35 https://hg.mozilla.org/mozilla-central/rev/357d4762fa8f https://hg.mozilla.org/mozilla-central/rev/ea2cd3e66c56 https://hg.mozilla.org/mozilla-central/rev/b3a1baa85807
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox64:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
You need to log in
before you can comment on or make changes to this bug.
Description
•