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