Closed Bug 501973 Opened 15 years ago Closed 15 years ago

Long OGG videos lose sync

Categories

(Core :: Audio/Video, defect)

1.9.1 Branch
defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 506061

People

(Reporter: personman_145, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5

I have a 2 and a half hour OGG video. Starts playing fine, but as time goes by (maybe 45 minutes or so) the audio begins to lose sync with the video.

I've tested with an external player to see if my encoding is the problem, but it syncs fine with an external player.

Reproducible: Always

Steps to Reproduce:
1. Start watching a lengthy OGG video embedded with the <video> tag.
2. Let it play for 30-60 minutes.
Actual Results:  
Gradually the audio loses sync, and gets worse as time progresses.

Expected Results:  
Audio and video should remain in sync for the duration of the video.

Using an external player, the audio and video remain in sync.
Version: unspecified → 3.5 Branch
I should mention my test videos were made with ffmpeg2theora, compiled against libtheora v1.1a2.
Component: General → Video/Audio
Product: Firefox → Core
QA Contact: general → video.audio
Version: 3.5 Branch → 1.9.1 Branch
An interesting note. If I manually move the progress bar, the audio becomes synced again, temporarily.
OS: Linux → All
I've done further testing.

Old OGGs (those not using the Thusnelda encoder) exhibit this problem as well.

I've also test with Firefox on Windows, and the bug is present there as well, so I've updated the report as applicable to All OSes.

I do not have a Mac machine, but I expect that if the windows and linux versions exhibit this problem, in all likely-hood the Mac version does as well.
Can you please retest this with today's trunk build (ftp://ftp.mozilla.org/pub/firefox/nightly/latest-trunk/)?  I'm guessing that this was fixed by the patch for bug 506061.
Hi, thanks for the heads up!

I've tested this trunk release on a few machines in Windows as well as Linux.

The synchronization problem DOES SEEM to have been solved, however...

There seem to be issues with the video player stopping once the cache or buffer runs out which have made testing in-depth a bit difficult, but I'm going to keep working at it.

Also I'm using development versions of theora for most of my videos, and I realize this is development version as well, which could be related to the previous problem. Once theora 1.1 is finalized, (which should be any day now) I'll do more in depth testing, and possibly file a bug report if there are still issues in that respect. (video stream stopping, I mean)

I'd really like to try without the buffer problem, or wait till the changes trickle down to the release version, before I go ahead and mark this solved, but what do you think?

Thanks again!

-Andy
(In reply to comment #5)
> There seem to be issues with the video player stopping once the cache or buffer
> runs out which have made testing in-depth a bit difficult, but I'm going to
> keep working at it.

It would be great if you could provide some videos that this problem occurs on, and exact steps we can use to reproduce the problem.
Hi Chris,

I'm using the same video linked in this bug report, it's about 2 hours 47 minutes, and encoded with theora 1.1 alpha 2.

http://anarchismtoday.org/DF_Multimedia/page=watch/id=2.html

Here are a couple more that seem to have similar issues:

http://anarchismtoday.org/DF_Multimedia/page=watch/id=6.html

http://anarchismtoday.org/DF_Multimedia/page=watch/id=10.html

With the trunk from a couple days ago, it seemed to stop dead after the buffer ran out, with today's it hitches and continues every few seconds.

To reproduce, simply let the video play for about 15-30 minutes, or until the buffer runs out.

With some videos it will continue to buffer, and then stop for no apparent reason down the road. May not be quick and easy to reproduce, so you might just let these run in the background while you do other things. You may be able to speed the process up by seeking to the end of the buffer.

Hope this helps!

-Andy

On a somewhat related note, I wrote the video tag support for this site, and released the code to the community. It will likely be included in a future version of the DF_Multimedia module for the Dragonfly Content Management System. :)
(In reply to comment #5)
> There seem to be issues with the video player stopping once the cache or buffer
> runs out which have made testing in-depth a bit difficult, but I'm going to
> keep working at it.

We buffer 50MB of video data by default.  This is shared by all active videos, so if you have multiple videos open, that 50MB limit is spread across them.  As you play a video, we'll drop played parts from the cache and fetch new parts.

So, the fact that we only buffer a limited amount shouldn't cause you any problems, as we'll download more as necessary while the video plays.  If you're seeing any problems with this behaviour, please file a new bug describing the symptoms and include steps to reproduce if possible.

For experimentation, you can change the default cache size in about:config via the media.cache_size preference.

I'll mark this as a dupe of bug 506061.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.