Reply to thread

Message

<blockquote data-quote="Stepko" data-source="post: 729069" data-attributes="member: 57342">AW: Re: IPTV/DVB-IP in MP: Support for http, rtp and udpHi georgius and velis,after reading tourettes post and some further reading in msdn I got an idea for a new approach of the filter. All the time I thought that &quot;FillBuffer&quot; is called periodically in the default implementation. But in reality it is called immediately after an IMediaSample is available, and that happens in almost zero time. So when the&nbsp; execution of &quot;FillBiffer&quot; is finished it gets called again immediately.The only thing the filter has to wait for is the network traffic. Keeping that in mind I wrote a version that is as simple as possible: No extra thread, no extra buffer, no sleep(..), the fill loop for udp is only 6 lines long.The winsock is set to blocking mode. recv blocks until data is available. Once a packet is received the data is copied directly into IMediaSample and the IMediaSample is sent down the graph immediately.For rtp all data validation and memmoves are also done directly on the IMediaSample.I just did a quick stress test: Recorded one channel and watched another at the same time. During 2 hours there was only one error in the stream, and that looked like a &quot;real&quot;&nbsp; transmission error. Because my provider uses rtp I could use the rtp sequence numbers to analyze the stream.It would be very good if you could give this version a try, especially on a hd channel (unfortunately I don't have hd). This version works with udp and rtp.<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin&nbsp; &nbsp; :D" loading="lazy" data-shortname=":D" />Stepko</blockquote>

[QUOTE="Stepko, post: 729069, member: 57342"] [b]AW: Re: IPTV/DVB-IP in MP: Support for http, rtp and udp[/b] Hi georgius and velis, after reading tourettes post and some further reading in msdn I got an idea for a new approach of the filter. All the time I thought that "FillBuffer" is called [U]periodically [/U]in the default implementation. But in reality it is called [U]immediately [/U]after an IMediaSample is available, and that happens in almost zero time. So when the execution of "FillBiffer" is finished it gets called again immediately. The only thing the filter has to wait for is the network traffic. Keeping that in mind I wrote a version that is as simple as possible: No extra thread, no extra buffer, no sleep(..), the fill loop for udp is only 6 lines long. The winsock is set to blocking mode. recv blocks until data is available. Once a packet is received the data is copied directly into IMediaSample and the IMediaSample is sent down the graph immediately. For rtp all data validation and memmoves are also done directly on the IMediaSample. I just did a quick stress test: Recorded one channel and watched another at the same time. During 2 hours there was only one error in the stream, and that looked like a "real" transmission error. Because my provider uses rtp I could use the rtp sequence numbers to analyze the stream. It would be very good if you could give this version a try, especially on a hd channel (unfortunately I don't have hd). This version works with udp and rtp. :thx: Stepko [/QUOTE]

Verification