[Bug 762543] xvimagesink: wrong pool selection when rendering buffers having GstVideoCropMeta attached

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Wed Feb 24 08:56:35 UTC 2016


https://bugzilla.gnome.org/show_bug.cgi?id=762543

--- Comment #6 from sreerenj <bsreerenj at gmail.com> ---
(In reply to Nicolas Dufresne (stormer) from comment #5)
> For the reference:
> 
> commit df313a6dbc563cd4922f9897316516b760738ba4
> Author: Nicolas Dufresne <nicolas.dufresne at collabora.co.uk>
> Date:   Fri Jun 5 14:30:12 2015 -0400
> 
>     xvimagesink: Don't share internal pool
>     
>     Sharing the internal pool results in situation where the pool may have
>     two upstream owners. This creates a race upon deactivation. Instead,
>     always offer a new pool, and keep the internal pool internal in case
>     we absolutely need it.
>     
>     https://bugzilla.gnome.org/show_bug.cgi?id=748344
> 
> So the pool created in set_caps() is only used for when upstream buffer are
> not using the proposed pool. I'm not sure how you get a miss-match in
> video_info here. Are you using an upstream pool with a size that does not
> match the one allocated in the caps ?

The reason by xvimagesink can work with vaapidecode is that vaaapidecode is
always reporting uncropped values to xvimagesink->set_caps(),
but I am going to change this to report cropped dimension (display size)...

Now the issue is:
vaapidecode will report the cropped values, and xvimagesink will maintain itz
own pool created in setcaps based on this cropped resolution.
But then vaapidecode will create itz own pool with uncropped values and those
values will be only available in xvimagesink->propose_allocation.
In this scenario, vaapidecode and xvimagesink have their own pools and
xvimagesink is trying to copy the frames with uncropped values which will
simply break the playback.

issues:
1: gst_video_frame_map(src_buffer) with wrong resolution which is saved in
set_caps
2: gst_video_frame_copy(dst_buffer, src_buffer) where dst_buffer and src_buffer
have different resolution..

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list