[PATCH v2 6/8] winegstreamer: Keep wg_transform output samples in a list.

[Zebediah Figura (she/her)]

On 2/25/22 14:37, Rémi Bernon wrote:
> On 2/25/22 18:45, Zebediah Figura (she/her) wrote:
>> On 2/23/22 08:46, Rémi Bernon wrote:
>>> Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51931
>>> Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52391
>>> Signed-off-by: Rémi Bernon <rbernon at codeweavers.com>
>>> ---
>>>   dlls/winegstreamer/wg_transform.c | 31 +++++++++++++++++++++++++++++++
>>>   1 file changed, 31 insertions(+)
>>>
>>
>> What's the motivation for doing this?
>>
>> (And why not, say, use a queue element instead? Not that this is
>> particularly complex, to be fair.)
>>
> 
> 
> It seemed simpler like this as it doesn't need to wait on ProcessOutput 
> to be called.

That's a good point; I did not consider that. And of course the concern 
of memory usage doesn't apply here.

> 
> Still, I'd like to add a queue later anyway, for the purpose of 
> implementing zero-copy, so maybe I can use it there, I'll have a try.
> 
> 
>>> +    if (!(entry = calloc(1, sizeof(*entry))))
>>> +        GST_ERROR("Failed to allocate sample entry");
>>> +    else
>>> +    {
>>> +        pthread_mutex_lock(&transform->mutex);
>>> +        entry->sample = gst_sample_new(buffer, NULL, NULL, NULL);
>>> +        list_add_tail(&transform->samples, &entry->entry);
>>> +        pthread_mutex_unlock(&transform->mutex);
>>
>> Why create a GstSample?
>>
> 
> 
> Because I think we'll need to hold the caps for the buffers too, to 
> detect format changes which can and must happen with H264.
> 
> I can change it later too, it makes future changes smaller to have the 
> sample now.
> 

Okay, that probably makes sense; I just couldn't tell from the commit.