GNOME Bugzilla – Bug 762547
The NV12 UV plane address does not match with 1920x1080 frames
Last modified: 2016-11-23 16:44:07 UTC
I use a pipeline like vaapidecode ! vaapipostproc ! appsink The buffer I get from appsink with buffer = gst_sample_get_buffer(_sample); caps = gst_sample_get_caps(_sample); gst_video_frame_map(&frame, &vinfo, buffer, GST_MAP_READ); has a mismatch of the UV plane with the NV12 format. I should be able to access the video planes via frame.data[0] for the Y plane and frame.data[1] for the UV plane. But the UV plane does not start there, it starts later. With lower resolutions like 1280x720 this doesn't happen. There the address is correct.
Hi, vaapidecode is outputting buffers with 1088 rows, when asked to decode 1920x1080. The problem is, the pipeline doesn't know about that. Regards,
Could you try with gstreamer-vaapi 1.9.2 ?? We have a lot of changes regarding resolution handling for non-accelerated sinks. Or could you upload a test code with appsink?
I will do so as soon as I get the time for it. Thanks
I have tested it with 1.10.0 I can see that the plane address is correct. But the strides and the offsets are still wrong.
Do you have test app to share?
Aha! Now I can imagine what's happening! appsink doesn't negotiates a buffer pool with GST_BUFFER_POOL_OPTION_VIDEO_META and, only if downstream requests it, the vaapi buffer pool will stamp the GstVideoMeta in the buffer with the correct strides and offsets. Without it, the gst_video_frame_map() will try to figure out those parameters which may not match with the GPU mapped memory. So, either you create your own sink which ask for a buffer pool with GST_BUFFER_POOL_OPTION_VIDEO_META, or, perhaps, you should insert a software-based video filter, like gamma, to request it for you. I'm going to close the issue but if you feel that we should fix something in gstreamer-vaapi, please reopen it.