[Live-devel] Urgent help needed!

[Morgan Tørvolt]

> Unfortunately this will also prevent "fPresentationTime" from being
> set, which will in turn lead to incorrect RTP timestamps.  For MPEG
> Transport Streams, however, that may not be a huge problem, because
> the Transport Stream data itself contains the timing (PCR)
> information that receivers use to properly play the stream.  However,
> it will cause RTCP statistics (jitter, etc.) to not get reported
> correctly.

Ah, thanks Ross. I remember now. What we did was alter the live
library so that it uses the timestamp and not durationInMicroseconds
if durationInMicroseconds == 0. That made it possible for us to just
set the current time, making the timestamps correct for live sources
as well.

> The real puzzle here, though, is: Why is "MPEG2TransportStreamFramer"
> apparently generating incorrect average durations for Victor Lee's
> Transport Streams?  "MPEG2TransportStreamFramer" uses the PCR
> timestamps in the source Transport Stream data to generate duration
> estimates, thereby pacing the streaming of the outgoing data.  If the
> stream is getting sent too slowly (on average), then this suggests
> that the PCR timestamps are incorrect.  But if that's the case, then
> how is a media player able to play the audio/video at the correct
> pace when it plays from the file stored locally?

The TransportStremFramer uses previous PCR times and packets between
them to calculate an expected datarate for the following data. This
caused alot of headache for us as our STBs did not have enough buffer
to handle sudden bitrate changes in variable bitrate streams. A long
durationPerPacket because of low bitrate, used on a suddenly high
bitrate (usually because of scene change) caused buffer underruns, and
a few extreme times buffer overruns when the other way around.  I
believe I have mentioned this to you before also, but that might have
been ouside the mailing list.
As to the "correct" way of doing packet duration calculations, it
would be to buffer the incoming data until you have  the next PCR, and
calculate time per packet based on the PCRs actually related to the
data between.
If Victors live input is variable bitrate, and especially if there are
big variations, he could experience too low bitrate at some points.
The way TransportStreamFramer works will give you alot more "too low
bitrate" than "too high bitrate", as the too high bitrate last for a
short time (few packets between PCRs), while the too low bitrate is
used on many more packets as the sudden high bitrate increases the
number of packets between PCRs. This gives an overall too low bitrate.

As a sidenote, I see you have added discontinuity_indicator support,
but strictly speaking, you should keep a set discontinuity_indicator
value to the next PCR comes along, since it is not nessesarily set in
a the packet with PCR time discontinuity. The standard states "the
next PCR in a Transport Stream packet with the same PID".

> It would be helpful if Victor Lee would put one of his Transport
> Stream files on a web site, and post the URL, so we can download the
> file and check it for ourselves.

Agreed

Victor:
> Thank you very much for taking your WEEKEND time to answer my
> questions! I appreciate your helpful information!

 My day off is Friday. I live in a muslim country at the moment =)

-Morgan-