One example of such video: http://pkg-gnome.alioth.debian.org/bugzilla172043.mpg

Fixed in CVS

and broken in CVS again. I need to think about how to handle mpeg's with broken
timestamps a bit longer :)

yep, broken.. well it's broken also in xine :)

To reawaken this bug, this seems broken in 0.10 in both the gst-plugins-ugly demuxer and in the fluendo one.

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.

*** Bug 529014 has been marked as a duplicate of this bug. ***

Same issue with latest gst. I'd love to see this fixed so if you need more information, just ask. Thanks!

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.

(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.

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.

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.

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.

Martin, that file doesn't exist anymore, can you provide a new one ?

Also, re-assigning to -bad since that's where mpegpsdemux is.

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.

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 ?

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

ok, marking fix (that was the file I tried it with).

the second link has the same file name but is a different video.

The second file also has a constant duration (59s).

Life of Brian I suppose ? :)