[MPlayer-users] Re: Mplayer as a Client for VideoLAN server

[Nico]

Hi,



Ross Finlayson wrote:

> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
>
>> I don't know that code and RTP in general, but reading the sources it
>> seems that in this case the presence of MP2T in the sdp file should make
>> demux_is_mpeg_rtp_stream() return TRUE, right?
>
>
> Yes - so the code in "video_read_properties()" will (correctly) fall 
> through to the MPEG header parsing code. 


quoting video.c:

demux_stream_t *d_video=sh_video->ds;

........

#ifdef STREAMING_LIVE_DOT_COM
 case DEMUXER_TYPE_RTP:
   // If the RTP stream is a MPEG stream, then we use this code to check
   // for MPEG headers:
   if (!demux_is_mpeg_rtp_stream(d_video->demuxer)) break;
   // otherwise fall through to...
#endif
 case DEMUXER_TYPE_PVA:
 case DEMUXER_TYPE_MPEG_TS:
 case DEMUXER_TYPE_MPEG_ES:
 case DEMUXER_TYPE_MPEG_TY:
 case DEMUXER_TYPE_MPEG_PS: {
//mpeg_header_parser:
   // Find sequence_header first:
   videobuf_len=0; videobuf_code_len=0;
   telecine=0; telecine_cnt=-2.5;
   mp_msg(MSGT_DECVIDEO,MSGL_V,"Searching for sequence header... ");fflush(stdout);

 while(1){
      int i=sync_video_packet(d_video);


at this point in d_video there will be an interleaved stream of audio 
and video (as Rett's stream.dump shows: it was generated with 
-dumpvideo, not with -dumpstream)
This is the reason why in Rett's case mplayer soon dies: because his 
video stream is corrupted by the relative audio data.

Maybe I'm  missing something?