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 172043 - [mpegpsdemux] wrong video length on mpeg file
[mpegpsdemux] wrong video length on mpeg file
Status: VERIFIED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: 0.10.11
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 529014 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-03-29 22:42 UTC by Sebastien Bacher
Modified: 2009-03-06 15:48 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sebastien Bacher 2005-03-29 22:42:35 UTC
Using totem 1.0.1 / gst-plugins 0.8.8 / gstreamer 0.8.9 some video have a wrong
length displayed.
Comment 1 Sebastien Bacher 2005-03-29 22:44:28 UTC
One example of such video: http://pkg-gnome.alioth.debian.org/bugzilla172043.mpg
Comment 2 Jan Schmidt 2005-04-07 19:38:15 UTC
Fixed in CVS
Comment 3 Jan Schmidt 2005-04-16 15:18:59 UTC
and broken in CVS again. I need to think about how to handle mpeg's with broken
timestamps a bit longer :)
Comment 4 Luca Ognibene 2005-09-19 18:35:09 UTC
yep, broken.. well it's broken also in xine :)
Comment 5 Jan Schmidt 2006-01-12 14:52:16 UTC
To reawaken this bug, this seems broken in 0.10 in both the gst-plugins-ugly demuxer and in the fluendo one.
Comment 6 Aaron VanDevender 2006-04-27 13:56:15 UTC
This bug is still a problem with gstreamer-0.10.4, gstreamer-plugins-base-0.10.5,
and gstreamer-plugins-ugly-0.10.3.

http://renny.netdot.net/~sig/jumpvids/jump-0146.mpg

This first video is 1m15s. Xine says it is 00:00, but the slider works correctly, so it must have the correct length somewhere. Mplayer shows the correct length. When totem (gstreamer) starts up it says it is 00:57, then after a few seconds changes its mind to 01:02, then to 01:14 (or sometimes 01:11) after a few more seconds. It stays that way till the end, so when it finishes the time says something like 01:15/01:11, which makes no sense. It's like my soccer coach telling me to give 110%.

I try seeking, which doesn't work, but when I click the slider it makes the image jerk and the total time jumps to either 01:16 or 01:18, so sometimes it underestimates, and sometimes it overestimates, but it never seems to get it right.
Comment 7 Martin Jürgens 2008-09-03 18:22:24 UTC
*** Bug 529014 has been marked as a duplicate of this bug. ***
Comment 8 Martin Jürgens 2008-09-03 18:24:02 UTC
Same issue with latest gst. I'd love to see this fixed so if you need more information, just ask. Thanks!
Comment 9 Martin Jürgens 2008-11-05 17:53:34 UTC
here's another example:

http://fallingillini.org/~sig/jumpvids/jump-0146.mpg

the video length displayed changes over time, xine does it right. would be nice if someone could look into it.
Comment 10 Jan Schmidt 2008-11-05 19:40:30 UTC
(In reply to comment #9)
> here's another example:
> 
> http://fallingillini.org/~sig/jumpvids/jump-0146.mpg
> 
> the video length displayed changes over time, xine does it right. would be nice
> if someone could look into it.

xine fails to report either a duration or the current time at all here - it shows 00:00 the whole time. The slider progresses at something like the correct rate... but that's because xine uses the percentage of bytes consumed from the input stream to report the current position, rather than attempting any accounting for VBR or discontinuities.
Comment 11 Martin Jürgens 2008-11-05 20:00:35 UTC
yup right, but i have another mpg movie (see attached screencast in bug 529014) in which xine reports the length the right way and gstreamer just jumps over and over again. can i give you some debugging information about that video? it would be nice if you would look at it.
Comment 12 Martin Jürgens 2008-11-05 20:28:43 UTC
as a side note i only experience the wrong length being displayed with videos about file says the following:

: MPEG sequence, v1, system multiplex

or 

: RIFF (little-endian) data, wrapped MPEG-1 (CDXA)

it would be really good to have this fixed. This has been bugging me for so long now.
Comment 13 Martin Jürgens 2008-11-06 15:39:20 UTC
Okay I've found another video on the web (2 MB) that shows the same behavior, but with which Xine calculates the length the right way. It can be found here: http://uploaded.to/?id=alk6gv Would be great if you could try to reproduce.
Comment 14 Edward Hervey 2009-03-06 09:33:08 UTC
Martin, that file doesn't exist anymore, can you provide a new one ?

Also, re-assigning to -bad since that's where mpegpsdemux is.
Comment 15 Martin Jürgens 2009-03-06 12:39:38 UTC
Well I have found another video that shows the same symptoms:

http://uploaded.to/?id=6p9wkg

When playing the video, the length changes all the time at the start (but not at the end of it). Using Xine it works fine.
Comment 16 Edward Hervey 2009-03-06 12:47:19 UTC
Martin, the duration stays constant with git of -bad (using mpegpsdemux).

For that file I get a constant 39s duration.

Martin, can you confirm it's fixed in git for your use cases ?
Comment 17 Martin Jürgens 2009-03-06 13:05:26 UTC
I guess that it will be hard for me to get the latest git snapshot.

Can you check if the duration is also correctly shown with that video which I've found on the internet? :-D:

http://uploaded.to/?id=989igx

If yes, I'd suggest to mark this bug fixed.. Thanks
Comment 18 Edward Hervey 2009-03-06 13:08:07 UTC
ok, marking fix (that was the file I tried it with).
Comment 19 Martin Jürgens 2009-03-06 13:23:42 UTC
the second link has the same file name but is a different video.
Comment 20 Edward Hervey 2009-03-06 15:48:00 UTC
The second file also has a constant duration (59s).

Life of Brian I suppose ? :)