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@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.