[FFmpeg-devel] Realmedia patch
Tue Sep 9 16:07:55 CEST 2008
Ronald S. Bultje wrote:
> 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
> 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
> - SDP (there's an item "IsRealDataType: 0 / 1")
So, real really managed to mess everything up. "RDT vs RTP" ia a
transport protocol choice, so it must be described in the "Transport:"
tag of the SETUP request. Not in the SDP.
Anyway, we can work around this issue by considering "IsRealDataType:"
as a hint for the transport protocol that we have to select in the
> - payload (any of the Real-mimetypes indicate RDT, versus more generic
> ones like H264 or AAC indicating RTP)
I do not buy this ;-)
The payload type is (as the name suggests) about the payload, not about
> Only based on either one of those can you detect whether the contained
> datastream will be RDT or RTP.
No. You know if the stream is RDT or RTP by looking at the response to
the SETUP command.
> Real servers can stream anything,
Yes. And if they stream regular RTP, a request for an RDT stream will fail.
So, no problem here: you just have to send the correct SETUP command and
to look at the response.
> 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
AFAIK, they are not standard SDP lines... At least, I could not find any
RFC describing any of them.
> 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).
What is this code needed for? In case of RDT streams, I see that it
is needed for setting up the RM parser, but in case of standard RTP
streams, I do not see why it would be needed...
> 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.
Isn't ASMRuleBook something real-specific? So, it should not be
in rtsp.c... If you want to create a "real_rtsp.c" file, ok, but
I do not know... Anyway, it should not touch RTSPState (but should
only modify some real-specific structure).
> 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
Ah, ok... If this is what you are thinking about, sorry, I misunderstood
you. I am ok with splitting rdt.c in multiple files, if you want. But
none of this code should go in 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.
This is ok too (sorry, I misunderstood you and I thought you wanted
to put this data in the generic RTSP structure).
> - 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
I still think that this must be selected based on the transport protocol
(currently, we have the assumption "real == RDT", but this can be easily
> As for the transport, it can always be x-pn-tng for Real servers
Are you really sure about this? I've seen real servers handling this
properly (that is, accepting requests with the correct "Transport:"
tag and replying with a correct "Transport:").
The standard (RFC 2326) says:
This request header indicates which transport protocol is to be used
and configures its parameters such as destination address,
compression, multicast time-to-live and destination port for a single
stream. It sets those values not already determined by a presentation
So, if a server selects the transport protocol independently from
"Transport:" the server is buggy. But I do not believe that real
is so broken.
> doesn't "select" the server to send RTP or RDT, these two are
Do you have traces showing this? A quick search shows that a
"helix server" behaves correctly:
(see the "SETUP" request and response).
> 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
There is no "hope". In the SETUP request, you ask for one (or more)
transport protocol; if the server supports it, it will reply with a
"success" response (possibly indicating the transport protocol). If
it does not, it will fail.
So: if you see the "IsRealDataType" tag set to 1, you can guess that
the server supports RDT, and you can ask for it. Otherwise, you just
ask for regular RTP (RTP/AVP, etc...). If the guess is correct, the
server will reply with a success, otherwise the setup will fail and
you can try to ask for a different transport.
> think it's the wrong approach, this behaviour could change any day
Which behaviour can change? Surely, something that is documented in
RFC 2326 will not change.
> depends on order of the RTSP_PROTOCOL_* fields
No, my current proposal (ask for RDT if the server is real - or if
you see "IsRealDataType" set to 1, as you prefer) does not depend
More information about the ffmpeg-devel