Need serious help with codecs (completely confused) (1 Viewer)

[velis]

While at the same time, full HD MKVs decode fine? I think not!
Besides, the CPU is underclocked and quite cool. I have no overheating problems whatsoever.

This is definitely problem with TVServer which loses packets. Why it does that I don't know yet.

 

[tourettes]

This is definitely problem with TVServer which loses packets. Why it does that I don't know yet.

In that case please upload the TsReader.log. It will show if the TV server side has been dropping packets.

 

[tourettes]

I cant make ffdshow work. Tried just about any setting. In the end it just gets pulled into the graph, but no pins connected. Instead either Cyberlink or Avivo decoder is used.

For live tv ffdshow is not allowed for MPEG2 content (is blacklisted) as changing between SD / HD channels cause issues.

 

[velis]

tourettes: yes, it does show dropped packets. Will upload in the evening when I get home.
Entries are very similar to what I posted in https://forum.team-mediaportal.com/...-454/cpu-intensive-teletext-73896/#post539857 (logs attached there). Only in that particular case there are more discontinuities because I've also purposely created situations where discontinuities would occur through TTX.

 

[velis]

Here's the log.

 

[velis]

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