[Live-devel] stocking mplayer and errors at
testOnDemandRTSP
Ross Finlayson
finlayson at live.com
Fri Jan 23 03:19:40 PST 2004
>the error messages are gone, but from time to time the mplayer stocks, and
>the pts and also the presentationTime.tv_sec and tv_usec (in mplayer
>libdemux/demux_rtp.cpp (around line 446 of the today cvs) is jumping
>sometimes more than a second.
The problem here is that the timing information in your "test.m4v" file is
all messed up, and this is causing "testOnDemandRTSPServer" to insert
delays into the streaming of the outgoing data. I.e., the bug is in your
"test.m4v" file, not the LIVE.COM code.
More specifically: Your MPEG-4 data is buggy, because whenever a
"GroupOfVideoObjectPlane" header is inserted (along with a 'time code'),
the "vop_time_increment" is not reset accordingly. For example, the
following sequence of frames occurred near the start of your "test.m4v" file:
modulo_time_base vop_time_increment
0 0
0 1
0 2
...
0 10
0 11
<then a "GroupOfVideoObjectPlane" header, specifying a "time_code" of 0
seconds>
0 12
0 13
...
This is wrong. Because the "vop_time_increment" is relative to the
"modulo_time_base", which in turn is relative to the
"GroupOfVideoObjectPlane" time code, the first "vop_time_increment" after
the "GroupOfVideoObjectPlane" header should be 0, not 12. A
"vop_time_increment" of 12 here specifies that there is a delay equal to 12
frame times before the frame gets played, which is not what you want.
This sort of thing happens throughout your file, and it's causing the RTSP
server to add delays to the streaming of RTP packets.
So, it looks like "ffmpeg" - the tool that you use to generate this MPEG-4
file - is buggy.
(BTW, I now recommend that people use "VLC" <http://www.videolan.org/vlc/>
rather than "MPlayer" to play RTSP/RTP streams on Linux/Unix. I have found
that "VLC" performs better and plays smoother than "MPlayer".)
Ross Finlayson
LIVE.COM
<http://www.live.com/>
More information about the live-devel
mailing list