When input is not in byte-stream format there is no need to wait for the first
buffer before setting src caps. We already have all the information from the
input codec_data.
This allow us to already configure downstream elements allowing them,
for example, to already allocate their internal buffers as they know
the format of the input they are about to receive.
Same change as the one I just did in h264parse.
https://bugzilla.gnome.org/show_bug.cgi?id=790709
When input is in AVC format there is no need to wait for the first buffer
before setting src caps. We already have all the information from the
input codec_data.
This allow us to already configure downstream elements allowing them,
for example, to already allocate their internal buffers as they know
the format of the input they are about to receive.
https://bugzilla.gnome.org/show_bug.cgi?id=790709
It causes crashes in applications because the result of
fbGetDisplay() might be in use elsewhere in the application
and Vivante doesn't seem to do any refcounting
This reverts commit 47fd4d391e.
This patch is incorrect. It doesn't actually compile, and causes a crash
because the viv-fb window implementation needs a native EGL handle
to pass to fbCreateWindow, but the GstGLDisplayEGL handleis actually
an EGLDisplay now (and gets cast to the wrong type)
Try prioritizing downstream's caps over upstream's if possible so the
parser can configured in "passthrough" if possible and save it from
doing useless conversions.
Exact same change as the one I just did in h264parse.
https://bugzilla.gnome.org/show_bug.cgi?id=790628
Try prioritizing downstream's caps over upstream's if possible so the
parser can configured in "passthrough" if possible and save it from
doing useless conversions.
https://bugzilla.gnome.org/show_bug.cgi?id=790628
If the driver requires more data, just unref the frame at the moment
then retreive/finish the frame after encoding is finished.
This also fixes a memory leak.
https://bugzilla.gnome.org/show_bug.cgi?id=790312
Fixes outputted frame sequence when performing a seek
i.e. when seeking backwards, the first frame after the seek was a frame
from the future. This would result in GstVideoDecoder essentially
marking all the timestamps as essentially bogus and the base class would
attempt to compensate. A visible indication of this was 'decreasing timestamp'
warning after a seek.
https://bugzilla.gnome.org/show_bug.cgi?id=790478
A deserialised timecode has a framerate of 0/1 by default. That breaks
it when comparing the frames field with another timecode (incoming from
the frame). We were setting the framerate when receiving the caps event,
but not when setting the timecode in set_property, so it was broken for
timecodes set after the caps event.
Also checking if the fps_n we got from the caps event is != 0 before
setting it - also at the caps event.
https://bugzilla.gnome.org/show_bug.cgi?id=790334
Now that timecodes support proper serialisation / deserialisation, a
timecode might have an invalid fps_n / fps_d even without using the
target-time-code-string property. Detect those cases and set fps_n/fps_d
properly.
The "fields" flag is ignored because currently GStreamer doesn't support
having only top or only bottom fields inside a frame. The "drop frame"
flag is ignored because some occurrences have been spotted where it
wasn't set while it should have been. In practice, when we have 29.97 or
59.94 FPS, it's always drop-frame.
https://bugzilla.gnome.org/show_bug.cgi?id=790112
