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
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
Attachments
Last edited by a moderator: