After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 346626 - MPEG stream playing much too fast
MPEG stream playing much too fast
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
0.10.3
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-07-05 10:23 UTC by Philip Jägenstedt
Modified: 2007-12-10 03:45 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Philip Jägenstedt 2006-07-05 10:23:25 UTC
The following stream plays much too fast using totem or playbin:
http://fredrik.hubbe.net/plugger/test.mpg

Compare with how mplayer plays it back.

I'm unsure where the fault lies, but a good guess might be the mpeg demuxer in ugly.
Comment 1 Tim-Philipp Müller 2006-07-05 10:47:04 UTC
Can't see how it's playing too fast with GStreamer CVS. Looks more or less the same as in mplayer to me, and the clock time is about right too (ca. 48 secs). The duration display in totem is completely bogus though, but there's another bug open for this.

I don't think mpegdemux is involved here at all, it seems to go straight to the mpeg2dec element:

/playbin0/decoder/typefind.src: caps = video/mpeg, systemstream=(boolean)false, mpegversion=(int)1
/playbin0/decoder/mpeg2dec0.sink: caps = video/mpeg, systemstream=(boolean)false, mpegversion=(int)1
/playbin0/decoder/mpeg2dec0.src: caps = video/x-raw-yuv, format=(fourcc)I420, width=(int)320, height=(int)240, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)25/1

That might also explain the missing newsegment event the sink is complaining about ...

WARNING: Element "videosink-actual-sink" warns: gstbasesink.c(1876): gst_base_sink_chain_unlocked (): /playbin0/vbin/videosink/videosink-actual-sink:
Received buffer without a new-segment. Assuming timestamps start from 0.

Comment 2 Philip Jägenstedt 2007-12-10 03:45:10 UTC
I am no longer able to reproduce this bug myself. It may have been accidentally fixed so I'm closing as obsolete.