home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
Support
Watch / Listen Media
Television (MyTV frontend and TV-Server)
IPTV not working
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="Stepko" data-source="post: 605026" data-attributes="member: 57342"><p><strong>AW: Re: IPTV not working</strong></p><p></p><p>Hi,</p><p></p><p>I did some changes to the rtp and udp part of the filter and also included dimkas latest http changes (2010/04/09).</p><p></p><p>Thanks for the hint. Your are right, the data must be send forward as quick as possible. But I don't see the possibility that radio streams are handled with this filter, as the mediatype is set to "MEDIASUBTYPE_MPEG2_TRANSPORT". To be sure that streams with low bitrates also work, I lowered the buffersize of the mediasample from 256kb to 4kb! This buffer is filled up quick enough I think, and it works perfectly on my systems.</p><p></p><p></p><p>Luckily I didn't have any problems with this. Seems that your changes to the winsock buffersize fixed the problem!</p><p></p><p>I looked at the other thread and have to agree with tourettes: The thread priority should not be "time critical" especially not any more since I added some logic when handling rtp streams. So I set it to "above normal" which works fine on my systems.</p><p></p><p>The changes:</p><ul> <li data-xf-list-type="ul"> Lowered mediasample buffer to 4kb (all)</li> <li data-xf-list-type="ul"> Lowered rtp buffer to 128kb (rtp only)</li> <li data-xf-list-type="ul"> Lowered thread priority to "above normal" (all)</li> <li data-xf-list-type="ul"> Fixed a bug: A packet the arrives late was inserted at the wrong position (rtp only)</li> <li data-xf-list-type="ul"> The first few packages are now not checked if they are continuous or not. I did this because the filter now doesn't fill up the whole buffer before sending the first data to the next filter. Should improve zapping time a lot. (rtp only)</li> <li data-xf-list-type="ul"> The rtp part is now in a separate source file (rtp only)</li> <li data-xf-list-type="ul"> Sets the size of mediaSample to 0 instead of -1, when first packet comes late (udp only)</li> </ul><p></p><p>This version now reorders the packages correctly and uses less memory. The channel switching should now be faster on rtp streams.</p><p>I hope the error some people had with upd packets is now fixed. The only explanation I have is that the stream needs some time before the first packet arrives. The filter returned a length of -1 to the next filter, which I think causes the next filter to stop the graph. This version now returns 0, I hope that it fixes the problem.</p><p></p><p>There are 2 versions: Please only use the release version. The logging is completly disabled in the release version. If you have trouble with the filter you might use the debug version. But be warned: It produces very large log files (>10 MB in a few minutes watching rtp streams)!! It also needs a lot of cpu power (about 50% on my 4 year old amd, only for logging!!). My advice is NOT to use the filter within MP. If you need to log something start preview or timeshift in TvServer-Configuration. <strong>Please use the debug version only if you really need it and if you know what you do!!</strong></p><p></p><p>Stepko</p></blockquote><p></p>
[QUOTE="Stepko, post: 605026, member: 57342"] [b]AW: Re: IPTV not working[/b] Hi, I did some changes to the rtp and udp part of the filter and also included dimkas latest http changes (2010/04/09). Thanks for the hint. Your are right, the data must be send forward as quick as possible. But I don't see the possibility that radio streams are handled with this filter, as the mediatype is set to "MEDIASUBTYPE_MPEG2_TRANSPORT". To be sure that streams with low bitrates also work, I lowered the buffersize of the mediasample from 256kb to 4kb! This buffer is filled up quick enough I think, and it works perfectly on my systems. Luckily I didn't have any problems with this. Seems that your changes to the winsock buffersize fixed the problem! I looked at the other thread and have to agree with tourettes: The thread priority should not be "time critical" especially not any more since I added some logic when handling rtp streams. So I set it to "above normal" which works fine on my systems. The changes: [LIST] [*] Lowered mediasample buffer to 4kb (all) [*] Lowered rtp buffer to 128kb (rtp only) [*] Lowered thread priority to "above normal" (all) [*] Fixed a bug: A packet the arrives late was inserted at the wrong position (rtp only) [*] The first few packages are now not checked if they are continuous or not. I did this because the filter now doesn't fill up the whole buffer before sending the first data to the next filter. Should improve zapping time a lot. (rtp only) [*] The rtp part is now in a separate source file (rtp only) [*] Sets the size of mediaSample to 0 instead of -1, when first packet comes late (udp only) [/LIST] This version now reorders the packages correctly and uses less memory. The channel switching should now be faster on rtp streams. I hope the error some people had with upd packets is now fixed. The only explanation I have is that the stream needs some time before the first packet arrives. The filter returned a length of -1 to the next filter, which I think causes the next filter to stop the graph. This version now returns 0, I hope that it fixes the problem. There are 2 versions: Please only use the release version. The logging is completly disabled in the release version. If you have trouble with the filter you might use the debug version. But be warned: It produces very large log files (>10 MB in a few minutes watching rtp streams)!! It also needs a lot of cpu power (about 50% on my 4 year old amd, only for logging!!). My advice is NOT to use the filter within MP. If you need to log something start preview or timeshift in TvServer-Configuration. [B]Please use the debug version only if you really need it and if you know what you do!![/B] Stepko [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Support
Watch / Listen Media
Television (MyTV frontend and TV-Server)
IPTV not working
Contact us
RSS
Top
Bottom
