[FFmpeg-devel] [PATCH] libavformat/rtspdec: Don't send teardown if rtsp_hd_out is null

Ross Nicholson phunkyfish at gmail.com
Thu Sep 5 08:33:07 EEST 2019 

Hey All,

Anything needed from me to progress this?

Thanks in advance,

Ross

> On 29 Aug 2019, at 17:04, Ross Nicholson <phunkyfish at 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 at gmail.com> wrote:
>> On Wed, Aug 28, 2019 at 3:09 PM Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>> 
>> > Am Mo., 5. Aug. 2019 um 09:19 Uhr schrieb Ross Nicholson <
>> > phunkyfish at 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 at ffmpeg.org
>> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> >
>> > To unsubscribe, visit link above, or email
>> > ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel at ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> 
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".

More information about the ffmpeg-devel mailing list