DVDs always have subpictures that start on an even Y
coordinate, but gstspu does more generic vobsubs these
days, so handle ones that start on an odd vertical position.
https://bugzilla.gnome.org/show_bug.cgi?id=777400
timecodestamper will post an element message which contains the current
timecode it just stamped. If a timecode was already found and not
replaced, it will still post it in a message.
https://bugzilla.gnome.org/show_bug.cgi?id=777048
... rather than when determining when to end the frame.
The opportunity to do so might not come when forced to drain,
and it seems nicer anyway to do so at parse wrapup time.
This happens if we had no CAPS event yet but e.g. got an EOS event. We
would then try to output a 0-sized buffer, but getting that from the
adapter will give an assertion, return NULL and then crash.
If they were not ported after 4+ years it seems unlikely that anybody is
ever going to need them again. They're still in the GIT history if
needed.
https://bugzilla.gnome.org/show_bug.cgi?id=774530
Compositor does not support it currently and it needs special support
for handling this correctly, and is rather non-trivial to implement for
all formats.
For frame->buffer, baseparse is doing that automatically for us. For
frame->output_buffer it doesn't and assumes that the subclass is already
doing that. Consistency!
This is useful e.g. if audio buffers should be exactly the duration of a
video frame, or if a audio buffers should never be too large because of
latency constraints.
The element is taking a fractional buffer duration, to allow working
with e.g. 1001/30000 as output duration and it accumulates rounding
errors in the buffer durations and compensates for them by making some
buffers one sample larger than the others.
https://bugzilla.gnome.org/show_bug.cgi?id=774689
We will allocate a screen area of width*height*bpp bytes, however this
calculation can easily overflow if too high width or height are given
inside the stream. Nonetheless we would just assume that enough memory
was allocated, try to fill it and overwrite as much memory as wanted.
Also allocate the screen area filled with zeroes to ensure that we start
with full-black and not any random (or not so random) data.
https://scarybeastsecurity.blogspot.gr/2016/11/0day-poc-risky-design-decisions-in.html
Ideally we should just remove this plugin in favour of the one in
gst-libav, which generally seems to be of better code quality.
https://bugzilla.gnome.org/show_bug.cgi?id=774533
Type cast has higher precedence than bitwise shift, so the third
argument will truncate to 8 bits and then shift right by 8 bits
resulting in constant zero.
https://bugzilla.gnome.org/show_bug.cgi?id=774293
Consistently use GST_ROUND_UP_4(width) as stride for
bayer buffers. Bayer data will usually come in widths
that are multiples of 4 anyway, so hopefully this
should not have any adverse impact on anyone in
practice.
Before, bayer2rgb required input buffers to are sized
accordingly, but then didn't actually round up when
calculating row offsets. rgb2bayer didn't use a rounded
stride nor buffer size.
https://bugzilla.gnome.org/show_bug.cgi?id=752014
