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/DVB-IP in MP: Support for http, rtp and udp
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="velis" data-source="post: 728608" data-attributes="member: 96429"><p><strong>Re: AW: Re: AW: Re: IPTV/DVB-IP in MP: Support for http, rtp and udp</strong></p><p></p><p></p><p>This is exactly the way my version works. So far it's the only way of making sure there are no dropped packets, but the CPU usage is erratic as I described in my last post. And Georgius says he gets 100% CPU usage with it <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite3" alt=":(" title="Frown :(" loading="lazy" data-shortname=":(" /></p><p></p><p></p><p>Hence my idea of spoofing a "snow" clip...</p><p></p><p>Georgius, I've been looking at the source code of this latest filter: I think it would be better to have three separate thread functions, each for its own transport. Currently the code is hardly readable because of all the branching. Also please see my latest solution for logging. It doesn't require #ifdef in code.</p><p>It's a shame we don't have a SVN for this. It's so hard for multiple people to work on the same file <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite3" alt=":(" title="Frown :(" loading="lazy" data-shortname=":(" /></p><p></p><p>Edit: I'm continuing work on my version of filter because so far it's the only one I know that produces stutter free grabbing. I must say that I can't see how Georgius's code makes any difference in regard to CPU usage stability. In fact, it should be worse since it performs memcpy every now and then. To be quite honest, I can't see where my code could *ever* use that much CPU, yet it happens. I will prepare the stutter free code tonight in case anyone would be interested in looking for what I am missing here (in regard to CPU usage problem, of course).</p><p></p><p>when a good, low CPU, stutter free code base is established, it can easily be reused for other methods. That's where I see usefulness of my ongoing efforts. Plus - I don't have to constantly verify any progress made by Georgius <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin :D" loading="lazy" data-shortname=":D" /></p></blockquote><p></p>
[QUOTE="velis, post: 728608, member: 96429"] [b]Re: AW: Re: AW: Re: IPTV/DVB-IP in MP: Support for http, rtp and udp[/b] This is exactly the way my version works. So far it's the only way of making sure there are no dropped packets, but the CPU usage is erratic as I described in my last post. And Georgius says he gets 100% CPU usage with it :( Hence my idea of spoofing a "snow" clip... Georgius, I've been looking at the source code of this latest filter: I think it would be better to have three separate thread functions, each for its own transport. Currently the code is hardly readable because of all the branching. Also please see my latest solution for logging. It doesn't require #ifdef in code. It's a shame we don't have a SVN for this. It's so hard for multiple people to work on the same file :( Edit: I'm continuing work on my version of filter because so far it's the only one I know that produces stutter free grabbing. I must say that I can't see how Georgius's code makes any difference in regard to CPU usage stability. In fact, it should be worse since it performs memcpy every now and then. To be quite honest, I can't see where my code could *ever* use that much CPU, yet it happens. I will prepare the stutter free code tonight in case anyone would be interested in looking for what I am missing here (in regard to CPU usage problem, of course). when a good, low CPU, stutter free code base is established, it can easily be reused for other methods. That's where I see usefulness of my ongoing efforts. Plus - I don't have to constantly verify any progress made by Georgius :D [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Support
Watch / Listen Media
Television (MyTV frontend and TV-Server)
IPTV/DVB-IP in MP: Support for http, rtp and udp
Contact us
RSS
Top
Bottom
