GNOME Bugzilla – Bug 641952
[videoscale] assertion on fixate_caps
Last modified: 2011-03-22 18:40:06 UTC
Videoscale asserts on fixate_caps when it receives these caps to fixate: 0:00:14.493877834 30131 0x81c71f0 DEBUG videoscale gstvideoscale.c:471:gst_video_scale_fixate_caps:<zoom-scale> trying to fixate othercaps video/x-raw-yuv, format=(fourcc)YUY2, color-matrix=(string)sdtv, chroma-site=(string)mpeg2, width=(int)1, height=(int)1, framerate=(fraction)1/2147483647 based on caps video/x-raw-yuv, format=(fourcc)YUY2, color-matrix=(string)sdtv, chroma-site=(string)mpeg2, width=(int)1, height=(int)1, framerate=(fraction)1/2147483647 The direction passed to the fixate function is GST_PAD_SRC (added an extra debug line to find that out) The assertion happens on line 518.
Right, this happens if both input and output caps are missing the pixel-aspec-ratio, we then assume in_par=1/1 and out_par=[1/MAX,MAX/1], and the latter then makes the is_fixed assertion fail.
Created attachment 181820 [details] [review] videoscale: Fix assertion on caps fixation When fixating caps, from_par should always be initialized with a fixed value. In case the fixation is from src to sink pad it was setting the from par (srcpad par) to a fraction range, this patch initializes it to 1/1, based on the assumption that missing PAR is 1/1.
Slomo, could you take a look at this patch? It seems you were the author of the code that does the gvalue initialization to a fraction range. Do you remember the reason? The commit seems to be b3808a57. Thanks!
It might be that instead all the code below this needs to be inverted for the GST_PAD_SRC case (flip caps and othercaps). The code was there to make assumptions about the PAR of caps without explicit PAR. Upstream caps without PAR are assumed to have 1/1 PAR while downstream caps without PAR are assumed to have [0,MAX] PAR. The code below that tries to keep the DAR of the upstream caps and tries to select downstream caps according to that. For the case of GST_PAD_SRC it probably has to change "caps" instead of "othercaps". Unfortunately I wasn't able to get this called with GST_PAD_SRC at all in the last minutes :) Anyway, I think the patch is wrong
Created attachment 183051 [details] [review] tests: videoscale: refactor reverse negotiation tests Adds new negotiation tests that are more flexible. This exposes a bug on videoscale reverse negotiation when videoscale receives a caps different than what asks on pad_alloc and that it can't handle (such as framerate changes).
Thiago are you working on fixing this?
Fixed by commit 91ed9290b880804ac479a9ddcab256494f7a31d6
Comment on attachment 181820 [details] [review] videoscale: Fix assertion on caps fixation Pushed, there might be a better and more complete solution, but this one improves the situation (avoids the assertion) and probably covers the great majority of the use cases.