Our encoder implementation actually supports a small subset of the
formats supported by the decoder. Those are the formats for which we
have a copy path in gst_omx_video_enc_fill_buffer() and which are not
filtered out in filter_supported_formats().
Coverity was complaining with:
Null pointer dereferences (REVERSE_INULL) Null-checking "frame"
suggests that it may be null, but it has already been
dereferenced on all paths leading to the check.
The frame == NULL has been removed as 'frame' is actively used
in the code above without any change of dereferencing and setting
its value to NULL before the test.
CID: 1461287
Does not change anything for now but will be needed when we'll support
interlace-mode=alternate as the field rate will be twice the frame rate.
Made the code safe from division by 0 while I was on it.
Tell buffer consumer about our paddings.
v4l2src can now uses these paddings information when trying to import
buffers to configure the v4l2 driver accordingly.
Those debug infos have proved to be very helpful when debugging
timestamp issues. They are often linked to gst-omx picking the wrong
frame when trying to map from OMX.
If less than 1%.
The dynamic format change should not happen when the
resolution does not change and when only the framerate
changes but very slightly, i.e. from 50000/1677=29.81
to 89/3=29.66 so a "percentage change" of less than 1%
(i.e. 100*(29.81-29.66)/29.66 = 0.50 < 1 ). In that case
just ignore it to avoid unnecessary renegotiation.
https://bugzilla.gnome.org/show_bug.cgi?id=759043
Some live streams can set the framerate to 50000/1677 (=29.81).
GstVideoInfo.fps_n << 16 is wrong if the fps_n is 50000
(i.e. greater than 32767).
https://bugzilla.gnome.org/show_bug.cgi?id=759043
Identical functionality spread of two different components.
We can't use a common base class because of different inheritance,
but let's try to share the code anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=726024
