[FFmpeg-devel] [PATCH] fix sdp(file) vs rtsp dep
Tue Nov 3 17:04:06 CET 2009
Diego Biurrun wrote:
> On Tue, Nov 03, 2009 at 12:00:49AM +0100, Luca Abeni wrote:
>> Here is the patch I am currently working on. I just compile-tested it
>> with some different configurations, and I tested the SDP demuxer.
>> If you can provide me with some "critical" configurations, tomorrow I'll
>> compile-test them. I'll also run some tests for the RTSP demuxer. Can
>> anyone provide me with some ms and real URLs for testing? (otherwise,
>> I'll just test standard RTSP).
> Try with the sdp demuxer and the rtsp demuxer separately disabled.
Ok; I already tried this, and everything seems to work as expected: when I
disable the SDP demuxer, the RTSP demuxer is disabled too (because it depends
on the SDP demuxer) and everything compiles fine. When I disable the RTSP
demuxer, the SDP demuxer still compiles and works without problems.
> I still wonder why all the SDP code resides in rtsp.c.
I do not know... I did not write this stuff :)
To make the situation even more funny, there are some SDP functions and
data structures which are named "rtsp something". I did not change all those
names, because the patch would become incredibly large.
> I would expect it in sdp.c.
I can do that... But then the patch would become even larger.
>> --- libavformat/rtsp.c (revision 20433)
>> +++ libavformat/rtsp.c (working copy)
>> @@ -43,19 +43,18 @@
>> +#if CONFIG_RTSP_DEMUXER
>> static int rtsp_read_play(AVFormatContext *s);
>> +static int tcp_read_packet(AVFormatContext *s, RTSPStream **prtsp_st,
>> + uint8_t *buf, int buf_size);
>> +static int rtsp_read_reply (AVFormatContext *s, RTSPMessageHeader *reply,
>> + unsigned char **content_ptr, int return_on_interleaved_data);
> Is the #if really necessary?
I got some warnings when compiling with RTSP disabled (functions declared
but not defined, or similar), so I added the #if to remove them.
I believe these forward declarations can be removed by reordering the
functions or moving some code around... But then the size of the patch
would increase again.
> Also, you could format newly added lines properly while you're at it.
Sorry, I just cut'n'pasted them without modifications... I'll fix this.
> Anyway, the patch is quite big. Maybe you could split it by first
> moving the functions around.
Ok; I'll try to do this when I'll find some more time to work on this
More information about the ffmpeg-devel