First, rather than 'polling' (with a 50 ms delay)
to check whether new data can be read, it is
better to use the new 'event trigger' mechanism.
See "liveMedia/DeviceSource.cpp" for a model on
how to do this.
Ø For MPEG2 we are using this class MPEG1or2VideoStreamDiscreteFramer.
So when I see this code I observe that a lot of
manipulation is done to the presentation time.
So is it possible that the time stamp values are
getting jumbled here?
"MPEG1or2VideoStreamDiscreteFramer" assumes that
its input frames are in 'decoding order' - i.e.,
the order in which frames should be fed into a
decoder (at the receiving end). This is the same
order in which frames should be sent across the
network (via RTP).
The 'preentation time' for each frame, however,
will be different - it corresponds to the time
that each frame will be displayed on the
(receiver's) screen. Therefore, the
"MPEG1or2VideoStreamDiscreteFramer" code adjusts
the presentation times as appropriate (if the
stream contains "B" frames).
To summarize: If your input data frames are being
delivered in decoding order, then everything
should be OK; any 'jittery' behavior that you see
must be due to something else (unrelated to our
code). However, if your input data frames are
*not* being delivered (to
"MPEG1or2VideoStreamDiscreteFramer") in decoding
order, then you will need to fix this.
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
