Closed
Bug 1497951
Opened 6 years ago
Closed 6 years ago
Have VP8/VP9 decoder wrapper to detect change of stream content
Categories
(Core :: WebRTC: Audio/Video, enhancement, P2)
Core
WebRTC: Audio/Video
Tracking
()
RESOLVED
FIXED
mozilla65
Tracking | Status | |
---|---|---|
firefox65 | --- | fixed |
People
(Reporter: jya, Assigned: jya)
References
Details
Attachments
(7 files)
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details |
For H264 content we have the H264Converter which will analyse the raw bitstream and if needed recreate a new H264 converter.
We don't have such mechanism for VP8 and VP9 and so when the content change decoders not handling content change (e.g. all but libvpx) will cause a decoding error.
Ideally we could make the H264Converter codec independent, a generic wrapper handling vp8, vp9 and h264.
This task is required in order to use the playback VP8 or VP9 decoder with WebRTC
Priority: -- → P2
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 1•6 years ago
|
||
So that we can later expand and use it for other codecs.
Assignee | ||
Comment 2•6 years ago
|
||
For AVC1 content (where the SPS/PPS is provided out of band), we would use VideoInfo has found in the container's metadata which may not always be correct.
Likely the reason on why we had bug 1498788 (decoded sample size didn't match the video config's dimensions)
We also always set the MediaRawData::mTrackInfo member for all samples, not just the first one as it's the right thing to do.
Depends on D10907
Assignee | ||
Comment 3•6 years ago
|
||
This ensures that the test always work whenever the sample contains an extradata that is different to the info specified in the VideoInfo.
Depends on D10908
Assignee | ||
Comment 4•6 years ago
|
||
Depends on D10909
Assignee | ||
Comment 5•6 years ago
|
||
Depends on D10911
Assignee | ||
Comment 6•6 years ago
|
||
This is now done in the MediaChangeMonitor.
Depends on D10912
Assignee | ||
Comment 7•6 years ago
|
||
Because why not...
Depends on D10913
Pushed by jyavenard@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/aecd59f2fb30
P1. Abstract H264Converter. r=bryce
https://hg.mozilla.org/integration/autoland/rev/06c764a40a02
P2. Always ensure the provided VideoConfig exactly match the content. r=bryce
https://hg.mozilla.org/integration/autoland/rev/e8e4842ca7bf
P3. Improve out of band SPS change detection. r=bryce
https://hg.mozilla.org/integration/autoland/rev/80643ce074f6
P4. Rework and simplify code flow. r=bryce
https://hg.mozilla.org/integration/autoland/rev/9b18bd5c4c8b
P5. Add VPXChangeMonitor and detect VPx inband resolution change. r=bryce
https://hg.mozilla.org/integration/autoland/rev/4e832384a464
P6. Remove resolution detection in webm demuxer. r=bryce
https://hg.mozilla.org/integration/autoland/rev/f91c9161f993
P7. Check for in-band profile VP9 change, r=bryce
Comment 9•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/aecd59f2fb30
https://hg.mozilla.org/mozilla-central/rev/06c764a40a02
https://hg.mozilla.org/mozilla-central/rev/e8e4842ca7bf
https://hg.mozilla.org/mozilla-central/rev/80643ce074f6
https://hg.mozilla.org/mozilla-central/rev/9b18bd5c4c8b
https://hg.mozilla.org/mozilla-central/rev/4e832384a464
https://hg.mozilla.org/mozilla-central/rev/f91c9161f993
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox65:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
You need to log in
before you can comment on or make changes to this bug.
Description
•