Flushing may leave H264Converter in inconsistent state

RESOLVED FIXED in Firefox 55

Status

()

enhancement
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: jya, Assigned: jya)

Tracking

Trunk
mozilla55
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox55 fixed)

Details

Attachments

(1 attachment)

In the H264Converter, when we encounter a change of stream we flush then shutdown the current decoder.

However, if Flush is called right at that time, then the decoder may not be properly re-created as we have stored the new extradata before actually using.

So after the next Decode, the decoder will not be correctly recreated.
My original analysis was incorrect.

The extradata fields are properly updated when they need to be so it's all fine there.

However, if H264Converter::Flush() is called in the middle of a configuration change, then the current decoder may be left in an inconsistent state (such as being called while a flush is currently going).
Also H264Converter::Flush should wait for any pending shutdown to complete before resolving its promise.
Summary: Decoder may not be recreated if flushing occurred in the middle of a stream change → Flushing may leave H264Converter in inconsistent state
Comment on attachment 8874523 [details]
Bug 1370164: Properly handle flushing during ongoing operations.

https://reviewboard.mozilla.org/r/145890/#review149986
Attachment #8874523 - Flags: review?(jwwang) → review+
Pushed by jyavenard@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/78dcfa118bdd
Properly handle flushing during ongoing operations. r=jwwang
https://hg.mozilla.org/mozilla-central/rev/78dcfa118bdd
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
You need to log in before you can comment on or make changes to this bug.