[PATCH v6 0/3] MR302: winegstreamer: Some wg_transform H264 fixes for Mortal Kombat 11 and Yakuza 4.

[Rémi Bernon (@rbernon)]

> [...] I'd still be 
> surprised if a well-behaved application would never release samples. 
> That would result in a significant memory leak.
> 

Sure, but we should prepare for the worst, because it's what happens.

Badly behaving applications is the norm. Or actually, because we don't
know what the good behavior really is, applications that do not behave
like we expected them to.

> > I don't think a fixed pool can work. We cannot expect the output buffers passed downstream to the application to ever be released, or, even if they probably will, I don't think we can easily and safely put them in back in the pool when they are.
> 
> Wait, we can't?
> 
> I assume you mean for Media Foundation specifically, in particular 
> because DirectShow does have pooling built into the API (and with a 
> maximum buffer count as well). As far as I understand neither Media 
> Foundation nor the ASF reader explicitly pool, but [...]

> > 
> > 1) We'd need a custom buffer implementation for each API.
> 
> Wait, why?
> 
> > 
> > 4) The buffers may be released after the pipeline has been shutdown, we'd need to keep it alive until all the buffers are released, which is likely going to cause problems.
> 
> Why? We shouldn't need to provide anything to the Unix side except for 
> the buffer pointer and size. I would expect that the PE buffers should 
> outlive the unix device under normal operation.

I don't see any notion of a buffer pool in MF, though I have only a
limited knowledge of the API. But even with quartz, I understand the
buffers are pooled by a IMemAllocator object. The allocator gets
notified when buffers are released, but we (the wg_parser used) don't.

As I understand it the allocator may also be application provided and
the buffer implementation too.

So I don't really understand how you expect the buffers to be released
to the unix buffer pool if not by periodically requesting new buffers
from the IMemAllocator, or, for the MF API, by implementing our own
IMFSample interface to hook the final buffer release.

In any case it's starting to look very similar to allocations on demand
through the wg_allocator callback.


> > 
> > 2) Some API provide allocation callback which conflicts with 1) needs.
> > 
> > 3) The allocation callbacks may block.
> 
> They may block waiting for what?

Idk, anything?

The callbacks can be app provided, I'm not making any assumption on what
they decide to wait for.

I don't know what pattern native is using, though I expect it to be
more or less like GStreamer, with allocations as needed.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/302#note_3381