Experimental TsReader development (3 Viewers)

[HomeY]

Tony,

Sebastiii compiled this latest version for me since i also was having issue while seeking in recordings.

If tested this version and noticed the following:

After an inconsistent number of skipsteps (happens after 2 but sometimes it takes 6 or 7 steps) the playback is stopped, resulting in an error:

2012-02-27 17:51:07.218944 [ERROR][MPMain(1)]: TSReaderPlayer: No sound driver is available!

Attached error & TsReader log, hope they're of some use to you.

I'm getting the best results so far with: TsReader_0_4_17_black_screen_and RTSP_fixes1

I must add that my build is kinda 'tricky' (v1.2.2 Final TVE + v1.2.2 GIT MP + 4TR v1.6.0.2), so i hope that doesn't influence the testing too much...

Cheers,

Jeroen

 

[Owlsroost]

Tony,

Sebastiii compiled this latest version for me since i also was having issue while seeking in recordings.

If tested this version and noticed the following:

After an inconsistent number of skipsteps (happens after 2 but sometimes it takes 6 or 7 steps) the playback is stopped, resulting in an error:

2012-02-27 17:51:07.218944 [ERROR][MPMain(1)]: TSReaderPlayer: No sound driver is available!

Attached error & TsReader log, hope they're of some use to you.

I'm getting the best results so far with: TsReader_0_4_17_black_screen_and RTSP_fixes1

I must add that my build is kinda 'tricky' (v1.2.2 Final TVE + v1.2.2 GIT MP + 4TR v1.6.0.2), so i hope that doesn't influence the testing too much...

Cheers,

Jeroen

Thanks for the feedback

The 'TSReaderPlayer: No sound driver is available!' message is a side-effect - it's the only way I've found of aborting playback when it hangs (TsReader.ax sends an 'EC_ERRORABORT' message to the graph manager when it detects a video decoder hang, which MP responds to by stopping playback - otherwise it would hang forever or crash to desktop ).

Testing with a debug version of LAV video decoder hasn't shown up any problems, so it must be something else....

Tony

 

[tourettes]

Testing with a debug version of LAV video decoder hasn't shown up any problems, so it must be something else....

As it is mainly seeking plus debug / release related issue I'm pretty sure that it is some timing or threading issue on TsReader side. Did you check if the ffmpeg based decoder reports any errors? It might / will report even thou it wouldn't freeze or crash. Hopefully it will give some clues what could be wrong. If it wont then it will be a really rocky ride as debugging the binary stream (H264/MPEG2) that TsReader is sending downstream is pretty much an impossile task.

 

[Owlsroost]

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.

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

I've only ever seen the issue when seeking (never at start of play or while playing).

Tony

 

[tourettes]

NewSegment - -735892918

Isn't that negative position a bit odd looking? also check if there are any threads waiting somehting to happen.

 

[tourettes]

Isn't that negative position a bit odd looking? also check if there are any threads waiting somehting to happen.

[22:20]
<nevcairiel> my fault, used wrong formatting params in the debug message

So it is probably some thread that is just sitting and waiting some other thread to release some lock or event.

 

[tourettes]

<+nevcairiel> also, in LAVVideo.h set DEBUG_FRAME_TIMINGS to 1
<+nevcairiel> will tell you waht timestamps it outputs for the video frames
<+nevcairiel> after a seek it should always start around 0
<+nevcairiel> otherwise the source is sending odd times
<+nevcairiel> I would check the frame timings, it would easily appear as a hang when the renderer just doesnt render the frames yet because the time is way into the future

 

[disaster123]

disaster123 - can you try building the version I've just committed please ?

Tony

OK this build works now fine again with MS DTV like v45. Still not working with LAV while seeking (but you know that already). So you can revert 141d8fd3358b8ac4d24cdb5c2275df361d6506ba again as it wasn't the showstopper?.

 

[Owlsroost]

<+nevcairiel> also, in LAVVideo.h set DEBUG_FRAME_TIMINGS to 1
<+nevcairiel> will tell you waht timestamps it outputs for the video frames
<+nevcairiel> after a seek it should always start around 0
<+nevcairiel> otherwise the source is sending odd times
<+nevcairiel> I would check the frame timings, it would easily appear as a hang when the renderer just doesnt render the frames yet because the time is way into the future

Thanks for the thoughts.

I'd thought about the 'way into the future' problem' before, but the timestamps and NewSegment start times all look OK (and match between the TsReader and LAV debug logs). MP pauses the graph when seeks, so the timestamps don't start at zero afterwards (they would if it stopped the graph).

I suspect a thread locking problem too....time for some more debug logging

Tony

 

[olavm]

LAV 0.46 is out with a new version of the Quicksync-decoder. And for some reason it now works in both mpeg2 and h264 using TsReader_nostop44 on my end.

Strange but positive

Seems like this was a bit premature. Sorry about that. I found it strange that my cpu fan was running at a noisy level when watching TV. Found out that the latest versions of LAV falls back to software mode instead of crashing when decoding h264 with the quicksync decoder on the tswriter45.ax (and probably the same with earlier versions). I double checked by installing the ffdshow build with the quicksync decoder and using the OSD it said libavcodec when decoding h264 and quicksync when decoding mpeg2. A x264 mkv file using ffdshow shows quicksync decoder in the OSD.

So, there is still an issue using the quicksync decoder in either ffdshow or lav with h264 tv. Also tested a recording with the same result.