Closed
Bug 957908
Opened 11 years ago
Closed 9 years ago
h.264/AAC video fails to play in nightly with GStreamer backend
Categories
(Core :: Audio/Video: Playback, defect, P5)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: kinetik, Unassigned)
References
()
Details
Attachments
(3 files)
The video served by YouTube in the bug URL fails to play in Firefox nightly with the GStreamer backend, but works in Chrome. Attached is a truncated file for local testing.
When the YouTube video is downloaded locally, it works in ffplay and mplayer, but Totem (which uses Gst) requested a bunch of codecs:
Jan 09 15:38:07 Installed: gstreamer1-libav-1.2.1-1.fc20.x86_64
Jan 09 15:38:07 Installed: gstreamer1-plugins-bad-freeworld-1.2.1-1.fc20.x86_64
Jan 09 15:38:07 Installed: gstreamer-plugin-crystalhd-3.10.0-6.fc20.x86_64
...after installing these it plays in Totem, but still fails in Firefox. One slightly unusual thing about the file is that the AAC track is the first track.
Debugging reveals that we're hung in GStreamerReader::ReadMetadata at:
message = gst_bus_timed_pop_filtered(mBus, GST_CLOCK_TIME_NONE,
(GstMessageType)(GST_MESSAGE_ASYNC_DONE | GST_MESSAGE_ERROR));
Debug log produced with env var GST_DEBUG=2 set also attached.
Reporter | ||
Comment 1•11 years ago
|
||
Comment 2•11 years ago
|
||
I can't repro this on Mac, neither with gstreamer 0.10 nor with gstreamer 1.0.
Comment 3•10 years ago
|
||
Works for me with Firefox 33, GStreamer 1.2.x, on Fedora 20.
Works fine for me with 39.0 but doesn't work on 41.0a2 (on the same computer, they both use GStreamer).
Updated•9 years ago
|
Component: Audio/Video → Audio/Video: Playback
I'm seeing this with the latest nightly of 20150925 and all videos on vimeo. When a video plays, sound begins, with no picture, then after a few seconds it all stops. Here is a link to a video that is failing right now. https://vimeo.com/140096021
I think this started a few days ago, after the major clobber that occurred. Firefox 41 works fine.
I haven't done any regression search, since each compile takes upward of an hour. I suppose I could run mozregression, to see if they also have the failure. After I complete this, I'll give them a go as they are relatively fast.
I will attach my .mozconfig, as it is custom. I tried both the default gstreamer and gstreamer 1.0, and both have the problem.
This is the mozconfig that I use to compile the nightly that is failing.
I just tried to run mozregression to determine which change caused the problem, but all the nightlies I tried worked fine with that video. So, this is some obscure bug caused by my custom configuration. Darn.
I just noticed that there is no system information. So this is on 64 bit linux, Fedora 21.
This is bizarre. I just tried again, and if I leave akamaihd turned off, the video usually plays normally. When akamaihd is on, it plays the sound, but never the video. I think that means there is some kind of issue with the video format that akamaihd is serving to firefox, but not with the format that comes directly from vimeo.com.
Not sure how anyone could debug and fix this. I guess I'll just have to wait and see if normal progress resolves this.
Updated•9 years ago
|
Priority: -- → P5
The latest version of nightly, from yesterday 20151009, fixes this. The videos on vimeo play properly again.
Thank you.
Comment 10•9 years ago
|
||
gstreamer is going in bug 1234092
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Comment 11•9 years ago
|
||
Thanks for the heads up.
You need to log in
before you can comment on or make changes to this bug.
Description
•