For downloading file streams and the majority
of live streams, the initial stream of audio and video messages have
a timestamp of zero, and this timestamp value gradually increments
for the following audio and video messages.
However
some live streams do something else. Because live streams can
be dipped into at any time, some RTMP servers use an arbitrary
rolling value for the timestamp. So the initial stream of
audio and video messages may have a timestamp of zero, but the
following audio and video messages will have a timestamp of, for
example, 8019282.
Any media player or file convertor is not
going to like this. The audio and video will play very slowly,
or the video will be out of sync with the audio, or no data will be
saved to the FLV file.
Fortunately there is a fix. The
audio and video messages are bunched together into "aggregate"
messages, and these aggregate messages have valid, meaningful
timestamps. So RtmpClient can offset the timestamp of the
aggregated messages by the timestamp of the parent aggregate
message.
To instruct RtmpClient to do this, set the
eBehaviourFlags for the RtmpConnection to include
AutoAdjustAggregatedMediaTimestamps.
Sometimes an RTMP stream can be played, and command
and metadata messages start arriving, but little or no audio or video
messages.
This can be caused by aggregate messages.
When the RTMP server bunches lots of the audio and video
messages into one large message, the large message is called an "aggregate
message".
Each child message in an aggregate message has its
own StreamId.
However, there is inconsistency between RTMP servers
as to how they set the child message's StreamId. Some RTMP
servers set a valid value for the StreamId for each child message.
And some RTMP servers set the child message's StreamId to zero.
If little or no audio and video messages are arriving, it could
be that they their StreamId has been set to zero, and they are not
being identified as audio and video for the stream.
To fix this,
when you create the client connection, make sure the following
behavior flag is included:
RtmpConnection.eBehaviourFlags.AutoAdjustAggregatedMediaMsgTarget
This flag ensures that if the StreamId for a child message is
zero, the value for StreamId is taken from the aggregate message.
The RTMP parameters can be difficult to
identify, even if the url is known.
If you have an
application that can connect to an RTMP server, use Net Monitor to
capture the initial connection details, and copy them in your
application. If this is too technical for you, and the RTMP
server is on the Internet, send us the details and we will do it for
you.
The parameters for playing a live stream are
different from those for a static file download. If the stream
is live, use the code in the
LiveTv
project, otherwise see the
FileDump project.
