In the H263 spec, CPFMT is present only if the use of a custom
picture format is signalled in PLUSEPTYPE and UFEP is "001",
so we need to check params->format and only if the value is
6 (custom source format) the CPFMT should be read, otherwise
it's not present and wrong data will be parsed.
When reading the CPFMT, the width and height were not
calculated correctly (wrong bitmask).
https://bugzilla.gnome.org//show_bug.cgi?id=749253
Rather than one of the input pad video info's.
The test checking this was not constraining the output frame size
to ensure that the out of frame stream was not being displayed.
The custom code is wrong as it ignores the templates, which leads to
missing fields in the result. Instead, simply use the default get_caps
implementation which does it correctly (get the template, intersect
with filter and return).
https://bugzilla.gnome.org/show_bug.cgi?id=749237
Without this, we will fixate weird pixel-aspect-ratios like 1/2147483647. But
in the end, all the negotiation code in videoaggregator needs a big cleanup
and videoaggregator needs to get rid of the software-mixer specific things
everywhere.
Unless stopRequest is set, we should unlock conditionally -- otherwise,
the 'create:' method can wake up to an empty buffer queue
and pull a nil buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=748054
No need to call gst_remove_silence_reset() in gst_remove_silence_init() because
vad_new() already calls this function. Since there are no more uses of
_silence_reset(), we can remove it altogether.
Don't use the apis in codec-utils to extract the profile and level
syntax elements since it is wrong if there are emulation prevention
bytes existing in the byte-stream data.
https://bugzilla.gnome.org/show_bug.cgi?id=747613
Make the passthrough check contingent on only the fields we
can modify being unchanged, and pre-compute it when caps
change instead of checking on each buffer. Makes the passthrough
more lenient if consumers are lax about making input and output
caps complete.
We verify that all the buffers on an obscured sinkpad are skipped by overriding
the map() function in the GstVideoMeta of the buffers to set a variable when
called. We also test that the buffers do get mapped when they're not obscured.
Blame^WCredit for the GstVideoMeta map() idea goes to Tim.
https://bugzilla.gnome.org/show_bug.cgi?id=746147
It's a waste of resources to map it if it won't be converted
or used at all. Since we moved the frame mapping down, we need
to use the GST_VIDEO_INFO accessor macros now in the code above
that instead of the GST_VIDEO_FRAME accessor macros.
https://bugzilla.gnome.org/show_bug.cgi?id=746147
For each frame, compare the frame boundaries, check if the format contains an
alpha channel, check opacity, and skip the frame if it's going to be completely
overwritten by a higher zorder frame. The check is O(n^2), but that doesn't
matter here because the number of sinkpads is small.
More can be done to avoid needless drawing, but this covers the majority of
cases. See TODOs. Ideally, a reverse painter's algorithm should be used for
optimal drawing, but memcpy during compositing is small compared to the CPU used
for frame conversion on each pad.
https://bugzilla.gnome.org/show_bug.cgi?id=746147
