[FFmpeg-devel] Realmedia patch

Ronald S. Bultje rsbultje
Mon Sep 1 21:17:59 CEST 2008

Hi Luca,

On Mon, Sep 1, 2008 at 3:12 PM, Luca Abeni <lucabe72 at email.it> wrote:
> Ronald S. Bultje wrote:
> [...]
>>>> +    if (!(rt->server_type == RTSP_SERVER_RDT && rt->need_subscription)) {
>>> This change looks suspicious...
>>> (same for the rtsp_read_pause() change)
>> These two can (hopefully) be addressed in one...
>> So, for Realmedia, you can subscribe to one of the N rules. The way
>> ffplay does that is that it calls av_open_input_file() and
>> av_find_stream_info(), then chooses one of the N streams (based on the
>> -ast X parameter) and then it sets the AVDISCARD_* flag in all
>> AVStreams and starts reading data.
> [...]
> Thanks for the explaination. As usual, I forgot about stream selection ;-)

Painful, isn't it? :-). Just wait until we get to MMS (you're lucky,
you won't have to review that one :-) ).

>> I modified rtsp_play() (and pause()) to not be sent while the
>> Subscribe command hasn't been sent yet, that's the second half of this
>> change. Ugly, I know, but it worked. :-]. I'm open for suggestions on
>> how to better do this.
> After thinking about this for one day, I arrived to the conclusion that
> the cleanest solution here is a little bit too radical:
> remove the rtsp_read_play() call from rtsp_read_header(), move the real
> "subscribe" code to rtsp_read_play(), and add a mechanism to call
> rtsp_read_play() from rtsp_read_packet() the first time it is called
> (similarly to your patch).

Don't forget that apps (ffplay) can call rtsp_read_play()/pause()
also, which is why I'm somewhat opposed to doing the actual subscribe
call in _play(), since we'd basically have to make it a state-machine.
Especially if we start thinking about supporting dynamic stream
changing (i.e. switching from rule=0 to rule=2 after a while, 'a' key
in ffplay).

Anyway, we should forward this to LucaB and see what he thinks...

Thanks for your comment so far,

More information about the ffmpeg-devel mailing list