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

[velis]

Man, I really need to set up VPN to home
Yeah, sorry, forgot to attach the .rar.
Will do immediately when I get home (in 7 hours).

Edit: attached

One further observation: This mostly drops in HDTV signals - or better said: when CPU usage is ~100% on all cores. It seems that the grabber thread will normally grab the packets, but the mm thread can't get them because it's blocked by too much CPU usage. Pretty much every stutter is reflected by additional buffer allocation in the grabber thread.
Need to verify what happens if I also set mm thread to time_critical.
Two expected outcomes:
1. mm thread is blocking and grabber thread will not be able to grab packets == stutter
2. TvService will successfully get all its CPU cycles and do its work. Only the client will drop video frames due to inability to render fast enough
Naturally the second outcome is much preferred

Edit2: I don't get it. Playing IPTV with 8Mbit SDTV MPEG2 signal takes <10% of my CPU, but playing a 24Mbit HDTV MPEG2 totally stumps my CPU So for 4x the pixels I get ~10x CPU usage

 

[georgius]

Hi,

when I test my filter I get same results. For SD video I have CPU utilization low (TvService cca 5 - 10%, MP cca 25 %), for HD is much higher (TvService cca same 5 - 15 %, MP 40 - 60 %). I found out that it is caused by codecs ... MP is not using in my case ffdshow DXVA but is using ffdshow normal codec. I suppose that it is caused by TvService, which streams only MPEG2 stream - but I'm not sure, I'll try to investigate it.

I tested today my filter on UDP and in HD video I detect loose of packets. I'll make some changes and post here.

 

[georgius]

Hi,

HTTP code is rewritten and tested as far as I can. Links provided by micmanm are mostly unworking (at least for me) and for working is there loose of packets (I tried also VLC to confirm that I have bug or not - in VLC same result). Instalation procedure is same.

Try and let me know.

 

[georgius]

Hi,

I tested your posted filter and my posted filter and here are results:

velis:

• SD channel:
  • CPU
    • TvService 50 %
    • MediaPortal <10 %
• HD channel:
  • CPU
    • TvService 55 - 58 %
    • MediaPortal 30 - 40 %

georgius:

• SD channel:
  • CPU
    • TvService <2 %
    • MediaPortal <10 %
• HD channel:
  • CPU
    • TvService <10 %
    • MediaPortal 48 - 55 %

Logs are attached. I also noticed that video using your filter was little bit stuttered (frames were dropped, see evr.log).

Test procedure:

1. stop MP and TvService
2. copy filter to TvService
3. delete logs from MP and TvService
4. start TvService
5. start MP
6. turn TV on
7. wait cca 2 minutes, watch on CPU utilization
8. turn TV off
9. close MP and stop TvService
10. copy logs

 

[velis]

Very interesting results. Where my Athlon takes ~6-7% for grabbing a HDTV, yours takes 50% for SDTV?!?

Also the MPIPTV log shows that your mm thread was unable to get the grabbed packets - which makes sense since I assume the grabber thread took those 50%. I don't see why though. I have the select() with a timeout there?!? Maybe the timeout is too low (100msec)??!?!?

This is funny because the waiting code is "the same" as in MPIPTVFilter provided with MP. If this new filter takes 100%, the original one should too on your computer.

Edit: Can you please try this one? It has logging disabled, maybe that will help?

 

[georgius]

Hi,

results are much better:

• SD channel
  • TvService <2%
  • MediaPortal <10%
• HD channel
  • TvService <10%
  • MediaPortal 50 - 60%

SD channel was OK (without stuttering, no frames dropped), HD channel stuttering (no dropped frames, discontinuity errors).

Very interesting results. Where my Athlon takes ~6-7% for grabbing a HDTV, yours takes 50% for SDTV?!?

Also the MPIPTV log shows that your mm thread was unable to get the grabbed packets - which makes sense since I assume the grabber thread took those 50%. I don't see why though. I have the select() with a timeout there?!? Maybe the timeout is too low (100msec)??!?!?

This is funny because the waiting code is "the same" as in MPIPTVFilter provided with MP. If this new filter takes 100%, the original one should too on your computer.

Edit: Can you please try this one? It has logging disabled, maybe that will help?

 

[micmanm]

Links provided by micmanm are mostly unworking (at least for me)

Try this streams

 

[velis]

OK, I did a bit of comparison testing.
On my HTPC both filters do their job well, without any visible stuttering.

The only difference is that TV Service takes about 1% CPU more with my filter. Seems like all that synchronization takes its toll

Logs + latest version of my filter included (adjusted priorities for mm thread as well - seems it helps with stutter).

I'm currently time testing Georgius's filter since it seems the better solution. Will see in a day or so how it fares long-term.

 

[velis]

Again it just locked (TVService) after about 1 hour watching (SD channel)
Logs attached, but look a bit before the end since they also contain the first channel after service kill / start.

 

[georgius]

Hi,

can you remember which channel have you been looking? It seems that after kill / start all necessary logs have been overwritten

Again it just locked (TVService) after about 1 hour watching (SD channel)
Logs attached, but look a bit before the end since they also contain the first channel after service kill / start.