1084185 - test_streams_element_capture_reset.html fails on small-shot.m4a

Status: RESOLVED WONTFIX

(Core :: Audio/Video: Playback, defect)

Description

[JW Wang [:jwwang] [:jw_wang]]

I tried to have test_streams_element_capture_reset.html iterate over all files of gSmallTests to increase test coverage and found it failed on small-shot.m4a.

code change:
https://hg.mozilla.org/try/rev/56aeb57b223a

error log:
https://treeherder.mozilla.org/ui/logviewer.html#?job_id=2470119&repo=try

02:37:52 INFO - 1970 INFO TEST-UNEXPECTED-FAIL | /tests/content/media/test/test_streams_element_capture_reset.html | Got 0.2773469387755102, expected 0.29; checking vout.currentTime at first 'ended' event - expected PASS
02:37:52 INFO - 1971 INFO TEST-UNEXPECTED-FAIL | /tests/content/media/test/test_streams_element_capture_reset.html | Got 0.277346, expected 0.29; checking v.currentTime at first 'ended' event - expected PASS

The reported duration of small-shot.m4a is 299000us while the timestamp of last audio sample is [256000,277333].

Should we fill the gap with silence or last video frame when the last sample end time is smaller than the media end time in order to get an consistent end time for both file and stream case?

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Where does the value 299000us come from?

Comment 2

[JW Wang [:jwwang] [:jw_wang]]

Reported by gstreamer on Linux. I think other media backend should also report the same value.

Comment 3

[JW Wang [:jwwang] [:jw_wang]]

Not quite the same, but still close.

Win7: Media goes from 0 to 298666 (duration 298666) transportSeekable=1, mediaSeekable=1
Win8: Media goes from 0 to 298666 (duration 298666) transportSeekable=1, mediaSeekable=1
Linux: Media goes from 0 to 299000 (duration 299000) transportSeekable=1, mediaSeekable=1
OSX 10.6: Media goes from 42666 to 341332 (duration 298666) transportSeekable=1, mediaSeekable=1
OSX 10.8: Media goes from 0 to 298666 (duration 298666) transportSeekable=1, mediaSeekable=1

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Why are they reporting that value? Is it coming from some header value that doesn't match the length of the audio track?

Comment 5

[JW Wang [:jwwang] [:jw_wang]]

Hi Chris,
Per comment 0, do you have ideas about how media duration is calculated by the media backends?

Comment 6

[Chris Pearce [:cpearce (Not reading bugmail)]]

We use the media backends to calculate the duration. On OSX and Windows both use the MP4Reader, so they are more likely to get the same behaviour, whereas on Linux we use GStreamerReader as we don't have an MP4Reader backend there yet.

MP4Reader uses the duration from the MP4 container, the maximum of the length of the audio and video streams. [1]

I don't know how GStreamerReader does it, I don't know what version of the GStreamer code is being run here.

[1] http://mxr.mozilla.org/mozilla-central/source/media/libstagefright/binding/mp4_demuxer.cpp#142

Comment 7

[JW Wang [:jwwang] [:jw_wang]]

Since the duration is the maximum length of audio/video streams, the last audio sample of small-shot.m4a shouldn't be [256000,277333]. I will add more logs to confirm that.

Comment 8

[JW Wang [:jwwang] [:jw_wang]]

This is what I got on a B2G emulator:

Decoder=4028c590 Media goes from 0 to 298666 (duration 298666) transportSeekable=1, mediaSeekable=1
Decoder=4028c590 OnAudioDecoded [256000,277333] disc=0
Decoder=4028c590 OnAudioDecoded [277333,298666] disc=0

The last audio sample time matches the duration.

It looks like we have some problems in GStreamerReader.

Comment 9

[JW Wang [:jwwang] [:jw_wang]]

Hi Alessandro,

The reported duration of small-shot.m4a is 299000us while the timestamp of last audio sample is [256000,277333] on Linux with gstreamer. However, the last sample is [277333,298666] on B2G. Can you help check why there is one sample missing in Linux gstreamer? Thanks.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

With my modifications to test_streams_element_capture in bug 1200099 I'm seeing this same bug. Both small-shot.m4a and small-shot.mp3.mp4 are affected. I'm going to work around it in bug 1200099 by making test_streams_element_capture behave like test_streams_element_capture_reset.

Comment 11

[JW Wang [:jwwang] [:jw_wang]]

gstreamer is no longer supported.