Closed Bug 973139 Opened 6 years ago Closed 6 years ago

GStreamerReader considers EOS of one stream to be EOS of all streams

Categories

(Core :: Audio/Video, defect)

29 Branch
x86_64
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla30

People

(Reporter: cpearce, Assigned: cpearce)

References

Details

Attachments

(1 file)

I discovered that mochitest test_streams_element_capture.html was failing on gizmo.mp4 on Linux/GStreamer/Ubuntu 12.04 x64. The failure was the media was finishing playing and reporting EOS before it reached the duration stated in the files metadata.

The problem is that the GStreamerReader is receiving a callback for EOS of an GstAppSink and assuming that the EOS applies to all both the audio and video app sink, not the stream for the app sink for which the callback arrived for. We receive a callback for both the audio and video appsink, and we should track the sink's EOS separately. I think we should also wait until the decoded count of buffers for a stream is 0 before reporting EOS to the state machine.
Track EOS of audio and video app sinks separately. This fixes the test for me.

I also initialized the "duration" variable in GStreamerReader::DecodeVideoFrame() to prevent an uninitialized variable used warning.
Attachment #8376642 - Flags: review?(alessandro.d)
Blocks: 949346
Comment on attachment 8376642 [details] [diff] [review]
Patch: Track EOS of audio and video app sinks separately

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

Well spotted. Patch looks good!
Attachment #8376642 - Flags: review?(alessandro.d) → review+
https://hg.mozilla.org/mozilla-central/rev/c4ff618cf72b
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
You need to log in before you can comment on or make changes to this bug.