[FFmpeg-devel] Realmedia patch

[Ronald S. Bultje]

Hi Luca,

On Tue, Sep 9, 2008 at 2:42 AM, Luca Abeni <lucabe72 at email.it> wrote:
> The right thing is the following one:
> 1) the "OPTION" command is used to detect the server type
> 2) according to the server type, you can select a different protocol
>    (RTP, RDT, etc...) in the "SETUP" command. This is done through the
>    "Transport:" tag.
>    The usage of RTP or RDT parsing functions depend on the answer you
>    receive to "SETUP"
> 3) the payload type is determined by the "rtpmap" attributes in the
>    SDP lines describing the various media.
> So, transpor-protocol (rtp, rdt, etc...) parsing is not payload
> dependent, and does not depend on the SDP. Payload parsing is
> SDP-dependent.

That's close to what I was thinking myself, but won't completely work.
There's two items that tell us it's RDT vs RTP, and it's not the
transport:
- SDP (there's an item "IsRealDataType: 0 / 1")
- payload (any of the Real-mimetypes indicate RDT, versus more generic
ones like H264 or AAC indicating RTP)
Only based on either one of those can you detect whether the contained
datastream will be RDT or RTP. There is not other way to know. Real
servers can stream anything, and use RTSP extensions to support their
own RTP variant (RDT) as well as a standard-alike one.
There's more problems: many of the SDP extensions that I used in rdt.c
are supported by RTP (non-RDT) as streamed by Real/RTSP servers as
well. This code has to be moved out, either into rtsp_real.c or back
into real.c, needs access to the RTSP structures (such as RTSPState)
or a new private structure (not rdt_data). Only then can I properly
support things like stream selection (based on the ASMRuleBook SDP
line) in RTP as well as RDT streamed by Real/RTSP Servers.
Of course, the RealChallenge field is also emitted by servers on these
streams, fortunately that code is mostly in rtsp.c already, and does
not depend on rdt_data (even though the calculate() function is in
rdt.c, that should move to real_rtsp.c also).

What I think I should do:
- move the non-RDT-related SDP parsing (ASMRuleBook, AvgBitRate, add
IsRealDataType) and functions (calculate(), subscribe_to_rule()) and
move them into a new file, real_rtsp.c, and make them independent of
rdt_data and instead make them use a new private structure,
real_rtsp_data that can hold information about ASMRuleBook etc.
- change rtsp.c to call the above two real_rtsp() functions instead of
the ff_rdt_*() functions for the if (server == RTSP_SERVER_REAL)
- modify rtsp_read_packet() to call ff_rdt_parse_packet() if server ==
REAL && IsRealDataType == 1

As for the transport, it can always be x-pn-tng for Real servers, it
doesn't "select" the server to send RTP or RDT, these two are
unrelated. I suppose that it will support RTP/AVP also for regular
RTP, but didn't test (if it does, I'll change it to use that, but
again, it doesn't select, it purely depends on the IsRealDataType SDP
line and on the payload type).
If you make it send RTP/AVP depending on Real or not and "hope" that
it fails for RDT but not RTP I support it could work in theory, but I
think it's the wrong approach, this behaviour could change any day and
depends on order of the RTSP_PROTOCOL_* fields (Michael was against
such kind of behaviour in earlier threads).

> Your code assumes real==rdt, so if a real server does not want to stream
> over rdt the setup fails. Which, in a first approximation, is fine (I
> asked you to first extend the rtsp code making it more generic, and to
> add live/rdt support later, but you decided this was more complex).

We don't know what we're running up against. :-). I prefer to extend
knowing what we're dealing with rather than making things more generic
without knowing if it'll fix the problem. Anyway, eventually all this
will work, I'll just need to spend time on it until it does... :-).

Ronald