Reply to thread

Message

<blockquote data-quote="velis" data-source="post: 729147" data-attributes="member: 96429">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 <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin&nbsp; &nbsp; :D" loading="lazy" data-shortname=":D" /> 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 &quot;smart&quot; 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'tI 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 &quot;no signal&quot; processing (spoofing a custom video)</blockquote>

[QUOTE="velis, post: 729147, member: 96429"] 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 :D 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) [/QUOTE]

Verification