
<html><head></head><body>Hi,<br><br>In my understanding, the filter input pictures are allocated by upstream as before. This already followed the push model from the beginning.<br><br>And filter output pictures are the responsibility of the filter to allocate. For preexisting in-place/destructive filters, that means no changes from before. For non-destructive filters, that means allocating in whatever way they see fit, with the potential use of the video context.<br><br>filter_NewPicture() should be just a compatibility alias for picture_NewFromFormat(). Hardware-driving filters should use custom allocators like VDPAU already does, IIRC.<br><br>tl;dr: push model for picture allocation<br><br><div class="gmail_quote">Le 30 juillet 2019 23:40:48 GMT+03:00, Alexandre Janniaux <ajanni@videolabs.io> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<pre class="k9mail">Hi,<br><br>On Tue, Jul 30, 2019 at 08:12:47PM +0300, Rémi Denis-Courmont wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Le tiistaina 30. heinäkuuta 2019, 10.14.17 EEST Steve Lhomme a écrit :<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">On 2019-07-29 21:18, Rémi Denis-Courmont wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;">Le maanantaina 29. heinäkuuta 2019, 22.08.58 EEST Alexandre Janniaux a<br></blockquote></blockquote>écrit :<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;">While I agree that we probably don't need flow control and that image<br>number is probably dominated, the starvation issue seems a real issue to<br>tackle. What are the solution against starvation on Windows ? Should we<br>just fail if we got starved ?<br></blockquote> In general, it is the halting problemm which is to say that the general<br> case cannot be solved and assumptions have to be made.<br><br> If we need to make assumptions, we might just as well assume that filters<br> are well-behaved, as indeed they have so far been. Ideally, a filter that<br> needs to allocate surfaces (rather than modify input surface in-place)<br> should allocate a suitably large pool for itself. And that turns out<br> incompatible with filter_NewPicture().<br></blockquote>I don't see how. This particular patch adds the possibility for filters<br>to provide their own (output) allocator. A filter could very well create<br>a pool and have its allocator pick pictures in that pool. That still<br>goes through filter_NewPicture, because the filter doesn't know if it<br>has to use pictures from the outside or it can use its own.<br></blockquote></blockquote><br>I don't really understand how can you use picture from the outside in a GPU<br>filter ? It doesn't seem to fit the push model too.<br><br>><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> That makes no sense. The "outside" cannot know if the filter allocates or not.<br> Already now, both cases have to work - it has more or less always been that<br> way with filters.<br><br> So far only converters could be assumed to allocate pictures - and in the push<br> model, that would be from the video context, not from the downstream/<br> filter_NewPicture().<br><br></blockquote><br>Just to clarify, do we agree that it has to allocate pictures thanks to the<br>video context, but not from it ? Meaning the video context can only provide a<br>rendering-like context for rendering-like API in the case of filter (be it GPU<br>or CPU, the CPU case being "allocate your memory that way (shm) or that way<br>(dynamic memory chunk)") and the memory is allocated by the filter through this<br>context with the rendering API, which should match the context ?<br><br>For instance, even if I'm not really fond of this model, it would be an openGL<br>context as a video context, and the filter would use glGenTextures ? Or would<br>the video context provide a `picture_t pf_AllocatePicture(some args)` ?<br><br>> ><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;">Since the filter chain is (partially) dynamic, we cannot even rely on<br>filters telling how many "extra" surfaces they need - the total value<br>could change in the middle of the stream. Instead, the filter ought to<br>allocate its surfaces during initialization, and potentially refuse to<br>start if it cannot succeed - but not break the whole pipeline.<br></blockquote>I'm not sure we can estimate this amount easily. For example what would<br>be the amount an adjust filter has to allocate ?<br></blockquote> The adjust filter needs 0 surfaces since it operates in place.<br><br> Point being anyway that only the filter can know that, if anything. Since the<br> filter chain is dynamic, it cannot be taken into account when the decoder and<br> display are set up. It may be that even the filter does not know how many<br> pictures it needs, but then there is nothing to fix; it will just maybe or<br> maybe not work by allocating on the fly.<br></blockquote><br>I don't really agree, doing things in place seems to go against the usual<br>practice with filters. Or do we change this model to add copy filters ?<br><br>In the mean time, if filters are still processed synchronously, every filters<br>would need only a fixed number of pictures, or at least a number of pictures<br>known by the filter itself, except maybe the last one which have to take into<br>account the pictures allocated by the display. Copies can be made by the filters<br>itself if they absolutely need to keep a picture, and optimization could be made<br>so as to do late copies later only if the image is to be reused.<br><br>Remi, is the last-filter special-case what you mean with the fact that only<br>converters are allocating pictures or is it more complex than that ?<br><br>Regards,<br>--<br>Alexandre Janniaux<br>VideoLabs<br><br><br>><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> --<br> レミ・デニ-クールモン<br> <a href="http://www.remlab.net/">http://www.remlab.net/</a><hr> vlc-devel mailing list<br> To unsubscribe or modify your subscription options:<br> <a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a><br></blockquote><hr>vlc-devel mailing list<br>To unsubscribe or modify your subscription options:<br><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a></pre></blockquote></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>