Reply to thread

Message

<blockquote data-quote="Owlsroost" data-source="post: 846993" data-attributes="member: 83973">It was the ffmpeg decoder I was using (can't use CUVID on the dev laptop) - I managed to get that to hang....&nbsp;The LAV debug logging below is the output for the seek operation that ended in a hang - I think it looks as expected - begin/end flush, then NewSegment, then the H264 parser finds an I frame (which is what the first sample is supposed to contain). The other seeks in the log are similar.&nbsp;[CODE]00000402&nbsp; &nbsp; 64.21269226&nbsp; &nbsp; [172] LAVAudio.ax(tid 1884)&nbsp; 1811807 : CLAVAudio::BeginFlush() 00000403&nbsp; &nbsp; 64.21485901&nbsp; &nbsp; [172] LAVVideo.ax(tid 1884)&nbsp; 1811889 : ::BeginFlush 00000404&nbsp; &nbsp; 64.35076904&nbsp; &nbsp; [172] LAVVideo.ax(tid 1884)&nbsp; 1812024 : ::EndFlush 00000405&nbsp; &nbsp; 64.35507965&nbsp; &nbsp; [172] LAVVideo.ax(tid 2038)&nbsp; 1812029 : ::NewSegment - -735892918 / 0 00000406&nbsp; &nbsp; 64.36518860&nbsp; &nbsp; [172] LAVAudio.ax(tid 1884)&nbsp; 1811960 : CLAVAudio::EndFlush() 00000407&nbsp; &nbsp; 64.36824036&nbsp; &nbsp; [172] LAVAudio.ax(tid 231c)&nbsp; 1811963 : CLAVAudio::NewSegment() tStart: 3559074378, tStop: 4611686018427387903, dRate: 1.00 00000408&nbsp; &nbsp; 64.50039673&nbsp; &nbsp; [172] LAVVideo.ax(tid 2038)&nbsp; 1812174 : h264RandomAccess::parseForRecoveryPoint(): Found I frame 00000409&nbsp; &nbsp; 64.50257111&nbsp; &nbsp; [172] LAVVideo.ax(tid 2038)&nbsp; 1812174 : h264RandomAccess::parseForRecoveryPoint(): Found IDR slice 00000410&nbsp; &nbsp; 64.50518036&nbsp; &nbsp; [172] LAVAudio.ax(tid 231c)&nbsp; 1812099 : Resync Request; old: 0; new: 90000; buffer: 0 [/CODE]&nbsp;I've only ever seen the issue when seeking (never at start of play or while playing).&nbsp;Tony</blockquote>

[QUOTE="Owlsroost, post: 846993, member: 83973"] It was the ffmpeg decoder I was using (can't use CUVID on the dev laptop) - I managed to get that to hang.... The LAV debug logging below is the output for the seek operation that ended in a hang - I think it looks as expected - begin/end flush, then NewSegment, then the H264 parser finds an I frame (which is what the first sample is supposed to contain). The other seeks in the log are similar. [CODE] 00000402 64.21269226 [172] LAVAudio.ax(tid 1884) 1811807 : CLAVAudio::BeginFlush() 00000403 64.21485901 [172] LAVVideo.ax(tid 1884) 1811889 : ::BeginFlush 00000404 64.35076904 [172] LAVVideo.ax(tid 1884) 1812024 : ::EndFlush 00000405 64.35507965 [172] LAVVideo.ax(tid 2038) 1812029 : ::NewSegment - -735892918 / 0 00000406 64.36518860 [172] LAVAudio.ax(tid 1884) 1811960 : CLAVAudio::EndFlush() 00000407 64.36824036 [172] LAVAudio.ax(tid 231c) 1811963 : CLAVAudio::NewSegment() tStart: 3559074378, tStop: 4611686018427387903, dRate: 1.00 00000408 64.50039673 [172] LAVVideo.ax(tid 2038) 1812174 : h264RandomAccess::parseForRecoveryPoint(): Found I frame 00000409 64.50257111 [172] LAVVideo.ax(tid 2038) 1812174 : h264RandomAccess::parseForRecoveryPoint(): Found IDR slice 00000410 64.50518036 [172] LAVAudio.ax(tid 231c) 1812099 : Resync Request; old: 0; new: 90000; buffer: 0 [/CODE] I've only ever seen the issue when seeking (never at start of play or while playing). Tony [/QUOTE]

Verification