[MPlayer-dev-eng] Re: MPlayer-dev-eng digest, Vol 1 #1242 - 16 msgs

[Ross Finlayson]

> > -if(stream_dump_type==5){
> > +if(stream_dump_type==5 && stream->fd >= 0){
> >     unsigned char buf[4096];
>
>i've reversed this change and teh one for -cache too

I notice from the latest CVS that you've reinstated these tests, by 
rejecting streams without fds only if their type is 
"STREAMTYPE_STREAM".  For RTP sessions, this does the right thing: 
attempting to use the "-cache" or "-dumpstream" options on such streams 
will fail (without crashing).

>- route your raw steram theough our stream layer --> preferred way but maybe
>   hard/impossible to implement with live.com lib design

What would make this hard/impossible is not the LIVE.COM design, but the 
nature of RTP itself.  In RTP sessions, audio and video (and any other 
media) are not multiplexed together, but instead are sent in separate 
packet streams.  (The reason for this is flexibility - for example, this 
makes it possible for a client to receive only audio (e.g., if he has a 
low-bandwidth connection), and even makes it possible for audio and video 
to come from separate sources.)  So, it would not make sense to try to 
multiplex together these separate audio and video packet sequences into a 
single combined 'stream' (only to have mplayer's audio and video demuxers 
then split them apart again for playing).

Note, BTW, that although "-dumpstream" cannot be used on a RTP session, 
"-dumpaudio" and "-dumpvideo" work OK.

         Ross.