Hi Marcel,
> I just noticed that the counter in xine-ui stays at 00:00:00 when playing
> video only files (tried it using mpeg1 video only).
I think this applies only to MPEG1 video elementary streams. These are hand=
led=20
by the "elem" demuxer, which does not calculate the required value for the=
=20
time display, since it does not have any information on the datarate. The=20
other MPEG demuxers extract the datarate from some program stream header, b=
ut=20
these do not exist in elementary streams. So it might not even be possible =
to=20
get an accurate datarate for an elementary stream. (Except by guessing, but=
=20
datarate estimation is not implemented in xine.)
Michael
=2D-=20
"In my opinion MS is a lot better at making money than it is at making
good operating systems"
-Linus Torvalds, August 1997

Hi Michael,
V So, 17. 04. 2004 v 21:47, Michael Roitzsch p=C3=AD=C5=A1e:
> Hi Marcel,
>=20
> > I just noticed that the counter in xine-ui stays at 00:00:00 when pla=
ying
> > video only files (tried it using mpeg1 video only).
>=20
> I think this applies only to MPEG1 video elementary streams. These are =
handled=20
> by the "elem" demuxer, which does not calculate the required value for =
the=20
> time display, since it does not have any information on the datarate. T=
he=20
> other MPEG demuxers extract the datarate from some program stream heade=
r, but=20
> these do not exist in elementary streams. So it might not even be possi=
ble to=20
> get an accurate datarate for an elementary stream. (Except by guessing,=
but=20
> datarate estimation is not implemented in xine.)
>=20
Does the time have to be computed/guessed only by demuxers? I don't know
too much these parts of xine, but from my "end user view" I think xine
can know about time from time stamps in the frames (but true, only with
enabled decoders).
Maybe also this is due to Thibaut's patches for handling frames with no
duration...?
Cheers,
Frantisek

Hi Frantisek,
> > > I just noticed that the counter in xine-ui stays at 00:00:00 when
> > > playing video only files (tried it using mpeg1 video only).
> >
> > I think this applies only to MPEG1 video elementary streams. These are
> > handled by the "elem" demuxer, which does not calculate the required
> > value for the time display, since it does not have any information on t=
he
> > datarate. The other MPEG demuxers extract the datarate from some program
> > stream header, but these do not exist in elementary streams. So it might
> > not even be possible to get an accurate datarate for an elementary
> > stream. (Except by guessing, but datarate estimation is not implemented
> > in xine.)
>
> Does the time have to be computed/guessed only by demuxers? I don't know
> too much these parts of xine, but from my "end user view" I think xine
> can know about time from time stamps in the frames (but true, only with
> enabled decoders).
The timestamps of the frames can jump or even wrap around. So especially af=
ter=20
seeking, only the demuxer can tell you, where in the file you are.
Michael
=2D-=20
/* Identify the flock of penguins. */
2.2.16 /usr/src/linux/arch/alpha/kernel/setup.c

On Saturday 17 April 2004 21:47, Michael Roitzsch wrote:
> Hi Marcel,
>
> > I just noticed that the counter in xine-ui stays at 00:00:00 when playing
> > video only files (tried it using mpeg1 video only).
>
> I think this applies only to MPEG1 video elementary streams. These are
> handled by the "elem" demuxer, which does not calculate the required value
> for the time display, since it does not have any information on the
> datarate. The other MPEG demuxers extract the datarate from some program
> stream header, but these do not exist in elementary streams.
That explains.
> So it might
> not even be possible to get an accurate datarate for an elementary stream.
> (Except by guessing, but datarate estimation is not implemented in xine.)
I just thought it to be a bug as I never saw it this before.
Regards,
Marcel

On Sun, 2004-04-18 at 01:39, Frantisek Dvorak wrote:
> Hi Michael,
>
> V So, 17. 04. 2004 v 21:47, Michael Roitzsch píše:
> > Hi Marcel,
> >
> > > I just noticed that the counter in xine-ui stays at 00:00:00 when playing
> > > video only files (tried it using mpeg1 video only).
> >
> > I think this applies only to MPEG1 video elementary streams. These are handled
> > by the "elem" demuxer, which does not calculate the required value for the
> > time display, since it does not have any information on the datarate. The
> > other MPEG demuxers extract the datarate from some program stream header, but
> > these do not exist in elementary streams. So it might not even be possible to
> > get an accurate datarate for an elementary stream. (Except by guessing, but
> > datarate estimation is not implemented in xine.)
> >
>
> Does the time have to be computed/guessed only by demuxers? I don't know
> too much these parts of xine, but from my "end user view" I think xine
> can know about time from time stamps in the frames (but true, only with
> enabled decoders).
>
> Maybe also this is due to Thibaut's patches for handling frames with no
> duration...?
What ????
The "no duration" patch has not been commited.
The mpeg elem demuxer tags all packets sent to the decoder with pts=0.
>
> Cheers,
> Frantisek
Thibaut

Hi Thibaut,
hi all,
V Ne, 18. 04. 2004 v 03:55, Thibaut Mattern p=C3=AD=C5=A1e:
> On Sun, 2004-04-18 at 01:39, Frantisek Dvorak wrote:
> > > > I just noticed that the counter in xine-ui stays at 00:00:00 when=
playing
> > > > video only files (tried it using mpeg1 video only).
> > >=20
> > > I think this applies only to MPEG1 video elementary streams. These =
are handled=20
> > > by the "elem" demuxer, which does not calculate the required value =
for the=20
> > > time display, since it does not have any information on the datarat=
e. The=20
> > > other MPEG demuxers extract the datarate from some program stream h=
eader, but=20
> > > these do not exist in elementary streams. So it might not even be p=
ossible to=20
> > > get an accurate datarate for an elementary stream. (Except by guess=
ing, but=20
> > > datarate estimation is not implemented in xine.)
> > >=20
> >=20
> > Does the time have to be computed/guessed only by demuxers? I don't k=
now
> > too much these parts of xine, but from my "end user view" I think xin=
e
> > can know about time from time stamps in the frames (but true, only wi=
th
> > enabled decoders).
> >=20
And note I still have a film which takes 0:00:09 according to MPEG and
1:04:14 according to MPEG_PES. :-)
> > Maybe also this is due to Thibaut's patches for handling frames with =
no
> > duration...?
>=20
> What ????
> The "no duration" patch has not been commited.
Yes, I've spoken about your not commited work. I meant no breaking.
> The mpeg elem demuxer tags all packets sent to the decoder with pts=3D0.
>=20
So I was wrong. This is something different.
> >=20
> > Cheers,
> > Frantisek