
<html dir="ltr"><head></head><body style="text-align:left; direction:ltr;" bgcolor="#ffffff" text="#4c4c4c" link="#007aa6" vlink="#007aa6"><div>Hi,</div><div><br></div><div>Who owns the memory space was a topic of much internal discussion.</div><div><br></div><div>On the sender side (access_output module):</div><div><br></div><div>We have to keep the data around for a long time (every packet for 1 second or more depending on settings) to fulfill re-trasmissions requests. This requirement forces to use our own fifo and copy the data out of the calling app into our fifo as soon as we get it. </div><div>That being said, we could take the approach you suggest and loop internally within the library to "split" it into the proper packet sizes there and save one or more memcpy operations outside. I will make that change and re-submit.</div><div><br></div><div>On the receiver side (access module):</div><div><br></div><div>We have two ways to pass data to the calling app and we left both in the code for comments. One uses a callback and one uses a poll with a timeout against a fifo of length of 1000. In either case, we pass a pointer to the fifo structure (a rist_data_block) to the app and save a memcpy internally as these fifos our only freed during library shutdown (data is valid for 1000 packets). Technically, the app could use the data pointer directly without a memcpy with the caveat that if it takes too long to process it (1000 packets later), the data they read would belong to a much newer packet and other unpredictable results would follow.</div><div><br></div><div>Regarding the callback vs poll, I think poll matches the architecture of the "BlockRist" loop better than having the additional overhead of a fifo (unless I missed something). Feedback/thoughts are welcome.</div><div><br></div><div>Regards,</div><div><br></div><div>Sergio</div><div><br></div><div><br></div><div>-----Original Message-----</div><div><b>From</b>: Ilkka Ollakka <<a href="mailto:Ilkka%20Ollakka%20%3cileoo@videolan.org%3e">ileoo@videolan.org</a>></div><div><b>Reply-To</b>: Mailing list for VLC media player developers <<a href="mailto:Mailing%20list%20for%20VLC%20media%20player%20developers%20%3cvlc-devel@videolan.org%3e">vlc-devel@videolan.org</a>></div><div><b>To</b>: Mailing list for VLC media player developers <<a href="mailto:Mailing%20list%20for%20VLC%20media%20player%20developers%20%3cvlc-devel@videolan.org%3e">vlc-devel@videolan.org</a>></div><div><b>Subject</b>: Re: [vlc-devel] RIST Protocol: remove old rist modules and add new ones based on the librist library</div><div><b>Date</b>: Sat, 18 Apr 2020 17:04:31 +0300</div><div><br></div><pre>On Fri, Apr 17, 2020 at 08:09:35PM -0400, Sergio M. Ammirata, Ph.D. wrote:</pre><pre><br></pre><pre></pre><pre>I have created a new fork with just two commits to make it</pre><pre>easy to read. One commit deletes the old modules and the</pre><pre>next one creates the new ones.</pre><pre>Can I get some feedback please? I am ready to submit a</pre><pre>merge request.</pre><pre><a href="https://code.videolan.org/rist/vlc/-/commits/rist-dev">https://code.videolan.org/rist/vlc/-/commits/rist-dev</a></pre><pre>Thanks,</pre><pre></pre><pre><br></pre><pre>Hi,</pre><pre><br></pre><pre>Didn't yet read the whole module code through, but I spotted that</pre><pre>modules use memcpy on quite core of write/read functions, in most cases</pre><pre>it means that they do lot of small copies. And in littlebit later you</pre><pre>check the side you have on creating rist_buffer and writing.</pre><pre><br></pre><pre>On BlockRist this looks like only way to do it for now, as librist</pre><pre>doesn't seem to support providing own allocation function. So similar</pre><pre>approach that is used in in avcodec-modules doesn't seem to be possible.</pre><pre><br></pre><pre>In access_output/rist.c:Write, Why not just queue blocks as they are and</pre><pre>write block at a time (and reduce it if it doesn't fit), as you anyway</pre><pre>loop until the buffer is empty? That looks like possible approach,</pre><pre>unless I missed something on how librist handles given buffers?</pre><pre><br></pre><pre><br></pre><pre><br></pre><pre><br></pre><pre>_______________________________________________</pre><pre>vlc-devel mailing list</pre><pre>To unsubscribe or modify your subscription options:</pre><pre><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a></pre></body></html>