On Fri, 6 Apr 2012, Ronald S. Bultje wrote:

Hi,

On Fri, Apr 6, 2012 at 7:13 AM, Martin Storsjö <mar...@martin.st> wrote:
This avoids blocking for a long time in
avformat_find_stream_info while waiting for a codec to be set
for data streams in MS-RTSP streams, where the codec won't
ever be set.

This is an adaptation of one part of commit 4c050429780b0d
in FFmpeg.

Alternatively, we could just ignore data streams in MS-RTSP
and not pass them through to the caller.
---
 libavformat/utils.c |    2 ++
 1 file changed, 2 insertions(+)

I'd say your suggestion sounds better. A codec-less stream is by
definition useless. Why do we pass data streams? Do they ever contain
actual relevant data? (I don't remember anymore.) If not, they
shouldn't be user-visible.

I'm not sure if they contain anything of value.

It seems it's not totally trivial to do this, as streams are added while parsing the SDP. If a section of it looks like this:

m=application 0 RTP/AVP 96
b=RS:0
b=RR:0
a=rtpmap:96 x-wms-rtx/1000
a=control:rtx
a=stream:65536

When parsing the m=application line, we add the AVStream (unless it's not part of the media_type_mask). Only once we parse rtpmap, we realize it's not a known codec - if we don't want that exposed to the caller, we'd have to remove the AVStream again - not as straightforward as one would like.

Another option would be to remove AVMEDIA_TYPE_DATA from the default media_type_mask, but mpeg2ts in rtp is signalled as that data type (that's about the only case where we actually do anything with a m=application stream in SDP at the moment).

// Martin
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to