I have added NV12 to qmlglsink and use raw video with NV12 from vah264dec. Looks good and seems to be the least expensive approach. Since I have seen that there are specific implementation for supported caps with i965, does it make sense to disable YV12 as it does not work correctly?
Since I did not test with an older version of va plugins I cannot say if this happened before. I use the conversion simply because qmlglsink already provides the YV12 input caps, this is what auto-negotiation gives me. I will add NV12 support and try that. So you expect the problem to be in the conversion from NV12 to YV12 and not in the conversion from VAMemory to DMABuf?
On i965 (Intel BYT) platform the conversion from memory:VAMemory with format NV12 to memory:DMABuf with format YV12 leads to corrupt memory.
Observed Behavior: One C plane (U or V) has corrupted memory.
I have tested with qmlglsink, however, the exact same problem can be observed with glimagesink, too.
The attached image shows the 3 planes (YUV) rendered next to each other (for this I modified the YV12->RGBA shader from gstqsgmaterial/qmlglsink). Obviously the one in the upper/left corner (U or V, I'm not sure) has corrupted memory, parts of the correct data can be seen in to bottom part of the section.
Please let me know if you need additional information or if I can do any further tests.
Additional attachments contain the pipeline dump and some log output. Interesting part for me is the mismatch from vadmabufallocator.
[pipeline.dot](/uploads/50fcf6e9fd3d58dc25acf48a6073228d/pipeline.dotvapostproc_7_vamemory_7.log.gz
Since GST_MESSAGE_ASYNC_DONE might be used the wrong way following the current description and the usage of GST_MESSAGE_ASYNC_DONE is discouraged update the documentation.
Jochen Henneberg (8f60dce6) at 23 Feb 06:15
element: Update gst_element_set_state() description
... and 33 more commits
Jochen Henneberg (eb641af4) at 23 Feb 06:14
rtp: Fix constant for maximum two-byte RTP header extension length
... and 32 more commits
Jochen Henneberg (5e1c69c7) at 23 Feb 06:13
element: Update gst_element_set_state() description
Jochen Henneberg (c6636533) at 22 Feb 10:04
Done as proposed.
Jochen Henneberg (caffac18) at 22 Feb 06:43
ptp-helper: Allow sync to master clock on same host
Will do. Does it make sense to wrap this block into a #[cfg(not(target_os = "linux"))] and maybe some others (which I don't know, maybe you do) since the whole check can be skipped for Linux?
Jochen Henneberg (a1798535) at 21 Feb 16:13
ptp-helper: Allow sync to master clock on same host
Jochen Henneberg (d6521f13) at 21 Feb 16:10
ptp-helper: Allow sync to master clock on same host
If we drop all messages with the same clock id as ours we will also drop all messages coming from a PTP clock on our host since both clock ids are build from the same MAC address.
At least for Linux we do not see our own messages anyway since the network stack can well distinguish between multicast send from our socket or from another socket on the same machine. To make sure that this works for all supported platforms just drop delay requests since this is the only message that is sent from the GStreamer PTP clock.
Jochen Henneberg (e2ce162d) at 21 Feb 16:03
ptp-helper: Allow sync to master clock on same host
Jochen Henneberg (9e2e456d) at 21 Feb 15:43
adaptivedemux2: fix build with recent meson
... and 38 more commits
Jochen Henneberg (6608b899) at 19 Feb 12:29
Used g_steal_pointer(), used gst_buffer_list_new () where the size is not known and fixed the sized alloc with the queue size. Also rebased the commits to current main.
Jochen Henneberg (227434ea) at 19 Feb 10:16
rtpxqtdepay: Enabled header extension aggregation
... and 2 more commits
Jochen Henneberg (1dc374bb) at 19 Feb 10:11
rtpxqtdepay: Enabled header extension aggregation
... and 1153 more commits