Closed
Bug 1496529
Opened 7 years ago
Closed 7 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•7 years ago
|
Rank: 25
Priority: -- → P3
QA Contact: jib
| Assignee | ||
Comment 1•7 years ago
|
||
| Assignee | ||
Comment 2•7 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•7 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•7 years ago
|
||
TaskQueue no longer requires explicit shutdown
Depends on D7862
| Assignee | ||
Comment 5•7 years ago
|
||
Depends on D7864
| Assignee | ||
Comment 6•7 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•7 years ago
|
||
Depends on D7882
Updated•7 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•7 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•7 years ago
|
||
Depends on D7908
Updated•7 years ago
|
QA Contact: jib
| Assignee | ||
Comment 10•7 years ago
|
||
Depends on D7909
Updated•7 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•7 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•7 years ago
|
Attachment #9014774 -
Attachment is obsolete: true
Comment 11•7 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•7 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: 7 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
•