On Thu, 21 Nov 2013, Josh Allmann wrote:
Instead of assuming a single payload type per RTSPStream,
store a collection of payload types, along with the necessary
data (indexes, transports, dynamic handlers, etc).
Upon reading the first RTP-UDP packet, set the transport_priv
pointer for the RTSPStream to the transport for the corresponding
payload (via pick_transport_priv), and the rest of the processing
proceeds as usual.
Only tested with RTP-UDP. Most likely breaks RTSP, TCP, RDT,
leaks and/or corrupts data, etc. Clearly, a work-in-progress.
---
libavformat/rtsp.c | 155 ++++++++++++++++++++++++++++++++++++----------------
libavformat/rtsp.h | 30 ++++++----
2 files changed, 129 insertions(+), 56 deletions(-)
I didn't read this through in detail since it's just a WIP, but a few more
comments:
In general the common use of this probably is for when a peer in SDP
offer/answer lists a number of possible codecs but in practice only will
use one of them - then your WIP probably works quite ok. However as Luca
pointed out they could actually change, and that's quite hard to handle.
If we assume only one single codec ever actually will be sent it should be
doable I guess, though.
I don't really see how you're handling setting/picking the codec ID for
the AVStream in your patch - is it simply overwriting this field and
keeping the last one set? I guess libavformat callers can handle the fact
that one AVStream is set to AV_CODEC_ID_NONE initially and later gets set
to something when we know which one we're getting, but changing it later
probably isn't supported by any callers.
Also, handling payload type specific a= lines and such, as Luca pointed
out, is another challenge to keep in mind.
A special case to think about is comfort noise. Even if you only use one
single codec for the stream itself, you can have a separate payload type
chosen for comfort noise parameters (which is handled as a separate codec
ID in libavcodec). Hooking this up in practice wouldn't be all that simple
(since you would have to generate comfort noise using the latest comfort
noise descriptor, but only up until you actually get more data in the real
codec channel - see RFC 3389).
A second special case is forward error correction (RFC 5109), which uses
two other RTP payload types for framing the redundant data stream. All of
that can be hidden inside the RTSP demuxer/RTP depacketizer combo though -
none of it needs to be visible outside of the RTSP demuxer externally. You
can see my WIP patches on this topic at
https://github.com/mstorsjo/libav/commits/rtpdec-fec and have a look at
what it would take to support this without conflicting with your design.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
