Stuttering on Live-TV - since 1.2 (1 Viewer)

Owlsroost

Retired Team Member
  • Premium Supporter
  • October 28, 2008
    5,540
    5,038
    Cambridge
    Home Country
    United Kingdom United Kingdom
    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

    Retired Team Member
  • Premium Supporter
  • October 28, 2008
    5,540
    5,038
    Cambridge
    Home Country
    United Kingdom United Kingdom

    technick

    Portal Pro
    May 6, 2009
    566
    155
    Home Country
    France France
    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

    Portal Pro
    April 14, 2005
    574
    66
    Denmark
    Home Country
    Denmark Denmark
    @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
     

    glenn 1990

    Portal Pro
    July 1, 2010
    247
    36
    Home Country
    Belgium Belgium
    @ 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?

    Code:
    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

    Retired Team Member
  • Premium Supporter
  • October 28, 2008
    5,540
    5,038
    Cambridge
    Home Country
    United Kingdom United Kingdom
    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

    Retired Team Member
  • Premium Supporter
  • October 28, 2008
    5,540
    5,038
    Cambridge
    Home Country
    United Kingdom United Kingdom
    @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 :D

    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
     

    Users who are viewing this thread

    Top Bottom