home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
Development
Submit: code patches (MediaPortal/TV-Server/etc.)
Slow RTSP startup causes EOF indication
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="dmertz" data-source="post: 744315" data-attributes="member: 110045"><p>Apparently my server can be a bit slow to begin delivering recorded TV via RTSP at times. When this startup delay exceeds 2000 ticks, it causes TsReader's demuxer to declare a premature EOF condition. This causes MP to further misbehave in that MP fails to play the file while continuing to keep the RTSP stream coming, eventually exceeding the maximum allowed amount of buffering. The fix I'm providing here deals with preventing the false EOF at startup, eliminating this particular trigger of the MP hang. This does not include any changes to improve MP's handling of an RTSP EOF at startup; I've only corrected the false EOF.</p><p> </p><p>CDeMultiplexer.ReadFromFile() declares an EOF if the time since the previous RTSP packet arrived (or, in this case, since the initiation of the RTSP stream) exceeds 2000 ticks. Since CDeMultiplexer.Start() is already capable of making repeated calls to ReadFromFile() to establish an initial amount of buffered data, it makes sense that a premature EOF be ignored. The code change I made simply moves one line of code to cause m_bEndOfFile to be reinitialized to false immediatly prior to each call to ReadFromFile() by Start(). If the final call to ReadFromFile() by Start() results in an EOF indication, the EOF indication remains set.</p><p> </p><p>I've also increased the time allowed by Start() to initially fill the buffer from 5000 ticks to 10000 ticks. This increase normally has no effect since the initial fill should complete prior to that anyway, but the higher value provides a bit more margin since the premature EOF issue shows that the beginning of streaming can be delayed by at least 2000 ticks.</p><p> </p><p>I've attached a set of logs made before the code change that show the EOF indication being prematurely set (TsReader log, demux:endoffile) and the subsequent filling of the buffer to maximum because the data is not being consumed. (Ignore the server logs; the client was actually connecting to a server on a different machine.) TsReader logs made after implementing the code change show that recorded-TV playing proceeds normally despite demux:endof file appearing in the log, and the MP hang is avoided.</p><p> </p><p>The .patch file contains changes to DirectShowFilters\TsReader\DeMultiplexer.cpp.</p><p> </p><p>Dave</p></blockquote><p></p>
[QUOTE="dmertz, post: 744315, member: 110045"] Apparently my server can be a bit slow to begin delivering recorded TV via RTSP at times. When this startup delay exceeds 2000 ticks, it causes TsReader's demuxer to declare a premature EOF condition. This causes MP to further misbehave in that MP fails to play the file while continuing to keep the RTSP stream coming, eventually exceeding the maximum allowed amount of buffering. The fix I'm providing here deals with preventing the false EOF at startup, eliminating this particular trigger of the MP hang. This does not include any changes to improve MP's handling of an RTSP EOF at startup; I've only corrected the false EOF. CDeMultiplexer.ReadFromFile() declares an EOF if the time since the previous RTSP packet arrived (or, in this case, since the initiation of the RTSP stream) exceeds 2000 ticks. Since CDeMultiplexer.Start() is already capable of making repeated calls to ReadFromFile() to establish an initial amount of buffered data, it makes sense that a premature EOF be ignored. The code change I made simply moves one line of code to cause m_bEndOfFile to be reinitialized to false immediatly prior to each call to ReadFromFile() by Start(). If the final call to ReadFromFile() by Start() results in an EOF indication, the EOF indication remains set. I've also increased the time allowed by Start() to initially fill the buffer from 5000 ticks to 10000 ticks. This increase normally has no effect since the initial fill should complete prior to that anyway, but the higher value provides a bit more margin since the premature EOF issue shows that the beginning of streaming can be delayed by at least 2000 ticks. I've attached a set of logs made before the code change that show the EOF indication being prematurely set (TsReader log, demux:endoffile) and the subsequent filling of the buffer to maximum because the data is not being consumed. (Ignore the server logs; the client was actually connecting to a server on a different machine.) TsReader logs made after implementing the code change show that recorded-TV playing proceeds normally despite demux:endof file appearing in the log, and the MP hang is avoided. The .patch file contains changes to DirectShowFilters\TsReader\DeMultiplexer.cpp. Dave [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Development
Submit: code patches (MediaPortal/TV-Server/etc.)
Slow RTSP startup causes EOF indication
Contact us
RSS
Top
Bottom