[MPlayer-dev-eng] Re: UPDATED: A RTSP/ RTP streaming patch for "mplayer"

[Ross Finlayson]

> > I would very much like to see this patch included in the official mplayer
> > sources.  Please let me know if this can be done.
>
>ok it's in the official mplayer now :)

Great - thanks!

>anyway i had to do 3 changes in your patch:
>
>1. i've disabled live.com libs by default in ./configure, as your
>    way of detection live libs is not strict enough - ie it only
>    checks for the directory, not for teh files there nor the
>    correct version number. imagine users with empty live/ dirs
>    or having other project's files (possible - the word "live" is not
>    copyrighted...) or just too old version of your lib, making the
>    whole mplayer compile process to break.
>    i've also changed it a bit, so it always find the dir if not
>    specified, so its' enough to do --enable-live if the libs are
>    in 'path'

OK, fair enough.

>2. in network.c imho you made a typo, maybe even worse:
>
>+#ifdef STREAMING_LIVE_DOT_COM

Oops, you're right.  That should have been "#ifndef".  Thanks for catching 
and fixing this.

>btw, now rtp:// is disabled if live.com is enabled - if your lib supports
>rtp:// then it should really work, now it isn't accepted.
>so, either left rtp:// code enabled, or implement rtp:// too using live.com

The intention was for the "rtp://" URL hack to *not* be accepted if the 
LIVE.COM libraries are being used.  Changing the "#ifdef" typo to "#ifndef" 
- which you did - does the right thing.

By the way, the reason why a "rtp://" URL is a hack is that - by specifying 
only an IP address and port number - it does not convey enough information 
to describe a RTP stream, in general.  In particular, it does not specify 
the stream's RTP payload format code, nor the RTP timestamp 
frequency.  That's why you need a SDP file, or the use of RTSP (which uses 
SDP internally), to give "mplayer" all the information that it needs.  (The 
reason why "rtp://" happened to work with the old code is that the old code 
was intended for handling MPEG Transport Streams *only*  - for which the 
RTP payload format code is fixed at 33, and the RTP timestamp frequency is 
fixed at 90000.)


>3. at video.c:
>
>@@ -208,10 +215,18 @@
>      float pts1=d_video->pts;
>  //    unsigned char* start=NULL;
>      int in_size=0;
>+    int isMPEG;
>
>      *start=NULL;
>
>-  if(demuxer->file_format==DEMUXER_TYPE_MPEG_ES ||
>demuxer->file_format==DEMUXER_TYPE_MPEG_PS
>+#ifdef STREAMING_LIVE_DOT_COM
>+    if (demuxer->file_format==DEMUXER_TYPE_RTP) {
>+      isMPEG = demux_is_mpeg_rtp_stream(demuxer);
>+    } else
>+#endif
>+    isMPEG = demuxer->file_format==DEMUXER_TYPE_MPEG_ES
>+      || demuxer->file_format==DEMUXER_TYPE_MPEG_PS;
>+    if (isMPEG) {
>          int in_frame=0;
>          //float newfps;
>          //videobuf_len=0;
>
>this will overwrite the result of the live.com check above:
>
>+    isMPEG = demuxer->file_format==DEMUXER_TYPE_MPEG_ES
>+      || demuxer->file_format==DEMUXER_TYPE_MPEG_PS;

Actually, not.  Notice the "else" just above this.  However, this was a bit 
of a hack; I like your fix better.

>anyway it doesn't compile... at least for me.
>with gcc 2.95.3 it has lotsa unknown symbols at linking state,

This is not good.  Are you sure it's using the various LIVE.COM 
libraries?  Could you send me the error messages that you're getting?

>with gcc 3.1 i get compiler internal error while compiling vd_libmpeg2.c :(

That should have nothing to do with my patch; I didn't modify that 
file.  Are you saying that, with gcc 3.1, you *don't* get the same error 
when compiling without my patch??

         Ross.