Slovenia
Georgius, I will do this tonight. I can't right now because I'm at work. The 100% process, naturally, is TV Service.
IPTV/DVB-IP in MP: Support for http, rtp and udp (6 Viewers)
- Thread starter Stepko
- Start date
Georgius, I will do this tonight. I can't right now because I'm at work. The 100% process, naturally, is TV Service.
Can you use debug version of filter and post here MPITVSource*.log file?
Sorry Georgius, I went gathering the logs tonight but ended up reprogramming the filter. As I just finished part of my other project, it seemed the logical thing to do 
I'm currently testing with the last half-hour without one single dropped packet.
CPU usage watching a HD 20Mbit interlaced MPEG2 is ~7% for TvService, 45% MediaPortal.exe.
If tomorrow no dropped packets / other problems, I will post the filter so that it can be incorporated into the latest source.
I must admit though that I went modifying the SVN version, not the latest Stepko's version.
I'm currently testing with the last half-hour without one single dropped packet.
CPU usage watching a HD 20Mbit interlaced MPEG2 is ~7% for TvService, 45% MediaPortal.exe.
If tomorrow no dropped packets / other problems, I will post the filter so that it can be incorporated into the latest source.
I must admit though that I went modifying the SVN version, not the latest Stepko's version.
Hi,
I have the same results from HD video. Also I tested my version of filter on two simultaneous UDP streams (one wataching in MP, one recording) without any problem. I'm looking forward for your build and source codes to study
I have the same results from HD video. Also I tested my version of filter on two simultaneous UDP streams (one wataching in MP, one recording) without any problem. I'm looking forward for your build and source codes to study
Hi,
from your logs it seems that you don't have TsWriter filter:
From your logs it seems that you don't have any DVB-T (for aerial signal) card in your PC, so you can't test classic DVB-T television in MP.
Look in install directory of TV server if you have TsWriter.ax file. If yes, check with MONOGRAM GraphStudio (also part of K-Lite Codec Pack) if you have in filters (GraphStudio -> Insert -> Insert filter) MediaPortal Ts Writer and if file name and file path (path is without file name) on right side are correct.
from your logs it seems that you don't have TsWriter filter:
From your logs it seems that you don't have any DVB-T (for aerial signal) card in your PC, so you can't test classic DVB-T television in MP.
Look in install directory of TV server if you have TsWriter.ax file. If yes, check with MONOGRAM GraphStudio (also part of K-Lite Codec Pack) if you have in filters (GraphStudio -> Insert -> Insert filter) MediaPortal Ts Writer and if file name and file path (path is without file name) on right side are correct.
OK, after a few more hours testing I think this might be a good solution. I did see some stutters, but I can't be sure if those were glitches on the network or in the filter. Logs sure didn't show anything.
Included in the .rar are both sources and the .ax file.
as for .ax, instructions for installation are the same as for Georgius's version.
Sources are a bit of a problem since I only have VS 2008. You need to manually add the grabberthread.h and grabberthread.cpp to the project include / source files.
The filter writes log to Program Data\Team MediaPortal\MediaPortal TV Server\log
file name is MPIPTVSource-date.log.
This is in no way final code.
This is not the same solution as Georgius' version.
Use at your own risk
georgius:
I think this is stable, but I'm havin issues presumably with thread priorities / locking, mostly in the HD channel grabbing. Seems like even though the grabber thread doesn't take much CPU it still doesn't let the mm thread grab the buffers that are already filled. That's why you will see I allocate 200! buffers (300 KB) at the beginning of the grabber thread. This was pretty much necessary so that grabber thread doesn't have to allocate the buffers all the time.
But then there's this sudden burst when the mm thread in a few milliseconds cleans out the entire buffer. It's possible the interim non-grabbing may be an issue related to waiting for a signal from mm system. Need to investigate further since I really don't like so many mini-buffers.
Anyway, I think the architecture of this implementation should be pretty evident. The existing main thread source has been throughly cleaned out since all socket-related functions have been moved to the grabber thread. I also fixed logging so that the logging calls are no longer #ifdef-ed, but still generate no code when logging is disabled.
Grabber thread only grabs the socket and puts anything obtained in a deque.
I also maintain another deque which only stores empty buffers so that there's minimum allocation going on.
The previous grabber thread (mm thread - HRESULT CMPIptvSourceStream:: DoBufferProcessingLoop(void)) now only acts as an intermediary between mm system and grabber thread.
Grabber thread has elevated priority so that it presumably doesn't miss any packet. The internal grabbing loop is pretty tight IMO. A bit could be done about locking both deques, but not much really.
The mm thread has normal priority and just moves the data from grabber thread's buffers into mm buffers.
I could find no use for cyclic buffers. In fact I think they are dangerous (as in more stutter) should there be an overflow.
This is about it for now.
Included in the .rar are both sources and the .ax file.
as for .ax, instructions for installation are the same as for Georgius's version.
Sources are a bit of a problem since I only have VS 2008. You need to manually add the grabberthread.h and grabberthread.cpp to the project include / source files.
The filter writes log to Program Data\Team MediaPortal\MediaPortal TV Server\log
file name is MPIPTVSource-date.log.
This is in no way final code.
This is not the same solution as Georgius' version.
Use at your own risk
georgius:
I think this is stable, but I'm havin issues presumably with thread priorities / locking, mostly in the HD channel grabbing. Seems like even though the grabber thread doesn't take much CPU it still doesn't let the mm thread grab the buffers that are already filled. That's why you will see I allocate 200! buffers (300 KB) at the beginning of the grabber thread. This was pretty much necessary so that grabber thread doesn't have to allocate the buffers all the time.
But then there's this sudden burst when the mm thread in a few milliseconds cleans out the entire buffer. It's possible the interim non-grabbing may be an issue related to waiting for a signal from mm system. Need to investigate further since I really don't like so many mini-buffers.
Anyway, I think the architecture of this implementation should be pretty evident. The existing main thread source has been throughly cleaned out since all socket-related functions have been moved to the grabber thread. I also fixed logging so that the logging calls are no longer #ifdef-ed, but still generate no code when logging is disabled.
Grabber thread only grabs the socket and puts anything obtained in a deque.
I also maintain another deque which only stores empty buffers so that there's minimum allocation going on.
The previous grabber thread (mm thread - HRESULT CMPIptvSourceStream:: DoBufferProcessingLoop(void)) now only acts as an intermediary between mm system and grabber thread.
Grabber thread has elevated priority so that it presumably doesn't miss any packet. The internal grabbing loop is pretty tight IMO. A bit could be done about locking both deques, but not much really.
The mm thread has normal priority and just moves the data from grabber thread's buffers into mm buffers.
I could find no use for cyclic buffers. In fact I think they are dangerous (as in more stutter) should there be an overflow.
This is about it for now.
Hi, maybe it's only my problem but I don't see any attachement to download.