[MPlayer-dev-eng] Re: Mplayer unable to play MPEG2-TS over RTP (Was: Mplayer as a Client for VideoLAN server)

[Nico]

Ross Finlayson wrote:

>
>>> Note that "demux_open_rtp()" needs to correctly handle all four of 
>>> the following cases:
>>> 1/ Audio and video on separate RTP streams
>>> 2/ Audio only (on a single RTP stream)
>>> 3/ Video only (on a single RTP stream)
>>> 4/ Audio+Video interleaved on a single RTP stream.
>>>
>>> The code already correctly handles cases 1 through 3, so any fix to 
>>> the code that also handles case 4 needs to make sure that cases 1 
>>> through 3 (the vast majority of RTP streams) don't get broken.
>>
> [...]
>
>> IMHO you can use the code I posted for all cases
>
>
> I tested this, and it's definitely *not* true.   The patch that you 
> posted will *replace* "demuxer->video->sh" and "demuxer->audio->sh", 
> if they're already non-NULL.  For the most common types of RTP 
> sessions (cases 1-3), this is not what you want; for those cases, you 
> want the "sh" field(s) 

> left as is. 


I meant the method (pipelining) of the patch I posted, not the code 
itself, infact my message
read "a prototype of patch"; btw you are right in saying that my patch 
is incorrect for any other case.

>
> So, what I've done instead is updated the LIVE.COM interface code (in 
> the latest CVS) to add a new function:
>         int demux_is_multiplexed_rtp_stream(demuxer_t* demuxer)
>
> This function will tell you whether or not a RTP demuxer will contain 
> multiplexed (i.e., interleaved) audio+video.  If you decide to add 
> special-case code  - e.g., to "demuxer.c" - to handle interleaved 
> streams, you can use this function, after calling "demux_open_rtp()", 
> to tell you whether or not to execute this special-case code.
>
>         Ross.

why not calling demux_open_stream() from within demux_rtp.cpp ?
demuxer.c is already a mess, and IMO needs  a serious clean-up, not more 
code that can be put in each demuxer ( where imo  it belongs ).

                    Nico