Closed Bug 1054024 Opened 10 years ago Closed 10 years ago

Apple PDM media mochitest timeouts

Categories

(Core :: Audio/Video, defect)

Product:
Core
Component:
Audio/Video
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: rillian, Assigned: rillian)

References

Details

A number of media mochitests timeout with the Apple PlatformDecoderModule and media.fragmented-mp4.exposed true.

 content/media/test/test_autoplay_contentEditable.html | Test timed out.
 content/media/test/test_bug448534.html | Test timed out.
 content/media/test/test_bug465498.html | Test timed out.
 content/media/test/test_bug495145.html | Test timed out.
Assignee: nobody → giles
Blocks: 1043696
Could you please indicate exactly the steps to reproduce the issue ?

running:
./mach mochitest-plain content/media/test/test_autoplay_contentEditable.html

shows in the browser once loaded that all 28 tests passed.

And how do you know if the test succeeded or not ?
I think the issue with timeouts is whether the test exits correctly or not. Does you see a COMPLETED at the end? Or does it quit with a timeout five minutes later? At least that's the problem on the continuous integration server.

  https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=dd5e88f7a193
Or 10 minutes later.

11:39.67 TEST-UNEXPECTED-TIMEOUT | /tests/content/media/test/test_autoplay_contentEditable.html | application timed out after 330 seconds with no output
11:39.67 Failed to retrieve MOZ_UPLOAD_DIR env var
TEST-INFO | Main app process: killed by SIGTRAP
11:40.07 TEST-UNEXPECTED-FAIL | /tests/content/media/test/test_autoplay_contentEditable.html | application terminated with exit code 5
11:40.07 runtests.py | Application ran for: 0:11:34.856422
test_autoplay_contentEditable seems to be working with gizmo. The timeout happens because bogus.duh never fires any 'play' events, as might be expected. And indeed it times out on my local runs even without media.fragmented-mp4.exposed.

How does this test work anywhere?
(In reply to Ralph Giles (:rillian) from comment #4)
> test_autoplay_contentEditable seems to be working with gizmo. The timeout
> happens because bogus.duh never fires any 'play' events, as might be
> expected.

bogus.duh should not be played, as the code to start the test should check the mimetype and decide that "bogus/duh" isn't a supported mime type, and so not run that case. Is the canPlayType logic failing for the MP4Decoder?

> And indeed it times out on my local runs even without
> media.fragmented-mp4.exposed.
 
The test fails here on Windows too...

> How does this test work anywhere?

That's an interesting question indeed...
Ah, it's failing on Windows with MP4Reader being used due to small-shot-mp3.mp4 timing out, not anything else. MP4Reader on Windows does not yet support mp3 in mp4.
Thanks, I remembered about the canPlayType filter eventually. Can we add filtering based on codecs=mp3?
Yes. The MP4Reader/Decoder should only report that we can play MP3 if it can play MP3.
(In reply to Chris Pearce (:cpearce) from comment #5)
> bogus.duh should not be played, as the code to start the test should check
> the mimetype and decide that "bogus/duh" isn't a supported mime type, and so
> not run that case. Is the canPlayType logic failing for the MP4Decoder?

bogus/duh sees canPlayType properly returns CANPLAY_NO and so returns an empty string as it should

Is the js code even valid and properly handle what it should?
(In reply to Chris Pearce (:cpearce) from comment #8)
> Yes. The MP4Reader/Decoder should only report that we can play MP3 if it can
> play MP3.

and it does return CANPLAY_NO if fmp4 is disabled.
(In reply to Ralph Giles (:rillian) from comment #2)
> I think the issue with timeouts is whether the test exits correctly or not.
> Does you see a COMPLETED at the end? Or does it quit with a timeout five
> minutes later? At least that's the problem on the continuous integration
> server.
> 
>   https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=dd5e88f7a193

after running ./mach mochitest-plain, I see in the console once all tests have been running:
178 INFO TEST-OK | /tests/content/media/test/test_autoplay_contentEditable.html | took 23826ms
179 INFO TEST-START | Shutdown
180 INFO Passed:  28
181 INFO Failed:  0
182 INFO Todo:    0
183 INFO Slowest: 23827ms - /tests/content/media/test/test_autoplay_contentEditable.html
184 INFO SimpleTest FINISHED
185 INFO TEST-INFO | Ran 1 Loops
186 INFO SimpleTest FINISHED

and the main process never quits until I manually exit.

This is no different in behaviour as another mochi test:
1035 INFO TEST-OK | /tests/content/base/test/test_CrossSiteXHR.html | took 25291ms
1036 INFO TEST-START | Shutdown
1037 INFO Passed:  829
1038 INFO Failed:  0
1039 INFO Todo:    0
1040 INFO Slowest: 25290ms - /tests/content/base/test/test_CrossSiteXHR.html
1041 INFO SimpleTest FINISHED
1042 INFO TEST-INFO | Ran 1 Loops
1043 INFO SimpleTest FINISHED

so what exactly is failing ?
(In reply to Jean-Yves Avenard [:jya] from comment #11)
IIRC, our test runner will hang in shutdown when you run only one test. Do you still see this problem when you run a whole folder?
(In reply to JW Wang [:jwwang] from comment #12)
> (In reply to Jean-Yves Avenard [:jya] from comment #11)
> IIRC, our test runner will hang in shutdown when you run only one test. Do
> you still see this problem when you run a whole folder?

This is what I'm currently doing.

Could you please confirm which platform you're running the test against, and what command do you use to start the test?
./mach mochitest-plain content/media/test on Ubuntu to run the whole media test folder.
(In reply to JW Wang [:jwwang] from comment #14)
> ./mach mochitest-plain content/media/test on Ubuntu to run the whole media
> test folder.

thank you.

Using gstreamer or ffmpeg ? what compilation flags did you use?
my .mozconfig:

ac_add_options --enable-debug
ac_add_options --enable-debug-symbols
ac_add_options --disable-unified-compilation

I think it defaults to gstreamer 0.1. How do I turn on ffmpeg?
(In reply to JW Wang [:jwwang] from comment #16)
> my .mozconfig:
> 
> ac_add_options --enable-debug
> ac_add_options --enable-debug-symbols
> ac_add_options --disable-unified-compilation
> 
> I think it defaults to gstreamer 0.1. How do I turn on ffmpeg?

I thought that to enable gstream you had to add:
ac_add_options --enable-gstreamer

For FFmpeg
ac_add_options --enable-ffmpeg

but that would also require to enable fragmented mp4 which I believe is disable when running those tests
I enabled the MP4Reader on Windows, and ran test_bug495145. It timed out once. I noticed that the state machine would play a few frames, and then switch to BUFFERING state for several seconds, then play a bit more, etc. The WMFReader doesn't do that on my machine. This also happens when the MP4Reader is set to use the same naive buffered ranges implementation that WMFReader uses. So the cause of some of the timeouts could be related to this buffering behaviour somehow.
No timeouts on my latest try push. I'll give it another day and close if I can no longer reproduce.
This seems to be fixed.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.