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
Support
Codecs, External Players
Need serious help with codecs (completely confused)
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="velis" data-source="post: 546798" data-attributes="member: 96429"><p>I have tested with Elecard grabber. That one works fine with no artifacts / dropped packets.</p><p>So the problem seems to lie in the MPIPTVSource. Though I can't figure out why.</p><p></p><p>I've been looking at the source and I don't see any particular faults.</p><p>The filter just reads the socket and passes the data on to renderer (TsWriter? in this case).</p><p></p><p>Initially I thought there may be a problem with read buffer being only 128KB (15ms for 8Mbit stream) (at least 64KB read before passed on), but checking out MSDN documentations doesn't suggest this to be the case as this is only intermediate buffer which is passed on immediately after it reaches 64KB.</p><p>The filter itself should work as intended, even the thread priority is set to higest. But for some reason packets still get dropped.</p><p></p><p>Is it possible that the buffer would be too large? With very low bitrates, such as audio only streams 64KB could mean as much as 10 seconds (64Kbit audio). Maybe TsWriter's demuxer eliminates data that is too "late"? Together with 300ms timeshift buffer set for live TV this should not be an issue.</p><p></p><p>I'll play around with source a bit to see if there's a combination of time + size that lessens the problem.</p><p></p><p>Edit: Oops, found one possible culprit:</p><p>if GetDeliveryBuffer call fails, the loop is repeated and any existing data discarded (m_bufsize = 0 at the beginning of the relevant loop).</p><p>The other possible culprit is fillBuffer implementation. If getDeliveryBuffer returns buffer that is smaller than current m_bufsize, data is again discarded. This is a much more possible cause as getDeliveryBuffer only fails if allocator somehow disappeared.</p><p>Darn, wrong again. getDeliveryBuffer should return 128KB as requested and verified in DecideBufferSize <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite3" alt=":(" title="Frown :(" loading="lazy" data-shortname=":(" /></p></blockquote><p></p>
[QUOTE="velis, post: 546798, member: 96429"] I have tested with Elecard grabber. That one works fine with no artifacts / dropped packets. So the problem seems to lie in the MPIPTVSource. Though I can't figure out why. I've been looking at the source and I don't see any particular faults. The filter just reads the socket and passes the data on to renderer (TsWriter? in this case). Initially I thought there may be a problem with read buffer being only 128KB (15ms for 8Mbit stream) (at least 64KB read before passed on), but checking out MSDN documentations doesn't suggest this to be the case as this is only intermediate buffer which is passed on immediately after it reaches 64KB. The filter itself should work as intended, even the thread priority is set to higest. But for some reason packets still get dropped. Is it possible that the buffer would be too large? With very low bitrates, such as audio only streams 64KB could mean as much as 10 seconds (64Kbit audio). Maybe TsWriter's demuxer eliminates data that is too "late"? Together with 300ms timeshift buffer set for live TV this should not be an issue. I'll play around with source a bit to see if there's a combination of time + size that lessens the problem. Edit: Oops, found one possible culprit: if GetDeliveryBuffer call fails, the loop is repeated and any existing data discarded (m_bufsize = 0 at the beginning of the relevant loop). The other possible culprit is fillBuffer implementation. If getDeliveryBuffer returns buffer that is smaller than current m_bufsize, data is again discarded. This is a much more possible cause as getDeliveryBuffer only fails if allocator somehow disappeared. Darn, wrong again. getDeliveryBuffer should return 128KB as requested and verified in DecideBufferSize :( [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Support
Codecs, External Players
Need serious help with codecs (completely confused)
Contact us
RSS
Top
Bottom