1180214 - Wrong video duration when using GStreamer0.10

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[Marco Castelluccio [:marco]]

At the beginning, the duration is correct (40 seconds), while playing it gets bigger.

I've seen the same behavior on other videos as well (not only Facebook ones).

Comment 1

[Marco Castelluccio [:marco]]

Attachment: 11424936_1460675567288831_593511664_n.mp4

Comment 2

[Matthew Turnbull [Bluefang]]

I can confirm this. I see this happening on YouTube

https://www.youtube.com/watch?v=ks8PZ8X6Yo8

This video is 2:26, but once the video has finished loading, Firefox says it's over 14 (the exact length seems to vary between repeat views).

This also messes with the seek bar, as it reflects the incorrect video length. If you seek beyond the real length of the video, the player seems to break and you have to reload the page.

Comment 3

[Marco Castelluccio [:marco]]

I can't reproduce with this Ogg video: http://mirrorblender.top-ix.org/peach/bigbuckbunny_movies/big_buck_bunny_1080p_stereo.ogg

Comment 4

[Marco Castelluccio [:marco]]

Nightly regression window: [2015-06-28, 2015-06-29]
Last good revision: eaf4f9b45117
First bad revision: c26dbd63604d

Comment 5

[Marco Castelluccio [:marco]]

I've narrowed it down to: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=28e6664ad1a1&tochange=9fb9dbd7a0dd

Comment 6

[Bobby Holley (:bholley)]

Jean-Yves, does this look related to the other regressions from that landing?

Comment 7

[Jean-Yves Avenard [:jya]]

I can't reproduce it here, on either 41 or Nightly.

The video appears to be 40s long and plays for 40s. when it ends, the seek bar shows 40s.

>> document.getElementsByTagName("video")[0].duration
39.938321

seems all good to me.

Do you still still the problem?

Comment 8

[Matthew Turnbull [Bluefang]]

Yes, I can still reproduce it - with the attached video.

42.0a1 build 20150712030212 Linux x86_64 broken
41.0a2 build 20150712004007 Linux x86_64 broken
40.0b- build 20150709163524 Linux x86_64 working

>> document.getElementsByTagName("video")[0].duration
441.444

Comment 9

[Jean-Yves Avenard [:jya]]

Do you use gstreamer or the build-in mp4 reader with ffmpeg ?

Comment 10

[Jean-Yves Avenard [:jya]]

Marco are you too using linux ?

Comment 11

[Matthew Turnbull [Bluefang]]

My Firefox is linking to gstreamer 0.10.36

If I set:

media.gstreamer.enabled;false
media.fragmented-mp4.exposed;true
media.fragmented-mp4.ffmpeg.enabled;true

Then the attached MP4 file plays correctly. If either of the fragmented-mp4 preferences are false, then I am prompted to download the file instead of seeing the HTML5 player.

Comment 12

[Marco Castelluccio [:marco]]

I can still reproduce the problem. I'm on Linux.

Comment 13

[Jean-Yves Avenard [:jya]]

I can't reproduce it using either gstreamer (v1.2.4 nor 0.10.36) nor fmp4/ffmpeg

Matthew, what exactly are you setting to reproduce the problem?
what gstreamer backend are you using ? the ffmpeg/libav one ?

I have media.gstreamer.enabled;true
all other mp4 settings (fmp4 etc) set to false.

Comment 14

[Jean-Yves Avenard [:jya]]

By can't reproduce, I mean I play that weird video. Duration is set at 40 and it appears as 40 during the entire time. And after 40s playback stops.

can't see anything wrong there

Comment 15

[Matthew Turnbull [Bluefang]]

I am able to reproduce with a new profile - all of the prefs are default.

These are the gstreamer/ffmpeg packages I have installed in Gentoo.

media-libs/gstreamer-0.10.36-r2
media-libs/gst-plugins-base-0.10.36-r2
media-libs/gst-plugins-good-0.10.31-r1
media-plugins/gst-plugins-ffmpeg-0.10.13_p201211-r4
media-video/ffmpeg-2.7.1

Comment 16

[Jean-Yves Avenard [:jya]]

are you using with e10s pref on ?

Comment 17

[Jean-Yves Avenard [:jya]]

Just to be sure, you are using the mp4 attached to this bug?

I now have exactly the same version of all components, and I can't reproduce it with my local build.

Comment 18

[Jean-Yves Avenard [:jya]]

Also downloaded today's nightly ; works fine too.
document.getElementsByTagName("video")[0].duration
39.937

Comment 19

[Matthew Turnbull [Bluefang]]

Attachment: Firefox 42.0a1 (2015-07-17) profile

$ mkdir /tmp/profile
$ firefox -no-remote -profile /tmp/profile "https://bugzilla.mozilla.org/attachment.cgi?id=8629375"
$ cd /tmp/
$ tar -czf profile.tar.gz profile

This is a brand new profile that exhibits the issue. No preferences have been changed other than those which are changed by Firefox starting the first time.

I see the broken behavior with e10s both enabled and disabled.

Is there any verbose/debug logging I can enable which would be useful?
Would the output of "gst-inspect-0.10 -a" be useful?
Is there a version of Firefox that works with gstreamer 1.0+?

Comment 20

[Matthew Turnbull [Bluefang]]

Attachment: Video demonstrating the broken behavior.

Video demonstrating the broken behavior on my system. This includes a hard refresh to show the increasing length as the video re-downloads.

Comment 21

[Matthew Turnbull [Bluefang]]

Sorry for the bug-spam, but I have one more observation - I can only reproduce this broken behavior if the is viewed over http[s]://. If I download the file and open it via file:// then it has the correct length.

Comment 23

[Marco Castelluccio [:marco]]

According to bug 1180884 comment 1 this affects Aurora as well.

Comment 25

