IPTV/DVB-IP in MP: Support for http, rtp and udp (2 Viewers)

[georgius]

I've added baseclasses for those whos don't want to install SDK. I don't know nothing about kartina, but it was in Stepko's source code, so I decided to leave it (however it's not referenced).

IPTV_SOCKET_BUFFER_SIZE is big, but then you don't have to go through grabber too often. When I make some tests with lower values, then values lower as 16 KB were unusable. My provider sends data at approx. 250 KB/s. It means that 8 KB buffer is filled in 32 ms. I think that bigger buffer can be balanced with stuttering free

 

[velis]

IPTV_SOCKET_BUFFER_SIZE is big, but then you don't have to go through grabber too often. When I make some tests with lower values, then values lower as 16 KB were unusable. My provider sends data at approx. 250 KB/s. It means that 8 KB buffer is filled in 32 ms. I think that bigger buffer can be balanced with stuttering free

Precisely. The funny thing I found was that even if I had buffer set to 1MB, I would never get more than 1360 bytes from it. So if I am not reading fast enough, I'll miss the packet.
If what you say is correct, that means there's no need for grabber thread. Just set a timer to read once in 30 ms and then read the entire 250 KB, passing it directly to DirectShow chain.
No stutter, no lost packets, no fuss...

Though I must say current code of your version does support this. Otherwise sleep(10) when no data had been read would lose huge packet numbers. But then again, such was the original code (it had sleep(1)) and it lost packets like crazy

Edit: BTW: after 2 hrs, no stuttering. So your filter looks really good so far

 

[georgius]

It works little bit different (as I know). IPTV_SOCKET_BUFFER_SIZE specifies size of buffer for socket (in other words, Windows create its internal buffer of this size and attach it to socket, you don't have access to this buffer). In this buffer are written packets received from network. When you call recvfrom() it returns only first packet received (not all packets received) and memory in buffer is marked as free. With non-blocking sockets you have to call recvfrom() until it doesn't return SOCKET_ERROR and then you have to check if WSAGetLastError() is WSAEWOULDBLOCK, which means that are no data. With blocking sockets you just call recvfrom(). It doesn't return while no data received - this approach makes another problem with unresponsible thread because is blocked with recvfrom(). If you look in my code you'll see that I call Sleep(10) only when no data received or there is not space in my buffer.

 

[velis]

?!?!!?
Taking what you said into account I modified my version of the filter.

The result of very short testing is that the filter is taking consistently 1.5% CPU (one core - therefore <1%), drops nothing and in fact works like a charm.

Attaching source + .ax
Unfortunately I won't be home for the rest of this weekend so while I'd appreciate any feedback, I won't be able to respond before tomorrow evening.

As always, this version of the filter works with UDP only.

 

[Stepko]

AW: Re: IPTV/DVB-IP in MP: Support for http, rtp and udp

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 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 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.


Stepko

 

[georgius]

Re: AW: Re: IPTV/DVB-IP in MP: Support for http, rtp and udp

This week I migrated from my development PC to "production" HTPC and there were few problems which I have to solve as first. I'll try velis and your version ASAP, but I think that blocking mode isn't good. It's because thread can be locked in recv() if no data - the filter can't be removed and TvService can't be stopped.

 

[velis]

Re: AW: Re: IPTV/DVB-IP in MP: Support for http, rtp and udp

This week I migrated from my development PC to "production" HTPC and there were few problems which I have to solve as first. I'll try velis and your version ASAP, but I think that blocking mode isn't good. It's because thread can be locked in recv() if no data - the filter can't be removed and TvService can't be stopped.

Second that for blocking / nonblocking.
And I am happy to report the latest filter version is looking good. Everything is as reported yesterday, but I still think this needs more testing before I can definitely confirm filter working. Seems like "magic" will really be magic

I think I will now attempt to support RTP and HTTP. I think the code will be cleaner than previous versions because I only need to write a new grabber thread. This should be easier to maintain and also probably much easier to convince Mikeyko to include in SVN

 

[georgius]

I made some tests and I must say that biggest progress made velis. His filter is working at lowest CPU usage - I don't test it for long time so I can't say nothing about stability.

Here are results:

• georgius
  • SD channel 2 - 4%
  • HD channel 4 - 6%
• velis
  • SD channel 1 - 2%
  • HD channel 1 - 2%
• Stepko
  • SD channel 10 - 14%
  • HD channel 10 - 15% and stuttering (my opinion is that you have too small size of media sample)

Also adding my new version of filter, there is only modified logging. On this filter I'm doing long time tests and stress tests. After few hours of using on my HTPC it seems to be working without any problems.

From my results it seems that velis version is better than mine (at least on UDP protocol). It will be great if anybody other tests velis version on UDP protocol. If velis solution will be stable, I think that his solution should be added to SVN as new IPTV filter for MP.

 

[velis]

Thanks Georgius.
I think I can now say that my filter is 100% stable. It will NOT drop any packets. Ever!
In fact I'm sure of it, because my filter now has Sleep() in it and it still works I have no idea what I was doing previously with those buffers.
Thanks for the tips, Georgius!

I'm currently writing a HTTP class (sorry Stepko) because it's much easier than RTP. Georgius or Stepko, I'd very much appreciate it if one of you could take on RTP.
I have made it so that this is very easy. See the attached grabber_udp.h / cpp. The entire connection code is in .run() method, but can be split if so desired. It should be very easy to implement. But in order for it to work (low CPU, no dropping), methodology from udp grabber should be used (same socket parameters, same way of grabbing, etc.). AFAIK the RTP code should be just the same as udp, except for parsing the packet header and ordering packets according to data therein. It's just that current implementation is somewhat hard to understand. My suggestion is that existing UDP code is duplicated and then only the "smart" part (parsing headers / reordering) is added on top of it. Perhaps the better solution is to add virtual functions to udp grabber (which don't do anyting in UDP), and implement the functions for RTP class... Still, for the best results, this code should be run from mm thread, not grabber thread...

Edit: The functionality differences between my and Georgius' version:
Georgius's version knows how to reconnect, mine doesn't
I think this is about it.
The above functionality can easily be added to my version as well. In fact I plan to do this when all three protocols are implemented. At that point I will also add "no signal" processing (spoofing a custom video)

 

[felix_clerc]

Hello,

I installed the "magic" version yesterday and am very happy with it.
I got less "blocky" images (still some, but probably not due to the filter, but my ISP), and switching from one channel to another seems faster.
I noticed that the "record" button on the manual control page is grayed - the "test timeshift" is working. I don't remember if this button was laready grayed out with the normal filter - might have a look at this.
I haven't tried recording yet, but I'll post some feedback once tested.

I think this should be included in SVN - stepko's implementation already helped, but this version seems better.
Thanks for the hard work!

Cheers,
Felix