Allows use to add API in the future without breaking ABI. We broke the API/ABI
once between 1.2 and 1.4, let's try to avoid this in the future even if this
is an unstable library.
https://bugzilla.gnome.org/show_bug.cgi?id=730914
Fix documentation for GstH264NalUnit. The @ref_idc part was totally
unbalanced. Also add a note about @offset and @size fields to remind
that this is relative to the start of the NAL unit, thus including
the header bytes.
An end_of_seq() [EOSEQ] or end_of_stream() [EOS] NAL unit is really
one byte long because this shall include the NalHeaderBytes (1) too.
The NALU.offset starts from the first byte of the header.
This is the proper fix to commit d37f842. In practice, this fixes
parsing of FRExt1_Panasonic_D and FRExt2_Panasonic_C, that include
additional frames after an EOSEQ.
https://bugzilla.gnome.org/show_bug.cgi?id=732553
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
The gst_h264_parse_pps() function dynamically allocates the slice
group ids map array, so that needs to be cleared before parsing a
new PPS NAL unit again, or when it is no longer needed.
Likewise, a clean copy to the internal NAL parser state needs to be
performed so that to avoid a double-free corruption.
https://bugzilla.gnome.org/show_bug.cgi?id=707282
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
The recovery point SEI message helps a decoder in determining if the
decoding process would produce acceptable pictures for display after
the decoder initiates random access or after the encoder indicates
a broken link in the coded video sequence.
This is not used in the h264parse element, but it could help debugging.
https://bugzilla.gnome.org/show_bug.cgi?id=723380
Add nal_reader_skip_long() helper function to allow an arbitrary number
of bits to be skipped. The former nal_reader_skip() function is too
limited to the actual cache size.
Use this new function to simplify gst_h264_parser_parse_sei_message()
default case, that skips unsupported payloads.
v2: made args consistent from header to source file.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Use the first _gst_reserved[] slot to hold the built-in range decoder
private data. The first slot was formerly the buffer size, which was
then promoted to semi-public namespace when it got integrated as git
commit 2940ac6.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
It was previously a mix and match of both variants, introducing just too much
confusion.
The prefix are from now on:
* GstMpegts for structures and type names (and not GstMpegTs)
* gst_mpegts_ for functions (and not gst_mpeg_ts_)
* GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_)
* GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_)
The rationale for chosing that is:
* the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts)
* the namespace is one word under Gst
* it's shorter (yah)
We cannot do it as the winsys may crash if we initialize too late.
Example, GLX contexts with Intel drivers:
Intel requires the X Display to be the same in order to share GL
resources across GL contexts. These GL contexts are generally
accessed from different threads. Without winsys support it is
nearly impossible to guarentee that concurrent access will not
occur. This concurrent access could result in crashes or abortion
by the winsys (xcb).
https://bugzilla.gnome.org/show_bug.cgi?id=731525
This drops the ugly GstWaylandWindowHandle structure and is much
more elegant because we can now request the display separately
from the window handle. Therefore the window handle can be requested
in render(), i.e. when it is really needed and we can still open
the correct display for getting caps and creating the pool earlier.
This change also separates setting the wl_surface from setting its size.
Applications should do that by calling two functions in sequence:
gst_video_overlay_set_window_handle (overlay, surface);
gst_wayland_video_set_surface_size (overlay, w, h);
This is the initial implementation, without the GstVideoOverlay.expose()
method. It only implements using an external (sub)surface and resizing
it with GstWaylandVideo.
This interface is needed to be able to embed waylandsink into
other wayland surfaces. Due to the special nature of wayland,
GstVideoOverlay is not enough for this job.
Fix routine names for zigzag/raster scan order conversion routines for
quantization matrices. This ought to use the gst_h264_quant_matrix_*()
naming convention instead of gst_h264_video_quant_matrix_*(), which
derived from the MPEG-2 function names.
https://bugzilla.gnome.org/show_bug.cgi?id=731524
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Fix MPEG-4 and VP8 APIs to export their external symbols as pure C
symbols, i.e. un-mangled for C++.
https://bugzilla.gnome.org/show_bug.cgi?id=731522
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
The reshape property was never used.
Replace the draw property with a signal.
Based on patch by Mathieu Duponchelle <mathieu.duponchelle@epitech.eu>
https://bugzilla.gnome.org/show_bug.cgi?id=704507
Fixes a segfault with decodebin ! glmixer where the request pads on
both sides were being requested after the state change to PAUSED.
Also fixes dynamically adding and removing pads while glmixer is
in a state >= PAUSED.
Currently, GstGLWindowWaylandEGL holds the wayland display connection
If we create the EGLDisplay at the GstDisplay creation time, then
libEGL will internally open another connection to the wayland server.
These two display connections are unable to communicate resulting in
no window output/display and hangs inside libEGL.
Eventually we will move the wl_display from GstGLWindow to GstGLDisplay.
Fixes the case where _perform_with_buffer() is called without
intervening calls to _release_buffer() as is the case on start up
with glimagesink.
Also release the buffer when reseting the upload.
https://bugzilla.gnome.org/show_bug.cgi?id=731107
Fixes issues with .so (without numbering) being installed for development
(such as from mesa-dev) but actual driver (with numbering) coming from
some other place (like nvidia drivers)
