Stuttering on Live-TV - since 1.2 (5 Viewers)

[Owlsroost]

It's basically comparing the timestamps of the incoming PES packets with the presentation clock. It's always the audio side that triggers the pause, because the video timestamps are always further into the future than the audio (due to the way the stream is muxed).

If you look at glenn 1990's log, you can see the slow drift (downwards) in the amount of buffered data - the 'Demux : Audio to render ' times - until it triggers the pause.

Tony

 

[Owlsroost]

I am, right after upgrading to 1.2.0 and even 1.2.1 the stutters occur every couple of minutes on hd channels only.

Logs please ?

Tony

 

[Owlsroost]

EDIT: Found some older thread with the same issue https://forum.team-mediaportal.com/mediaportal-1-1-0-rc-3-6-519/continous-glitches-livetv-both-sd-hd-83762/index6.html

And they say that it's introduced after tsreader 25138, so after the pause 200ms stuff.

Yes, arion_p does a good explanation of the basic buffer underrun problem and the fix (which I agree with).

Tony

 

[technick]

Owlsroost

For your information, I make tests again this weekend.

1 - I found this error in the event viewer, it seem that MP make too many I/O for a standard Windows 7 64 install :

Event ID: 2017
Task Category: None
Level: Error
Computer: HTPC
Description:
The server was unable to allocate from the system nonpaged pool because the server reached the configured limit for nonpaged pool allocations.

And found the solution here :
Event Id 2017 The server was unable to allocate from the system nonpaged pool because the server reached the configured limit for nonpaged pool allocations.

Result : MP is now very fast, so fast that I made the same modification on my dev computer Zapping is like all others things faster and globally everything work better now.

2 - I found also this :
Windows Experts Community
I Try, it change nothing but the test is interesting.

3 - With the TsReader_300msAudio_patched_2 version I have good result but less that I have on my sony TV, specially on TNT HD channel, the strange thing is that the same channel on IP is better :-/ There is perhaps something in the TNT stream itself that disturb ? We need perhaps add filters in the stream itself ?

4 - I can eliminate 98% of problems if I use SAF audio decoder and "Directsound: NVIDIA HDMI out NVIDIA high definition audio" and not the "default direct sound device" as sound output. The strange thing is that the HDMI audio is the default output in the windows sound config !

5 - only on TNT HD channels the dshowhelper v92a no DWM work better that the 92 DWM, there is something that I don't understand...

6 - The video files I have (HD MKV) are perfect with ffdshow everywhere in the config so there is 4 parameters in the tests we can make (after made a correct windows setup) :

-Video or TV
-( if TV) tsreader version
-( if TV) TNT or IP TV
-(both ) Dshowhelper version

If it can help you,

Technick

 

[mylle]

@Owlsroost

For your information, I make tests again this weekend.

1 - I found this error in the event viewer, it seem that MP make too many I/O for a standard Windows 7 64 install :

Event ID: 2017
Task Category: None
Level: Error
Computer: HTPC
Description:
The server was unable to allocate from the system nonpaged pool because the server reached the configured limit for nonpaged pool allocations.

And found the solution here :
Event Id 2017 The server was unable to allocate from the system nonpaged pool because the server reached the configured limit for nonpaged pool allocations.

Result : MP is now very fast, so fast that I made the same modification on my dev computer Zapping is like all others things faster and globally everything work better now.

2 - I found also this :
Windows Experts Community
I Try, it change nothing but the test is interesting.

3 - With the TsReader_300msAudio_patched_2 version I have good result but less that I have on my sony TV, specially on TNT HD channel, the strange thing is that the same channel on IP is better :-/ There is perhaps something in the TNT stream itself that disturb ? We need perhaps add filters in the stream itself ?

4 - I can eliminate 98% of problems if I use SAF audio decoder and "Directsound: NVIDIA HDMI out NVIDIA high definition audio" and not the "default direct sound device" as sound output. The strange thing is that the HDMI audio is the default output in the windows sound config !

5 - only on TNT HD channels the dshowhelper v92a no DWM work better that the 92 DWM, there is something that I don't understand...

6 - The video files I have (HD MKV) are perfect with ffdshow everywhere in the config so there is 4 parameters in the tests we can make (after made a correct windows setup) :

