Re: [FFmpeg-devel] [PATCH] avformat/mpegts: make sure mpegts_read_header always stops at the first pmt
On Wed, 18 Nov 2020 at 20:11, Marton Balint wrote: > > > On Sun, 15 Nov 2020, Ross Nicholson wrote: > > > On Sat, 14 Nov 2020 at 23:40, Marton Balint wrote: > > > >> mpegts_read_header stops parsing the file at the first PMT. However the > >> check > >> that ensured this was wrong because streams can also be added before the > >> first > >> PMT is received (e.g. EIT). > >> > >> So let's make sure we are in the header reading phase by checking if > >> ts->pkt is > >> unset instead of checking if the number of streams found so far is 0. > >> > >> Signed-off-by: Marton Balint > >> --- > >> libavformat/mpegts.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c > >> index 80d010db6c..a2003c6632 100644 > >> --- a/libavformat/mpegts.c > >> +++ b/libavformat/mpegts.c > >> @@ -2355,7 +2355,7 @@ static void pmt_cb(MpegTSFilter *filter, const > >> uint8_t *section, int section_len > >> goto out; > >> > >> // stop parsing after pmt, we found header > >> -if (!ts->stream->nb_streams) > >> +if (!ts->pkt) > >> ts->stop_parse = 2; > >> > >> set_pmt_found(ts, h->id); > >> -- > >> 2.26.2 > >> > >> ___ > >> ffmpeg-devel mailing list > >> ffmpeg-devel@ffmpeg.org > >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >> > >> To unsubscribe, visit link above, or email > >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > > > > > Thanks for this. With this fix streams with embedded EIT data open in > > approx 1-1.5 seconds as opposed to 10-15 seconds without the fix. If > > possible also having this fix in the 4.3 branch as well as master would > be > > great. > > Ok, will apply and backport. > > Regards, > Marton > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". Thanks! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/mpegts: make sure mpegts_read_header always stops at the first pmt
On Sat, 14 Nov 2020 at 23:40, Marton Balint wrote: > mpegts_read_header stops parsing the file at the first PMT. However the > check > that ensured this was wrong because streams can also be added before the > first > PMT is received (e.g. EIT). > > So let's make sure we are in the header reading phase by checking if > ts->pkt is > unset instead of checking if the number of streams found so far is 0. > > Signed-off-by: Marton Balint > --- > libavformat/mpegts.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c > index 80d010db6c..a2003c6632 100644 > --- a/libavformat/mpegts.c > +++ b/libavformat/mpegts.c > @@ -2355,7 +2355,7 @@ static void pmt_cb(MpegTSFilter *filter, const > uint8_t *section, int section_len > goto out; > > // stop parsing after pmt, we found header > -if (!ts->stream->nb_streams) > +if (!ts->pkt) > ts->stop_parse = 2; > > set_pmt_found(ts, h->id); > -- > 2.26.2 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". Thanks for this. With this fix streams with embedded EIT data open in approx 1-1.5 seconds as opposed to 10-15 seconds without the fix. If possible also having this fix in the 4.3 branch as well as master would be great. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/rtsp: Put strings instead of pointers to strings into array
> On 20 Apr 2020, at 02:42, Andreas Rheinhardt
> wrote:
>
> In this example, the difference in length between the shortest and
> longest string is three, so that not using pointers to strings saves
> space even on 32bit systems.
>
> Moreover, there is no need to use a sentinel here; it can be replaced
> with FF_ARRAY_ELEMS.
Thanks, again.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> I have to admit that this is untested.
>
> libavformat/rtsp.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> index 0a6462000d..b2b3f32011 100644
> --- a/libavformat/rtsp.c
> +++ b/libavformat/rtsp.c
> @@ -2526,10 +2526,11 @@ static int rtp_read_header(AVFormatContext *s)
>
> p = strchr(s->url, '?');
> if (p) {
> -static const char *filters[][2] = {{"sources", "incl"}, {"block",
> "excl"}, {NULL, NULL}};
> +static const char filters[][2][8] = { { "sources", "incl" },
> + { "block", "excl" } };
> int i;
> char *q;
> -for (i = 0; filters[i][0]; i++) {
> +for (i = 0; i < FF_ARRAY_ELEMS(filters); i++) {
> if (av_find_info_tag(filters_buf, sizeof(filters_buf),
> filters[i][0], p)) {
> q = filters_buf;
> while ((q = strchr(q, ',')) != NULL)
> --
> 2.20.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/rtsp: Don't free uninitialized AVBPrint
> On 20 Apr 2020, at 08:53, Marton Balint wrote: > > > >> On Mon, 20 Apr 2020, Andreas Rheinhardt wrote: >> >> Fixes Coverity ID 1462307. >> >> Signed-off-by: Andreas Rheinhardt >> --- >> I intend to apply this soon if there are no objections. >> >> libavformat/rtsp.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c >> index 49f7644fab..0a6462000d 100644 >> --- a/libavformat/rtsp.c >> +++ b/libavformat/rtsp.c >> @@ -2567,8 +2567,8 @@ static int rtp_read_header(AVFormatContext *s) >> fail_nobuf: >>ret = AVERROR(ENOMEM); >>av_log(s, AV_LOG_ERROR, "rtp_read_header(): not enough buffer space for >> sdp-headers\n"); >> -fail: >>av_bprint_finalize(, NULL); >> +fail: >>avcodec_parameters_free(); >>if (in) >>ffurl_close(in); > > LGTM thanks. I guess this rtsp fix has a series of bad luck :) Man, and I was sure the last version was good. Thanks Andreas for fixing up. > > Regards, > Marton > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/rtp: Pass sources and block filter addresses via sdp file for rtp
> On 19 Apr 2020, at 20:30, Carl Eugen Hoyos wrote: > > Am So., 19. Apr. 2020 um 20:45 Uhr schrieb Ross Nicholson > : >> >> That’s really strange all my git config’s are just phunkyfish. >> >> I don’t really mind which name is used but I guess I’ll update >> everything to my real name going forward now that you mention it. > > It is completely your decision which "name" you choose for > your commits (invented or real) but please avoid top-posting > on all FFmpeg mailing lists. > > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". Apologies Carl. I only just learned what top-posting is. Won’t happen again. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/rtp: Pass sources and block filter addresses via sdp file for rtp
That’s really strange all my git config’s are just phunkyfish. I don’t really mind which name is used but I guess I’ll update everything to my real name going forward now that you mention it. > On 19 Apr 2020, at 18:55, Jean-Baptiste Kempf wrote: > > On Sun, Apr 19, 2020, at 16:28, Ross Nicholson wrote: >> How do you mean? What’s that problem? > > You've used Ross Nicholson for committing, and now you > only use > phunkyfish . > > Since you are not anonymous, why not use your actual name? > > > -- > Jean-Baptiste Kempf - President > +33 672 704 734 > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/rtp: Pass sources and block filter addresses via sdp file for rtp
How do you mean? What’s that problem?
I generally just use phunkyfish as the name and it’s corresponding gmail
address for stuff.
Do you require my real name for git?
> On 19 Apr 2020, at 14:23, Jean-Baptiste Kempf wrote:
>
> Ross,
>
> Could you, please, fix your git email and name?
>
> Thanks
>
>> On Fri, Apr 17, 2020, at 13:07, Ross Nicholson wrote:
>> Ping
>>
>>>> On 15 Apr 2020, at 17:21, Ross Nicholson wrote:
>>>
>>>
>>> Ping to hopefully apply this patch!
>>>
>>>>> On 12 Apr 2020, at 16:54, Ross Nicholson wrote:
>>>>>
>>>>
>>>> User testing has been completed successfully so this is ready to be
>>>> applied.
>>>>
>>>> Thanks
>>>>
>>>>>> On 7 Apr 2020, at 23:50, Ross Nicholson wrote:
>>>>>>
>>>>>
>>>>> Thank you for the explanation Marton. It's make perfect sense to me know.
>>>>> So UNLIMITED would be the right choice here.
>>>>>
>>>>> All of your other comments are addressed in the latest version. Thanks
>>>>> again for reviewing.
>>>>>
>>>>>> On Tue, 7 Apr 2020 at 22:03, Marton Balint wrote:
>>>>>>
>>>>>>
>>>>>> On Tue, 7 Apr 2020, Ross Nicholson wrote:
>>>>>>
>>>>>>> Great, thanks again.
>>>>>>>
>>>>>>> A question about AV_BPRINT_SIZE_AUTOMATIC. Is there a heuristic for
>>>>>>> when to use this versus unlimited?
>>>>>>>
>>>>>>> Or is it that generally if you would have used a buffer of 1000 or less
>>>>>>> automatic is the right choice?
>>>>>>
>>>>>> It depends on what you want. With AUTOMATIC you limit length to 1000
>>>>>> chars
>>>>>> but you don't have to free the buffer. Otherwise you are not limiting
>>>>>> the
>>>>>> buffer size, but you have to free it. So if it is impossible to hit the
>>>>>> limit, you should always use AUTOMATIC.
>>>>>>
>>>>>> In this case you have to decide for yourself which to use, because I
>>>>>> don't
>>>>>> know if 1000 char buffer is big enough for the possible use cases. I
>>>>>> only suggested to consider it, because you are using limited buffers for
>>>>>> other strings, so it may not even be possible to outgrow 1000 chars. It
>>>>>> is
>>>>>> up to you decide depending on what you want to support.
>>>>>>
>>>>>> Regards,
>>>>>> Marton
>>>>>>
>>>>>>>
>>>>>>>> On 7 Apr 2020, at 20:50, Marton Balint wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Tue, 7 Apr 2020, phunkyfish wrote:
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>> libavformat/rtsp.c | 48 +-
>>>>>>>>> 1 file changed, 39 insertions(+), 9 deletions(-)
>>>>>>>>>
>>>>>>>>> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
>>>>>>>>> index cd6fc32a29..dad3f7915e 100644
>>>>>>>>> --- a/libavformat/rtsp.c
>>>>>>>>> +++ b/libavformat/rtsp.c
>>>>>>>>> @@ -21,6 +21,7 @@
>>>>>>>>> #include "libavutil/avassert.h"
>>>>>>>>> #include "libavutil/base64.h"
>>>>>>>>> +#include "libavutil/bprint.h"
>>>>>>>>> #include "libavutil/avstring.h"
>>>>>>>>> #include "libavutil/intreadwrite.h"
>>>>>>>>> #include "libavutil/mathematics.h"
>>>>>>>>> @@ -2447,7 +2448,7 @@ static int rtp_probe(const AVProbeData *p)
>>>>>>>>> static int rtp_read_header(AVFormatContext *s)
>>>>>>>>> {
>>>>>>>>> uint8_t recvbuf[RTP_MAX_PACKET_LENGTH];
>>>>>>>>> -char host[500], sdp[500];
>>>>>>>>> +char host[500], filters_buf[1000];
>>>>>>>>>
Re: [FFmpeg-devel] [PATCH] avformat/rtp: Pass sources and block filter addresses via sdp file for rtp
Ping
> On 15 Apr 2020, at 17:21, Ross Nicholson wrote:
>
>
> Ping to hopefully apply this patch!
>
>>> On 12 Apr 2020, at 16:54, Ross Nicholson wrote:
>>>
>>
>> User testing has been completed successfully so this is ready to be applied.
>>
>> Thanks
>>
>>>> On 7 Apr 2020, at 23:50, Ross Nicholson wrote:
>>>>
>>>
>>> Thank you for the explanation Marton. It's make perfect sense to me know.
>>> So UNLIMITED would be the right choice here.
>>>
>>> All of your other comments are addressed in the latest version. Thanks
>>> again for reviewing.
>>>
>>>> On Tue, 7 Apr 2020 at 22:03, Marton Balint wrote:
>>>>
>>>>
>>>> On Tue, 7 Apr 2020, Ross Nicholson wrote:
>>>>
>>>> > Great, thanks again.
>>>> >
>>>> > A question about AV_BPRINT_SIZE_AUTOMATIC. Is there a heuristic for when
>>>> > to use this versus unlimited?
>>>> >
>>>> > Or is it that generally if you would have used a buffer of 1000 or less
>>>> > automatic is the right choice?
>>>>
>>>> It depends on what you want. With AUTOMATIC you limit length to 1000 chars
>>>> but you don't have to free the buffer. Otherwise you are not limiting the
>>>> buffer size, but you have to free it. So if it is impossible to hit the
>>>> limit, you should always use AUTOMATIC.
>>>>
>>>> In this case you have to decide for yourself which to use, because I don't
>>>> know if 1000 char buffer is big enough for the possible use cases. I
>>>> only suggested to consider it, because you are using limited buffers for
>>>> other strings, so it may not even be possible to outgrow 1000 chars. It is
>>>> up to you decide depending on what you want to support.
>>>>
>>>> Regards,
>>>> Marton
>>>>
>>>> >
>>>> >> On 7 Apr 2020, at 20:50, Marton Balint wrote:
>>>> >>
>>>> >>
>>>> >>
>>>> >>> On Tue, 7 Apr 2020, phunkyfish wrote:
>>>> >>>
>>>> >>> ---
>>>> >>> libavformat/rtsp.c | 48 +-
>>>> >>> 1 file changed, 39 insertions(+), 9 deletions(-)
>>>> >>>
>>>> >>> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
>>>> >>> index cd6fc32a29..dad3f7915e 100644
>>>> >>> --- a/libavformat/rtsp.c
>>>> >>> +++ b/libavformat/rtsp.c
>>>> >>> @@ -21,6 +21,7 @@
>>>> >>> #include "libavutil/avassert.h"
>>>> >>> #include "libavutil/base64.h"
>>>> >>> +#include "libavutil/bprint.h"
>>>> >>> #include "libavutil/avstring.h"
>>>> >>> #include "libavutil/intreadwrite.h"
>>>> >>> #include "libavutil/mathematics.h"
>>>> >>> @@ -2447,7 +2448,7 @@ static int rtp_probe(const AVProbeData *p)
>>>> >>> static int rtp_read_header(AVFormatContext *s)
>>>> >>> {
>>>> >>>uint8_t recvbuf[RTP_MAX_PACKET_LENGTH];
>>>> >>> -char host[500], sdp[500];
>>>> >>> +char host[500], filters_buf[1000];
>>>> >>>int ret, port;
>>>> >>>URLContext* in = NULL;
>>>> >>>int payload_type;
>>>> >>> @@ -2456,6 +2457,8 @@ static int rtp_read_header(AVFormatContext *s)
>>>> >>>AVIOContext pb;
>>>> >>>socklen_t addrlen = sizeof(addr);
>>>> >>>RTSPState *rt = s->priv_data;
>>>> >>> +const char *p;
>>>> >>> +AVBPrint sdp;
>>>> >>>
>>>> >>>if (!ff_network_init())
>>>> >>>return AVERROR(EIO);
>>>> >>> @@ -2513,16 +2516,38 @@ static int rtp_read_header(AVFormatContext *s)
>>>> >>>av_url_split(NULL, 0, NULL, 0, host, sizeof(host), ,
>>>> >>> NULL, 0, s->url);
>>>> >>> -snprintf(sdp, sizeof(sdp),
>>>> >>> - "v=0\r\nc=IN IP%d %s\r\nm=%s %d RTP/AVP %d\r\n",
>>>> &
Re: [FFmpeg-devel] [PATCH] avformat/rtp: Pass sources and block filter addresses via sdp file for rtp
Ping to hopefully apply this patch!
> On 12 Apr 2020, at 16:54, Ross Nicholson wrote:
>
>
> User testing has been completed successfully so this is ready to be applied.
>
> Thanks
>
>>> On 7 Apr 2020, at 23:50, Ross Nicholson wrote:
>>>
>>
>> Thank you for the explanation Marton. It's make perfect sense to me know. So
>> UNLIMITED would be the right choice here.
>>
>> All of your other comments are addressed in the latest version. Thanks again
>> for reviewing.
>>
>>> On Tue, 7 Apr 2020 at 22:03, Marton Balint wrote:
>>>
>>>
>>> On Tue, 7 Apr 2020, Ross Nicholson wrote:
>>>
>>> > Great, thanks again.
>>> >
>>> > A question about AV_BPRINT_SIZE_AUTOMATIC. Is there a heuristic for when
>>> > to use this versus unlimited?
>>> >
>>> > Or is it that generally if you would have used a buffer of 1000 or less
>>> > automatic is the right choice?
>>>
>>> It depends on what you want. With AUTOMATIC you limit length to 1000 chars
>>> but you don't have to free the buffer. Otherwise you are not limiting the
>>> buffer size, but you have to free it. So if it is impossible to hit the
>>> limit, you should always use AUTOMATIC.
>>>
>>> In this case you have to decide for yourself which to use, because I don't
>>> know if 1000 char buffer is big enough for the possible use cases. I
>>> only suggested to consider it, because you are using limited buffers for
>>> other strings, so it may not even be possible to outgrow 1000 chars. It is
>>> up to you decide depending on what you want to support.
>>>
>>> Regards,
>>> Marton
>>>
>>> >
>>> >> On 7 Apr 2020, at 20:50, Marton Balint wrote:
>>> >>
>>> >>
>>> >>
>>> >>> On Tue, 7 Apr 2020, phunkyfish wrote:
>>> >>>
>>> >>> ---
>>> >>> libavformat/rtsp.c | 48 +-
>>> >>> 1 file changed, 39 insertions(+), 9 deletions(-)
>>> >>>
>>> >>> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
>>> >>> index cd6fc32a29..dad3f7915e 100644
>>> >>> --- a/libavformat/rtsp.c
>>> >>> +++ b/libavformat/rtsp.c
>>> >>> @@ -21,6 +21,7 @@
>>> >>> #include "libavutil/avassert.h"
>>> >>> #include "libavutil/base64.h"
>>> >>> +#include "libavutil/bprint.h"
>>> >>> #include "libavutil/avstring.h"
>>> >>> #include "libavutil/intreadwrite.h"
>>> >>> #include "libavutil/mathematics.h"
>>> >>> @@ -2447,7 +2448,7 @@ static int rtp_probe(const AVProbeData *p)
>>> >>> static int rtp_read_header(AVFormatContext *s)
>>> >>> {
>>> >>>uint8_t recvbuf[RTP_MAX_PACKET_LENGTH];
>>> >>> -char host[500], sdp[500];
>>> >>> +char host[500], filters_buf[1000];
>>> >>>int ret, port;
>>> >>>URLContext* in = NULL;
>>> >>>int payload_type;
>>> >>> @@ -2456,6 +2457,8 @@ static int rtp_read_header(AVFormatContext *s)
>>> >>>AVIOContext pb;
>>> >>>socklen_t addrlen = sizeof(addr);
>>> >>>RTSPState *rt = s->priv_data;
>>> >>> +const char *p;
>>> >>> +AVBPrint sdp;
>>> >>>
>>> >>>if (!ff_network_init())
>>> >>>return AVERROR(EIO);
>>> >>> @@ -2513,16 +2516,38 @@ static int rtp_read_header(AVFormatContext *s)
>>> >>>av_url_split(NULL, 0, NULL, 0, host, sizeof(host), ,
>>> >>> NULL, 0, s->url);
>>> >>> -snprintf(sdp, sizeof(sdp),
>>> >>> - "v=0\r\nc=IN IP%d %s\r\nm=%s %d RTP/AVP %d\r\n",
>>> >>> - addr.ss_family == AF_INET ? 4 : 6, host,
>>> >>> - par->codec_type == AVMEDIA_TYPE_DATA ? "application" :
>>> >>> - par->codec_type == AVMEDIA_TYPE_VIDEO ? "video" : "audio",
>>> >>> - port, payload_type);
>>> >>> -av_log(s, AV_LOG_VERBOSE, "SDP:\n%s\n", sdp);
>>>
Re: [FFmpeg-devel] [PATCH] avformat/rtp: Pass sources and block filter addresses via sdp file for rtp
User testing has been completed successfully so this is ready to be applied.
Thanks
> On 7 Apr 2020, at 23:50, Ross Nicholson wrote:
>
>
> Thank you for the explanation Marton. It's make perfect sense to me know. So
> UNLIMITED would be the right choice here.
>
> All of your other comments are addressed in the latest version. Thanks again
> for reviewing.
>
>> On Tue, 7 Apr 2020 at 22:03, Marton Balint wrote:
>>
>>
>> On Tue, 7 Apr 2020, Ross Nicholson wrote:
>>
>> > Great, thanks again.
>> >
>> > A question about AV_BPRINT_SIZE_AUTOMATIC. Is there a heuristic for when
>> > to use this versus unlimited?
>> >
>> > Or is it that generally if you would have used a buffer of 1000 or less
>> > automatic is the right choice?
>>
>> It depends on what you want. With AUTOMATIC you limit length to 1000 chars
>> but you don't have to free the buffer. Otherwise you are not limiting the
>> buffer size, but you have to free it. So if it is impossible to hit the
>> limit, you should always use AUTOMATIC.
>>
>> In this case you have to decide for yourself which to use, because I don't
>> know if 1000 char buffer is big enough for the possible use cases. I
>> only suggested to consider it, because you are using limited buffers for
>> other strings, so it may not even be possible to outgrow 1000 chars. It is
>> up to you decide depending on what you want to support.
>>
>> Regards,
>> Marton
>>
>> >
>> >> On 7 Apr 2020, at 20:50, Marton Balint wrote:
>> >>
>> >>
>> >>
>> >>> On Tue, 7 Apr 2020, phunkyfish wrote:
>> >>>
>> >>> ---
>> >>> libavformat/rtsp.c | 48 +-
>> >>> 1 file changed, 39 insertions(+), 9 deletions(-)
>> >>>
>> >>> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
>> >>> index cd6fc32a29..dad3f7915e 100644
>> >>> --- a/libavformat/rtsp.c
>> >>> +++ b/libavformat/rtsp.c
>> >>> @@ -21,6 +21,7 @@
>> >>> #include "libavutil/avassert.h"
>> >>> #include "libavutil/base64.h"
>> >>> +#include "libavutil/bprint.h"
>> >>> #include "libavutil/avstring.h"
>> >>> #include "libavutil/intreadwrite.h"
>> >>> #include "libavutil/mathematics.h"
>> >>> @@ -2447,7 +2448,7 @@ static int rtp_probe(const AVProbeData *p)
>> >>> static int rtp_read_header(AVFormatContext *s)
>> >>> {
>> >>>uint8_t recvbuf[RTP_MAX_PACKET_LENGTH];
>> >>> -char host[500], sdp[500];
>> >>> +char host[500], filters_buf[1000];
>> >>>int ret, port;
>> >>>URLContext* in = NULL;
>> >>>int payload_type;
>> >>> @@ -2456,6 +2457,8 @@ static int rtp_read_header(AVFormatContext *s)
>> >>>AVIOContext pb;
>> >>>socklen_t addrlen = sizeof(addr);
>> >>>RTSPState *rt = s->priv_data;
>> >>> +const char *p;
>> >>> +AVBPrint sdp;
>> >>>
>> >>>if (!ff_network_init())
>> >>>return AVERROR(EIO);
>> >>> @@ -2513,16 +2516,38 @@ static int rtp_read_header(AVFormatContext *s)
>> >>>av_url_split(NULL, 0, NULL, 0, host, sizeof(host), ,
>> >>> NULL, 0, s->url);
>> >>> -snprintf(sdp, sizeof(sdp),
>> >>> - "v=0\r\nc=IN IP%d %s\r\nm=%s %d RTP/AVP %d\r\n",
>> >>> - addr.ss_family == AF_INET ? 4 : 6, host,
>> >>> - par->codec_type == AVMEDIA_TYPE_DATA ? "application" :
>> >>> - par->codec_type == AVMEDIA_TYPE_VIDEO ? "video" : "audio",
>> >>> - port, payload_type);
>> >>> -av_log(s, AV_LOG_VERBOSE, "SDP:\n%s\n", sdp);
>> >>> +av_bprint_init(, 0, AV_BPRINT_SIZE_UNLIMITED);
>> >>
>> >> You may also use AV_BPRINT_SIZE_AUTOMATIC in which case you will get a
>> >> static buffer which will be limited (roughly 1000 chars) but you don't
>> >> have to free it with av_bprint_finalize().
>> >>
>> >>> +av_bprintf(, "v=0\r\nc=IN IP%d %s\r\n",
>> >>> + addr.ss_family == AF_INE
Re: [FFmpeg-devel] [PATCH] avformat/rtp: Pass sources and block filter addresses via sdp file for rtp
Thank you for the explanation Marton. It's make perfect sense to me know.
So UNLIMITED would be the right choice here.
All of your other comments are addressed in the latest version. Thanks
again for reviewing.
On Tue, 7 Apr 2020 at 22:03, Marton Balint wrote:
>
>
> On Tue, 7 Apr 2020, Ross Nicholson wrote:
>
> > Great, thanks again.
> >
> > A question about AV_BPRINT_SIZE_AUTOMATIC. Is there a heuristic for when
> to use this versus unlimited?
> >
> > Or is it that generally if you would have used a buffer of 1000 or less
> automatic is the right choice?
>
> It depends on what you want. With AUTOMATIC you limit length to 1000 chars
> but you don't have to free the buffer. Otherwise you are not limiting the
> buffer size, but you have to free it. So if it is impossible to hit the
> limit, you should always use AUTOMATIC.
>
> In this case you have to decide for yourself which to use, because I don't
> know if 1000 char buffer is big enough for the possible use cases. I
> only suggested to consider it, because you are using limited buffers for
> other strings, so it may not even be possible to outgrow 1000 chars. It is
> up to you decide depending on what you want to support.
>
> Regards,
> Marton
>
> >
> >> On 7 Apr 2020, at 20:50, Marton Balint wrote:
> >>
> >>
> >>
> >>> On Tue, 7 Apr 2020, phunkyfish wrote:
> >>>
> >>> ---
> >>> libavformat/rtsp.c | 48 +-
> >>> 1 file changed, 39 insertions(+), 9 deletions(-)
> >>>
> >>> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> >>> index cd6fc32a29..dad3f7915e 100644
> >>> --- a/libavformat/rtsp.c
> >>> +++ b/libavformat/rtsp.c
> >>> @@ -21,6 +21,7 @@
> >>> #include "libavutil/avassert.h"
> >>> #include "libavutil/base64.h"
> >>> +#include "libavutil/bprint.h"
> >>> #include "libavutil/avstring.h"
> >>> #include "libavutil/intreadwrite.h"
> >>> #include "libavutil/mathematics.h"
> >>> @@ -2447,7 +2448,7 @@ static int rtp_probe(const AVProbeData *p)
> >>> static int rtp_read_header(AVFormatContext *s)
> >>> {
> >>>uint8_t recvbuf[RTP_MAX_PACKET_LENGTH];
> >>> -char host[500], sdp[500];
> >>> +char host[500], filters_buf[1000];
> >>>int ret, port;
> >>>URLContext* in = NULL;
> >>>int payload_type;
> >>> @@ -2456,6 +2457,8 @@ static int rtp_read_header(AVFormatContext *s)
> >>>AVIOContext pb;
> >>>socklen_t addrlen = sizeof(addr);
> >>>RTSPState *rt = s->priv_data;
> >>> +const char *p;
> >>> +AVBPrint sdp;
> >>>
> >>>if (!ff_network_init())
> >>>return AVERROR(EIO);
> >>> @@ -2513,16 +2516,38 @@ static int rtp_read_header(AVFormatContext *s)
> >>>av_url_split(NULL, 0, NULL, 0, host, sizeof(host), ,
> >>> NULL, 0, s->url);
> >>> -snprintf(sdp, sizeof(sdp),
> >>> - "v=0\r\nc=IN IP%d %s\r\nm=%s %d RTP/AVP %d\r\n",
> >>> - addr.ss_family == AF_INET ? 4 : 6, host,
> >>> - par->codec_type == AVMEDIA_TYPE_DATA ? "application" :
> >>> - par->codec_type == AVMEDIA_TYPE_VIDEO ? "video" :
> "audio",
> >>> - port, payload_type);
> >>> -av_log(s, AV_LOG_VERBOSE, "SDP:\n%s\n", sdp);
> >>> +av_bprint_init(, 0, AV_BPRINT_SIZE_UNLIMITED);
> >>
> >> You may also use AV_BPRINT_SIZE_AUTOMATIC in which case you will get a
> static buffer which will be limited (roughly 1000 chars) but you don't have
> to free it with av_bprint_finalize().
> >>
> >>> +av_bprintf(, "v=0\r\nc=IN IP%d %s\r\n",
> >>> + addr.ss_family == AF_INET ? 4 : 6, host);
> >>> +
> >>> +p = strchr(s->url, '?');
> >>> +if (p) {
> >>> +static const char *filters[][2] = {{"sources", "incl"},
> {"block", "excl"}, {NULL, NULL}};
> >>> +int i;
> >>> +char *q;
> >>> +for (i = 0; filters[i][0]; i++) {
> >>> +if (av_find_info_tag(filters_buf, sizeof(filters_buf),
> filters[i][0], p)) {
> >>> +q = filters_buf;
> >>
Re: [FFmpeg-devel] [PATCH] avformat/rtp: Pass sources and block filter addresses via sdp file for rtp
Great, thanks again.
A question about AV_BPRINT_SIZE_AUTOMATIC. Is there a heuristic for when to use
this versus unlimited?
Or is it that generally if you would have used a buffer of 1000 or less
automatic is the right choice?
> On 7 Apr 2020, at 20:50, Marton Balint wrote:
>
>
>
>> On Tue, 7 Apr 2020, phunkyfish wrote:
>>
>> ---
>> libavformat/rtsp.c | 48 +-
>> 1 file changed, 39 insertions(+), 9 deletions(-)
>>
>> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
>> index cd6fc32a29..dad3f7915e 100644
>> --- a/libavformat/rtsp.c
>> +++ b/libavformat/rtsp.c
>> @@ -21,6 +21,7 @@
>> #include "libavutil/avassert.h"
>> #include "libavutil/base64.h"
>> +#include "libavutil/bprint.h"
>> #include "libavutil/avstring.h"
>> #include "libavutil/intreadwrite.h"
>> #include "libavutil/mathematics.h"
>> @@ -2447,7 +2448,7 @@ static int rtp_probe(const AVProbeData *p)
>> static int rtp_read_header(AVFormatContext *s)
>> {
>>uint8_t recvbuf[RTP_MAX_PACKET_LENGTH];
>> -char host[500], sdp[500];
>> +char host[500], filters_buf[1000];
>>int ret, port;
>>URLContext* in = NULL;
>>int payload_type;
>> @@ -2456,6 +2457,8 @@ static int rtp_read_header(AVFormatContext *s)
>>AVIOContext pb;
>>socklen_t addrlen = sizeof(addr);
>>RTSPState *rt = s->priv_data;
>> +const char *p;
>> +AVBPrint sdp;
>>
>>if (!ff_network_init())
>>return AVERROR(EIO);
>> @@ -2513,16 +2516,38 @@ static int rtp_read_header(AVFormatContext *s)
>>av_url_split(NULL, 0, NULL, 0, host, sizeof(host), ,
>> NULL, 0, s->url);
>> -snprintf(sdp, sizeof(sdp),
>> - "v=0\r\nc=IN IP%d %s\r\nm=%s %d RTP/AVP %d\r\n",
>> - addr.ss_family == AF_INET ? 4 : 6, host,
>> - par->codec_type == AVMEDIA_TYPE_DATA ? "application" :
>> - par->codec_type == AVMEDIA_TYPE_VIDEO ? "video" : "audio",
>> - port, payload_type);
>> -av_log(s, AV_LOG_VERBOSE, "SDP:\n%s\n", sdp);
>> +av_bprint_init(, 0, AV_BPRINT_SIZE_UNLIMITED);
>
> You may also use AV_BPRINT_SIZE_AUTOMATIC in which case you will get a static
> buffer which will be limited (roughly 1000 chars) but you don't have to free
> it with av_bprint_finalize().
>
>> +av_bprintf(, "v=0\r\nc=IN IP%d %s\r\n",
>> + addr.ss_family == AF_INET ? 4 : 6, host);
>> +
>> +p = strchr(s->url, '?');
>> +if (p) {
>> +static const char *filters[][2] = {{"sources", "incl"}, {"block",
>> "excl"}, {NULL, NULL}};
>> +int i;
>> +char *q;
>> +for (i = 0; filters[i][0]; i++) {
>> +if (av_find_info_tag(filters_buf, sizeof(filters_buf),
>> filters[i][0], p)) {
>> +q = filters_buf;
>> +while ((q = strchr(q, ',')) != NULL)
>> +*q = ' ';
>> +av_bprintf(, "a=source-filter:%s IN IP%d %s %s\r\n",
>> + filters[i][1],
>> + addr.ss_family == AF_INET ? 4 : 6, host,
>> + filters_buf);
>> +}
>> +}
>> +}
>> +
>> +av_bprintf(, "m=%s %d RTP/AVP %d\r\n",
>> + par->codec_type == AVMEDIA_TYPE_DATA ? "application" :
>> + par->codec_type == AVMEDIA_TYPE_VIDEO ? "video" : "audio",
>> + port, payload_type);
>> +av_log(s, AV_LOG_VERBOSE, "SDP:\n%s\n", sdp.str);
>> +if (av_bprint_is_complete())
>
> I think this check should be negated here, because you want to report error
> if the buffer is truncated, not if it is complete.
>
>> +goto fail_nobuf;
>>avcodec_parameters_free();
>> -ffio_init_context(, sdp, strlen(sdp), 0, NULL, NULL, NULL, NULL);
>> +ffio_init_context(, sdp.str, strlen(sdp.str), 0, NULL, NULL, NULL,
>> NULL);
>
> You can use sdp.len instead of strlen().
>
>>s->pb =
>>
>>/* sdp_read_header initializes this again */
>> @@ -2532,9 +2557,14 @@ static int rtp_read_header(AVFormatContext *s)
>>
>>ret = sdp_read_header(s);
>>s->pb = NULL;
>> +av_bprint_finalize(, NULL);
>>return ret;
>> +fail_nobuf:
>> +ret = AVERROR(ENOMEM);
>> +av_log(s, AV_LOG_ERROR, "rtp_read_header(): not enough buffer space for
>> sdp-headers\n");
>> fail:
>> +av_bprint_finalize(, NULL);
>>avcodec_parameters_free();
>>if (in)
>>ffurl_close(in);
>
> Regards,
> Marton
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/rtp: Pass sources and block filter addresses via sdp file for rtp
Hey Nicolas,
Thanks for the review. I have incorporated your comments in the latest
version.
I have to get some users local to the problematic streams to do the
testing, they are not available in my region. It has made it somewhat
problematic to get this far ;)
phunkyfish
On Mon, 6 Apr 2020 at 23:36, Nicolas George wrote:
> phunkyfish (12020-04-06):
> > ---
> > libavformat/rtsp.c | 50 +-
> > 1 file changed, 41 insertions(+), 9 deletions(-)
> >
> > diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> > index cd6fc32a29..2b59a9330d 100644
> > --- a/libavformat/rtsp.c
> > +++ b/libavformat/rtsp.c
> > @@ -21,6 +21,7 @@
> >
> > #include "libavutil/avassert.h"
> > #include "libavutil/base64.h"
> > +#include "libavutil/bprint.h"
> > #include "libavutil/avstring.h"
> > #include "libavutil/intreadwrite.h"
> > #include "libavutil/mathematics.h"
> > @@ -2447,7 +2448,7 @@ static int rtp_probe(const AVProbeData *p)
> > static int rtp_read_header(AVFormatContext *s)
> > {
> > uint8_t recvbuf[RTP_MAX_PACKET_LENGTH];
> > -char host[500], sdp[500];
> > +char host[500], filters_buf[1000];
> > int ret, port;
> > URLContext* in = NULL;
> > int payload_type;
> > @@ -2456,6 +2457,8 @@ static int rtp_read_header(AVFormatContext *s)
> > AVIOContext pb;
> > socklen_t addrlen = sizeof(addr);
> > RTSPState *rt = s->priv_data;
> > +const char *p;
> > +AVBPrint sdp;
> >
> > if (!ff_network_init())
> > return AVERROR(EIO);
> > @@ -2513,16 +2516,40 @@ static int rtp_read_header(AVFormatContext *s)
> > av_url_split(NULL, 0, NULL, 0, host, sizeof(host), ,
> > NULL, 0, s->url);
> >
> > -snprintf(sdp, sizeof(sdp),
> > - "v=0\r\nc=IN IP%d %s\r\nm=%s %d RTP/AVP %d\r\n",
> > - addr.ss_family == AF_INET ? 4 : 6, host,
> > - par->codec_type == AVMEDIA_TYPE_DATA ? "application" :
> > - par->codec_type == AVMEDIA_TYPE_VIDEO ? "video" : "audio",
> > - port, payload_type);
> > -av_log(s, AV_LOG_VERBOSE, "SDP:\n%s\n", sdp);
> > +av_bprint_init(, 0, AV_BPRINT_SIZE_UNLIMITED);
> > +av_bprintf(, "v=0\r\nc=IN IP%d %s\r\n",
> > + addr.ss_family == AF_INET ? 4 : 6, host);
> > +
> > +p = strchr(s->url, '?');
> > +if (p) {
> > +static const char *filters[][2] = {{"sources", "incl"},
> {"block", "excl"}, {NULL, NULL}};
> > +int i;
> > +char *q;
> > +for (i = 0; filters[i][0]; i++) {
> > +if (av_find_info_tag(filters_buf, sizeof(filters_buf),
> filters[i][0], p)) {
> > +q = filters_buf;
> > +while ((q = strchr(q, ',')) != NULL)
> > +*q = ' ';
> > +av_bprintf(, "a=source-filter:%s IN IP%d %s %s\r\n",
> > + filters[i][1],
> > + addr.ss_family == AF_INET ? 4 : 6, host,
> > + filters_buf);
>
> > +if (sdp.len != sdp.size)
> > +goto fail_nobuf;
>
> Only check at the end.
>
> > +}
> > +}
> > +}
> > +
> > +av_bprintf(, "m=%s %d RTP/AVP %d\r\n",
> > + par->codec_type == AVMEDIA_TYPE_DATA ? "application" :
> > + par->codec_type == AVMEDIA_TYPE_VIDEO ? "video" :
> "audio",
> > + port, payload_type);
> > +av_log(s, AV_LOG_VERBOSE, "SDP:\n%s\n", sdp.str);
>
> > +if (sdp.len != sdp.size)
> > +goto fail_nobuf;
>
> av_bprint_is_complete(). Is this test even correct? Did you test the
> code?
>
> > avcodec_parameters_free();
> >
> > -ffio_init_context(, sdp, strlen(sdp), 0, NULL, NULL, NULL, NULL);
> > +ffio_init_context(, sdp.str, strlen(sdp.str), 0, NULL, NULL,
> NULL, NULL);
> > s->pb =
> >
> > /* sdp_read_header initializes this again */
> > @@ -2532,9 +2559,14 @@ static int rtp_read_header(AVFormatContext *s)
> >
> > ret = sdp_read_header(s);
> > s->pb = NULL;
> > +av_bprint_finalize(, NULL);
> > return ret;
> >
> > +fail_nobuf:
>
> > +ret = AVERROR(ENOBUFS);
>
> This is not the error code you are looking for.
>
> > +av_log(s, AV_LOG_ERROR, "rtp_read_header(): not enough buffer space
> for sdp-headers\n");
> > fail:
> > +av_bprint_finalize(, NULL);
> > avcodec_parameters_free();
> > if (in)
> > ffurl_close(in);
>
> Regards,
>
> --
> Nicolas George
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/rtp: Pass sources and block filter addresses via sdp file for rtp
Ok, latest patch uses AVBPrint. Please let me know if my usage is correct,
I have not used it before.
In the meantime I will get some users to test this.
On Mon, 6 Apr 2020 at 20:57, Marton Balint wrote:
>
>
> On Mon, 6 Apr 2020, phunkyfish wrote:
>
> > ---
> > libavformat/rtsp.c | 47 ++
> > 1 file changed, 39 insertions(+), 8 deletions(-)
> >
> > diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> > index cd6fc32a29..0d0bc2be0d 100644
> > --- a/libavformat/rtsp.c
> > +++ b/libavformat/rtsp.c
> > @@ -2447,8 +2447,8 @@ static int rtp_probe(const AVProbeData *p)
> > static int rtp_read_header(AVFormatContext *s)
> > {
> > uint8_t recvbuf[RTP_MAX_PACKET_LENGTH];
> > -char host[500], sdp[500];
> > -int ret, port;
> > +char host[500], sdp[1000], filters_buf[1000];
> > +int ret, port, sdp_length, nc;
> > URLContext* in = NULL;
> > int payload_type;
> > AVCodecParameters *par = NULL;
> > @@ -2456,6 +2456,7 @@ static int rtp_read_header(AVFormatContext *s)
> > AVIOContext pb;
> > socklen_t addrlen = sizeof(addr);
> > RTSPState *rt = s->priv_data;
> > +const char *p;
> >
> > if (!ff_network_init())
> > return AVERROR(EIO);
> > @@ -2513,13 +2514,40 @@ static int rtp_read_header(AVFormatContext *s)
> > av_url_split(NULL, 0, NULL, 0, host, sizeof(host), ,
> > NULL, 0, s->url);
> >
> > -snprintf(sdp, sizeof(sdp),
> > - "v=0\r\nc=IN IP%d %s\r\nm=%s %d RTP/AVP %d\r\n",
> > - addr.ss_family == AF_INET ? 4 : 6, host,
> > - par->codec_type == AVMEDIA_TYPE_DATA ? "application" :
> > - par->codec_type == AVMEDIA_TYPE_VIDEO ? "video" : "audio",
> > - port, payload_type);
> > +sdp_length = snprintf(sdp, sizeof(sdp),
> > + "v=0\r\nc=IN IP%d %s\r\n",
> > + addr.ss_family == AF_INET ? 4 : 6, host);
>
> Please use an AVBPrint buffer instead of snprintf()-ing to sdp.
>
> Thanks,
> Marton
>
> > +
> > +p = strchr(s->url, '?');
> > +if (p) {
> > +static const char *filters[][2] = {{"sources", "incl"},
> {"block", "excl"}, {NULL, NULL}};
> > +int i;
> > +char *q;
> > +for (i = 0; filters[i][0]; i++) {
> > +if (av_find_info_tag(filters_buf, sizeof(filters_buf),
> filters[i][0], p)) {
> > +q = filters_buf;
> > +while ((q = strchr(q, ',')) != NULL)
> > +*q = ' ';
> > +nc = snprintf(sdp + sdp_length, sizeof(sdp) -
> sdp_length,
> > + "a=source-filter:%s IN IP%d %s %s\r\n",
> > + filters[i][1],
> > + addr.ss_family == AF_INET ? 4 : 6, host,
> > + filters_buf);
> > +if (nc < 0 || nc + sdp_length >= sizeof(sdp))
> > +goto fail_nobuf;
> > +sdp_length += nc;
> > +}
> > +}
> > +}
> > +
> > +nc = snprintf(sdp + sdp_length, sizeof(sdp) - sdp_length,
> > + "m=%s %d RTP/AVP %d\r\n",
> > + par->codec_type == AVMEDIA_TYPE_DATA ? "application"
> :
> > + par->codec_type == AVMEDIA_TYPE_VIDEO ? "video" :
> "audio",
> > + port, payload_type);
> > av_log(s, AV_LOG_VERBOSE, "SDP:\n%s\n", sdp);
> > +if (nc < 0 || nc + sdp_length >= sizeof(sdp))
> > +goto fail_nobuf;
> > avcodec_parameters_free();
> >
> > ffio_init_context(, sdp, strlen(sdp), 0, NULL, NULL, NULL, NULL);
> > @@ -2534,6 +2562,9 @@ static int rtp_read_header(AVFormatContext *s)
> > s->pb = NULL;
> > return ret;
> >
> > +fail_nobuf:
> > +ret = AVERROR(ENOBUFS);
> > +av_log(s, AV_LOG_ERROR, "rtp_read_header(): not enough buffer space
> for sdp-headers\n");
> > fail:
> > avcodec_parameters_free();
> > if (in)
> > --
> > 2.24.1 (Apple Git-126)
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/rtp: Pass sources and block filter addresses via sdp file for rtp
> sdp_length is used uninitialized here it is used uninitialized in the
> version that was merged as b71685865fe761925feedda3cd0b288224d9a509. The
> newer versions [2], [3] don't exhibit this flaw.
>
> [3] and [1] also have a flaw in common that [2] and this one are
> lacking: The semicolon of the definition of const char *p is missing.
>
> Finally, neither of these versions here seems to have been based upon
> git master which contains a call to av_log() directly after the above
> snprintf.
>
> - Andreas
Andreas,
Apologies I did not get back to you sooner I was indisposed.
I have updated the patch now which should be correct, addressing your
comments.
On Mon, 6 Apr 2020 at 17:56, phunkyfish wrote:
> ---
> libavformat/rtsp.c | 47 ++
> 1 file changed, 39 insertions(+), 8 deletions(-)
>
> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> index cd6fc32a29..0d0bc2be0d 100644
> --- a/libavformat/rtsp.c
> +++ b/libavformat/rtsp.c
> @@ -2447,8 +2447,8 @@ static int rtp_probe(const AVProbeData *p)
> static int rtp_read_header(AVFormatContext *s)
> {
> uint8_t recvbuf[RTP_MAX_PACKET_LENGTH];
> -char host[500], sdp[500];
> -int ret, port;
> +char host[500], sdp[1000], filters_buf[1000];
> +int ret, port, sdp_length, nc;
> URLContext* in = NULL;
> int payload_type;
> AVCodecParameters *par = NULL;
> @@ -2456,6 +2456,7 @@ static int rtp_read_header(AVFormatContext *s)
> AVIOContext pb;
> socklen_t addrlen = sizeof(addr);
> RTSPState *rt = s->priv_data;
> +const char *p;
>
> if (!ff_network_init())
> return AVERROR(EIO);
> @@ -2513,13 +2514,40 @@ static int rtp_read_header(AVFormatContext *s)
> av_url_split(NULL, 0, NULL, 0, host, sizeof(host), ,
> NULL, 0, s->url);
>
> -snprintf(sdp, sizeof(sdp),
> - "v=0\r\nc=IN IP%d %s\r\nm=%s %d RTP/AVP %d\r\n",
> - addr.ss_family == AF_INET ? 4 : 6, host,
> - par->codec_type == AVMEDIA_TYPE_DATA ? "application" :
> - par->codec_type == AVMEDIA_TYPE_VIDEO ? "video" : "audio",
> - port, payload_type);
> +sdp_length = snprintf(sdp, sizeof(sdp),
> + "v=0\r\nc=IN IP%d %s\r\n",
> + addr.ss_family == AF_INET ? 4 : 6, host);
> +
> +p = strchr(s->url, '?');
> +if (p) {
> +static const char *filters[][2] = {{"sources", "incl"}, {"block",
> "excl"}, {NULL, NULL}};
> +int i;
> +char *q;
> +for (i = 0; filters[i][0]; i++) {
> +if (av_find_info_tag(filters_buf, sizeof(filters_buf),
> filters[i][0], p)) {
> +q = filters_buf;
> +while ((q = strchr(q, ',')) != NULL)
> +*q = ' ';
> +nc = snprintf(sdp + sdp_length, sizeof(sdp) - sdp_length,
> + "a=source-filter:%s IN IP%d %s %s\r\n",
> + filters[i][1],
> + addr.ss_family == AF_INET ? 4 : 6, host,
> + filters_buf);
> +if (nc < 0 || nc + sdp_length >= sizeof(sdp))
> +goto fail_nobuf;
> +sdp_length += nc;
> +}
> +}
> +}
> +
> +nc = snprintf(sdp + sdp_length, sizeof(sdp) - sdp_length,
> + "m=%s %d RTP/AVP %d\r\n",
> + par->codec_type == AVMEDIA_TYPE_DATA ? "application" :
> + par->codec_type == AVMEDIA_TYPE_VIDEO ? "video" :
> "audio",
> + port, payload_type);
> av_log(s, AV_LOG_VERBOSE, "SDP:\n%s\n", sdp);
> +if (nc < 0 || nc + sdp_length >= sizeof(sdp))
> +goto fail_nobuf;
> avcodec_parameters_free();
>
> ffio_init_context(, sdp, strlen(sdp), 0, NULL, NULL, NULL, NULL);
> @@ -2534,6 +2562,9 @@ static int rtp_read_header(AVFormatContext *s)
> s->pb = NULL;
> return ret;
>
> +fail_nobuf:
> +ret = AVERROR(ENOBUFS);
> +av_log(s, AV_LOG_ERROR, "rtp_read_header(): not enough buffer space
> for sdp-headers\n");
> fail:
> avcodec_parameters_free();
> if (in)
> --
> 2.24.1 (Apple Git-126)
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/rtp: Pass sources and block filter addresses via sdp file for rtp
This patch will correctly pass any sources or block filters from the URL via
SDP to the underlying protocol.
Example URL: rtp://232.0.10.234:1?sources=87.141.215.251
Prior to this patch the sources params would be ignored and the stream reading
would fail.
> On 4 Mar 2020, at 23:47, phunkyfish wrote:
>
> ---
> libavformat/rtsp.c | 48 ++
> 1 file changed, 40 insertions(+), 8 deletions(-)
>
> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> index cd6fc32a29..f6d66526b0 100644
> --- a/libavformat/rtsp.c
> +++ b/libavformat/rtsp.c
> @@ -2447,8 +2447,8 @@ static int rtp_probe(const AVProbeData *p)
> static int rtp_read_header(AVFormatContext *s)
> {
> uint8_t recvbuf[RTP_MAX_PACKET_LENGTH];
> -char host[500], sdp[500];
> -int ret, port;
> +char host[500], sdp[1000], filters_buf[1000];
> +int ret, port, sdp_length, nc;
> URLContext* in = NULL;
> int payload_type;
> AVCodecParameters *par = NULL;
> @@ -2456,6 +2456,7 @@ static int rtp_read_header(AVFormatContext *s)
> AVIOContext pb;
> socklen_t addrlen = sizeof(addr);
> RTSPState *rt = s->priv_data;
> +const char *p;
>
> if (!ff_network_init())
> return AVERROR(EIO);
> @@ -2513,12 +2514,40 @@ static int rtp_read_header(AVFormatContext *s)
> av_url_split(NULL, 0, NULL, 0, host, sizeof(host), ,
> NULL, 0, s->url);
>
> -snprintf(sdp, sizeof(sdp),
> - "v=0\r\nc=IN IP%d %s\r\nm=%s %d RTP/AVP %d\r\n",
> - addr.ss_family == AF_INET ? 4 : 6, host,
> - par->codec_type == AVMEDIA_TYPE_DATA ? "application" :
> - par->codec_type == AVMEDIA_TYPE_VIDEO ? "video" : "audio",
> - port, payload_type);
> +sdp_length = snprintf(sdp, sizeof(sdp),
> + "v=0\r\nc=IN IP%d %s\r\n",
> + addr.ss_family == AF_INET ? 4 : 6, host);
> +
> +p = strchr(s->url, '?');
> +if (p) {
> +static const char *filters[][2] = {{"sources", "incl"}, {"block",
> "excl"}, {NULL, NULL}};
> +int i;
> +char *q;
> +for (i = 0; filters[i][0]; i++) {
> +if (av_find_info_tag(filters_buf, sizeof(filters_buf),
> filters[i][0], p)) {
> +/* av_log(s, AV_LOG_VERBOSE, "rtp_read_header() found %s
> %s\n", filters[i][0], filters_buf); */
> +q = filters_buf;
> +while ((q = strchr(q, ',')) != NULL)
> +*q = ' ';
> +nc = snprintf(sdp + sdp_length, sizeof(sdp) - sdp_length,
> + "a=source-filter:%s IN IP%d %s %s\r\n",
> + filters[i][1],
> + addr.ss_family == AF_INET ? 4 : 6, host,
> + filters_buf);
> +if (nc < 0 || nc + sdp_length >= sizeof(sdp))
> +goto fail_nobuf;
> +sdp_length += nc;
> +}
> +}
> +}
> +
> +nc = snprintf(sdp + sdp_length, sizeof(sdp) - sdp_length,
> + "m=%s %d RTP/AVP %d\r\n",
> + par->codec_type == AVMEDIA_TYPE_DATA ? "application" :
> + par->codec_type == AVMEDIA_TYPE_VIDEO ? "video" : "audio",
> + port, payload_type);
> +if (nc < 0 || nc + sdp_length >= sizeof(sdp))
> +goto fail_nobuf;
> av_log(s, AV_LOG_VERBOSE, "SDP:\n%s\n", sdp);
> avcodec_parameters_free();
>
> @@ -2534,6 +2563,9 @@ static int rtp_read_header(AVFormatContext *s)
> s->pb = NULL;
> return ret;
>
> +fail_nobuf:
> +ret = AVERROR(ENOBUFS);
> +av_log(s, AV_LOG_ERROR, "rtp_read_header(): not enough buffer space for
> sdp-headers\n");
> fail:
> avcodec_parameters_free();
> if (in)
> --
> 2.20.1 (Apple Git-117)
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/udp: support w32pthreads compat
Ping
> On 2 Mar 2020, at 21:30, Ross Nicholson wrote:
>
> phunkyfish in the history is fine thanks ;)
>
>> On 2 Mar 2020, at 21:00, Marton Balint wrote:
>>
>>
>>
>>>> On Mon, 2 Mar 2020, Ross Nicholson wrote:
>>>
>>> Updated to correct header.
>>
>> Can you resend the patch with the proper author (e.g. Ross Nicholson instead
>> of phunkyfish?) Or you want to appear as phunkyfish in the history?
>>
>> Thanks,
>> Marton
>>
>>>
>>>> On Mon, 2 Mar 2020 at 19:53, Marton Balint wrote:
>>>>
>>>>
>>>>
>>>>> On Mon, 2 Mar 2020, phunkyfish wrote:
>>>>
>>>>> ---
>>>>> compat/w32pthreads.h | 8
>>>>> libavformat/udp.c| 6 +-
>>>>> 2 files changed, 13 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
>>>>> index 7df33b7da4..6405e72b64 100644
>>>>> --- a/compat/w32pthreads.h
>>>>> +++ b/compat/w32pthreads.h
>>>>> @@ -63,6 +63,9 @@ typedef CONDITION_VARIABLE pthread_cond_t;
>>>>> #define InitializeCriticalSection(x) InitializeCriticalSectionEx(x, 0, 0)
>>>>> #define WaitForSingleObject(a, b) WaitForSingleObjectEx(a, b, FALSE)
>>>>>
>>>>> +#define PTHREAD_CANCEL_ENABLE 1
>>>>> +#define PTHREAD_CANCEL_DISABLE 0
>>>>> +
>>>>> static av_unused unsigned __stdcall attribute_align_arg
>>>> win32thread_worker(void *arg)
>>>>> {
>>>>>pthread_t *h = (pthread_t*)arg;
>>>>> @@ -180,4 +183,9 @@ static inline int pthread_cond_signal(pthread_cond_t
>>>> *cond)
>>>>>return 0;
>>>>> }
>>>>>
>>>>> +static inline int pthread_setcancelstate(int state, int *oldstate)
>>>>> +{
>>>>> +return 0;
>>>>> +}
>>>>> +
>>>>> #endif /* COMPAT_W32PTHREADS_H */
>>>>> diff --git a/libavformat/udp.c b/libavformat/udp.c
>>>>> index 23c3773c64..692ff07cec 100644
>>>>> --- a/libavformat/udp.c
>>>>> +++ b/libavformat/udp.c
>>>>> @@ -61,7 +61,11 @@
>>>>> #define IPPROTO_UDPLITE 136
>>>>> #endif
>>>>>
>>>>> -#if HAVE_PTHREAD_CANCEL
>>>>> +#if HAVE_W32THREADS
>>>>> +#include "compat/w32pthreads.h"
>>>>
>>>> This should be #include "libavutil/thread.h" instead, the compat layer
>>>> should not be included directly.
>>>>
>>>> Regards,
>>>> Marton
>>>>
>>>>> +#undef HAVE_PTHREAD_CANCEL
>>>>> +#define HAVE_PTHREAD_CANCEL 1
>>>>> +#elif HAVE_PTHREAD_CANCEL
>>>>> #include
>>>>> #endif
>>>>>
>>>>> --
>>>>> 2.20.1 (Apple Git-117)
>>>>>
>>>>> ___
>>>>> ffmpeg-devel mailing list
>>>>> ffmpeg-devel@ffmpeg.org
>>>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>>>
>>>>> To unsubscribe, visit link above, or email
>>>>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>>>> ___
>>>> ffmpeg-devel mailing list
>>>> ffmpeg-devel@ffmpeg.org
>>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>>
>>>> To unsubscribe, visit link above, or email
>>>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>> To unsubscribe, visit link above, or email
>>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/udp: support w32pthreads compat
phunkyfish in the history is fine thanks ;)
> On 2 Mar 2020, at 21:00, Marton Balint wrote:
>
>
>
>> On Mon, 2 Mar 2020, Ross Nicholson wrote:
>>
>> Updated to correct header.
>
> Can you resend the patch with the proper author (e.g. Ross Nicholson instead
> of phunkyfish?) Or you want to appear as phunkyfish in the history?
>
> Thanks,
> Marton
>
>>
>>> On Mon, 2 Mar 2020 at 19:53, Marton Balint wrote:
>>>
>>>
>>>
>>>> On Mon, 2 Mar 2020, phunkyfish wrote:
>>>
>>> > ---
>>> > compat/w32pthreads.h | 8
>>> > libavformat/udp.c| 6 +-
>>> > 2 files changed, 13 insertions(+), 1 deletion(-)
>>> >
>>> > diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
>>> > index 7df33b7da4..6405e72b64 100644
>>> > --- a/compat/w32pthreads.h
>>> > +++ b/compat/w32pthreads.h
>>> > @@ -63,6 +63,9 @@ typedef CONDITION_VARIABLE pthread_cond_t;
>>> > #define InitializeCriticalSection(x) InitializeCriticalSectionEx(x, 0, 0)
>>> > #define WaitForSingleObject(a, b) WaitForSingleObjectEx(a, b, FALSE)
>>> >
>>> > +#define PTHREAD_CANCEL_ENABLE 1
>>> > +#define PTHREAD_CANCEL_DISABLE 0
>>> > +
>>> > static av_unused unsigned __stdcall attribute_align_arg
>>> win32thread_worker(void *arg)
>>> > {
>>> > pthread_t *h = (pthread_t*)arg;
>>> > @@ -180,4 +183,9 @@ static inline int pthread_cond_signal(pthread_cond_t
>>> *cond)
>>> > return 0;
>>> > }
>>> >
>>> > +static inline int pthread_setcancelstate(int state, int *oldstate)
>>> > +{
>>> > +return 0;
>>> > +}
>>> > +
>>> > #endif /* COMPAT_W32PTHREADS_H */
>>> > diff --git a/libavformat/udp.c b/libavformat/udp.c
>>> > index 23c3773c64..692ff07cec 100644
>>> > --- a/libavformat/udp.c
>>> > +++ b/libavformat/udp.c
>>> > @@ -61,7 +61,11 @@
>>> > #define IPPROTO_UDPLITE 136
>>> > #endif
>>> >
>>> > -#if HAVE_PTHREAD_CANCEL
>>> > +#if HAVE_W32THREADS
>>> > +#include "compat/w32pthreads.h"
>>>
>>> This should be #include "libavutil/thread.h" instead, the compat layer
>>> should not be included directly.
>>>
>>> Regards,
>>> Marton
>>>
>>> > +#undef HAVE_PTHREAD_CANCEL
>>> > +#define HAVE_PTHREAD_CANCEL 1
>>> > +#elif HAVE_PTHREAD_CANCEL
>>> > #include
>>> > #endif
>>> >
>>> > --
>>> > 2.20.1 (Apple Git-117)
>>> >
>>> > ___
>>> > ffmpeg-devel mailing list
>>> > ffmpeg-devel@ffmpeg.org
>>> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>> >
>>> > To unsubscribe, visit link above, or email
>>> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>> To unsubscribe, visit link above, or email
>>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/udp: support w32pthreads compat
Updated to correct header.
On Mon, 2 Mar 2020 at 19:53, Marton Balint wrote:
>
>
> On Mon, 2 Mar 2020, phunkyfish wrote:
>
> > ---
> > compat/w32pthreads.h | 8
> > libavformat/udp.c| 6 +-
> > 2 files changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
> > index 7df33b7da4..6405e72b64 100644
> > --- a/compat/w32pthreads.h
> > +++ b/compat/w32pthreads.h
> > @@ -63,6 +63,9 @@ typedef CONDITION_VARIABLE pthread_cond_t;
> > #define InitializeCriticalSection(x) InitializeCriticalSectionEx(x, 0, 0)
> > #define WaitForSingleObject(a, b) WaitForSingleObjectEx(a, b, FALSE)
> >
> > +#define PTHREAD_CANCEL_ENABLE 1
> > +#define PTHREAD_CANCEL_DISABLE 0
> > +
> > static av_unused unsigned __stdcall attribute_align_arg
> win32thread_worker(void *arg)
> > {
> > pthread_t *h = (pthread_t*)arg;
> > @@ -180,4 +183,9 @@ static inline int pthread_cond_signal(pthread_cond_t
> *cond)
> > return 0;
> > }
> >
> > +static inline int pthread_setcancelstate(int state, int *oldstate)
> > +{
> > +return 0;
> > +}
> > +
> > #endif /* COMPAT_W32PTHREADS_H */
> > diff --git a/libavformat/udp.c b/libavformat/udp.c
> > index 23c3773c64..692ff07cec 100644
> > --- a/libavformat/udp.c
> > +++ b/libavformat/udp.c
> > @@ -61,7 +61,11 @@
> > #define IPPROTO_UDPLITE 136
> > #endif
> >
> > -#if HAVE_PTHREAD_CANCEL
> > +#if HAVE_W32THREADS
> > +#include "compat/w32pthreads.h"
>
> This should be #include "libavutil/thread.h" instead, the compat layer
> should not be included directly.
>
> Regards,
> Marton
>
> > +#undef HAVE_PTHREAD_CANCEL
> > +#define HAVE_PTHREAD_CANCEL 1
> > +#elif HAVE_PTHREAD_CANCEL
> > #include
> > #endif
> >
> > --
> > 2.20.1 (Apple Git-117)
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/udp: support w32pthreads compat
Thanks!
On Mon, 2 Mar 2020 at 14:16, Andriy Gelman wrote:
> On Mon, 02. Mar 13:38, phunkyfish wrote:
> > ---
> > compat/w32pthreads.h | 10 ++
> > libavformat/udp.c| 8 +++-
> > 2 files changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
> > index 7df33b7da4..64cd40cda4 100644
> > --- a/compat/w32pthreads.h
> > +++ b/compat/w32pthreads.h
> > @@ -63,6 +63,11 @@ typedef CONDITION_VARIABLE pthread_cond_t;
> > #define InitializeCriticalSection(x) InitializeCriticalSectionEx(x, 0,
> 0)
> > #define WaitForSingleObject(a, b) WaitForSingleObjectEx(a, b, FALSE)
> >
> > +#undef PTHREAD_CANCEL_ENABLE
> > +#undef PTHREAD_CANCEL_DISABLE
> > +#define PTHREAD_CANCEL_ENABLE 1
> > +#define PTHREAD_CANCEL_DISABLE 0
> > +
> > static av_unused unsigned __stdcall attribute_align_arg
> win32thread_worker(void *arg)
> > {
> > pthread_t *h = (pthread_t*)arg;
> > @@ -180,4 +185,9 @@ static inline int pthread_cond_signal(pthread_cond_t
> *cond)
> > return 0;
> > }
> >
> > +static inline int pthread_setcancelstate(int state, int *oldstate)
> > +{
> > +return 0;
> > +}
> > +
> > #endif /* COMPAT_W32PTHREADS_H */
> > diff --git a/libavformat/udp.c b/libavformat/udp.c
> > index 23c3773c64..4f42b026cd 100644
> > --- a/libavformat/udp.c
> > +++ b/libavformat/udp.c
> > @@ -61,10 +61,16 @@
> > #define IPPROTO_UDPLITE 136
> > #endif
> >
> > -#if HAVE_PTHREAD_CANCEL
>
> > +#if HAVE_PTHREAD_CANCEL && !defined(HAVE_W32THREADS)
> > #include
> > #endif
>
> In my config.h HAVE_W32THREADS is defined, but it's set to 0
> so it ends up not including the pthread.h header
>
> >
> > +#if HAVE_W32THREADS
> > +#include "compat/w32pthreads.h"
> > +#undef HAVE_PTHREAD_CANCEL
> > +#define HAVE_PTHREAD_CANCEL 1
> > +#endif
> > +
> > #ifndef IPV6_ADD_MEMBERSHIP
> > #define IPV6_ADD_MEMBERSHIP IPV6_JOIN_GROUP
> > #define IPV6_DROP_MEMBERSHIP IPV6_LEAVE_GROUP
>
> --
> Andriy
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/udp: support w32pthreads compat
This should allow the use of w32pthreads compat layer to be used for UDP.
For windows this would mean not needing to change the underlying
threading impl.
On Mon, 2 Mar 2020 at 12:53, phunkyfish wrote:
> ---
> compat/w32pthreads.h | 8
> libavformat/udp.c| 8 +++-
> 2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
> index 7df33b7da4..6405e72b64 100644
> --- a/compat/w32pthreads.h
> +++ b/compat/w32pthreads.h
> @@ -63,6 +63,9 @@ typedef CONDITION_VARIABLE pthread_cond_t;
> #define InitializeCriticalSection(x) InitializeCriticalSectionEx(x, 0, 0)
> #define WaitForSingleObject(a, b) WaitForSingleObjectEx(a, b, FALSE)
>
> +#define PTHREAD_CANCEL_ENABLE 1
> +#define PTHREAD_CANCEL_DISABLE 0
> +
> static av_unused unsigned __stdcall attribute_align_arg
> win32thread_worker(void *arg)
> {
> pthread_t *h = (pthread_t*)arg;
> @@ -180,4 +183,9 @@ static inline int pthread_cond_signal(pthread_cond_t
> *cond)
> return 0;
> }
>
> +static inline int pthread_setcancelstate(int state, int *oldstate)
> +{
> +return 0;
> +}
> +
> #endif /* COMPAT_W32PTHREADS_H */
> diff --git a/libavformat/udp.c b/libavformat/udp.c
> index 23c3773c64..4f42b026cd 100644
> --- a/libavformat/udp.c
> +++ b/libavformat/udp.c
> @@ -61,10 +61,16 @@
> #define IPPROTO_UDPLITE 136
> #endif
>
> -#if HAVE_PTHREAD_CANCEL
> +#if HAVE_PTHREAD_CANCEL && !defined(HAVE_W32THREADS)
> #include
> #endif
>
> +#if HAVE_W32THREADS
> +#include "compat/w32pthreads.h"
> +#undef HAVE_PTHREAD_CANCEL
> +#define HAVE_PTHREAD_CANCEL 1
> +#endif
> +
> #ifndef IPV6_ADD_MEMBERSHIP
> #define IPV6_ADD_MEMBERSHIP IPV6_JOIN_GROUP
> #define IPV6_DROP_MEMBERSHIP IPV6_LEAVE_GROUP
> --
> 2.20.1 (Apple Git-117)
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [avfomat/rtp: source ips lost when specified as URL options] Patch for ffmpeg using rtp protocol where sources option is not retained
Ping...
> On 26 Feb 2020, at 08:57, Ross Nicholson wrote:
>
>
> Thanks, just thought you might have another idea, as it works just was not
> sure if I was accomplishing it in the right way.
>
> Ya, I submitted the patch formally. Let’s see what’s a review comes back like.
>
> Thanks
>
>>> On 26 Feb 2020, at 05:10, Jun Li wrote:
>>>
>>
>>
>>
>>> On Tue, Feb 25, 2020 at 5:01 AM Ross Nicholson wrote:
>>> Hey Jun Li,
>>>
>>> I noticed you have submitted some patches which work around the same code
>>> area's that I submitted for. Your patches look quite tidy and well thought
>>> out so I was wondering if you could look at this patch and see if I'm going
>>> about it in the right way.
>>>
>>> I'm not sure this area of ffmpeg currently has a maintainer currently so
>>> the patches may be difficult to progress.
>>>
>>> Ross
>>>
>>>> On Tue, 11 Feb 2020 at 22:42, Ross Nicholson wrote:
>>>> The patch was created as a workaround to an issue from in kodi (apologies,
>>>> it's a rather long thread):
>>>> https://forum.kodi.tv/showthread.php?tid=350901=2923550#pid2923550
>>>>
>>>> As an example, here is a URL: rtp://87.141.215.251@232.0.10.234:1
>>>>
>>>> Taking this URL we should be able to either reformat it to:
>>>> rtp://232.0.10.234:1?sources=87.141.215.251 or pass the sources as an
>>>> av_dict to avfomat_open_input.
>>>>
>>>> Neither option works however. Instead the above workaround was created but
>>>> it's not really the right way to fix this. Would be great to get some
>>>> guidance on the right place to fix this in the right way.
>>>>
>>>> Thanks in advance.
>>>>
>>>>> On Tue, 11 Feb 2020 at 22:30, phunkyfish wrote:
>>>>> ---
>>>>> libavformat/rtsp.c | 26 --
>>>>> 1 file changed, 24 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
>>>>> index 859defa592..f922055134 100644
>>>>> --- a/libavformat/rtsp.c
>>>>> +++ b/libavformat/rtsp.c
>>>>> @@ -2334,7 +2334,9 @@ static int sdp_read_header(AVFormatContext *s)
>>>>> RTSPStream *rtsp_st;
>>>>> int size, i, err;
>>>>> char *content;
>>>>> +const char *p, *sp="", *sources="", *sp2, *sources2;
>>>>> char url[1024];
>>>>> +char sources_buf[1024];
>>>>>
>>>>> if (!ff_network_init())
>>>>> return AVERROR(EIO);
>>>>> @@ -2360,6 +2362,16 @@ static int sdp_read_header(AVFormatContext *s)
>>>>> av_freep();
>>>>> if (err) goto fail;
>>>>>
>>>>> +/* Search for sources= tag in original URL for rtp protocol only */
>>>>> +if (strncmp(s->url, "rtp://", 6) == 0) {
>>>>> +p = strchr(s->url, '?');
>>>>> +if (p && av_find_info_tag(sources_buf, sizeof(sources_buf),
>>>>> "sources", p)) {
>>>>> +/* av_log(s, AV_LOG_VERBOSE, "sdp_read_header found sources
>>>>> %s\n", sources_buf); */
>>>>> +sp = sources_buf;
>>>>> +sources = "=";
>>>>> +}
>>>>> +}
>>>>> +
>>>>> /* open each RTP stream */
>>>>> for (i = 0; i < rt->nb_rtsp_streams; i++) {
>>>>> char namebuf[50];
>>>>> @@ -2377,12 +2389,22 @@ static int sdp_read_header(AVFormatContext *s)
>>>>> av_dict_free();
>>>>> goto fail;
>>>>> }
>>>>> +
>>>>> +/* Prepare to add sources to the url to be opened.
>>>>> + Otherwise the join to the source specific muliticast will
>>>>> be missing */
>>>>> +sources2 = sources;
>>>>> +sp2 = sp;
>>>>> +/* ignore sources from original URL, when sources are
>>>>> already set in rtsp_st */
>>>>> +if (rtsp_st->nb_include_source_addrs > 0)
>>>>> +sources2 = sp2 = "";
&g
Re: [FFmpeg-devel] [avfomat/rtp: source ips lost when specified as URL options] Patch for ffmpeg using rtp protocol where sources option is not retained
Thanks, just thought you might have another idea, as it works just was not sure
if I was accomplishing it in the right way.
Ya, I submitted the patch formally. Let’s see what’s a review comes back like.
Thanks
> On 26 Feb 2020, at 05:10, Jun Li wrote:
>
>
>
>
>> On Tue, Feb 25, 2020 at 5:01 AM Ross Nicholson wrote:
>> Hey Jun Li,
>>
>> I noticed you have submitted some patches which work around the same code
>> area's that I submitted for. Your patches look quite tidy and well thought
>> out so I was wondering if you could look at this patch and see if I'm going
>> about it in the right way.
>>
>> I'm not sure this area of ffmpeg currently has a maintainer currently so the
>> patches may be difficult to progress.
>>
>> Ross
>>
>>> On Tue, 11 Feb 2020 at 22:42, Ross Nicholson wrote:
>>> The patch was created as a workaround to an issue from in kodi (apologies,
>>> it's a rather long thread):
>>> https://forum.kodi.tv/showthread.php?tid=350901=2923550#pid2923550
>>>
>>> As an example, here is a URL: rtp://87.141.215.251@232.0.10.234:1
>>>
>>> Taking this URL we should be able to either reformat it to:
>>> rtp://232.0.10.234:1?sources=87.141.215.251 or pass the sources as an
>>> av_dict to avfomat_open_input.
>>>
>>> Neither option works however. Instead the above workaround was created but
>>> it's not really the right way to fix this. Would be great to get some
>>> guidance on the right place to fix this in the right way.
>>>
>>> Thanks in advance.
>>>
>>>> On Tue, 11 Feb 2020 at 22:30, phunkyfish wrote:
>>>> ---
>>>> libavformat/rtsp.c | 26 --
>>>> 1 file changed, 24 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
>>>> index 859defa592..f922055134 100644
>>>> --- a/libavformat/rtsp.c
>>>> +++ b/libavformat/rtsp.c
>>>> @@ -2334,7 +2334,9 @@ static int sdp_read_header(AVFormatContext *s)
>>>> RTSPStream *rtsp_st;
>>>> int size, i, err;
>>>> char *content;
>>>> +const char *p, *sp="", *sources="", *sp2, *sources2;
>>>> char url[1024];
>>>> +char sources_buf[1024];
>>>>
>>>> if (!ff_network_init())
>>>> return AVERROR(EIO);
>>>> @@ -2360,6 +2362,16 @@ static int sdp_read_header(AVFormatContext *s)
>>>> av_freep();
>>>> if (err) goto fail;
>>>>
>>>> +/* Search for sources= tag in original URL for rtp protocol only */
>>>> +if (strncmp(s->url, "rtp://", 6) == 0) {
>>>> +p = strchr(s->url, '?');
>>>> +if (p && av_find_info_tag(sources_buf, sizeof(sources_buf),
>>>> "sources", p)) {
>>>> +/* av_log(s, AV_LOG_VERBOSE, "sdp_read_header found sources
>>>> %s\n", sources_buf); */
>>>> +sp = sources_buf;
>>>> +sources = "=";
>>>> +}
>>>> +}
>>>> +
>>>> /* open each RTP stream */
>>>> for (i = 0; i < rt->nb_rtsp_streams; i++) {
>>>> char namebuf[50];
>>>> @@ -2377,12 +2389,22 @@ static int sdp_read_header(AVFormatContext *s)
>>>> av_dict_free();
>>>> goto fail;
>>>> }
>>>> +
>>>> +/* Prepare to add sources to the url to be opened.
>>>> + Otherwise the join to the source specific muliticast will
>>>> be missing */
>>>> +sources2 = sources;
>>>> +sp2 = sp;
>>>> +/* ignore sources from original URL, when sources are already
>>>> set in rtsp_st */
>>>> +if (rtsp_st->nb_include_source_addrs > 0)
>>>> +sources2 = sp2 = "";
>>>> +
>>>> ff_url_join(url, sizeof(url), "rtp", NULL,
>>>> namebuf, rtsp_st->sdp_port,
>>>> -
>>>> "?localport=%d=%d=%d_to_source=%d",
>>>> +
>>>> "?localport=%d=%d=%d_to_source=%d%s%s",
>>>> rtsp_st->sdp_port, rtsp_st->sdp_
Re: [FFmpeg-devel] [avfomat/rtp: source ips lost when specified as URL options] Patch for ffmpeg using rtp protocol where sources option is not retained
Hey Jun Li,
I noticed you have submitted some patches which work around the same code
area's that I submitted for. Your patches look quite tidy and well thought
out so I was wondering if you could look at this patch and see if I'm going
about it in the right way.
I'm not sure this area of ffmpeg currently has a maintainer currently so
the patches may be difficult to progress.
Ross
On Tue, 11 Feb 2020 at 22:42, Ross Nicholson wrote:
> The patch was created as a workaround to an issue from in kodi (apologies,
> it's a rather long thread):
> https://forum.kodi.tv/showthread.php?tid=350901=2923550#pid2923550
>
> As an example, here is a URL: rtp://87.141.215.251@232.0.10.234:1
>
> Taking this URL we should be able to either reformat it to: rtp://
> 232.0.10.234:1?sources=87.141.215.251 or pass the sources as an
> av_dict to avfomat_open_input.
>
> Neither option works however. Instead the above workaround was created but
> it's not really the right way to fix this. Would be great to get some
> guidance on the right place to fix this in the right way.
>
> Thanks in advance.
>
> On Tue, 11 Feb 2020 at 22:30, phunkyfish wrote:
>
>> ---
>> libavformat/rtsp.c | 26 --
>> 1 file changed, 24 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
>> index 859defa592..f922055134 100644
>> --- a/libavformat/rtsp.c
>> +++ b/libavformat/rtsp.c
>> @@ -2334,7 +2334,9 @@ static int sdp_read_header(AVFormatContext *s)
>> RTSPStream *rtsp_st;
>> int size, i, err;
>> char *content;
>> +const char *p, *sp="", *sources="", *sp2, *sources2;
>> char url[1024];
>> +char sources_buf[1024];
>>
>> if (!ff_network_init())
>> return AVERROR(EIO);
>> @@ -2360,6 +2362,16 @@ static int sdp_read_header(AVFormatContext *s)
>> av_freep();
>> if (err) goto fail;
>>
>> +/* Search for sources= tag in original URL for rtp protocol only */
>> +if (strncmp(s->url, "rtp://", 6) == 0) {
>> +p = strchr(s->url, '?');
>> +if (p && av_find_info_tag(sources_buf, sizeof(sources_buf),
>> "sources", p)) {
>> +/* av_log(s, AV_LOG_VERBOSE, "sdp_read_header found sources
>> %s\n", sources_buf); */
>> +sp = sources_buf;
>> +sources = "=";
>> +}
>> +}
>> +
>> /* open each RTP stream */
>> for (i = 0; i < rt->nb_rtsp_streams; i++) {
>> char namebuf[50];
>> @@ -2377,12 +2389,22 @@ static int sdp_read_header(AVFormatContext *s)
>> av_dict_free();
>> goto fail;
>> }
>> +
>> +/* Prepare to add sources to the url to be opened.
>> + Otherwise the join to the source specific muliticast will
>> be missing */
>> +sources2 = sources;
>> +sp2 = sp;
>> +/* ignore sources from original URL, when sources are
>> already set in rtsp_st */
>> +if (rtsp_st->nb_include_source_addrs > 0)
>> +sources2 = sp2 = "";
>> +
>> ff_url_join(url, sizeof(url), "rtp", NULL,
>> namebuf, rtsp_st->sdp_port,
>> -
>> "?localport=%d=%d=%d_to_source=%d",
>> +
>> "?localport=%d=%d=%d_to_source=%d%s%s",
>> rtsp_st->sdp_port, rtsp_st->sdp_ttl,
>> rt->rtsp_flags & RTSP_FLAG_FILTER_SRC ? 1 : 0,
>> -rt->rtsp_flags & RTSP_FLAG_RTCP_TO_SOURCE ? 1 :
>> 0);
>> +rt->rtsp_flags & RTSP_FLAG_RTCP_TO_SOURCE ? 1 :
>> 0,
>> +sources2, sp2);
>>
>> append_source_addrs(url, sizeof(url), "sources",
>> rtsp_st->nb_include_source_addrs,
>> --
>> 2.20.1 (Apple Git-117)
>>
>>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [avfomat/rtp: source ips lost when specified as URL options] Patch for ffmpeg using rtp protocol where sources option is not retained
The patch was created as a workaround to an issue from in kodi (apologies,
it's a rather long thread):
https://forum.kodi.tv/showthread.php?tid=350901=2923550#pid2923550
As an example, here is a URL: rtp://87.141.215.251@232.0.10.234:1
Taking this URL we should be able to either reformat it to: rtp://
232.0.10.234:1?sources=87.141.215.251 or pass the sources as an av_dict
to avfomat_open_input.
Neither option works however. Instead the above workaround was created but
it's not really the right way to fix this. Would be great to get some
guidance on the right place to fix this in the right way.
Thanks in advance.
On Wed, 12 Feb 2020 at 19:40, phunkyfish wrote:
> ---
> libavformat/rtsp.c | 26 --
> 1 file changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> index 859defa592..f922055134 100644
> --- a/libavformat/rtsp.c
> +++ b/libavformat/rtsp.c
> @@ -2334,7 +2334,9 @@ static int sdp_read_header(AVFormatContext *s)
> RTSPStream *rtsp_st;
> int size, i, err;
> char *content;
> +const char *p, *sp="", *sources="", *sp2, *sources2;
> char url[1024];
> +char sources_buf[1024];
>
> if (!ff_network_init())
> return AVERROR(EIO);
> @@ -2360,6 +2362,16 @@ static int sdp_read_header(AVFormatContext *s)
> av_freep();
> if (err) goto fail;
>
> +/* Search for sources= tag in original URL for rtp protocol only */
> +if (strncmp(s->url, "rtp://", 6) == 0) {
> +p = strchr(s->url, '?');
> +if (p && av_find_info_tag(sources_buf, sizeof(sources_buf),
> "sources", p)) {
> +/* av_log(s, AV_LOG_VERBOSE, "sdp_read_header found sources
> %s\n", sources_buf); */
> +sp = sources_buf;
> +sources = "=";
> +}
> +}
> +
> /* open each RTP stream */
> for (i = 0; i < rt->nb_rtsp_streams; i++) {
> char namebuf[50];
> @@ -2377,12 +2389,22 @@ static int sdp_read_header(AVFormatContext *s)
> av_dict_free();
> goto fail;
> }
> +
> +/* Prepare to add sources to the url to be opened.
> + Otherwise the join to the source specific muliticast will
> be missing */
> +sources2 = sources;
> +sp2 = sp;
> +/* ignore sources from original URL, when sources are already
> set in rtsp_st */
> +if (rtsp_st->nb_include_source_addrs > 0)
> +sources2 = sp2 = "";
> +
> ff_url_join(url, sizeof(url), "rtp", NULL,
> namebuf, rtsp_st->sdp_port,
> -
> "?localport=%d=%d=%d_to_source=%d",
> +
> "?localport=%d=%d=%d_to_source=%d%s%s",
> rtsp_st->sdp_port, rtsp_st->sdp_ttl,
> rt->rtsp_flags & RTSP_FLAG_FILTER_SRC ? 1 : 0,
> -rt->rtsp_flags & RTSP_FLAG_RTCP_TO_SOURCE ? 1 :
> 0);
> +rt->rtsp_flags & RTSP_FLAG_RTCP_TO_SOURCE ? 1 : 0,
> +sources2, sp2);
>
> append_source_addrs(url, sizeof(url), "sources",
> rtsp_st->nb_include_source_addrs,
> --
> 2.20.1 (Apple Git-117)
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4] libavformat/rtsp: return error if rtsp_hd_out is null instead of crash
Can this be applied? > On 19 Sep 2019, at 16:14, Ross Nicholson wrote: > > Updated to v4 of patch after learning from Aman Gupta that 'rt' did not need > to be checked in the context of this function. > > Should be good to go now. > >> On Thu, 19 Sep 2019 at 16:12, phunkyfish wrote: >> --- >> libavformat/rtsp.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c >> index c153cac88b..859defa592 100644 >> --- a/libavformat/rtsp.c >> +++ b/libavformat/rtsp.c >> @@ -1318,6 +1318,9 @@ static int >> rtsp_send_cmd_with_content_async(AVFormatContext *s, >> char buf[4096], *out_buf; >> char base64buf[AV_BASE64_SIZE(sizeof(buf))]; >> >> +if (!rt->rtsp_hd_out) >> +return ENOTCONN; >> + >> /* Add in RTSP headers */ >> out_buf = buf; >> rt->seq++; >> -- >> 2.20.1 (Apple Git-117) >> ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] libavformat/rtsp: return error if rtsp_hd_out is null instead of crash
Makes sense. Latest version of patch v4 should reflect this. > On 18 Sep 2019, at 21:42, phunkyfish wrote: > > --- > libavformat/rtsp.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c > index c153cac88b..5e8adfaf3c 100644 > --- a/libavformat/rtsp.c > +++ b/libavformat/rtsp.c > @@ -1318,6 +1318,9 @@ static int > rtsp_send_cmd_with_content_async(AVFormatContext *s, > char buf[4096], *out_buf; > char base64buf[AV_BASE64_SIZE(sizeof(buf))]; > > +if (rt && !rt->rtsp_hd_out) > +return ENOTCONN; > + > /* Add in RTSP headers */ > out_buf = buf; > rt->seq++; > -- > 2.20.1 (Apple Git-117) > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4] libavformat/rtsp: return error if rtsp_hd_out is null instead of crash
Updated to v4 of patch after learning from Aman Gupta that 'rt' did not need to be checked in the context of this function. Should be good to go now. On Thu, 19 Sep 2019 at 16:12, phunkyfish wrote: > --- > libavformat/rtsp.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c > index c153cac88b..859defa592 100644 > --- a/libavformat/rtsp.c > +++ b/libavformat/rtsp.c > @@ -1318,6 +1318,9 @@ static int > rtsp_send_cmd_with_content_async(AVFormatContext *s, > char buf[4096], *out_buf; > char base64buf[AV_BASE64_SIZE(sizeof(buf))]; > > +if (!rt->rtsp_hd_out) > +return ENOTCONN; > + > /* Add in RTSP headers */ > out_buf = buf; > rt->seq++; > -- > 2.20.1 (Apple Git-117) > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] libavformat/rtsp: return error if rtsp_hd_out is null instead of crash
Checking other functions I don't see this checked for so I guess latest patch is fine. On Wed, 18 Sep 2019 at 21:51, Ross Nicholson wrote: > Technically this function should also return an error is rt is NULL. Which > error code would apply for this? > > On Wed, 18 Sep 2019 at 21:42, phunkyfish wrote: > >> --- >> libavformat/rtsp.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c >> index c153cac88b..5e8adfaf3c 100644 >> --- a/libavformat/rtsp.c >> +++ b/libavformat/rtsp.c >> @@ -1318,6 +1318,9 @@ static int >> rtsp_send_cmd_with_content_async(AVFormatContext *s, >> char buf[4096], *out_buf; >> char base64buf[AV_BASE64_SIZE(sizeof(buf))]; >> >> +if (rt && !rt->rtsp_hd_out) >> +return ENOTCONN; >> + >> /* Add in RTSP headers */ >> out_buf = buf; >> rt->seq++; >> -- >> 2.20.1 (Apple Git-117) >> >> ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] libavformat/rtsp: return error if rtsp_hd_out is null instead of crash
Technically this function should also return an error is rt is NULL. Which error code would apply for this? On Wed, 18 Sep 2019 at 21:42, phunkyfish wrote: > --- > libavformat/rtsp.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c > index c153cac88b..5e8adfaf3c 100644 > --- a/libavformat/rtsp.c > +++ b/libavformat/rtsp.c > @@ -1318,6 +1318,9 @@ static int > rtsp_send_cmd_with_content_async(AVFormatContext *s, > char buf[4096], *out_buf; > char base64buf[AV_BASE64_SIZE(sizeof(buf))]; > > +if (rt && !rt->rtsp_hd_out) > +return ENOTCONN; > + > /* Add in RTSP headers */ > out_buf = buf; > rt->seq++; > -- > 2.20.1 (Apple Git-117) > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] libavformat/rtsp: return error if rtsp_hd_out is null instead of crash
Sorry, my name is Ross Nicholson. But the alias is fine too. > On 18 Sep 2019, at 21:14, Michael Niedermayer wrote: > >> On Wed, Sep 18, 2019 at 07:54:27AM +0100, phunkyfish wrote: >> --- >> libavformat/rtsp.c | 3 +++ >> 1 file changed, 3 insertions(+) > > The Author lacks your name > "From: phunkyfish " > > is that intended ? > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > While the State exists there can be no freedom; when there is freedom there > will be no State. -- Vladimir Lenin > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] libavformat/rtsp: return error if rtsp_hd_out is null instead of crash
Updated patch to add return after variable definitions. On Wed, 18 Sep 2019 at 07:54, phunkyfish wrote: > --- > libavformat/rtsp.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c > index c153cac88b..3e8606dade 100644 > --- a/libavformat/rtsp.c > +++ b/libavformat/rtsp.c > @@ -1318,6 +1318,9 @@ static int > rtsp_send_cmd_with_content_async(AVFormatContext *s, > char buf[4096], *out_buf; > char base64buf[AV_BASE64_SIZE(sizeof(buf))]; > > +if (rt->rtsp_hd_out == NULL) > +return ENOTCONN; > + > /* Add in RTSP headers */ > out_buf = buf; > rt->seq++; > -- > 2.20.1 (Apple Git-117) > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/rtspdec: Don't send teardown if rtsp_hd_out is null
This can be closed. New patch created which returns an error instead to
prevent crash.
On Thu, 12 Sep 2019 at 08:21, Ross Nicholson wrote:
> Ping, any update?
>
> On Thu, 5 Sep 2019 at 06:33, Ross Nicholson wrote:
>
>> Hey All,
>>
>> Anything needed from me to progress this?
>>
>> Thanks in advance,
>>
>> Ross
>>
>> On 29 Aug 2019, at 17:04, Ross Nicholson wrote:
>>
>> Hey Jun,
>>
>> So I got kodi running with FFmpeg n4.2 and the issue persists. Here's the
>> debugger output after trying to play the test link you provided.
>>
>> With the patch this does not occur so their must be some way to call
>> function with rt->rtsp_hd_out as NULL;
>>
>> Thanks,
>>
>> Ross
>>
>> Process 92017 stopped
>>
>> * thread #28, name = 'VideoPlayer', stop reason = EXC_BAD_ACCESS (code=1,
>> address=0x20)
>>
>> frame #0: 0x0001037af09e
>> kodi.bin`ffurl_write(h=0x, buf="TEARDOWN RTSP/1.0\r\nCSeq:
>> 1\r\nUser-Agent: Lavf58.29.100\r\n\r\n", size=58) at avio.c:423:20 [opt]
>>
>>420
>>
>>421 int ffurl_write(URLContext *h, const unsigned char *buf, int size)
>>
>>422 {
>>
>> -> 423 if (!(h->flags & AVIO_FLAG_WRITE))
>>
>>424 return AVERROR(EIO);
>>
>>425 /* avoid sending too big packets */
>>
>>426 if (h->max_packet_size && size > h->max_packet_size)
>>
>> Target 0: (kodi.bin) stopped.
>>
>>
>> And the backtrace:
>>
>>
>> * thread #28, name = 'VideoPlayer', stop reason = EXC_BAD_ACCESS (code=1,
>> address=0x20)
>>
>> * frame #0: 0x0001037af09e
>> kodi.bin`ffurl_write(h=0x, buf="TEARDOWN RTSP/1.0\r\nCSeq:
>> 1\r\nUser-Agent: Lavf58.29.100\r\n\r\n", size=58) at avio.c:423:20 [opt]
>>
>> frame #1: 0x0001038c3be9
>> kodi.bin`rtsp_send_cmd_with_content_async(s=0x00011989c000,
>> method=, url=, headers=,
>> send_content=0x, send_content_length=0) at rtsp.c:1352:5
>> [opt]
>>
>> frame #2: 0x0001038c928c
>> kodi.bin`rtsp_read_close(s=0x00011989c000) at rtspdec.c:61:9 [opt]
>>
>> frame #3: 0x0001038f9994
>> kodi.bin`avformat_close_input(ps=0x00014dbb8000) at utils.c:4450:13
>> [opt]
>>
>> frame #4: 0x0001004c7841
>> kodi.bin`CDVDDemuxFFmpeg::Open(this=0x00014dbb7ff0,
>> pInput=std::__1::shared_ptr::element_type @
>> 0x00014dbb7d10 strong=4 weak=1, streaminfo=true, fileinfo=false) at
>> DVDDemuxFFmpeg.cpp:278:7
>>
>> frame #5: 0x0001004eb802
>> kodi.bin`CDVDFactoryDemuxer::CreateDemuxer(pInputStream=std::__1::shared_ptr::element_type
>> @ 0x00014dbb7d10 strong=4 weak=1, fileinfo=false) at
>> DVDFactoryDemuxer.cpp:88:15
>>
>> frame #6: 0x000100575ff3
>> kodi.bin`CVideoPlayer::OpenDemuxStream(this=0x00011d90d800) at
>> VideoPlayer.cpp:822:18
>>
>> frame #7: 0x000100579642
>> kodi.bin`CVideoPlayer::Prepare(this=0x00011d90d800) at
>> VideoPlayer.cpp:1224:8
>>
>> frame #8: 0x00010057b70f
>> kodi.bin`CVideoPlayer::Process(this=0x00011d90d800) at
>> VideoPlayer.cpp:1310:3
>>
>> frame #9: 0x000100aa7a04
>> kodi.bin`CThread::Action(this=0x00011d90d800) at Thread.cpp:282:5
>>
>> frame #10: 0x000100aadc90
>> kodi.bin`CThread::Create(this=0x00014d19f670,
>> pThread=0x00011d90d800, promise=promise @
>> 0x7b522e70)::$_0::operator()(CThread*, std::__1::promise)
>> const at Thread.cpp:140:18
>>
>> frame #11: 0x000100aad9eb
>> kodi.bin`decltype(__f=0x00014d19f670, __args=0x00014d19f678,
>> __args=0x00014d19f680)::$_0>(fp)(std::__1::forward(fp0),
>> std::__1::forward >(fp0)))
>> std::__1::__invoke> std::__1::promise >(CThread::Create(bool)::$_0&&, CThread*&&,
>> std::__1::promise&&) at type_traits:4339:1
>>
>> frame #12: 0x000100aad917 kodi.bin`void
>> std::__1::__thread_execute> std::__1::default_delete >,
>> CThread::Create(bool)::$_0, CThread*, std::__1::promise, 2ul,
>> 3ul>(__t=size=4, (null)=__tuple_indices<2, 3> @ 0x7b522eb8)::$_0,
>> CThread*, std::__1::promise >&, std::__1::__tuple_indices<2ul, 3ul>)
>> at thread:342:5
>>
>> frame #13: 0x000100aad026 kodi.bin`void*
>> std::__1::__thread_proxy> std::__1::default_delete
Re: [FFmpeg-devel] [PATCH] libavformat/rtspdec: Don't send teardown if rtsp_hd_out is null
Ping, any update?
On Thu, 5 Sep 2019 at 06:33, Ross Nicholson wrote:
> Hey All,
>
> Anything needed from me to progress this?
>
> Thanks in advance,
>
> Ross
>
> On 29 Aug 2019, at 17:04, Ross Nicholson wrote:
>
> Hey Jun,
>
> So I got kodi running with FFmpeg n4.2 and the issue persists. Here's the
> debugger output after trying to play the test link you provided.
>
> With the patch this does not occur so their must be some way to call
> function with rt->rtsp_hd_out as NULL;
>
> Thanks,
>
> Ross
>
> Process 92017 stopped
>
> * thread #28, name = 'VideoPlayer', stop reason = EXC_BAD_ACCESS (code=1,
> address=0x20)
>
> frame #0: 0x0001037af09e
> kodi.bin`ffurl_write(h=0x, buf="TEARDOWN RTSP/1.0\r\nCSeq:
> 1\r\nUser-Agent: Lavf58.29.100\r\n\r\n", size=58) at avio.c:423:20 [opt]
>
>420
>
>421 int ffurl_write(URLContext *h, const unsigned char *buf, int size)
>
>422 {
>
> -> 423 if (!(h->flags & AVIO_FLAG_WRITE))
>
>424 return AVERROR(EIO);
>
>425 /* avoid sending too big packets */
>
>426 if (h->max_packet_size && size > h->max_packet_size)
>
> Target 0: (kodi.bin) stopped.
>
>
> And the backtrace:
>
>
> * thread #28, name = 'VideoPlayer', stop reason = EXC_BAD_ACCESS (code=1,
> address=0x20)
>
> * frame #0: 0x0001037af09e
> kodi.bin`ffurl_write(h=0x, buf="TEARDOWN RTSP/1.0\r\nCSeq:
> 1\r\nUser-Agent: Lavf58.29.100\r\n\r\n", size=58) at avio.c:423:20 [opt]
>
> frame #1: 0x0001038c3be9
> kodi.bin`rtsp_send_cmd_with_content_async(s=0x00011989c000,
> method=, url=, headers=,
> send_content=0x, send_content_length=0) at rtsp.c:1352:5
> [opt]
>
> frame #2: 0x0001038c928c
> kodi.bin`rtsp_read_close(s=0x00011989c000) at rtspdec.c:61:9 [opt]
>
> frame #3: 0x0001038f9994
> kodi.bin`avformat_close_input(ps=0x00014dbb8000) at utils.c:4450:13
> [opt]
>
> frame #4: 0x0001004c7841
> kodi.bin`CDVDDemuxFFmpeg::Open(this=0x00014dbb7ff0,
> pInput=std::__1::shared_ptr::element_type @
> 0x00014dbb7d10 strong=4 weak=1, streaminfo=true, fileinfo=false) at
> DVDDemuxFFmpeg.cpp:278:7
>
> frame #5: 0x0001004eb802
> kodi.bin`CDVDFactoryDemuxer::CreateDemuxer(pInputStream=std::__1::shared_ptr::element_type
> @ 0x00014dbb7d10 strong=4 weak=1, fileinfo=false) at
> DVDFactoryDemuxer.cpp:88:15
>
> frame #6: 0x000100575ff3
> kodi.bin`CVideoPlayer::OpenDemuxStream(this=0x00011d90d800) at
> VideoPlayer.cpp:822:18
>
> frame #7: 0x000100579642
> kodi.bin`CVideoPlayer::Prepare(this=0x00011d90d800) at
> VideoPlayer.cpp:1224:8
>
> frame #8: 0x00010057b70f
> kodi.bin`CVideoPlayer::Process(this=0x00011d90d800) at
> VideoPlayer.cpp:1310:3
>
> frame #9: 0x000100aa7a04
> kodi.bin`CThread::Action(this=0x00011d90d800) at Thread.cpp:282:5
>
> frame #10: 0x000100aadc90
> kodi.bin`CThread::Create(this=0x00014d19f670,
> pThread=0x00011d90d800, promise=promise @
> 0x7b522e70)::$_0::operator()(CThread*, std::__1::promise)
> const at Thread.cpp:140:18
>
> frame #11: 0x000100aad9eb
> kodi.bin`decltype(__f=0x00014d19f670, __args=0x00014d19f678,
> __args=0x00014d19f680)::$_0>(fp)(std::__1::forward(fp0),
> std::__1::forward >(fp0)))
> std::__1::__invoke std::__1::promise >(CThread::Create(bool)::$_0&&, CThread*&&,
> std::__1::promise&&) at type_traits:4339:1
>
> frame #12: 0x000100aad917 kodi.bin`void
> std::__1::__thread_execute std::__1::default_delete >,
> CThread::Create(bool)::$_0, CThread*, std::__1::promise, 2ul,
> 3ul>(__t=size=4, (null)=__tuple_indices<2, 3> @ 0x7b522eb8)::$_0,
> CThread*, std::__1::promise >&, std::__1::__tuple_indices<2ul, 3ul>)
> at thread:342:5
>
> frame #13: 0x000100aad026 kodi.bin`void*
> std::__1::__thread_proxy std::__1::default_delete >,
> CThread::Create(bool)::$_0, CThread*, std::__1::promise >
> >(__vp=0x00014d19f670) at thread:352:5
>
> frame #14: 0x7fff68c1c2eb libsystem_pthread.dylib`_pthread_body +
> 126
>
> frame #15: 0x7fff68c1f249 libsystem_pthread.dylib`_pthread_start
> + 66
>
> frame #16: 0x7fff68c1b40d libsystem_pthread.dylib`thread_start +
> 13
>
>
>
> On Thu, 29 Aug 2019 at 00:20, Jun Li wrote:
>
>> On Wed, Aug 28, 2019 at 3:09 PM Carl Eugen Hoyos
>> wrote:
>>
>> > Am Mo., 5. Aug. 2019 um 09:19 Uhr schrieb Ross Nicholson <
>> > phunkyf...@gmail.c
Re: [FFmpeg-devel] [PATCH] libavformat/rtspdec: Don't send teardown if rtsp_hd_out is null
Hey All,
Anything needed from me to progress this?
Thanks in advance,
Ross
> On 29 Aug 2019, at 17:04, Ross Nicholson wrote:
>
> Hey Jun,
>
> So I got kodi running with FFmpeg n4.2 and the issue persists. Here's the
> debugger output after trying to play the test link you provided.
>
> With the patch this does not occur so their must be some way to call function
> with rt->rtsp_hd_out as NULL;
>
> Thanks,
>
> Ross
>
> Process 92017 stopped
> * thread #28, name = 'VideoPlayer', stop reason = EXC_BAD_ACCESS (code=1,
> address=0x20)
> frame #0: 0x0001037af09e kodi.bin`ffurl_write(h=0x,
> buf="TEARDOWN RTSP/1.0\r\nCSeq: 1\r\nUser-Agent: Lavf58.29.100\r\n\r\n",
> size=58) at avio.c:423:20 [opt]
>420
>421int ffurl_write(URLContext *h, const unsigned char *buf, int
> size)
>422{
> -> 423if (!(h->flags & AVIO_FLAG_WRITE))
>424return AVERROR(EIO);
>425/* avoid sending too big packets */
>426if (h->max_packet_size && size > h->max_packet_size)
> Target 0: (kodi.bin) stopped.
>
> And the backtrace:
>
> * thread #28, name = 'VideoPlayer', stop reason = EXC_BAD_ACCESS (code=1,
> address=0x20)
> * frame #0: 0x0001037af09e kodi.bin`ffurl_write(h=0x,
> buf="TEARDOWN RTSP/1.0\r\nCSeq: 1\r\nUser-Agent: Lavf58.29.100\r\n\r\n",
> size=58) at avio.c:423:20 [opt]
> frame #1: 0x0001038c3be9
> kodi.bin`rtsp_send_cmd_with_content_async(s=0x00011989c000,
> method=, url=, headers=,
> send_content=0x, send_content_length=0) at rtsp.c:1352:5 [opt]
> frame #2: 0x0001038c928c
> kodi.bin`rtsp_read_close(s=0x00011989c000) at rtspdec.c:61:9 [opt]
> frame #3: 0x0001038f9994
> kodi.bin`avformat_close_input(ps=0x00014dbb8000) at utils.c:4450:13 [opt]
> frame #4: 0x0001004c7841
> kodi.bin`CDVDDemuxFFmpeg::Open(this=0x00014dbb7ff0,
> pInput=std::__1::shared_ptr::element_type @
> 0x00014dbb7d10 strong=4 weak=1, streaminfo=true, fileinfo=false) at
> DVDDemuxFFmpeg.cpp:278:7
> frame #5: 0x0001004eb802
> kodi.bin`CDVDFactoryDemuxer::CreateDemuxer(pInputStream=std::__1::shared_ptr::element_type
> @ 0x00014dbb7d10 strong=4 weak=1, fileinfo=false) at
> DVDFactoryDemuxer.cpp:88:15
> frame #6: 0x000100575ff3
> kodi.bin`CVideoPlayer::OpenDemuxStream(this=0x00011d90d800) at
> VideoPlayer.cpp:822:18
> frame #7: 0x000100579642
> kodi.bin`CVideoPlayer::Prepare(this=0x00011d90d800) at
> VideoPlayer.cpp:1224:8
> frame #8: 0x00010057b70f
> kodi.bin`CVideoPlayer::Process(this=0x00011d90d800) at
> VideoPlayer.cpp:1310:3
> frame #9: 0x000100aa7a04
> kodi.bin`CThread::Action(this=0x00011d90d800) at Thread.cpp:282:5
> frame #10: 0x000100aadc90
> kodi.bin`CThread::Create(this=0x00014d19f670, pThread=0x00011d90d800,
> promise=promise @ 0x7b522e70)::$_0::operator()(CThread*,
> std::__1::promise) const at Thread.cpp:140:18
> frame #11: 0x000100aad9eb kodi.bin`decltype(__f=0x00014d19f670,
> __args=0x00014d19f678,
> __args=0x00014d19f680)::$_0>(fp)(std::__1::forward(fp0),
> std::__1::forward >(fp0)))
> std::__1::__invoke std::__1::promise >(CThread::Create(bool)::$_0&&, CThread*&&,
> std::__1::promise&&) at type_traits:4339:1
> frame #12: 0x000100aad917 kodi.bin`void
> std::__1::__thread_execute std::__1::default_delete >,
> CThread::Create(bool)::$_0, CThread*, std::__1::promise, 2ul,
> 3ul>(__t=size=4, (null)=__tuple_indices<2, 3> @ 0x7b522eb8)::$_0,
> CThread*, std::__1::promise >&, std::__1::__tuple_indices<2ul, 3ul>) at
> thread:342:5
> frame #13: 0x000100aad026 kodi.bin`void*
> std::__1::__thread_proxy std::__1::default_delete >,
> CThread::Create(bool)::$_0, CThread*, std::__1::promise >
> >(__vp=0x00014d19f670) at thread:352:5
> frame #14: 0x7fff68c1c2eb libsystem_pthread.dylib`_pthread_body + 126
> frame #15: 0x7fff68c1f249 libsystem_pthread.dylib`_pthread_start + 66
> frame #16: 0x7fff68c1b40d libsystem_pthread.dylib`thread_start + 13
>
>
>> On Thu, 29 Aug 2019 at 00:20, Jun Li wrote:
>> On Wed, Aug 28, 2019 at 3:09 PM Carl Eugen Hoyos wrote:
>>
>> > Am Mo., 5. Aug. 2019 um 09:19 Uhr schrieb Ross Nicholson <
>> > phunkyf...@gmail.com>:
>> > >
>> > > Example stream that does not work: rtsp://
>> > > 184.72.239.149/vod/mp4:BigBuckBunny_115k.mov
>> >
>> > I
Re: [FFmpeg-devel] [PATCH] libavformat/rtspdec: Don't send teardown if rtsp_hd_out is null
Hey Jun,
So I got kodi running with FFmpeg n4.2 and the issue persists. Here's the
debugger output after trying to play the test link you provided.
With the patch this does not occur so their must be some way to call
function with rt->rtsp_hd_out as NULL;
Thanks,
Ross
Process 92017 stopped
* thread #28, name = 'VideoPlayer', stop reason = EXC_BAD_ACCESS (code=1,
address=0x20)
frame #0: 0x0001037af09e kodi.bin`ffurl_write(h=0x,
buf="TEARDOWN RTSP/1.0\r\nCSeq: 1\r\nUser-Agent: Lavf58.29.100\r\n\r\n",
size=58) at avio.c:423:20 [opt]
420
421 int ffurl_write(URLContext *h, const unsigned char *buf, int size)
422 {
-> 423 if (!(h->flags & AVIO_FLAG_WRITE))
424 return AVERROR(EIO);
425 /* avoid sending too big packets */
426 if (h->max_packet_size && size > h->max_packet_size)
Target 0: (kodi.bin) stopped.
And the backtrace:
* thread #28, name = 'VideoPlayer', stop reason = EXC_BAD_ACCESS (code=1,
address=0x20)
* frame #0: 0x0001037af09e kodi.bin`ffurl_write(h=0x,
buf="TEARDOWN RTSP/1.0\r\nCSeq: 1\r\nUser-Agent: Lavf58.29.100\r\n\r\n",
size=58) at avio.c:423:20 [opt]
frame #1: 0x0001038c3be9
kodi.bin`rtsp_send_cmd_with_content_async(s=0x00011989c000,
method=, url=, headers=,
send_content=0x, send_content_length=0) at rtsp.c:1352:5
[opt]
frame #2: 0x0001038c928c
kodi.bin`rtsp_read_close(s=0x00011989c000) at rtspdec.c:61:9 [opt]
frame #3: 0x0001038f9994
kodi.bin`avformat_close_input(ps=0x00014dbb8000) at utils.c:4450:13
[opt]
frame #4: 0x0001004c7841
kodi.bin`CDVDDemuxFFmpeg::Open(this=0x00014dbb7ff0,
pInput=std::__1::shared_ptr::element_type @
0x00014dbb7d10 strong=4 weak=1, streaminfo=true, fileinfo=false) at
DVDDemuxFFmpeg.cpp:278:7
frame #5: 0x0001004eb802
kodi.bin`CDVDFactoryDemuxer::CreateDemuxer(pInputStream=std::__1::shared_ptr::element_type
@ 0x00014dbb7d10 strong=4 weak=1, fileinfo=false) at
DVDFactoryDemuxer.cpp:88:15
frame #6: 0x000100575ff3
kodi.bin`CVideoPlayer::OpenDemuxStream(this=0x00011d90d800) at
VideoPlayer.cpp:822:18
frame #7: 0x000100579642
kodi.bin`CVideoPlayer::Prepare(this=0x00011d90d800) at
VideoPlayer.cpp:1224:8
frame #8: 0x00010057b70f
kodi.bin`CVideoPlayer::Process(this=0x00011d90d800) at
VideoPlayer.cpp:1310:3
frame #9: 0x000100aa7a04
kodi.bin`CThread::Action(this=0x00011d90d800) at Thread.cpp:282:5
frame #10: 0x000100aadc90
kodi.bin`CThread::Create(this=0x00014d19f670,
pThread=0x00011d90d800, promise=promise @
0x7b522e70)::$_0::operator()(CThread*, std::__1::promise)
const at Thread.cpp:140:18
frame #11: 0x000100aad9eb kodi.bin`decltype(__f=0x00014d19f670,
__args=0x00014d19f678,
__args=0x00014d19f680)::$_0>(fp)(std::__1::forward(fp0),
std::__1::forward >(fp0)))
std::__1::__invoke >(CThread::Create(bool)::$_0&&, CThread*&&,
std::__1::promise&&) at type_traits:4339:1
frame #12: 0x000100aad917 kodi.bin`void
std::__1::__thread_execute >,
CThread::Create(bool)::$_0, CThread*, std::__1::promise, 2ul,
3ul>(__t=size=4, (null)=__tuple_indices<2, 3> @ 0x7b522eb8)::$_0,
CThread*, std::__1::promise >&, std::__1::__tuple_indices<2ul, 3ul>)
at thread:342:5
frame #13: 0x000100aad026 kodi.bin`void*
std::__1::__thread_proxy >,
CThread::Create(bool)::$_0, CThread*, std::__1::promise >
>(__vp=0x00014d19f670) at thread:352:5
frame #14: 0x7fff68c1c2eb libsystem_pthread.dylib`_pthread_body +
126
frame #15: 0x7fff68c1f249 libsystem_pthread.dylib`_pthread_start +
66
frame #16: 0x7fff68c1b40d libsystem_pthread.dylib`thread_start + 13
On Thu, 29 Aug 2019 at 00:20, Jun Li wrote:
> On Wed, Aug 28, 2019 at 3:09 PM Carl Eugen Hoyos
> wrote:
>
> > Am Mo., 5. Aug. 2019 um 09:19 Uhr schrieb Ross Nicholson <
> > phunkyf...@gmail.com>:
> > >
> > > Example stream that does not work: rtsp://
> > > 184.72.239.149/vod/mp4:BigBuckBunny_115k.mov
> >
> > Is this still valid?
> >
> >
> Carl, you can try this one for validation: rtsp://
> wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov
>
> Hi Ross,
> Just curious, is there any case the rt->rtsp_hd_out is NULL ?
> Looks like the hd_out is either TCP or HTTP(http tunnel case) for RTSP
> connection. And I only see it is set to NULL in ff_rtsp_close_connections,
> which is called after your check.
>
> -Jun
>
> I get a time-out both with and without your patch.
> >
> > Carl Eugen
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >
Re: [FFmpeg-devel] [PATCH] libavformat/rtspdec: Don't send teardown if rtsp_hd_out is null
I did leave out one detail. Currently kodi is using v4.0.4. It's possible there was a fix since that prevents rt->rtsp_hd being NULL in the call to rtsp_send_cmd_with_content_async in the first place. Won't be able to test with 4.2 and kodi until the version gets bumped to see if it persists without the patch. Could be that a flow used in kodi causes this to go to NULL. However, checking if rt->rtsp_hd_out is not null before calling rtsp_send_cmd_with_content_async should cause no harm either. On Thu, 29 Aug 2019 at 00:20, Jun Li wrote: > On Wed, Aug 28, 2019 at 3:09 PM Carl Eugen Hoyos > wrote: > > > Am Mo., 5. Aug. 2019 um 09:19 Uhr schrieb Ross Nicholson < > > phunkyf...@gmail.com>: > > > > > > Example stream that does not work: rtsp:// > > > 184.72.239.149/vod/mp4:BigBuckBunny_115k.mov > > > > Is this still valid? > > > > > Carl, you can try this one for validation: rtsp:// > wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov > > Hi Ross, > Just curious, is there any case the rt->rtsp_hd_out is NULL ? > Looks like the hd_out is either TCP or HTTP(http tunnel case) for RTSP > connection. And I only see it is set to NULL in ff_rtsp_close_connections, > which is called after your check. > > -Jun > > I get a time-out both with and without your patch. > > > > Carl Eugen > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/rtspdec: Don't send teardown if rtsp_hd_out is null
Hey guys, if there is anything else required to progress this please let me
know.
It’s my first patch submission to FFMpeg so not sure how long it should take.
> On 23 Aug 2019, at 20:10, Ross Nicholson wrote:
>
> Ping
>
>> On 17 Aug 2019, at 14:57, Ross Nicholson wrote:
>>
>> Ok, thanks Moritz.
>>
>>>> On 17 Aug 2019, at 14:10, Moritz Barsnick wrote:
>>>>
>>>> On Fri, Aug 16, 2019 at 10:35:43 -0700, Ross Nicholson wrote:
>>>> Need anything else Moritz?
>>>
>>> No. I only made one remark ("can't understand your issue"), hoping to
>>> push things forward with new facts for others to take into
>>> consideration. I can't and won't judge whether your fix is reasonable
>>> or required. You'll need to wait for others to look into it.
>>>
>>> Moritz
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>> To unsubscribe, visit link above, or email
>>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/rtspdec: Don't send teardown if rtsp_hd_out is null
Ping
> On 17 Aug 2019, at 14:57, Ross Nicholson wrote:
>
> Ok, thanks Moritz.
>
>>> On 17 Aug 2019, at 14:10, Moritz Barsnick wrote:
>>>
>>> On Fri, Aug 16, 2019 at 10:35:43 -0700, Ross Nicholson wrote:
>>> Need anything else Moritz?
>>
>> No. I only made one remark ("can't understand your issue"), hoping to
>> push things forward with new facts for others to take into
>> consideration. I can't and won't judge whether your fix is reasonable
>> or required. You'll need to wait for others to look into it.
>>
>> Moritz
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/rtspdec: Don't send teardown if rtsp_hd_out is null
Ok, thanks Moritz.
> On 17 Aug 2019, at 14:10, Moritz Barsnick wrote:
>
>> On Fri, Aug 16, 2019 at 10:35:43 -0700, Ross Nicholson wrote:
>> Need anything else Moritz?
>
> No. I only made one remark ("can't understand your issue"), hoping to
> push things forward with new facts for others to take into
> consideration. I can't and won't judge whether your fix is reasonable
> or required. You'll need to wait for others to look into it.
>
> Moritz
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/rtspdec: Don't send teardown if rtsp_hd_out is null
Need anything else Moritz? > On 14 Aug 2019, at 09:54, Ross Nicholson wrote: > > I would imagine that the way Kodi handles the stream, rtsp_hd_out is null as > per the following: > > URLContext * rtsp_hd_out > Additional output handle, used when input and output are done > separately, eg for HTTP tunneling. > > In your case it would not be. > >> On Wed, 14 Aug 2019 at 09:50, Ross Nicholson wrote: >> >> >>> On Wed, 14 Aug 2019 at 07:20, Moritz Barsnick wrote: >>> On Mon, Aug 05, 2019 at 08:18:32 +0100, Ross Nicholson wrote: >>> > Example stream that does not work: >>> > rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mov >>> > >>> > Extending the condition allows the stream to be processed correctly. >>> >>> Can you give a bit more detail? Decoding this stream works for me (at >>> last the first 20 seconds or so). >>> >> >> We made some changes in Kodi regardless handling TS streams the right way. >> An unfortunate side effect was that we caused an issue with RTSP streams due >> to an issue in rtsp_send_cmd_with_content_async. The issue can be avoided >> once sending teardown is skipped if rtsp_hd_out is null. >> >>> > On Mon, 5 Aug 2019 at 08:17, Ross Nicholson wrote: >>> > > From: phunkyfish >>> >>> Do you want your real name or this pseudonym registered in the repo? It >>> can't be changed afterwards. >> >> Yes, that email is registered on github if that's what you mean. >>> >>> Moritz >>> ___ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >>> To unsubscribe, visit link above, or email >>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/rtspdec: Don't send teardown if rtsp_hd_out is null
On Wed, 14 Aug 2019 at 07:20, Moritz Barsnick wrote: > On Mon, Aug 05, 2019 at 08:18:32 +0100, Ross Nicholson wrote: > > Example stream that does not work: rtsp:// > 184.72.239.149/vod/mp4:BigBuckBunny_115k.mov > > > > Extending the condition allows the stream to be processed correctly. > > Can you give a bit more detail? Decoding this stream works for me (at > last the first 20 seconds or so). > > We made some changes in Kodi regardless handling TS streams the right way. An unfortunate side effect was that we caused an issue with RTSP streams due to an issue in rtsp_send_cmd_with_content_async. The issue can be avoided once sending teardown is skipped if rtsp_hd_out is null. > > On Mon, 5 Aug 2019 at 08:17, Ross Nicholson > wrote: > > > From: phunkyfish > > Do you want your real name or this pseudonym registered in the repo? It > can't be changed afterwards. > Yes, that email is registered on github if that's what you mean. > > Moritz > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/rtspdec: Don't send teardown if rtsp_hd_out is null
I would imagine that the way Kodi handles the stream, rtsp_hd_out is null as per the following: URLContext <https://www.ffmpeg.org/doxygen/2.6/structURLContext.html> * rtsp_hd_out <https://www.ffmpeg.org/doxygen/2.6/structRTSPState.html#a418d3e730da96b45bf38c5c421f6e768> Additional output handle, used when input and output are done separately, eg for HTTP tunneling. In your case it would not be. On Wed, 14 Aug 2019 at 09:50, Ross Nicholson wrote: > > > On Wed, 14 Aug 2019 at 07:20, Moritz Barsnick wrote: > >> On Mon, Aug 05, 2019 at 08:18:32 +0100, Ross Nicholson wrote: >> > Example stream that does not work: rtsp:// >> 184.72.239.149/vod/mp4:BigBuckBunny_115k.mov >> > >> > Extending the condition allows the stream to be processed correctly. >> >> Can you give a bit more detail? Decoding this stream works for me (at >> last the first 20 seconds or so). >> >> > We made some changes in Kodi regardless handling TS streams the right way. > An unfortunate side effect was that we caused an issue with RTSP streams > due to an issue in rtsp_send_cmd_with_content_async. The issue can be > avoided once sending teardown is skipped if rtsp_hd_out is null. > > >> > On Mon, 5 Aug 2019 at 08:17, Ross Nicholson >> wrote: >> > > From: phunkyfish >> >> Do you want your real name or this pseudonym registered in the repo? It >> can't be changed afterwards. >> > > Yes, that email is registered on github if that's what you mean. > >> >> Moritz >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/rtspdec: Don't send teardown if rtsp_hd_out is null
Ping.
If I’m missing something I should have provided for this patch please let me
know. It’s my first patch to FFmpeg.
> On 11 Aug 2019, at 10:39, Ross Nicholson wrote:
>
> 3rd time lucky, can anyone take a look at this? It’s a minor patch and is
> required for kodi.
>
> Thanks in advance
>
>> On 8 Aug 2019, at 11:46, Ross Nicholson wrote:
>>
>> Any feedback on this patch?
>>
>>> On Mon, 5 Aug 2019 at 00:18, Ross Nicholson wrote:
>>> Example stream that does not work:
>>> rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mov
>>>
>>> Extending the condition allows the stream to be processed correctly.
>>>
>>>> On Mon, 5 Aug 2019 at 08:17, Ross Nicholson wrote:
>>>> From: phunkyfish
>>>>
>>>> ---
>>>> libavformat/rtspdec.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
>>>> index 32dff2319c..3a79d1b175 100644
>>>> --- a/libavformat/rtspdec.c
>>>> +++ b/libavformat/rtspdec.c
>>>> @@ -57,7 +57,7 @@ static int rtsp_read_close(AVFormatContext *s)
>>>> {
>>>> RTSPState *rt = s->priv_data;
>>>>
>>>> -if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN))
>>>> +if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN) && rt->rtsp_hd_out)
>>>> ff_rtsp_send_cmd_async(s, "TEARDOWN", rt->control_uri, NULL);
>>>>
>>>> ff_rtsp_close_streams(s);
>>>> --
>>>> 2.20.1 (Apple Git-117)
>>>>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/rtspdec: Don't send teardown if rtsp_hd_out is null
3rd time lucky, can anyone take a look at this? It’s a minor patch and is
required for kodi.
Thanks in advance
> On 8 Aug 2019, at 11:46, Ross Nicholson wrote:
>
> Any feedback on this patch?
>
>> On Mon, 5 Aug 2019 at 00:18, Ross Nicholson wrote:
>> Example stream that does not work:
>> rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mov
>>
>> Extending the condition allows the stream to be processed correctly.
>>
>>> On Mon, 5 Aug 2019 at 08:17, Ross Nicholson wrote:
>>> From: phunkyfish
>>>
>>> ---
>>> libavformat/rtspdec.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
>>> index 32dff2319c..3a79d1b175 100644
>>> --- a/libavformat/rtspdec.c
>>> +++ b/libavformat/rtspdec.c
>>> @@ -57,7 +57,7 @@ static int rtsp_read_close(AVFormatContext *s)
>>> {
>>> RTSPState *rt = s->priv_data;
>>>
>>> -if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN))
>>> +if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN) && rt->rtsp_hd_out)
>>> ff_rtsp_send_cmd_async(s, "TEARDOWN", rt->control_uri, NULL);
>>>
>>> ff_rtsp_close_streams(s);
>>> --
>>> 2.20.1 (Apple Git-117)
>>>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/rtspdec: Don't send teardown if rtsp_hd_out is null
Any feedback on this patch?
On Mon, 5 Aug 2019 at 00:18, Ross Nicholson wrote:
> Example stream that does not work: rtsp://
> 184.72.239.149/vod/mp4:BigBuckBunny_115k.mov
>
> Extending the condition allows the stream to be processed correctly.
>
> On Mon, 5 Aug 2019 at 08:17, Ross Nicholson wrote:
>
>> From: phunkyfish
>>
>> ---
>> libavformat/rtspdec.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
>> index 32dff2319c..3a79d1b175 100644
>> --- a/libavformat/rtspdec.c
>> +++ b/libavformat/rtspdec.c
>> @@ -57,7 +57,7 @@ static int rtsp_read_close(AVFormatContext *s)
>> {
>> RTSPState *rt = s->priv_data;
>>
>> -if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN))
>> +if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN) && rt->rtsp_hd_out)
>> ff_rtsp_send_cmd_async(s, "TEARDOWN", rt->control_uri, NULL);
>>
>> ff_rtsp_close_streams(s);
>> --
>> 2.20.1 (Apple Git-117)
>>
>>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/rtspdec: Don't send teardown if rtsp_hd_out is null
Example stream that does not work: rtsp://
184.72.239.149/vod/mp4:BigBuckBunny_115k.mov
Extending the condition allows the stream to be processed correctly.
On Mon, 5 Aug 2019 at 08:17, Ross Nicholson wrote:
> From: phunkyfish
>
> ---
> libavformat/rtspdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
> index 32dff2319c..3a79d1b175 100644
> --- a/libavformat/rtspdec.c
> +++ b/libavformat/rtspdec.c
> @@ -57,7 +57,7 @@ static int rtsp_read_close(AVFormatContext *s)
> {
> RTSPState *rt = s->priv_data;
>
> -if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN))
> +if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN) && rt->rtsp_hd_out)
> ff_rtsp_send_cmd_async(s, "TEARDOWN", rt->control_uri, NULL);
>
> ff_rtsp_close_streams(s);
> --
> 2.20.1 (Apple Git-117)
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] libavformat/rtspdec: Don't send teardown if rtsp_hd_out is null
From: phunkyfish
---
libavformat/rtspdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
index 32dff2319c..3a79d1b175 100644
--- a/libavformat/rtspdec.c
+++ b/libavformat/rtspdec.c
@@ -57,7 +57,7 @@ static int rtsp_read_close(AVFormatContext *s)
{
RTSPState *rt = s->priv_data;
-if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN))
+if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN) && rt->rtsp_hd_out)
ff_rtsp_send_cmd_async(s, "TEARDOWN", rt->control_uri, NULL);
ff_rtsp_close_streams(s);
--
2.20.1 (Apple Git-117)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Don't send teardown if rtsp_hd_out is null
Wrong commit message/subject. Please ignore. Will send new patch shortly.
On Sun, 4 Aug 2019 at 22:41, Ross Nicholson wrote:
> Example stream that does not work: rtsp://
> 184.72.239.149/vod/mp4:BigBuckBunny_115k.mov
>
> Extending the condition allows the stream to be processed correctly.
>
> On Sun, 4 Aug 2019 at 22:39, Ross Nicholson wrote:
>
>> From: phunkyfish
>>
>> ---
>> libavformat/rtspdec.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
>> index 32dff2319c..3a79d1b175 100644
>> --- a/libavformat/rtspdec.c
>> +++ b/libavformat/rtspdec.c
>> @@ -57,7 +57,7 @@ static int rtsp_read_close(AVFormatContext *s)
>> {
>> RTSPState *rt = s->priv_data;
>>
>> -if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN))
>> +if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN) && rt->rtsp_hd_out)
>> ff_rtsp_send_cmd_async(s, "TEARDOWN", rt->control_uri, NULL);
>>
>> ff_rtsp_close_streams(s);
>> --
>> 2.20.1 (Apple Git-117)
>>
>>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] Don't send teardown if rtsp_hd_out is null
From: phunkyfish
---
libavformat/rtspdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
index 32dff2319c..3a79d1b175 100644
--- a/libavformat/rtspdec.c
+++ b/libavformat/rtspdec.c
@@ -57,7 +57,7 @@ static int rtsp_read_close(AVFormatContext *s)
{
RTSPState *rt = s->priv_data;
-if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN))
+if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN) && rt->rtsp_hd_out)
ff_rtsp_send_cmd_async(s, "TEARDOWN", rt->control_uri, NULL);
ff_rtsp_close_streams(s);
--
2.20.1 (Apple Git-117)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Don't send teardown if rtsp_hd_out is null
Example stream that does not work: rtsp://
184.72.239.149/vod/mp4:BigBuckBunny_115k.mov
Extending the condition allows the stream to be processed correctly.
On Sun, 4 Aug 2019 at 22:39, Ross Nicholson wrote:
> From: phunkyfish
>
> ---
> libavformat/rtspdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
> index 32dff2319c..3a79d1b175 100644
> --- a/libavformat/rtspdec.c
> +++ b/libavformat/rtspdec.c
> @@ -57,7 +57,7 @@ static int rtsp_read_close(AVFormatContext *s)
> {
> RTSPState *rt = s->priv_data;
>
> -if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN))
> +if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN) && rt->rtsp_hd_out)
> ff_rtsp_send_cmd_async(s, "TEARDOWN", rt->control_uri, NULL);
>
> ff_rtsp_close_streams(s);
> --
> 2.20.1 (Apple Git-117)
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/rtspdec: Don't send teardown if rtsp_hd_out is null
Example: rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mov Extending the condition allows the stream to be processed correctly. 0001-Don-t-send-teardown-if-rtsp_hd_out-is-null.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
