[Live-devel] stocking mplayer and errors at testOnDemandRTSP

[Michael Hess]

Hi Ross, thanks for the long answer!

I thought, that this is such a problem, because it happens to all the
files i create.

I was using the ffmpeg which i have downloaded from the cvs of
mplayerhq.hu.. I also tried the release-version (0.4.8) but the same
things happen.

How do you extract all this information, and how do you analyze my files,
what do you use for this ? Maybe I should try an other coder, but I have
not found another one which is free... It is understandable that this is
confusing the server, but why is the ffmpeg doing this ?

I will have a look at the vlc-project, and will try this...

Can you tell me, what coders and analyzsetools you are using, I think this
would be useful for my research project here at the University of Plymouth
(UK).

Best regards,

Michael Hess


>
>>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/>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live.com
> http://lists.live.com/mailman/listinfo/live-devel