Closed Bug 1047188 Opened 10 years ago Closed 10 years ago

MP4Reader still doesn't drain properly

Categories

(Core :: Audio/Video, defect)

29 Branch
x86_64
Windows 8.1
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla34

People

(Reporter: cpearce, Assigned: cpearce)

References

()

Details

Attachments

(1 file)

I noticed when playing http://people.mozilla.org/~cpearce/video/h264_baseline_lvl3.mp4 that the MP4Reader gets stuck (on Windows at least) inside the loop in MP4Reader::Decode(), where it decides to call Drain(), sets data.mDrainComplete=false, calls Drain(), the decoder calls DrainComplete() (which resets mDrainComplete), but then we reenter the loop in Decode() again, and decide to Drain again and reset DrainComplete, and call Drain() again, repeat ad infinitum.

I need jya's patch from bug 1046549 applied to be able to play that file.
Attached patch PatchSplinter Review
* Don't call Drain() more than once.
* Add an EOS flag so that we can distinguish between "waiting for drain to complete", and "decoding normally and mDrainComplete is false".
* Add ResetDecode() which flushes decoders, and resets state.
* Don't call Flush and ResetDecode() in Seek(), since MediaDecoderStateMachine calls ResetDecode() for us.
Assignee: nobody → cpearce
Status: NEW → ASSIGNED
Attachment #8465936 - Flags: review?(ajones)
Comment on attachment 8465936 [details] [diff] [review]
Patch

Review of attachment 8465936 [details] [diff] [review]:
-----------------------------------------------------------------

::: content/media/fmp4/MP4Reader.cpp
@@ -669,5 @@
>      return NS_ERROR_FAILURE;
>    }
> -  Flush(kVideo);
> -  Flush(kAudio);
> -  ResetDecode();

Do we want to keep the call to ResetDecode() ?
Attachment #8465936 - Flags: review?(ajones) → review+
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #2)
> Comment on attachment 8465936 [details] [diff] [review]
> Patch

> Do we want to keep the call to ResetDecode() ?


We don't need to; the caller of Seek() deliberately calls ResetDecode() before calling Seek(). This is requried by the caller, because async Readers must cancel async operations in their ResetDecode(). So the ResetDecode() call isn't going to go away.
https://hg.mozilla.org/mozilla-central/rev/18ad94c69dff
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: