| Message ID | 20190805071646.14780-1-phunkyfish@gmail.com |
|---|---|
| State | Withdrawn |
| Headers | show |
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 <phunkyfish@gmail.com> wrote: > From: phunkyfish <phunkyfish@gmail.com> > > --- > 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) > >
Any feedback on this patch? On Mon, 5 Aug 2019 at 00:18, Ross Nicholson <phunkyfish@gmail.com> 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 <phunkyfish@gmail.com> wrote: > >> From: phunkyfish <phunkyfish@gmail.com> >> >> --- >> 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) >> >>
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 <phunkyfish@gmail.com> wrote: > > Any feedback on this patch? > >> On Mon, 5 Aug 2019 at 00:18, Ross Nicholson <phunkyfish@gmail.com> 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 <phunkyfish@gmail.com> wrote: >>> From: phunkyfish <phunkyfish@gmail.com> >>> >>> --- >>> 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) >>>
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 <phunkyfish@gmail.com> 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 <phunkyfish@gmail.com> wrote: >> >> Any feedback on this patch? >> >>> On Mon, 5 Aug 2019 at 00:18, Ross Nicholson <phunkyfish@gmail.com> 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 <phunkyfish@gmail.com> wrote: >>>> From: phunkyfish <phunkyfish@gmail.com> >>>> >>>> --- >>>> 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) >>>>
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). > On Mon, 5 Aug 2019 at 08:17, Ross Nicholson <phunkyfish@gmail.com> wrote: > > From: phunkyfish <phunkyfish@gmail.com> Do you want your real name or this pseudonym registered in the repo? It can't be changed afterwards. Moritz
On Wed, 14 Aug 2019 at 07:20, Moritz Barsnick <barsnick@gmx.net> 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 <phunkyfish@gmail.com> > wrote: > > > From: phunkyfish <phunkyfish@gmail.com> > > 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-request@ffmpeg.org with subject "unsubscribe".
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 <phunkyfish@gmail.com> wrote: > > > On Wed, 14 Aug 2019 at 07:20, Moritz Barsnick <barsnick@gmx.net> 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 <phunkyfish@gmail.com> >> wrote: >> > > From: phunkyfish <phunkyfish@gmail.com> >> >> 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-request@ffmpeg.org with subject "unsubscribe". > >
Need anything else Moritz? > On 14 Aug 2019, at 09:54, Ross Nicholson <phunkyfish@gmail.com> 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 <phunkyfish@gmail.com> wrote: >> >> >>> On Wed, 14 Aug 2019 at 07:20, Moritz Barsnick <barsnick@gmx.net> 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 <phunkyfish@gmail.com> wrote: >>> > > From: phunkyfish <phunkyfish@gmail.com> >>> >>> 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-request@ffmpeg.org with subject "unsubscribe".
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
Ok, thanks Moritz. > On 17 Aug 2019, at 14:10, Moritz Barsnick <barsnick@gmx.net> 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-request@ffmpeg.org with subject "unsubscribe".
Ping > On 17 Aug 2019, at 14:57, Ross Nicholson <phunkyfish@gmail.com> wrote: > > Ok, thanks Moritz. > >>> On 17 Aug 2019, at 14:10, Moritz Barsnick <barsnick@gmx.net> 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-request@ffmpeg.org with subject "unsubscribe".
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 <phunkyfish@gmail.com> wrote: > > Ping > >> On 17 Aug 2019, at 14:57, Ross Nicholson <phunkyfish@gmail.com> wrote: >> >> Ok, thanks Moritz. >> >>>> On 17 Aug 2019, at 14:10, Moritz Barsnick <barsnick@gmx.net> 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-request@ffmpeg.org with subject "unsubscribe".
Am Mo., 5. Aug. 2019 um 09:19 Uhr schrieb Ross Nicholson <phunkyfish@gmail.com>: > > Example stream that does not work: rtsp:// > 184.72.239.149/vod/mp4:BigBuckBunny_115k.mov Is this still valid? I get a time-out both with and without your patch. Carl Eugen
On Wed, Aug 28, 2019 at 3:09 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > Am Mo., 5. Aug. 2019 um 09:19 Uhr schrieb Ross Nicholson < > phunkyfish@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-request@ffmpeg.org with subject "unsubscribe".
No se puede acceder a este sitio web El mié., 28 ago. 2019 a las 20:20, Jun Li (<junli1026@gmail.com>) escribió: > On Wed, Aug 28, 2019 at 3:09 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> > wrote: > > > Am Mo., 5. Aug. 2019 um 09:19 Uhr schrieb Ross Nicholson < > > phunkyfish@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-request@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-request@ffmpeg.org with subject "unsubscribe".
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 <junli1026@gmail.com> wrote: > On Wed, Aug 28, 2019 at 3:09 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> > wrote: > > > Am Mo., 5. Aug. 2019 um 09:19 Uhr schrieb Ross Nicholson < > > phunkyfish@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-request@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-request@ffmpeg.org with subject "unsubscribe".
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: 0x00000001037af09e kodi.bin`ffurl_write(h=0x0000000000000000,
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: 0x00000001037af09e kodi.bin`ffurl_write(h=0x0000000000000000,
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: 0x00000001038c3be9
kodi.bin`rtsp_send_cmd_with_content_async(s=0x000000011989c000,
method=<unavailable>, url=<unavailable>, headers=<unavailable>,
send_content=0x0000000000000000, send_content_length=0) at rtsp.c:1352:5
[opt]
frame #2: 0x00000001038c928c
kodi.bin`rtsp_read_close(s=0x000000011989c000) at rtspdec.c:61:9 [opt]
frame #3: 0x00000001038f9994
kodi.bin`avformat_close_input(ps=0x000000014dbb8000) at utils.c:4450:13
[opt]
frame #4: 0x00000001004c7841
kodi.bin`CDVDDemuxFFmpeg::Open(this=0x000000014dbb7ff0,
pInput=std::__1::shared_ptr<CDVDInputStream>::element_type @
0x000000014dbb7d10 strong=4 weak=1, streaminfo=true, fileinfo=false) at
DVDDemuxFFmpeg.cpp:278:7
frame #5: 0x00000001004eb802
kodi.bin`CDVDFactoryDemuxer::CreateDemuxer(pInputStream=std::__1::shared_ptr<CDVDInputStream>::element_type
@ 0x000000014dbb7d10 strong=4 weak=1, fileinfo=false) at
DVDFactoryDemuxer.cpp:88:15
frame #6: 0x0000000100575ff3
kodi.bin`CVideoPlayer::OpenDemuxStream(this=0x000000011d90d800) at
VideoPlayer.cpp:822:18
frame #7: 0x0000000100579642
kodi.bin`CVideoPlayer::Prepare(this=0x000000011d90d800) at
VideoPlayer.cpp:1224:8
frame #8: 0x000000010057b70f
kodi.bin`CVideoPlayer::Process(this=0x000000011d90d800) at
VideoPlayer.cpp:1310:3
frame #9: 0x0000000100aa7a04
kodi.bin`CThread::Action(this=0x000000011d90d800) at Thread.cpp:282:5
frame #10: 0x0000000100aadc90
kodi.bin`CThread::Create(this=0x000000014d19f670,
pThread=0x000000011d90d800, promise=promise<bool> @
0x000070000b522e70)::$_0::operator()(CThread*, std::__1::promise<bool>)
const at Thread.cpp:140:18
frame #11: 0x0000000100aad9eb kodi.bin`decltype(__f=0x000000014d19f670,
__args=0x000000014d19f678,
__args=0x000000014d19f680)::$_0>(fp)(std::__1::forward<CThread*>(fp0),
std::__1::forward<std::__1::promise<bool> >(fp0)))
std::__1::__invoke<CThread::Create(bool)::$_0, CThread*,
std::__1::promise<bool> >(CThread::Create(bool)::$_0&&, CThread*&&,
std::__1::promise<bool>&&) at type_traits:4339:1
frame #12: 0x0000000100aad917 kodi.bin`void
std::__1::__thread_execute<std::__1::unique_ptr<std::__1::__thread_struct,
std::__1::default_delete<std::__1::__thread_struct> >,
CThread::Create(bool)::$_0, CThread*, std::__1::promise<bool>, 2ul,
3ul>(__t=size=4, (null)=__tuple_indices<2, 3> @ 0x000070000b522eb8)::$_0,
CThread*, std::__1::promise<bool> >&, std::__1::__tuple_indices<2ul, 3ul>)
at thread:342:5
frame #13: 0x0000000100aad026 kodi.bin`void*
std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct,
std::__1::default_delete<std::__1::__thread_struct> >,
CThread::Create(bool)::$_0, CThread*, std::__1::promise<bool> >
>(__vp=0x000000014d19f670) at thread:352:5
frame #14: 0x00007fff68c1c2eb libsystem_pthread.dylib`_pthread_body +
126
frame #15: 0x00007fff68c1f249 libsystem_pthread.dylib`_pthread_start +
66
frame #16: 0x00007fff68c1b40d libsystem_pthread.dylib`thread_start + 13
On Thu, 29 Aug 2019 at 00:20, Jun Li <junli1026@gmail.com> wrote:
> On Wed, Aug 28, 2019 at 3:09 PM Carl Eugen Hoyos <ceffmpeg@gmail.com>
> wrote:
>
> > Am Mo., 5. Aug. 2019 um 09:19 Uhr schrieb Ross Nicholson <
> > phunkyfish@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-request@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-request@ffmpeg.org with subject "unsubscribe".
Hey All, Anything needed from me to progress this? Thanks in advance, Ross > On 29 Aug 2019, at 17:04, Ross Nicholson <phunkyfish@gmail.com> 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: 0x00000001037af09e kodi.bin`ffurl_write(h=0x0000000000000000, 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: 0x00000001037af09e kodi.bin`ffurl_write(h=0x0000000000000000, 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: 0x00000001038c3be9 kodi.bin`rtsp_send_cmd_with_content_async(s=0x000000011989c000, method=<unavailable>, url=<unavailable>, headers=<unavailable>, send_content=0x0000000000000000, send_content_length=0) at rtsp.c:1352:5 [opt] > frame #2: 0x00000001038c928c kodi.bin`rtsp_read_close(s=0x000000011989c000) at rtspdec.c:61:9 [opt] > frame #3: 0x00000001038f9994 kodi.bin`avformat_close_input(ps=0x000000014dbb8000) at utils.c:4450:13 [opt] > frame #4: 0x00000001004c7841 kodi.bin`CDVDDemuxFFmpeg::Open(this=0x000000014dbb7ff0, pInput=std::__1::shared_ptr<CDVDInputStream>::element_type @ 0x000000014dbb7d10 strong=4 weak=1, streaminfo=true, fileinfo=false) at DVDDemuxFFmpeg.cpp:278:7 > frame #5: 0x00000001004eb802 kodi.bin`CDVDFactoryDemuxer::CreateDemuxer(pInputStream=std::__1::shared_ptr<CDVDInputStream>::element_type @ 0x000000014dbb7d10 strong=4 weak=1, fileinfo=false) at DVDFactoryDemuxer.cpp:88:15 > frame #6: 0x0000000100575ff3 kodi.bin`CVideoPlayer::OpenDemuxStream(this=0x000000011d90d800) at VideoPlayer.cpp:822:18 > frame #7: 0x0000000100579642 kodi.bin`CVideoPlayer::Prepare(this=0x000000011d90d800) at VideoPlayer.cpp:1224:8 > frame #8: 0x000000010057b70f kodi.bin`CVideoPlayer::Process(this=0x000000011d90d800) at VideoPlayer.cpp:1310:3 > frame #9: 0x0000000100aa7a04 kodi.bin`CThread::Action(this=0x000000011d90d800) at Thread.cpp:282:5 > frame #10: 0x0000000100aadc90 kodi.bin`CThread::Create(this=0x000000014d19f670, pThread=0x000000011d90d800, promise=promise<bool> @ 0x000070000b522e70)::$_0::operator()(CThread*, std::__1::promise<bool>) const at Thread.cpp:140:18 > frame #11: 0x0000000100aad9eb kodi.bin`decltype(__f=0x000000014d19f670, __args=0x000000014d19f678, __args=0x000000014d19f680)::$_0>(fp)(std::__1::forward<CThread*>(fp0), std::__1::forward<std::__1::promise<bool> >(fp0))) std::__1::__invoke<CThread::Create(bool)::$_0, CThread*, std::__1::promise<bool> >(CThread::Create(bool)::$_0&&, CThread*&&, std::__1::promise<bool>&&) at type_traits:4339:1 > frame #12: 0x0000000100aad917 kodi.bin`void std::__1::__thread_execute<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, CThread::Create(bool)::$_0, CThread*, std::__1::promise<bool>, 2ul, 3ul>(__t=size=4, (null)=__tuple_indices<2, 3> @ 0x000070000b522eb8)::$_0, CThread*, std::__1::promise<bool> >&, std::__1::__tuple_indices<2ul, 3ul>) at thread:342:5 > frame #13: 0x0000000100aad026 kodi.bin`void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, CThread::Create(bool)::$_0, CThread*, std::__1::promise<bool> > >(__vp=0x000000014d19f670) at thread:352:5 > frame #14: 0x00007fff68c1c2eb libsystem_pthread.dylib`_pthread_body + 126 > frame #15: 0x00007fff68c1f249 libsystem_pthread.dylib`_pthread_start + 66 > frame #16: 0x00007fff68c1b40d libsystem_pthread.dylib`thread_start + 13 > > >> On Thu, 29 Aug 2019 at 00:20, Jun Li <junli1026@gmail.com> wrote: >> On Wed, Aug 28, 2019 at 3:09 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >> >> > Am Mo., 5. Aug. 2019 um 09:19 Uhr schrieb Ross Nicholson < >> > phunkyfish@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-request@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-request@ffmpeg.org with subject "unsubscribe".
Ping, any update? On Thu, 5 Sep 2019 at 06:33, Ross Nicholson <phunkyfish@gmail.com> wrote: > Hey All, > > Anything needed from me to progress this? > > Thanks in advance, > > Ross > > On 29 Aug 2019, at 17:04, Ross Nicholson <phunkyfish@gmail.com> 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: 0x00000001037af09e > kodi.bin`ffurl_write(h=0x0000000000000000, 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: 0x00000001037af09e > kodi.bin`ffurl_write(h=0x0000000000000000, 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: 0x00000001038c3be9 > kodi.bin`rtsp_send_cmd_with_content_async(s=0x000000011989c000, > method=<unavailable>, url=<unavailable>, headers=<unavailable>, > send_content=0x0000000000000000, send_content_length=0) at rtsp.c:1352:5 > [opt] > > frame #2: 0x00000001038c928c > kodi.bin`rtsp_read_close(s=0x000000011989c000) at rtspdec.c:61:9 [opt] > > frame #3: 0x00000001038f9994 > kodi.bin`avformat_close_input(ps=0x000000014dbb8000) at utils.c:4450:13 > [opt] > > frame #4: 0x00000001004c7841 > kodi.bin`CDVDDemuxFFmpeg::Open(this=0x000000014dbb7ff0, > pInput=std::__1::shared_ptr<CDVDInputStream>::element_type @ > 0x000000014dbb7d10 strong=4 weak=1, streaminfo=true, fileinfo=false) at > DVDDemuxFFmpeg.cpp:278:7 > > frame #5: 0x00000001004eb802 > kodi.bin`CDVDFactoryDemuxer::CreateDemuxer(pInputStream=std::__1::shared_ptr<CDVDInputStream>::element_type > @ 0x000000014dbb7d10 strong=4 weak=1, fileinfo=false) at > DVDFactoryDemuxer.cpp:88:15 > > frame #6: 0x0000000100575ff3 > kodi.bin`CVideoPlayer::OpenDemuxStream(this=0x000000011d90d800) at > VideoPlayer.cpp:822:18 > > frame #7: 0x0000000100579642 > kodi.bin`CVideoPlayer::Prepare(this=0x000000011d90d800) at > VideoPlayer.cpp:1224:8 > > frame #8: 0x000000010057b70f > kodi.bin`CVideoPlayer::Process(this=0x000000011d90d800) at > VideoPlayer.cpp:1310:3 > > frame #9: 0x0000000100aa7a04 > kodi.bin`CThread::Action(this=0x000000011d90d800) at Thread.cpp:282:5 > > frame #10: 0x0000000100aadc90 > kodi.bin`CThread::Create(this=0x000000014d19f670, > pThread=0x000000011d90d800, promise=promise<bool> @ > 0x000070000b522e70)::$_0::operator()(CThread*, std::__1::promise<bool>) > const at Thread.cpp:140:18 > > frame #11: 0x0000000100aad9eb > kodi.bin`decltype(__f=0x000000014d19f670, __args=0x000000014d19f678, > __args=0x000000014d19f680)::$_0>(fp)(std::__1::forward<CThread*>(fp0), > std::__1::forward<std::__1::promise<bool> >(fp0))) > std::__1::__invoke<CThread::Create(bool)::$_0, CThread*, > std::__1::promise<bool> >(CThread::Create(bool)::$_0&&, CThread*&&, > std::__1::promise<bool>&&) at type_traits:4339:1 > > frame #12: 0x0000000100aad917 kodi.bin`void > std::__1::__thread_execute<std::__1::unique_ptr<std::__1::__thread_struct, > std::__1::default_delete<std::__1::__thread_struct> >, > CThread::Create(bool)::$_0, CThread*, std::__1::promise<bool>, 2ul, > 3ul>(__t=size=4, (null)=__tuple_indices<2, 3> @ 0x000070000b522eb8)::$_0, > CThread*, std::__1::promise<bool> >&, std::__1::__tuple_indices<2ul, 3ul>) > at thread:342:5 > > frame #13: 0x0000000100aad026 kodi.bin`void* > std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, > std::__1::default_delete<std::__1::__thread_struct> >, > CThread::Create(bool)::$_0, CThread*, std::__1::promise<bool> > > >(__vp=0x000000014d19f670) at thread:352:5 > > frame #14: 0x00007fff68c1c2eb libsystem_pthread.dylib`_pthread_body + > 126 > > frame #15: 0x00007fff68c1f249 libsystem_pthread.dylib`_pthread_start > + 66 > > frame #16: 0x00007fff68c1b40d libsystem_pthread.dylib`thread_start + > 13 > > > > On Thu, 29 Aug 2019 at 00:20, Jun Li <junli1026@gmail.com> wrote: > >> On Wed, Aug 28, 2019 at 3:09 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> >> wrote: >> >> > Am Mo., 5. Aug. 2019 um 09:19 Uhr schrieb Ross Nicholson < >> > phunkyfish@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-request@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-request@ffmpeg.org with subject "unsubscribe". > >
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 <phunkyfish@gmail.com> wrote: > Ping, any update? > > On Thu, 5 Sep 2019 at 06:33, Ross Nicholson <phunkyfish@gmail.com> wrote: > >> Hey All, >> >> Anything needed from me to progress this? >> >> Thanks in advance, >> >> Ross >> >> On 29 Aug 2019, at 17:04, Ross Nicholson <phunkyfish@gmail.com> 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: 0x00000001037af09e >> kodi.bin`ffurl_write(h=0x0000000000000000, 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: 0x00000001037af09e >> kodi.bin`ffurl_write(h=0x0000000000000000, 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: 0x00000001038c3be9 >> kodi.bin`rtsp_send_cmd_with_content_async(s=0x000000011989c000, >> method=<unavailable>, url=<unavailable>, headers=<unavailable>, >> send_content=0x0000000000000000, send_content_length=0) at rtsp.c:1352:5 >> [opt] >> >> frame #2: 0x00000001038c928c >> kodi.bin`rtsp_read_close(s=0x000000011989c000) at rtspdec.c:61:9 [opt] >> >> frame #3: 0x00000001038f9994 >> kodi.bin`avformat_close_input(ps=0x000000014dbb8000) at utils.c:4450:13 >> [opt] >> >> frame #4: 0x00000001004c7841 >> kodi.bin`CDVDDemuxFFmpeg::Open(this=0x000000014dbb7ff0, >> pInput=std::__1::shared_ptr<CDVDInputStream>::element_type @ >> 0x000000014dbb7d10 strong=4 weak=1, streaminfo=true, fileinfo=false) at >> DVDDemuxFFmpeg.cpp:278:7 >> >> frame #5: 0x00000001004eb802 >> kodi.bin`CDVDFactoryDemuxer::CreateDemuxer(pInputStream=std::__1::shared_ptr<CDVDInputStream>::element_type >> @ 0x000000014dbb7d10 strong=4 weak=1, fileinfo=false) at >> DVDFactoryDemuxer.cpp:88:15 >> >> frame #6: 0x0000000100575ff3 >> kodi.bin`CVideoPlayer::OpenDemuxStream(this=0x000000011d90d800) at >> VideoPlayer.cpp:822:18 >> >> frame #7: 0x0000000100579642 >> kodi.bin`CVideoPlayer::Prepare(this=0x000000011d90d800) at >> VideoPlayer.cpp:1224:8 >> >> frame #8: 0x000000010057b70f >> kodi.bin`CVideoPlayer::Process(this=0x000000011d90d800) at >> VideoPlayer.cpp:1310:3 >> >> frame #9: 0x0000000100aa7a04 >> kodi.bin`CThread::Action(this=0x000000011d90d800) at Thread.cpp:282:5 >> >> frame #10: 0x0000000100aadc90 >> kodi.bin`CThread::Create(this=0x000000014d19f670, >> pThread=0x000000011d90d800, promise=promise<bool> @ >> 0x000070000b522e70)::$_0::operator()(CThread*, std::__1::promise<bool>) >> const at Thread.cpp:140:18 >> >> frame #11: 0x0000000100aad9eb >> kodi.bin`decltype(__f=0x000000014d19f670, __args=0x000000014d19f678, >> __args=0x000000014d19f680)::$_0>(fp)(std::__1::forward<CThread*>(fp0), >> std::__1::forward<std::__1::promise<bool> >(fp0))) >> std::__1::__invoke<CThread::Create(bool)::$_0, CThread*, >> std::__1::promise<bool> >(CThread::Create(bool)::$_0&&, CThread*&&, >> std::__1::promise<bool>&&) at type_traits:4339:1 >> >> frame #12: 0x0000000100aad917 kodi.bin`void >> std::__1::__thread_execute<std::__1::unique_ptr<std::__1::__thread_struct, >> std::__1::default_delete<std::__1::__thread_struct> >, >> CThread::Create(bool)::$_0, CThread*, std::__1::promise<bool>, 2ul, >> 3ul>(__t=size=4, (null)=__tuple_indices<2, 3> @ 0x000070000b522eb8)::$_0, >> CThread*, std::__1::promise<bool> >&, std::__1::__tuple_indices<2ul, 3ul>) >> at thread:342:5 >> >> frame #13: 0x0000000100aad026 kodi.bin`void* >> std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, >> std::__1::default_delete<std::__1::__thread_struct> >, >> CThread::Create(bool)::$_0, CThread*, std::__1::promise<bool> > >> >(__vp=0x000000014d19f670) at thread:352:5 >> >> frame #14: 0x00007fff68c1c2eb libsystem_pthread.dylib`_pthread_body >> + 126 >> >> frame #15: 0x00007fff68c1f249 libsystem_pthread.dylib`_pthread_start >> + 66 >> >> frame #16: 0x00007fff68c1b40d libsystem_pthread.dylib`thread_start + >> 13 >> >> >> >> On Thu, 29 Aug 2019 at 00:20, Jun Li <junli1026@gmail.com> wrote: >> >>> On Wed, Aug 28, 2019 at 3:09 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> >>> wrote: >>> >>> > Am Mo., 5. Aug. 2019 um 09:19 Uhr schrieb Ross Nicholson < >>> > phunkyfish@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-request@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-request@ffmpeg.org with subject "unsubscribe". >> >>
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);
From: phunkyfish <phunkyfish@gmail.com> --- libavformat/rtspdec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)