[Jean-Yves Avenard [:jya]]

The regression that was introduced in https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=28e6664ad1a1&tochange=9fb9dbd7a0dd will be fixed in bug 1190238.

The actual bug tracking it is: bug 1186804

Comment 26

[Jean-Yves Avenard [:jya]]

note that I've never managed to reproduce the issue myself.

But I can see that the duplicate calls to NotifyDataArrived due to how MediaResource::SilentReadAt seeks twice could have an effect on invalid duration with some readers like the MP3 or OggReader

Comment 30

[u532768]

Anthony asked me to do a mozregression to narrow when this problem began for me (problem described in 1190829).  This is the result.

60:45.97 LOG: MainThread Bisector INFO Narrowed inbound regression window from [ac30d791, 9fb9dbd7] (3 revisions) to [28e6664a, 9fb9dbd7] (2 revisions) (~1 steps left)
60:45.97 LOG: MainThread Bisector INFO Oh noes, no (more) inbound revisions :(
60:45.97 LOG: MainThread Bisector INFO Last good revision: 28e6664ad1a1
60:45.97 LOG: MainThread Bisector INFO First bad revision: 9fb9dbd7a0dd
60:45.97 LOG: MainThread Bisector INFO Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=28e6664ad1a1&tochange=9fb9dbd7a0dd

Comment 31

[u532768]

So I've confirmed the previous results.  And this bug is already being fixed.  Hooray!

Comment 32

[Jean-Yves Avenard [:jya]]

Could you try again with this build http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-linux64/1439508759/ 

(this is from central, right now)

Comment 33

[u532768]

Sorry for the delay.  I just noticed the email from your response.  I downloaded http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-linux64/1439508759/firefox-43.0a1.en-US.linux-x86_64.tar.bz2, unpacked it, and ran the included firefox.  The problem was still there.

Comment 34

[u532768]

I'm running 43.0a1 (2015-08-14).  And it seems to work just fine on older videos on Vimeo.  But still exhibits the problem intermittently on newer videos.  How can that be?  Is there some difference in encoding or playback method that could cause this?  Has the standard changed in some subtle way?

Anyway, this video shows the problem - https://vimeo.com/136237174
As does this one - https://vimeo.com/134533311

And this one doesn't - https://vimeo.com/108587459
Nor does this one - https://vimeo.com/134531989

I'm not privy to the internal workings of vimeo, so I don't know what the difference between them is.

Comment 35

[Jean-Yves Avenard [:jya]]

But are you having the problem with the video attached to this bug?

Comment 36

[u532768]

I'm running 43.0a1 (2015-08-14).  And it seems to work just fine on older videos on Vimeo.  But still exhibits the problem intermittently on newer videos.  How can that be?  Is there some difference in encoding or playback method that could cause this?  Has the standard changed in some subtle way?

Anyway, this video shows the problem - https://vimeo.com/136237174
As does this one - https://vimeo.com/134533311

And this one doesn't - https://vimeo.com/108587459
Nor does this one - https://vimeo.com/134531989

I'm not privy to the internal workings of vimeo, so I don't know what the difference between them is.

Comment 37

[u532768]

Sorry about the duplicate.  There was some kind of collision.

Anyway, I can play the videos attached to this bug with no problem using the latest firefox nightly. 43.0a1 (2015-08-14)

I've checked vimeo, and the problem seems to start there sometime between 1 month and 2 months ago.  The time they display isn't more precise than that.  Older than that, all videos I sampled play fine.

Comment 38

[CommodoreFabianus]

I'm at the moment use the nightly from August 14th and I don't see the problem on vimeo like I do on YouTube. But the video in the attachment shows the same behaviour as YouTube videos showing an increasing duration. Unfortunately I don't know whether that nightly contains the fix you wanted us to try.

Comment 39

[u532768]

I might have been a little premature in saying that the video plays properly.  It does play properly if I allow it to play without any interference.  But if I click to move the play position, the video stops, and a message comes up saying "video can't be played because the file is corrupt".  I then have to refresh the page in order to get the video to play from the beginning again.

Comment 40

[Matthew Turnbull [Bluefang]]

I still see broken behavior on all of the attached and linked MP4 videos.

(In reply to stan from comment #36)
> Anyway, this video shows the problem - https://vimeo.com/136237174
> As does this one - https://vimeo.com/134533311
> 
> And this one doesn't - https://vimeo.com/108587459
> Nor does this one - https://vimeo.com/134531989

I can reproduce the problem with all of these videos. It's noteworthy that the vimeo player UI does show the correct duration and seek position when hovered. However, if you actually try seeking, things get broken. And if you directly open the vimeo video streams, they're all MP4s that illustrate the issue.

Comment 41

[u532768]

It's strange that we would see such different behavior.

On the good streams, I can click the position wherever I want it.  It's like the production firefox player.

And on the bad streams, if I click in the position bar, the play starts over, except this time everything is correct, and it is like the production firefox player.

And every old video (> 2 months) I've played on vimeo works correctly.

Is it possible that there is a commonly used program that had a recent release, and is now encoding videos incorrectly?

What do you mean by 'directly open the vimeo video streams', and how would I do it?

Comment 42

[u532768]

With the nightly from the 15th, these videos at youtube play without problem.

https://www.youtube.com/watch?v=KckZfTrj9gg
https://www.youtube.com/watch?v=Eo7cRJ03qw8

They are both old, though.

All these new videos at youtube exhibit the problem.  And it really screws things up.  I suddenly find myself watching a video I didn't select (I have autoplay turned off) when I click on the time track.  Or, I select a new video to play, and the old one doesn't go away.

https://www.youtube.com/watch?v=bha24P9uw-E

https://www.youtube.com/watch?v=KJtaIqahi3I&index=83&list=PLrEnWoR732-BHrPp_Pm8_VleD68f9s14-

https://www.youtube.com/watch?v=rdlJYpzS1qA

Anyway, just more evidence that this isn't only because of firefox, but that there has been some recent change in video encoding.

Maybe people with more knowledge than me can give another explanation for why this occurs.

Comment 43

[shrek0]

I see the problem only with GStreamer 0.10. With GStreamer 1 (--enable-gstreamer=1.0), everything work fine.

Can someone confirm?

Comment 44

[Matthew Turnbull [Bluefang]]

(In reply to stan from comment #42)
> https://www.youtube.com/watch?v=KckZfTrj9gg
> https://www.youtube.com/watch?v=Eo7cRJ03qw8
> https://www.youtube.com/watch?v=bha24P9uw-E
> https://www.youtube.com/watch?v=KJtaIqahi3I
> https://www.youtube.com/watch?v=rdlJYpzS1qA
> 
> Anyway, just more evidence that this isn't only because of firefox, but that
> there has been some recent change in video encoding.

I can reproduce the issue with all of these videos, so all that really illustrates is that we have some difference at the system level that is impacting Firefox differently.

But given that we are all seeing the same Firefox regression range, irrespective of system differences, this definitely seems like a Firefox issue to me.

Comment 45

[u532768]

To shrek0, I can confirm.  I compiled yesterday's nightly with the change to version 1.0 of GStreamer in my .mozconfig, and the videos that didn't play correctly before, now all play correctly.

Thank you, I'll use this as my workaround.

And Matthew Turnbull, given that changing to GStreamer 1.0 fixed the issue for me, I half agree.  There must be incompatibilities between .1 and 1 of GStreamer.  It seems that websites dropped support for .1 recently, and firefox needs to catch up to that change.  It's my theory for explaining why old videos worked with .1 in firefox, but new videos don't.  But I'm no expert, just trying to make sense of the evidence I have, so my theory could be completely wrong.

Comment 46

[Matthew Turnbull [Bluefang]]

(In reply to stan from comment #45)
> And Matthew Turnbull, given that changing to GStreamer 1.0 fixed the issue
> for me, I half agree.  There must be incompatibilities between .1 and 1 of
> GStreamer.  It seems that websites dropped support for .1 recently, and
> firefox needs to catch up to that change.  It's my theory for explaining why
> old videos worked with .1 in firefox, but new videos don't.  But I'm no
> expert, just trying to make sense of the evidence I have, so my theory could
> be completely wrong.

Sorry, but what I meant is that with the exact same versions of gstreamer 0.10, gst-plugins-ffmpeg, and ffmpeg, ALL of the videos in this thread play correctly for me with mozilla-central eaf4f9b45117 and are broken for me with mozilla-central c26dbd63604d.

To me, that says it has absolutely nothing to do with how the videos are encoded. What it does say is that we have different system libraries, which are presenting the regression in Firefox under different conditions, which is not at all surprising. For example, we could have different versions of ffmpeg/libav.

How this regression is fixed is a completely different issue. gstreamer 0.10 support could be fixed, or it could be dropped completely in favor of gstreamer 1.x. I honestly don't care, as I have both installed. Likewise, the internal fragmented-mp4 ffmpeg support could be enabled, since that seems to work as well.


Also, are there Firefox builds with gstreamer 1.0 support anywhere? I'd be happy to test it out, but I'm not set-up to build Firefox at the moment.

Comment 47

[u532768]

"are there Firefox builds with gstreamer 1.0 support anywhere?"

Sorry, can't help you with that.  There seem to be people more knowledgeable than me involved with this ticket (including you), so they probably can.

Comment 48

[Jean-Yves Avenard [:jya]]

I may have missed fixing something with 0.10. 

What's good to know is that builds from August 15th do fix something

Comment 49

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

These are build with gstreamer-1.0 https://launchpad.net/~ubuntu-mozilla-daily/+archive/ubuntu/ppa . I don't know what is available for other distros. You could repackage it with Alien https://en.wikipedia.org/wiki/Alien_%28software%29

Comment 50

[Jean-Yves Avenard [:jya]]

There is fundamentally nothing in the Firefox code that could explain a difference between gstreamer 0.10 and 1.x.
The code that had a problem is common between the two gstreamer interface. And this is what you find in nightly after August 15th.

My guess would be that the gstreamer ffmpeg/libav plugin in 0.10 is buggy. Try to see if you can get a newer build.

I can't reproduce it with either 0.10 or 1.0 on my Ubuntu 14.04 VM (and I use ffmpeg plugin from this repository sudo apt-add-repository ppa:mc3man/trusty-media as the default one didn't work)

Comment 51

[Marco Castelluccio [:marco]]

(In reply to Jean-Yves Avenard [:jya] from comment #50)
> There is fundamentally nothing in the Firefox code that could explain a
> difference between gstreamer 0.10 and 1.x.
> The code that had a problem is common between the two gstreamer interface.
> And this is what you find in nightly after August 15th.
> 
> My guess would be that the gstreamer ffmpeg/libav plugin in 0.10 is buggy.
> Try to see if you can get a newer build.
> 
> I can't reproduce it with either 0.10 or 1.0 on my Ubuntu 14.04 VM (and I
> use ffmpeg plugin from this repository sudo apt-add-repository
> ppa:mc3man/trusty-media as the default one didn't work)

Even if it's a bug in GStreamer 0.10, since we have a regression range it should
be possible to find a workaround (if it was working fine before, then there's a
way to make it work).

If we can't find it or don't want to spend time finding it, then we should at least
make GStreamer 1.0 the default (bug 947287).

Comment 52

[Jean-Yves Avenard [:jya]]

can't reproduce it here with gstreamer 0.10..

are you sure you didn't upgrade something in the meantime that could have broken your 0.10 install?

Comment 53

[Marco Castelluccio [:marco]]

(In reply to Jean-Yves Avenard [:jya] from comment #52)
> can't reproduce it here with gstreamer 0.10..
> 
> are you sure you didn't upgrade something in the meantime that could have
> broken your 0.10 install?

Seems unlikely to me, since there are many people who can reproduce on different
Linux distributions (I've seen Fedora 21-22, Gentoo, Debian in this and duplicate
bugs) and since we can use GStreamer0.10 with an older Firefox revision.
I've also tried uninstalling it and reinstalling it to make sure, no luck.

These are the GStreamer packages that I've installed:
> gstreamer-tools-0.10.36-11.fc22.x86_64
> gstreamer-0.10.36-11.fc22.x86_64
> gstreamer-plugins-base-0.10.36-12.fc22.x86_64
> gstreamer-devel-0.10.36-11.fc22.x86_64
> gstreamer-plugins-base-devel-0.10.36-12.fc22.x86_64
> gstreamer-ffmpeg-0.10.13-15.fc22.x86_64
> gstreamer-plugins-ugly-0.10.19-18.fc22.x86_64
> gstreamer-plugins-bad-free-0.10.23-24.fc22.x86_64
> gstreamer-plugins-good-0.10.31-13.fc22.x86_64
> gstreamer-plugins-espeak-0.4.0-5.fc22.x86_64

Maybe you could try reproducing on Fedora 22 with these packages installed.

Comment 54

[Jean-Yves Avenard [:jya]]

(In reply to Marco Castelluccio [:marco] from comment #53)
> Seems unlikely to me, since there are many people who can reproduce on
> different
> Linux distributions (I've seen Fedora 21-22, Gentoo, Debian in this and
> duplicate

sure, but all before the fix went in August 15th.

so far, every bug gstreamer related have been reported as fixed.

> 
> These are the GStreamer packages that I've installed:
> > gstreamer-tools-0.10.36-11.fc22.x86_64
> > gstreamer-0.10.36-11.fc22.x86_64
> > gstreamer-plugins-base-0.10.36-12.fc22.x86_64
> > gstreamer-devel-0.10.36-11.fc22.x86_64
> > gstreamer-plugins-base-devel-0.10.36-12.fc22.x86_64
> > gstreamer-ffmpeg-0.10.13-15.fc22.x86_64
> > gstreamer-plugins-ugly-0.10.19-18.fc22.x86_64
> > gstreamer-plugins-bad-free-0.10.23-24.fc22.x86_64
> > gstreamer-plugins-good-0.10.31-13.fc22.x86_64
> > gstreamer-plugins-espeak-0.4.0-5.fc22.x86_64
> 
> Maybe you could try reproducing on Fedora 22 with these packages installed.

going to download a VM and try

Comment 55

[Marco Castelluccio [:marco]]

(In reply to Jean-Yves Avenard [:jya] from comment #54)
> (In reply to Marco Castelluccio [:marco] from comment #53)
> > Seems unlikely to me, since there are many people who can reproduce on
> > different
> > Linux distributions (I've seen Fedora 21-22, Gentoo, Debian in this and
> > duplicate
> 
> sure, but all before the fix went in August 15th.
> 
> so far, every bug gstreamer related have been reported as fixed.

Bugs with GStreamer0.10?
stan and shrek0 in this bug have reported they don't see the bug anymore
with GStreamer1.0, but they do see it with GStreamer0.10.

Comment 56

[Jean-Yves Avenard [:jya]]

this is highly frustrating.

installed fedora 22.
Installer rpm fusion repository for the ffmpeg plugin

here are the packages installed:
gstreamer.x86_64                              0.10.36-11.fc22            @System
gstreamer-devel.x86_64                        0.10.36-11.fc22            @System
gstreamer-ffmpeg.x86_64                       0.10.13-15.fc22            @System
gstreamer-plugins-bad.x86_64                  0.10.23-7.fc22             @System
gstreamer-plugins-bad-free.x86_64             0.10.23-24.fc22            @System
gstreamer-plugins-base.x86_64                 0.10.36-12.fc22            @System
gstreamer-plugins-base-devel.x86_64           0.10.36-12.fc22            @System
gstreamer-plugins-espeak.x86_64               0.4.0-5.fc22               @System
gstreamer-plugins-good.x86_64                 0.10.31-13.fc22            @System
gstreamer-plugins-ugly.x86_64                 0.10.19-18.fc22            @System
gstreamer-tools.x86_64                        0.10.36-11.fc22            @System
gstreamer1.x86_64                             1.4.5-1.fc22               @System
gstreamer1-plugins-bad-free.x86_64            1.4.5-3.fc22               @System
gstreamer1-plugins-base.x86_64                1.4.5-2.fc22               @System
gstreamer1-plugins-good.x86_64                1.4.5-3.fc22               @System


Installed nightly 64 bits from mozilla website.

Played the video attached above:
video shows as 40s and doesn't grow.

what more can I try to reproduce it ?

Comment 57

[Marco Castelluccio [:marco]]

(In reply to Jean-Yves Avenard [:jya] from comment #56)
> gstreamer.x86_64                              0.10.36-11.fc22
> gstreamer-devel.x86_64                        0.10.36-11.fc22
> gstreamer-ffmpeg.x86_64                       0.10.13-15.fc22
> gstreamer-plugins-bad.x86_64                  0.10.23-7.fc22
> gstreamer-plugins-bad-free.x86_64             0.10.23-24.fc22
> gstreamer-plugins-base.x86_64                 0.10.36-12.fc22
> gstreamer-plugins-base-devel.x86_64           0.10.36-12.fc22
> gstreamer-plugins-espeak.x86_64               0.4.0-5.fc22
> gstreamer-plugins-good.x86_64                 0.10.31-13.fc22
> gstreamer-plugins-ugly.x86_64                 0.10.19-18.fc22
> gstreamer-tools.x86_64                        0.10.36-11.fc22
> gstreamer1.x86_64                             1.4.5-1.fc22
> gstreamer1-plugins-bad-free.x86_64            1.4.5-3.fc22
> gstreamer1-plugins-base.x86_64                1.4.5-2.fc22
> gstreamer1-plugins-good.x86_64                1.4.5-3.fc22

I didn't have gstreamer-plugins-bad, I've installed it now.
I can't reproduce the bug anymore with the video I attached originally.
It's very weird, since it doesn't seem to contain files related to h264:
/usr/lib64/gstreamer-0.10/libgstdtsdec.so
/usr/lib64/gstreamer-0.10/libgstdvdspu.so
/usr/lib64/gstreamer-0.10/libgstfaad.so
/usr/lib64/gstreamer-0.10/libgstmimic.so
/usr/lib64/gstreamer-0.10/libgstmms.so
/usr/lib64/gstreamer-0.10/libgstmpeg2enc.so
/usr/lib64/gstreamer-0.10/libgstmplex.so
/usr/lib64/gstreamer-0.10/libgstreal.so
/usr/lib64/gstreamer-0.10/libgstrtmp.so
/usr/lib64/gstreamer-0.10/libgstsiren.so
/usr/lib64/gstreamer-0.10/libgstvoamrwbenc.so
/usr/lib64/gstreamer-0.10/libgstxvid.so

I can still reproduce the bug with the video by Matthew (https://bug1180214.bmoattachments.org/attachment.cgi?id=8635653), it's 22 seconds long but Firefox reports 27 seconds.

I can also reproduce the issue intermittently on http://www.quirksmode.org/html5/videos/big_buck_bunny.mp4 (real duration is 1:00, Firefox sometimes reports 1:02. If you play it all and then try to seek Firefox says "Video can't be played because the file is corrupt.") and always with https://twitter.com/MythBusters/status/629751996359118848 (real duration 1:17, when you get to the end it grows to 1:47).

Comment 58

[Jean-Yves Avenard [:jya]]

the video has an aac stream ; it could use faad to decode it in place of ffmpeg (which may be using its own aac decoder (you can build ffmpeg to use ffad)). I do not know how gstreamer decides which plugin its going to use over another.

Wrong duration is one thing, duration increasing as playback goes is another and is the one, the fix that went on august 15th should have fixed.
I've looked over and over the firefox gstreamer code and I can't see anything that could explain that behaviour.

Comment 59

[u532768]

It's got to be frustrating.  People reporting a bug that you cannot reproduce.  Are we all imagining it?  Pulling your leg?  Spoiling your summer?  :-)  Thanks for being so diligent.

Using the gstreamer=1.0 build of nightly from august 15th, the attached video shows constant duration, and I can click to any point in the video without problem.  I'll build today's nightly (17th), when it is refreshed, with the .10 version and see if it still has the issue with the attached video.  I think the version from the 15th did, but I've done so many tests now I'm getting forgetful.

Anyhow, here are all the gstreamer related packages I have installed:

gstreamer-0.10.36-11.fc21.x86_64
gstreamer1-1.4.5-1.fc21.x86_64
gstreamer1-devel-1.4.5-1.fc21.x86_64
gstreamer1-devel-docs-1.4.5-1.fc21.noarch
gstreamer1-libav-1.4.5-1.fc21.x86_64
gstreamer1-plugins-bad-free-1.4.5-3.fc21.x86_64
gstreamer1-plugins-bad-free-devel-1.4.5-3.fc21.x86_64
gstreamer1-plugins-bad-free-extras-1.4.5-3.fc21.x86_64
gstreamer1-plugins-base-1.4.5-1.fc21.x86_64
gstreamer1-plugins-base-devel-1.4.5-1.fc21.x86_64
gstreamer1-plugins-base-devel-docs-1.4.5-1.fc21.noarch
gstreamer1-plugins-base-tools-1.4.5-1.fc21.x86_64
gstreamer1-plugins-entrans-docs-1.0.2-3.fc21.noarch
gstreamer1-plugins-fc-0.2-10.fc21.x86_64
gstreamer1-plugins-good-1.4.5-3.fc21.x86_64
gstreamer1-plugins-good-extras-1.4.5-3.fc21.x86_64
gstreamer1-plugins-ugly-1.4.5-1.fc21.x86_64
gstreamer1-plugins-ugly-devel-docs-1.4.5-1.fc21.noarch
gstreamer1-vaapi-0.5.10-2.fc21.x86_64
gstreamer1-vaapi-devel-0.5.10-2.fc21.x86_64
gstreamer-devel-0.10.36-11.fc21.x86_64
gstreamer-ffmpeg-0.10.13-15.fc21.x86_64
gstreamermm-0.10.11-5.fc21.x86_64
gstreamermm-devel-0.10.11-5.fc21.x86_64
gstreamer-plugins-bad-free-0.10.23-24.fc21.x86_64
gstreamer-plugins-bad-free-devel-0.10.23-24.fc21.x86_64
gstreamer-plugins-bad-free-devel-docs-0.10.23-24.fc21.x86_64
gstreamer-plugins-bad-nonfree-0.10.23-3.fc21.x86_64
gstreamer-plugins-base-0.10.36-12.fc21.x86_64
gstreamer-plugins-base-devel-0.10.36-12.fc21.x86_64
gstreamer-plugins-base-devel-docs-0.10.36-12.fc21.noarch
gstreamer-plugins-base-tools-0.10.36-12.fc21.x86_64
gstreamer-plugins-espeak-0.4.0-5.fc21.x86_64
gstreamer-plugins-fc-0.2-10.fc21.x86_64
gstreamer-plugins-good-0.10.31-13.fc21.x86_64
gstreamer-plugins-good-devel-docs-0.10.31-13.fc21.noarch
gstreamer-plugins-good-extras-0.10.31-13.fc21.x86_64
gstreamer-plugins-ugly-0.10.19-18.fc21.x86_64
gstreamer-plugins-ugly-devel-docs-0.10.19-18.fc21.noarch
gstreamer-python-0.10.22-7.fc21.x86_64
gstreamer-python-devel-0.10.22-7.fc21.x86_64
gstreamer-rtsp-0.10.8-9.fc21.x86_64
gstreamer-tools-0.10.36-11.fc21.x86_64
libnice-gstreamer1-0.1.7-1.fc21.x86_64
PackageKit-gstreamer-plugin-1.0.6-1.fc21.x86_64
perl-GStreamer-0.19-3.fc21.x86_64
perl-GStreamer-Interfaces-0.06-7.fc21.x86_64
phonon-backend-gstreamer-4.8.2-3.fc21.x86_64
python3-gstreamer1-1.4.0-1.fc21.x86_64
python-gstreamer1-1.4.0-1.fc21.x86_64
qt-gstreamer-1.2.0-2.fc21.x86_64
rubygem-gstreamer-2.2.5-1.fc21.x86_64

And all ffmpeg packages:
ffmpeg-2.4.10-1.fc21.x86_64
ffmpeg-compat-0.6.7-8.fc21.x86_64
ffmpeg-devel-2.4.10-1.fc21.x86_64
ffmpeg-libs-2.4.10-1.fc21.x86_64
gallery2-ffmpeg-2.3.2-11.fc21.noarch
gstreamer-ffmpeg-0.10.13-15.fc21.x86_64

I've noticed with audacity that the ffmpeg devs don't really maintain backward compatibility with changes.  I build audacity using the version of ffmpeg that comes in their svn repository, or the build usually fails.  Not always, but often enough that I don't try using the system version.  And the same happens with mplayer.  Their build pulls in the latest ffmpeg from the ffmpeg repository, and sometimes this causes the mplayer build to fail.  Perhaps that is in play here?  By fail I mean that variables or functions that are used aren't found.  They've either been added or removed between commits.  I'm just saying, not knocking, it's a choice I think they've made, to prioritize fast development above backward compatibility.

Comment 60

[Jean-Yves Avenard [:jya]]

I've found the 27s vs 22s .. This does revert a change made in the regression window provided above.

I don't think it will have an impact on the duration changing over time though

Comment 61

[u532768]

I do know that the august 15th build of nightly with gstreamer=.10 had the growing duration problem with some videos I played on the web.  I included links to some of them above.

Comment 62

[Jean-Yves Avenard [:jya]]

Attachment: Don't attempt to estimate duration until read metadata complete

Comment 63

[Jean-Yves Avenard [:jya]]

Well, this if it works for you with this build:

thanks for your patience here (and for testing !)

https://treeherder.mozilla.org/#/jobs?repo=try&revision=87580b86bdd2

Comment 64

[Jean-Yves Avenard [:jya]]

I could see how it could have a difference between gstreamer 0.10 and 1.0 now.

The state machine queries gstreamer for metadata ; which it can't decode until it reads the video toward the end (which contains the moov atom).

So gstreamer starts to download, which causes the buffered ranges to be updated. Previously, if we didn't have a duration it would return 0 but with the change in bug 1175768 it would instead attempts to estimate the duration from the size already downloaded, which is always going to be inaccurate.
The duration estimation from the size is different between gstreamer 1.0 and 0.10. 1.0 has an API exactly for that, but not 0.10.

I think the code is still wrong and the problem could still be triggered with very long video but until someone complain :)

Comment 65

[Jean-Yves Avenard [:jya]]

Attachment: P2. Returns empty interval until we have a start time.

Comment 66

[Jean-Yves Avenard [:jya]]

(In reply to Marco Castelluccio [:marco] from comment #57)
> (In reply to Jean-Yves Avenard [:jya] from comment #56)
> > gstreamer.x86_64                              0.10.36-11.fc22
> > gstreamer-devel.x86_64                        0.10.36-11.fc22
> > gstreamer-ffmpeg.x86_64                       0.10.13-15.fc22
> > gstreamer-plugins-bad.x86_64                  0.10.23-7.fc22
> > gstreamer-plugins-bad-free.x86_64             0.10.23-24.fc22
> > gstreamer-plugins-base.x86_64                 0.10.36-12.fc22
> > gstreamer-plugins-base-devel.x86_64           0.10.36-12.fc22
> > gstreamer-plugins-espeak.x86_64               0.4.0-5.fc22
> > gstreamer-plugins-good.x86_64                 0.10.31-13.fc22
> > gstreamer-plugins-ugly.x86_64                 0.10.19-18.fc22
> > gstreamer-tools.x86_64                        0.10.36-11.fc22
> > gstreamer1.x86_64                             1.4.5-1.fc22
> > gstreamer1-plugins-bad-free.x86_64            1.4.5-3.fc22
> > gstreamer1-plugins-base.x86_64                1.4.5-2.fc22
> > gstreamer1-plugins-good.x86_64                1.4.5-3.fc22
> 
> I didn't have gstreamer-plugins-bad, I've installed it now.
> I can't reproduce the bug anymore with the video I attached originally.
> It's very weird, since it doesn't seem to contain files related to h264:
> /usr/lib64/gstreamer-0.10/libgstdtsdec.so
> /usr/lib64/gstreamer-0.10/libgstdvdspu.so
> /usr/lib64/gstreamer-0.10/libgstfaad.so
> /usr/lib64/gstreamer-0.10/libgstmimic.so
> /usr/lib64/gstreamer-0.10/libgstmms.so
> /usr/lib64/gstreamer-0.10/libgstmpeg2enc.so
> /usr/lib64/gstreamer-0.10/libgstmplex.so
> /usr/lib64/gstreamer-0.10/libgstreal.so
> /usr/lib64/gstreamer-0.10/libgstrtmp.so
> /usr/lib64/gstreamer-0.10/libgstsiren.so
> /usr/lib64/gstreamer-0.10/libgstvoamrwbenc.so
> /usr/lib64/gstreamer-0.10/libgstxvid.so
> 

Yeah !

I can reproduce the bug by removing gstreamer-plugins-bad...

and can confirm that patch #1 fixes the problem.

P2 fixes bug referred in comment 64

Comment 67

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/4a8f9dc938e0
https://hg.mozilla.org/integration/mozilla-inbound/rev/2708af088758

Comment 68

[u532768]

I built nightly from the 17th with the default gstreamer (no version specification).  This doesn't have the problem on the attached video.  And the youtube videos work properly as well.  The only failures were

http://mirrorblender.top-ix.org/peach/bigbuckbunny_movies/big_buck_bunny_1080p_stereo.ogg which locked up after 10 seconds

https://vimeo.com/136237174  which restarted when I clicked to move the position, though the time was correct

https://vimeo.com/134533311  which had the expanding time problem.  Eventually, after clicking enough times in the position, it restarted and was correct in play and duration.

Is the change in on the 17th, or will it not hit till tomorrow?

I'm going back to using the gstreamer=1.0 as it had no problems.

Comment 69

[Jean-Yves Avenard [:jya]]

it hasn't hit central yet.
Tomorrow's is the best case scenario.

Ogg isn't using gstreamer so you may have found another bug.

Comment 70

[Matthew Turnbull [Bluefang]]

Thanks for your persistence in working on this. It's appreciated!

I tried the latest mozilla-inbound hourly build, and that did not fix the issue for me. Unless I'm mistaken, it should contain the two patches.

http://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-linux64/1439860168/

Built from https://hg.mozilla.org/integration/mozilla-inbound/rev/0fc1b3aba102358fe1ac3af8faf6c81faf1ea70d

At the very least, I can confirm that installing gst-plugins-faad (gst-plugins-bad) did "fix" the issue. So that's something I suppose :)

Comment 71

[Jean-Yves Avenard [:jya]]

I'm fairly certain the fix is good :)

certainly fixes for me... without the patch I get the duration to change to 7 minutes +

with it I get 40s...

Did you try the build I had made last night ?
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-87580b86bdd2/try-linux64/

this is made from central with just the first patch.

going to rebuild from inbound again and try again.

Comment 72

[Jean-Yves Avenard [:jya]]

hmmmm you're right... wtf..

Comment 73

[Jean-Yves Avenard [:jya]]

oh I see..

if the video is cached in memory, then it doesn't happen. Clear the cache and it occurs.

I'm now convinced that the bug is in gstreamer and has always been there, the change of timing due to bug 1175768 has just revealed it.

Comment 74

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

(In reply to Matthew Turnbull [Bluefang] from comment #70)
> At the very least, I can confirm that installing gst-plugins-faad
> (gst-plugins-bad) did "fix" the issue. So that's something I suppose :)

We need to figure out which broken aac decoder it falls back to and blacklist it.

Comment 75

[Matthew Turnbull [Bluefang]]

I think I spoke too soon, I am seeing some of the videos fixed, but not all. Here's the run-down of my testing results for everything mentioned in the thread so far. I tested these with the previously linked try-build and the mozilla-inbound hourly.

https://bugzilla.mozilla.org/attachment.cgi?id=8629375 (broken)
https://bugzilla.mozilla.org/attachment.cgi?id=8635653 (now working)
https://www.youtube.com/watch?v=ks8PZ8X6Yo8 (broken)
https://vimeo.com/136237174 (broken)
https://vimeo.com/134533311 (broken)
https://vimeo.com/108587459 (broken)
https://vimeo.com/134531989 (broken)
https://www.youtube.com/watch?v=KckZfTrj9gg (now working)
https://www.youtube.com/watch?v=Eo7cRJ03qw8 (now working)
https://www.youtube.com/watch?v=bha24P9uw-E (now working)
https://www.youtube.com/watch?v=KJtaIqahi3I (now working)
https://www.youtube.com/watch?v=rdlJYpzS1qA (now working)

So progress :)

(In reply to Jean-Yves Avenard [:jya] from comment #73)
> oh I see..
> 
> if the video is cached in memory, then it doesn't happen. Clear the cache
> and it occurs.
> 
> I'm now convinced that the bug is in gstreamer and has always been there,
> the change of timing due to bug 1175768 has just revealed it.

That's quite unfortunate.

Is it still worth trying to fix at this point? Or would time be better served reverting Bug 1175768 for Firefox 41/42, and then focusing on Bug 947287 to switch the default to gstreamer 1.x? Are Bug 1112371 and Bug 1016325 still issues with all of the refactors and clean-ups that have happened?

Comment 76

[Jean-Yves Avenard [:jya]]

Attachment: P3. Do not override known duration with approximated one.

Some gstreamer plugin return nonsensical values

Comment 77

[Jean-Yves Avenard [:jya]]

(In reply to Matthew Turnbull [Bluefang] from comment #75)
> I think I spoke too soon, I am seeing some of the videos fixed, but not all.
> Here's the run-down of my testing results for everything mentioned in the
> thread so far. I tested these with the previously linked try-build and the
> mozilla-inbound hourly.

it's racy.

If the video is entirely cached, the duration reported will be fine (so long that it's cached before the playback cursor is displayed)

I have a fast internet connection here (115Mbit/s) so that's usually the case for me, so I didn't see the bug.

> 
> https://bugzilla.mozilla.org/attachment.cgi?id=8629375 (broken)
> https://bugzilla.mozilla.org/attachment.cgi?id=8635653 (now working)
> https://www.youtube.com/watch?v=ks8PZ8X6Yo8 (broken)
> https://vimeo.com/136237174 (broken)
> https://vimeo.com/134533311 (broken)
> https://vimeo.com/108587459 (broken)
> https://vimeo.com/134531989 (broken)
> https://www.youtube.com/watch?v=KckZfTrj9gg (now working)
> https://www.youtube.com/watch?v=Eo7cRJ03qw8 (now working)
> https://www.youtube.com/watch?v=bha24P9uw-E (now working)
> https://www.youtube.com/watch?v=KJtaIqahi3I (now working)
> https://www.youtube.com/watch?v=rdlJYpzS1qA (now working)
> 
> So progress :)
> 
> (In reply to Jean-Yves Avenard [:jya] from comment #73)
> > oh I see..
> > 
> > if the video is cached in memory, then it doesn't happen. Clear the cache
> > and it occurs.
> > 
> > I'm now convinced that the bug is in gstreamer and has always been there,
> > the change of timing due to bug 1175768 has just revealed it.
> 
> That's quite unfortunate.
> 
> Is it still worth trying to fix at this point? Or would time be better
> served reverting Bug 1175768 for Firefox 41/42, and then focusing on Bug
> 947287 to switch the default to gstreamer 1.x? Are Bug 1112371 and Bug
> 1016325 still issues with all of the refactors and clean-ups that have
> happened?

we can't revert that bug. It would be a massive effort to do so and totally silly when we're just trying to get around a stupid gstreamer plugin..

GStreamer has an API to convert a byterange with a duration.

In that particular video, the duration is 39.937s ; yet when you call gst_element_query_convert to convert bytes to time ; it returns a value that appears to be off and in the wrong unit 7 minutes and 27s (447s close to 10x the real value) 

when you use the libfaad plugin you get the proper value: if the duration is known that's what is uses.

The patch I just posted check if gstreamer know the real duration, and if so ensure that the buffered ranges is bound to that duration.

Comment 78

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/4a8f9dc938e0
https://hg.mozilla.org/mozilla-central/rev/2708af088758

Comment 79

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

Comment on attachment 8649108 [details] [diff] [review]
P3. Do not override known duration with approximated one.

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

GStreamer is really edwin's baby.

Comment 80

[u532768]

Compiled nightly from the 18th with default gstreamer.  Plays everything with the exception of the two vimeo videos of yesterday.  The ogg problem I had yesterday was a false alarm on my part.  My link was too slow, and it was just waiting for material to arrive in order to play.  I was able to play the entire video today.

The behavior is strange on the two vimeo videos.  The duration is correct.  But if I click in the timeline, the position starts shrinking while still playing and advancing the time.  So, if 7 minutes is at half of a 14 minute video, and I click beyond the play point, it starts shrinking the position below half, even though the duration stays correct.  If I restart it, everything is correct, though it can be hard to get restarted.  Had to click several times.

https://vimeo.com/136237174

https://vimeo.com/134533311

I think it must be using the bad timing you found internally to determine position, even though you've fixed the duration.  It seems you've put in another fix, so this is old news, but putting it here for completeness.

Comment 81

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/7dd543ff5fe1

Comment 82

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/7dd543ff5fe1

Comment 83

[Jean-Yves Avenard [:jya]]

Comment on attachment 8648752 [details] [diff] [review]
Don't attempt to estimate duration until read metadata complete

Approval Request Comment
[Feature/regressing bug #]: 1175768 
[User impact if declined]: Playback stopping, error in playback, Youtube would revert to flash.
[Describe test coverage new/current, TreeHerder]: in central for a few days. Confirmed as fixed by users.
[Risks and why]: Low, revert to earlier logic and bypassing gstreamer plugins bug
[String/UUID change made/needed]: none

Comment 85

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Jean-Yves, when reviewing the beta uplift request, I noticed bug 1175768 indicates status-firefox41: fixed. Why are we then requesting an uplift to Beta41? Is there a mistake in the bug #?

Comment 87

[Jean-Yves Avenard [:jya]]

In bug 1175768 touched a lot of code, and it introduced a few regressions in the gstreamer reader.

a additional side effect of the original change was to ensure all functions run in the same thread. This has tweaked some timings and exposed a bug that was always there in the gstreamer code: this is part3 of the code.

P1 and P2 simply revert the two regressions added by bug 1175768

Comment 88

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8648752 [details] [diff] [review]
Don't attempt to estimate duration until read metadata complete

Patch looks simple enough and has been in Nightly for a week now. Let's uplift to Aurora42 and Beta41.

Comment 89

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/fe6c7020a8ab
https://hg.mozilla.org/releases/mozilla-aurora/rev/294ec17f7f46
https://hg.mozilla.org/releases/mozilla-aurora/rev/75c607b4bce1

Comment 90

[Ryan VanderMeulen [:RyanVM]]

Needs rebasing for Beta uplift.

Comment 92

[Jean-Yves Avenard [:jya]]

seems that bug 1178437 didn't make it for beta which is very unfortunate..
Starting to worry that media playback won't be good at all on 41 :(

So I've rebased so this change would work without bug 1178437 in.

Will push if tries are green

https://treeherder.mozilla.org/#/jobs?repo=try&revision=3a2372e50993

Comment 93

[Jean-Yves Avenard [:jya]]

remote:   https://hg.mozilla.org/releases/mozilla-beta/rev/4e1434b2aeb6
remote:   https://hg.mozilla.org/releases/mozilla-beta/rev/4555ce853395
remote:   https://hg.mozilla.org/releases/mozilla-beta/rev/cc43b2523d7b