Bug 616905

Summary:	webm playback can be very choppy even with available resources
Product:	[Fedora] Fedora	Reporter:	Scott Dowdle <dowdle>
Component:	gstreamer	Assignee:	Benjamin Otte <otte>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	13	CC:	otte
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-11-20 20:04:06 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Scott Dowdle 2010-07-21 17:23:57 UTC

I'm not sure what package to attach this bug to since none of the changelogs for the gstreamer packages seem to include the word "webm" unless I'm overlooking it somewhere.

Anyway, webm support was added to gstreamer recently.  rpmfusion updated their ffmpeg package so that it can now create webm content.  I've been doing a bit of testing with webm.  The encoding seems to work great.

Playback seems to work great... BUT gstreamer-based playback seems to bog down for unknown reasons sometimes.  Oddly it bogs down and seems to skip frames and become horribly choppy while there are plenty of system resources.  In fact when totem (for example) displays this extremely choppy behavior it is only taking up usually less than 10% of the CPU with plenty of system resources available.

I've seen this behavior on various machines with various CPUs and video card chipsets (Intel and ATI)... so I'm not sure what to blame it on other than gstreamer's webm playback abilities... or maybe libvpx?

Comment 1 Benjamin Otte 2010-07-21 18:05:58 UTC

This is probably a timestamping issue, so GStreamer seems like the correct place to put blame. If you are not running the latest GStreamer (0.10.30 from updates-testing), please upgrade first to see if it has been fixed there.

If it hasn't, we need to file a bug upstream with a file that doesn't work, so you'll need to provide one that exhibits the problem.

Comment 2 Scott Dowdle 2010-07-21 22:03:55 UTC

I've done some more testing and hopefully the additional information will help tracking down the real problem... and yeah, it'll probably need to go upstream.

I tried duplicating the problem with Big Buck Bunny but that movie is only 5 minutes long and I could not get the problem to happen.

Where I have noticed the problem though is in feature length movie.  So, I downloaded the video DVD image for Sita Singes the Blues from archive.org (http://www.archive.org/download/Sita_Sings_the_Blues/SITA_SINGS_MOVIE_ONLY.iso) and then extracted the main video track (1:21:34) to an mpeg file.

Then I converted that to a .webm video with the ffmpeg package that is available in the rpmfusion repository.  Unfortunately I can't find any movie length videos online in webm format that I can give you the URL for as a sample file.

Playing the video back in totem it is easy to get it to become very jumpy just by moving the play head around in the movie.  For example... there is a music video like section that starts at 51:43 and goes on for about 5 minutes.  Advancing the play head there and letting it play... it gets very choppy when compared to the playback in other video formats.

If I extract say 5 minutes of the video from that section of the movie to a separate file, it has no playback problem... so it does not have to do with the complexity of the video and it can play it just fine as long as it is in a smaller length video.

For samples of problem videos... I say download the Sita Sings the Blues movie in any of the available formats (the only open format is a rather low bitrate Theora video - http://www.archive.org/download/Sita_Sings_the_Blues/Sita_Sings_the_Blues.ogv) which I'm going to test next.  The .webm file I've created from the Video DVD is too big to share.

If you have any other ideas / criteria for further testing... please let me know.

Comment 3 Scott Dowdle 2010-11-20 20:04:06 UTC

This no longer seems to be a problem with the updated gstreamer / libvpx libs in Fedora 14... so closing this bug.