-Video or TV
-( if TV) tsreader version
-( if TV) TNT or IP TV
-(both ) Dshowhelper version

If it can help you,

Technick

Is this on single seat or tv-server with seperate clients? Do you change the setting on both server and client?

/Mylle

 

[technick]

single seat

 

[tourettes]

2 - I found also this :
Windows Experts Community
I Try, it change nothing but the test is interesting.

It shouldn't have anything to do with the issue you are seeing - results are probably placebo. http://www.decuslib.com/decus/vmslt99a/nt/tips.txt

All it changes is the Windows files haring behavior. Nothing related to single seat or tv service.

 

[glenn 1990]

@ Tony

Does this log mean that my audio clock drifts almost 200ms in less than 2 minutes?
Also what does the audio/video to render messages exactly mean?

22-10-2011 20:41:26.142 [1954]Demux : Audio to render 0.248 Sec
22-10-2011 20:41:27.449 [19e4]Demux : Audio to render 0.244 Sec
22-10-2011 20:41:28.448 [1954]Demux : Audio to render 0.242 Sec
22-10-2011 20:41:30.319 [1954]Demux : Audio to render 0.241 Sec
22-10-2011 20:41:34.856 [1954]Demux : Video to render 0.514 Sec
22-10-2011 20:41:35.582 [1954]Demux : Video to render 0.513 Sec
22-10-2011 20:41:35.831 [19e4]Demux : Video to render 0.493 Sec
22-10-2011 20:41:35.877 [1954]Demux : Video to render 0.492 Sec
22-10-2011 20:41:44.448 [1954]Demux : Audio to render 0.239 Sec
22-10-2011 20:41:44.740 [19e4]Demux : Audio to render 0.230 Sec
22-10-2011 20:41:45.039 [19e4]Demux : Audio to render 0.218 Sec
22-10-2011 20:41:47.928 [19e4]Demux : Audio to render 0.210 Sec
22-10-2011 20:41:49.370 [1954]Demux : Audio to render 0.206 Sec
22-10-2011 20:41:58.915 [1954]Demux : Video to render 0.479 Sec
22-10-2011 20:42:02.908 [19e4]Demux : Audio to render 0.202 Sec
22-10-2011 20:42:09.832 [1954]Demux : Audio to render 0.196 Sec
22-10-2011 20:42:11.015 [19e4]Demux : Audio to render 0.168 Sec
22-10-2011 20:42:14.047 [19e4]Demux : Audio to render 0.142 Sec
22-10-2011 20:42:14.235 [19e4]Demux : Audio to render 0.107 Sec
22-10-2011 20:42:14.957 [1954]Demux : Audio to render 0.101 Sec
22-10-2011 20:42:15.276 [19e4]Demux : Audio to render 0.085 Sec
22-10-2011 20:42:15.276 [19e4]Demux : Audio to render too late= 0.085 Sec, rendering will be paused for a while
22-10-2011 20:42:15.290 [1f38]Pause 200mS renderer clock to match provider/RTSP clock...

 

[Owlsroost]

The 'Audio to render' value is basically a measure of how much audio data is buffered in the filter graph from TsReader to the renderer.

Yes, if you play live Tv for a while and count up the '200ms' messages:

(message count x 0.2 sec)/play time in sec = clock error

Tony

 

[Owlsroost]

@Tony
I have not had any severe problems on my clients using default tsreader, but I have an old machine running since my first days with mp

This PC have stopped running (live tv) randomly and I have seen high cpu on svchost network service when it happens. I always thought it had something to do with the NIC... I have then been trying different tsreaders and since I have started to use tsReader300ms2 I have not had any hick-ups (running 24-7)!!
Does this make any sense or is there something else do you think?

Thanks for your fantastic work here!
/tompa

edit: using UNC path

I think it makes sense (for UNC paths) - because if the way timeshifting works, TsReader is usually reading very close to the end of the file - this makes it difficult for Windows to read ahead/cache much data, so you probably get a lot more network i/o activity than with a 'normal' file read situation. The modified TsReader buffers a bit more data at the start.

RTSP is different - the server pushes the data to the client, so the buffering and end-of-file handling is 'local' at the client i.e. it's designed for this sort of media streaming situation, but normal remote file sharing isn't really.

Tony