Write forward declarations in another way to avoid
repeated typedefs "error: redefinition of typedef".
Raised when using i686-apple-darwin11-llvm-gcc-4.2
It seems that C apple compiler does not support
C11 feature.
https://bugzilla.gnome.org/show_bug.cgi?id=703885
Indeed 'glXMakeCurrent (window_x11->device, None, NULL);'
has to be called in the thread where the glcontext is actually
current.
Otherwise glXDestroyContext may crash.
1) Need to include GL/glext.h on W32 to provide necessary macros
2) W32 macros that pre-processor has by default are different for different
toolchains. Borland uses __WIN32__, everyone else has _WIN32, so check both.
Side-note: glext.h is not supplied by mingw-w64 at the moment, but can be
downloaded from http://www.opengl.org/registry/https://bugzilla.gnome.org/show_bug.cgi?id=703364
We cannot use _finalize as this will be called before GstGLWindow's
_finalize. This causes us to try and perform operations with the
wayland server when the connection has been severed.
The window's loop could be still running when _finalize is called
and if we destroy the display connection it will never be closed.
Add _open and _close vfuncs to GstGLWindow so that subclasses can
start up and shutdown at the right time.
previously, on context creation, when we failed to get a valid context
we would still atempt to run the window mainloop as well as setting an error
on the display. This would cause the calling element to finalize the display
and therefore attempt to quit the window mainloop. However the mainloop
may not have started running. Thus when the window mainloop ran it would
never a get a quit message and never end.
GNUstep has a signal handler for SIGINT which runs in the main thread.
However that thread has never been 'registered' with GNUstep so
the autorelease magic of objective-c causes a segfault from accessing
a null NSThread object somewhere deep in GNUstep.
- Make GstGLWindow subclassablerather than specified at compile time.
- Add GstGLWindowX11 for x11 windows and two subclasses, GstGLWindowX11GLX
and GstGLWindwX11EGL for GLX and EGL repectively. (win32 and cocoa
ports to come)
- Also cleanup GL library detection in configure.ac
rename functions so that other code can create textures in the GL thread
change upload functions to take a GstVideoFrame
default to GLSL for upload conversion
Fix bug #310775
gst-launch audiotestsrc ! libvisual_gl_projectM ! glimagesink is working
but for now you cannot append any other opengl filters between
libvisual_gl_projectM and glimagesink because our FBO is turned OFF.
It would require that libvisual allows to split rendering between
pass1,2,3... and final rendering. In order to unbind our FBO before
the passN, and then rebind it just before the final libvisual rendering.
- cmake could not find glib
- put gtk variables at the beginning to avoid GL conflicts
- update examples to clutter-1.8
- use const instead of deprecated G_CONST_RETURN
- set max pending events to 0 to make cube example works again
Add a new convenience function in GstGLFilter that just draws an input
texture to a target texture using a simple shader with just a "tex"
uniform sampler.
Move draw_texture from glfiltersobel to glfilter. Still need to update
other plugins to this.
Allow to use the opengl context sharing feature if the original
context has been used already.
This is only possible on win32 with wglShareLists because on other
backends, the sharing is made when a context is created.
This new feature is only usefull when using external context
because gst-gl internally makes sure that the orginal context is not
already used when sharing it.
Fix bug #611067
First, inactivate shared gl contexts known by each sink pad.
Then, destroy the gl context known by the glmixer.
Finally, re-activate shared gl contexts.
This is to satisfy the fact that no shared gl context must be current
when an opengl context is destroyed.
Moreover the application may hang or crash without those steps.
Before, the window size was given at its creation. Now, it's done at
the drawing step because it's only relevant when there is a glimagesink
element in the pipeline.
glmixer can be seen as a glfilter except it handles N requested
sink pads.
Each sink pad and the src pad are video/x-raw-gl.
glmixer is responsible for managing different framerates from inputs.
It uses OpenGL context sharing. It means that each input is in its
own OpenGL context shared together and shared with the OpenGL context
of the ouput gl chain.
Also add a glmosaic which is an example of implementation of glmixer.
For now glmosaic is a cube but it will be fixed in the next commits.
For now the glmixer has some weird behaviours in some configurations
but it will be improved in the next commits.
The autotools builds is temporarly broken since those changes
have been made on win32.
Before, a gstgldisplay was instancied by the gl src in terms of gl chain.
And then the next element got it through the first gstglbuffer.
Now, this is done though queries.
All glelements get their ref on a gstgldisplay in READY state.
This rewrite is mainly a first step to be able to share OpenGL context hold
by the gstgldisplay using more complex glelements.
For example, with a glvideomixer. The associated gstgldisplay of each gl chain
of the sink pads will share their OpenGL context.
A texture is not destroyed when when we are done with it.
This texture is just added to the texture pool in order to be
re-used. In this case no OpenGL code is executed so we do not need to
request gl thread.
Add a pkg-config check for opengl and if not found assume opengl-es. If user has
none of both one still get build error later on (there is no pkg-config for
opengl-es).
Add more files to EXTRA dist and build the opengles variant if selected.
Simmilar changes could be done for the winCE backend.
Default implementation of NSOpenglView::update is not safe because it
just calls update on the opengl context whereas we are not in the gl thread.
Also fix the white flickering when resizing, because now we need to call
the draw callback manually when resizing.
- All gstglwindow members are now modified only in the gl thread
to avoid thread concurrency
- OpenGL context is now properly clean
- fix a couple of things in implementation of xoverlay interface
It works with both gst-launch and a cocoa app (non-embedded and embedded)
But there is still some problems:
- sometimes crash when closing
- flickering when resizing
- embedded mode not perfect
I will first make the CMake build work with cocoa backend
in order to generate a XCode project.
Then it should be easier to fix those issues.
Fixes bug #584877
Before this commit calling "gst_x_overlay_set_xwindow_id" more
than one time, had no effect.
It mainly affects the glimagesink implementation.
But on win32 (and CE), some stuff has to be done to
release the old parent.
And add a switchxoverlay example where the user
can click on left/right part of the main window to
switch the xoverlay.
The external opengl context must be specify when creating
our OpenGL context (glx) or just after (wgl).
When calling glXCreateContext or wglShareLists, the
external opengl context must not be current.
Then our gl context can be current in the gl thread while
the external gl context is current in an other thread.
See tests/examples/clutter/cluttershare.c
In OpenGL 2.x for Embedded System, a lot of basic scene/draw functions
have been removed. It means that everything is made using vertex and
fragment shaders.
I have also added a gstglwindow backend for winCE that uses EGL
(Native Platform Graphics Intercace) (which is a full part of
OpenGL ES specification). It remove the use of wgl/glx functions.
Althought the XEvent's xclient.data.l array is an array of
longs they will be constrained to 32 bit by the X11 protocol.
On 64 bit architectures use two elements of the array to store
one pointer.
This fixes segfaults that happen at least for every example
on startup.
This reverts commit 96e4ab18c2cf9876f6c031b9aba6282d0bd45a93.
You should have asked first. And you would have been told "no",
because it causes people on development branches to do a huge
amount of extra work.
Althought the XEvent's xclient.data.l array is an array of
longs they will be constrained to 32 bit by the X11 protocol.
On 64 bit architectures use two elements of the array to store
one pointer.
This fixes segfaults that happen at least for every example
on startup.
Registering GstRTSPMessage as a boxed type allows it to be conveniently
used as an argument to signals, a-la GstSDPMessage, and general usage
from bindings.
https://bugzilla.gnome.org/show_bug.cgi?id=762884
The while loop should end when all buffers "and" the preroll
buffer are consumed but this means to continue waiting if there
are still some pending buffers "or" preroll buffer.
The unit test was correct but racy because of this mistake.
I.e. because of the wrong "and" the while could finish too early.
cd tests/check && GST_CHECKS=test_query_drain make elements/appsink.forever
https://bugzilla.gnome.org/show_bug.cgi?id=789763
There is a race going on somewhere when we attempt to remove elements
*while* the parent container is switching to PLAYING.
In order to avoid this issue with discoverer, make sure we never
remove elements while switching to PLAYING.
This would result in a lot of warnings regarding elements not being
in NULL state when removed, or even leaked elements.
Instead make sure we take the lock and check whether we are processing
or not before allocating or adding anything to the pipeline
The attribute can be defined without value regardless session-level
or media-level.
Although `gst_sdp_message_insert_attribute` can be used to set NULL,
it would be easier if `gst_sdp_message_add_attribute` accepts NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=789841
RTCP XR provides supplements information of the report blocks
from SR and RR. This patch is for downgrading warnings when
XR is detected before implementing entire block types of RFC3611.
https://bugzilla.gnome.org/show_bug.cgi?id=789743
The lock is already taken before calling the flush method and can lead to
deadlock for some encoders that need to take the same lock from another
thread while flushing
https://bugzilla.gnome.org/show_bug.cgi?id=787311
It allows encoders to detect and drop input frames which are already
late to increase the chance of the pipeline to catch up.
The QoS logic and code is directly copied from gstvideodecoder.c.
https://bugzilla.gnome.org/show_bug.cgi?id=582166
Don't reuse the offset variables will contain a sample offset for an
intermediate time value. Instead add a segment_pos variable of type
GstClockTime for this. Use The clock-time macros to check if we got
a valid time.
When an empty mix matrix is passed, audio-channel-mixer
will now generate a (potentially truncated) identity matrix,
this replicates the behaviour of audiomixmatrix in first-channels
mode.
https://bugzilla.gnome.org/show_bug.cgi?id=788833
Properly handle protocol version in the connection
Add the following headers types:
* Pipelined-Request
* Media-Properties
* Seek-Style
* Accept-Ranges
https://bugzilla.gnome.org/show_bug.cgi?id=781446
Acording to the logic this cannot happen (we already check this before). So
add a assert like we do above and remove the check. This make it clearer that
we check for the offset range.
Also remove a dead assignment since we reassign this a few lines below.
This is the same code that is in decklinkaudiosrc, audioringbuffer,
audiomixer and various other places. Have it once instead of copying it
everywhere.
https://bugzilla.gnome.org/show_bug.cgi?id=787560
+ Refactor previous constructor to call on that new constructor
+ Reimplement is_passthrough to strictly check whether the matrix
is an identity matrix, comparing channel-masks was incorrect:
the mixer may be remixing from a list of positions to the same
list of positions, but ordered differently, and reciprocally,
the mixer may be remixing from a list of positions to another
list of positions identically ordered
+ Remove unused tmp field, must have been a refactoring leftover
https://bugzilla.gnome.org/show_bug.cgi?id=785471
If someone calls gst_app_sink_try_pull_sample they are
probably no longer interested in any preroll samples.
Useful if the user has not registered a preroll appsink callback.
Also added unit test 'test_do_not_care_preroll'
make elements/appsink.check
that fails without this patch.
https://bugzilla.gnome.org/show_bug.cgi?id=786740
There is no reason for appsink to hang onto the preroll buffer.
If needed, the application can just keep a ref on this buffer
after calling gst_app_sink_try_pull_preroll.
Also added unit test 'test_pull_preroll'
make elements/appsink.check
https://bugzilla.gnome.org/show_bug.cgi?id=786740
This is used to indicate upstream the requirement in buffers
while no buffer pool can be provided. In this case, only
configure the pool with caps/size/min/max if we have caps,
which we only parsed when there was no allocation pool.
https://bugzilla.gnome.org/show_bug.cgi?id=730758
__gst_video_element_proxy_caps is called by
__gst_video_element_proxy_getcaps with caps set to the caps
allowed downstream. As we didn't set colorimetry or
chroma-site on the resulting caps, upstream considered it
possible to use whatever values it wanted, leading to
not negotiated errors later on.
As the description for that function is:
"Takes caps and copies its video fields to tmpl_caps",
it seems legitimate to set these fields there.
https://bugzilla.gnome.org/show_bug.cgi?id=786172
Only adjusting the base_ts might lead to a negative ts and as such integer
overflow into a huge timestamp which then propagates into the granulepos
and so on. Instead, resync to incoming buffer timestamp using both base_ts
and sample count rather than only base_ts.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=785948
The g-i stuff for this helper lib was never usable from bindings
anyway and there are problems with the latest gobject-introspection,
so we might just as well remove the g-i integration entirely for
this lib.
And monitor no_more_pads.
With live sources such as rtsp, uridecodebin only creates its
child decodebins between PAUSED and PLAYING.
This means that the ASYNC_DONE it posts when getting NO_PREROLL
in its change_state method gets immediately propagated by the
GstBin parent class, as opposed to a situation where a
decodebin has been added to it already, and has posted ASYNC_START.
The proposed solution, instead of simply waiting for ASYNC_DONE,
and finishing prematurely in that case, waits for three conditions
to be true:
* the uridecodebin needs to have emitted no_more_pads
* its current state must be PAUSED if not live, PLAYING otherwise
* There must be no "pending subtitle pads", ie pads where we haven't
received tags yet.
All these conditions are checked in the message handler, as we
post custom messages on it when we get subtitle tags or no_more_pads.
https://bugzilla.gnome.org/show_bug.cgi?id=783257
When the input is TRICKMODE_KEY_UNITS, we expect to only receive keyframes
which we want to decode/push immediately. Therefore don't queue them.
If upstream didn't send just keyframes (which is the ideal situation), two
different things can happen:
1) Either the subclass checks the segment flags and properly configures
the decoder implementation to only decode/output keyframes,
2) Or the subclass really decodes and outputs everything, in which case
the reverse frames will end up arriving "late" downstream (and will
be dropped). If upstream did properly send GOP in reverse order, we
still end up just showing keyframes (but at the overhead of decoding
everything).
https://bugzilla.gnome.org/show_bug.cgi?id=777094
Always put multiview-caps onto the output caps, assuming
mono if we've got no other information. It's still easy for
downstream elements to override using a capssetter or event
probe if desired.
https://bugzilla.gnome.org/show_bug.cgi?id=776172
Child streams could have more accurate width/height or various other
information added. If they have the same name, they are likely to be the
same streams.
https://bugzilla.gnome.org/show_bug.cgi?id=782697
This is now needed as GstClock does not do that internally anymore,
because that broke bindings.
And mark the function correctly as (transfer full), which it already was
before.
https://bugzilla.gnome.org/show_bug.cgi?id=743062
Performing a gst_sdp_media_get_caps_from_media() would result in
changing fields in the GstSDPMedia violating the const tag in the
function declaration.
Before there would be a line with a=rtpmap:96 VP8/90000
after, that attribute would only contain a=rtpmap:96
Fix by performing modifications on duplicated strings instead of on
the internal values.
Also add a simple test for checking that the representation doesn't
change by a gst_sdp_media_get_caps_from_media()
The GSource for dealing with timeouts in
gst_video_convert_sample_async() might be attached to a non-default
context, so we should not be using g_source_remove() on the returned ID.
The correct thing to do is to keep a reference to the actual GSource and
then call g_source_destroy() on it.
https://bugzilla.gnome.org/show_bug.cgi?id=780297
Track how long it takes to generate the first buffer after a flush
as a simple measure of how efficient the decoder is at skipping /
rushing to get to the first decode.
When initializing a timecode from a GDateTime, and the remaining time
until the new second is less than half a frame (according to the given
frame rate), it would lead to the creation of an invalid timecode, e.g.
00:00:00:25 (at 25 fps) instead of 00:00:01:00. Fixed.
https://bugzilla.gnome.org/show_bug.cgi?id=779866
Use G_GUINT64_FORMAT for guint64 values.
Introduced by fcb63e77a9
Found by Alexander Larsson
gstvideodecoder.c: In function 'gst_video_decoder_have_frame':
gstvideodecoder.c:3312:51: error: format '%u' expects argument of type 'unsigned int', but argument 8 has type 'guint64 {aka long long unsigned int}' [-Werror=format=]
Don't guess a timestamp of the start of the segment when running
in reverse mode, as more likely it means we're discontinuous somewhere
in the middle of the segment, and we'll fix up timestamps once
the frames are decoded and reversed.
When a PTS is not set, we still want to store the rest of the
buffer information, or else we lose important things like the
duration or buffer flags when parsing.
This adds a property to select the maximum number of threads to use for
conversion and scaling. During processing, each plane is split into
an equal number of consecutive lines that are then processed by each
thread.
During tests, this gave up to 1.8x speedup with 2 threads and up to 3.2x
speedup with 4 threads when converting e.g. 1080p to 4k in v210.
https://bugzilla.gnome.org/show_bug.cgi?id=778974
In gst_video_time_code_is_valid, also check for invalid
ranges when using drop-frame TC. Refactor some code which
broke after the check was added.
https://bugzilla.gnome.org/show_bug.cgi?id=779010
It was taking the initial input y-offset from the output value, which
only works for y=0 (in which case both are the same). If y > 0, we would
always stay behind the requested input offset and never ever read
anything from the input.
The parser might do some conversion on a stream but the stream keeps
being the same, and we need to make sure GstDiscoverer detects it is the
case.
https://bugzilla.gnome.org/show_bug.cgi?id=778298
There was already a check for that, but it failed because
subformat_guid[0] is a guint32 and that is then casted implicitely to a
guint16 when recursing... just that we checked the uncasted value.
This caused an infinite recursion and thus stack overflow.
https://bugzilla.gnome.org/show_bug.cgi?id=777265
Sometimes there is a human-oriented timecode that represents an
interval between two other timecodes. It corresponds to the human
perception of "add X hours" or "add X seconds" to a specific timecode,
taking drop-frame oddities into account. This interval-representing
timecode is now a GstVideoTimeCodeInterval. Also added function to add it to
a GstVideoTimeCode.
https://bugzilla.gnome.org/show_bug.cgi?id=776447
It is often usefull to make sure that you get a full copy of a profile.
For example you want to let the user modify it in the user interface
but still keep an unchanged version for later use.
API:
gst_encoding_profile_copy
Initialize min and max _get_property() to gets rid of these
compiler warnings:
gstappsrc.c:741:7: error: 'max' may be used uninitialized in this function
g_value_set_int64 (value, max);
^
gstappsrc.c:733:7: error: 'min' may be used uninitialized in this function
g_value_set_int64 (value, min);
^
Which happens because gcc doesn't know that GST_IS_APP_SRC will never
fail here.
https://bugzilla.gnome.org/show_bug.cgi?id=752052
This way special characters such as '@' can be used in
usernames or passwords, e.g.
rtsp://view:%40dm%4An@<IP-ADDR>/media/camera1
will now parse username and password into:
User: view
Pass: @dm:n
https://bugzilla.gnome.org/show_bug.cgi?id=758389
When parsing NUL-terminated strings, do not include the terminating
NUL byte(s). Depending on the encoding used, either g_utf8_validate()
failed due to this, or worse the call to g_utf16_to_utf8() would
return 0 items read on an empty string, causing it to fail parsing
certain frames.
https://bugzilla.gnome.org/show_bug.cgi?id=770355
encoding-profile.c: In function ‘get_profile_format_from_possible_factory_name’:
encoding-profile.c:1532:6: error: ‘fact’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (fact)
^
encoding-profile.c: In function ‘profile_from_string’:
encoding-profile.c:1720:6: error: ‘res’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (profile)
^
cc1: all warnings being treated as errors
Instead of enforcing the user to know and understand caps to describe
the encoding format, let him use element factory names directly.
This also makes it possible to ensure that a specific encodore/muxer
is used instead of letting the ranking system do it.
It is now possible to describe an encoding format simply specifying:
matroskamux:x264enc:vobisenc
Factor out functions in the parsing, cleaning up the whole thing.
Update documentation.
We used to only care about the name of the files even if the name
is defined in the encoding target serialized file.
That commit also allows user to define several names for a single
target file (using a ';' between the names) which allows us to have
a target for youtube that is called 'youtube;yt' or a target for
'ogg;ogv;oga' file extension.
We checked this already earlier, so this is dead code.
Leave an assert in place for consistency with the other
branch and in case the rest of the code changes.
CID 1397350.
The caps put into the stream topology by decodebin are the caps at the
moment the pads are exposed on it. This is usually before decoders
received any buffers.
In discoverer we however wait for pre-roll, which ensures that each
decoder handled buffers already. At this point, there might be more
information known about the caps already that we could make use of.
One example here is extra information stored in the SEI of H264, like
the multiview-mode. This will be known if there is a SEI before the
first keyframe, but decodebin won't put this into the topology as it
only waits for the initial caps of h264parse (which come directly after
SPS/PPS).
With this change, the multiview-mode is in the caps reported by
discoverer in many cases.
To make the structs usable in bindings, and fix
gstrtspmessage.c:1188: Warning: GstRtsp:
gst_rtsp_message_parse_auth_credentials: return value: Invalid
non-constant return of bare structure or union; register as
boxed type or (skip)
https://bugzilla.gnome.org/show_bug.cgi?id=774416
Pass the frame data and size explicitly to
id3v2_add_id3v2_frame_blob_to_taglist() and add a
comment that it's being deliberately / manually
passed the full ID3v2 frame including header.
Ensure that nothing is in any of the streaming thread functions
anymore when going from PAUSED to READY. While the parent's state change
function has deactivated all pads, there is nothing preventing
downstream from activating our srcpad again and calling the getrange()
function. Although we're in READY!
https://bugzilla.gnome.org/show_bug.cgi?id=775687
The flags and field order weren't properly initialized in the
gst_video_info_init().
Furthermore in gst_video_info_from_caps() we might set unitiliazed
values previously, this only sets them if valid.
Optimize LE<->BE conversion by adding a dedicated fast path instead of
using the generic converter. Implement transform_ip function in order to do the
endian swap in place.
This saves buffer allocation for the intermediate format, can be done in place
and also performs the conversion in one step instead of unpack-convert-pack.
For all bit widths the naive algorithm is implemented, which provides the best
performance when compiled with -O3. ORC was considered but eventually removed
as it requires a dedicated function for in-place conversion (due to the
"restrict" parameters).
A more complex algorithm for the 24-bit conversion with unrolled loop and
32-bit processing is implemented in the #if 0 section. It performs better if
compiled with -O2. With -O3 however the naive algorithm performs better.
https://bugzilla.gnome.org/show_bug.cgi?id=773073
It is not needed to store a pointer to every single chain element to free it.
Instead walk the channel list backwards and free the chain elements one by one.
Rename GstAudioConverter->chain_pack to chain_end.
https://bugzilla.gnome.org/show_bug.cgi?id=773073
The caps might not be fixated (which is required by GstVideoInfo) and we
would assert otherwise. However the caps often contain useful
information in the already-fixed parts that we can use here.
When gst_rtp_buffer_add_extension_onebyte_header() is used over a
GstRtpBuffer that only contains a memory for the whole packet,
ensure_buffers function crashes at the next point:
mem = gst_memory_copy (rtp->map[i].memory, offset, rtp->size[i]);
when i==2 because the payload is not mapped.
In addition the offset is calculated subtracting in the wrong direction.
https://bugzilla.gnome.org/show_bug.cgi?id=774959
For example mmap can fail with EACCES if the the fd has been open
with read only mode. And mapping the memory might be the only way
to check that. So no need to print out an error.
Ex: ioctl(dev, DRM_IOCTL_PRIME_HANDLE_TO_FD, flags & ~DRM_RDWR)
https://bugzilla.gnome.org/show_bug.cgi?id=765600
This class was made subclassable, though for future growth of the code,
it's better if we have some room for add class members. Using the small
padding since this is unlikely.
For drop-frame timecodes, the nsec_since_daily_jam doesn't necessarily
directly correspond to this many hours/minutes/seconds/frames. We have
to get the frame count as per frames_since_daily_jam and then convert.
https://bugzilla.gnome.org/show_bug.cgi?id=774585
Rename function parameter and make sure the name in the
declaration matches the name in the implementation, to
avoid g-i warnings. Also add Since markers for gtk-doc.
gstappsink.c:1248: Warning: GstApp: gst_app_sink_set_buffer_list_support:
unknown parameter 'buffer_list' in documentation comment, should be 'drop'
Refuse to answer BYTES queries ourselves. The only
time they make sense is on raw elementary streams,
in which case upstream would already have answered.
https://bugzilla.gnome.org/show_bug.cgi?id=757631
Refuse to answer BYTES queries ourselves. The only
time they make sense is on raw elementary streams,
in which case upstream would already have answered.
They especially don't make sense for encoders to answer
based on upstream values - although perhaps later
we could make it do TIME->BYTES conversion on the source
pad based on bitrate.
https://bugzilla.gnome.org/show_bug.cgi?id=757631
It is actually needed as we need some symbols. We do not link
to libgstsdp as the user of the lib should do it (same with
autotools build).
This reverts previous commit
gst_audio_buffer_reorder_channels() was always mapping the buffer read-write
regardless whether any reordering was needed. If the from and to channel order
is identical return immediately without remapping the buffer.
Add a small helper function gst_audio_channel_positions_equal() which is used
in both gst_audio_reorder_channels() and gst_audio_buffer_reorder_channels().
https://bugzilla.gnome.org/show_bug.cgi?id=773833
It adds a third argument to pass GstBufferPoolAcquireParams
to gst_buffer_pool_acquire_buffer.
If a user subclasses GstBufferPoolAcquireParams, this allows to
pass an updated param to the underlying buffer pool at each
gst_video_decoder_allocate_output_frame_with_params call.
https://bugzilla.gnome.org/show_bug.cgi?id=773165
Adds "memory:DMABuf" caps feature. Since 1.11 tag.
Useful when the the dma-buf buffer cannot be mapped to CPU for r/w requests.
Example: protected content or platform constraints.
https://bugzilla.gnome.org/show_bug.cgi?id=759358
Usually this information is static for the whole stream, and various
container formats store this information inside the headers for the
whole stream.
Having it inside the caps for these cases simplifies code and makes it
possible to express these requirements more explicitly with the caps.
https://bugzilla.gnome.org/show_bug.cgi?id=771376
All the GstAudioClock method declarations required object of GstClock type
as a first argument, but in fact, required GstAudioClock object (runtime
check in function body). Instead of checking type in run-time, we can
change functions declaration, to accept only GstAudioClock methods. Then,
runtime check is not necessary anymore, since always GstAudioClock object
is passed to a function.
https://bugzilla.gnome.org/show_bug.cgi?id=756628
Also the format must be fixed on the default raw caps. If not
gst_video_info_from_caps() will fail and
gst_video_decoder_negotiate_default_caps() return FALSE.
The test simulates the use case where a gap event is received before
the first buffer causing the decoder to fall back to the default caps.
https://bugzilla.gnome.org/show_bug.cgi?id=773103
Seen on the Jenkins CI:
FAILED: subprojects/gst-plugins-base/gst-libs/gst/audio/audio_resampler_sse41@sta/audio-resampler-x86-sse41.c.o
ccache cc '-Isubprojects/gst-plugins-base/gst-libs/gst/audio/audio_resampler_sse41@sta' '-fdiagnostics-color=always' '-I../subprojects/gst-plugins-base/gst-libs/gst/audio' '-Isubprojects/gst-plugins-base/gst-libs/gst/audio' '-Isubprojects/gst-plugins-base/.' '-I../subprojects/gst-plugins-base/.' '-Isubprojects/gst-plugins-base/gst-libs' '-I../subprojects/gst-plugins-base/gst-libs' '-Isubprojects/gstreamer/libs' '-I../subprojects/gstreamer/libs' '-Isubprojects/gstreamer/.' '-I../subprojects/gstreamer/.' '-pipe' '-Wall' '-Winvalid-pch' '-DHAVE_CONFIG_H' '-msse4.1' '-fPIC' '-O0' '-g' '-fPIC' '-I/usr/include/glib-2.0' '-I/usr/lib/glib-2.0/include' '-pthread' '-Isubprojects/gstreamer/gst' '-MMD' '-MQ' 'subprojects/gst-plugins-base/gst-libs/gst/audio/audio_resampler_sse41@sta/audio-resampler-x86-sse41.c.o' '-MF' 'subprojects/gst-plugins-base/gst-libs/gst/audio/audio_resampler_sse41@sta/audio-resampler-x86-sse41.c.o.d' -o 'subprojects/gst-plugins-base/gst-libs/gst/audio/audio_resampler_sse41@sta/audio-resampler-x86-sse41.c.o' -c ../subprojects/gst-plugins-base/gst-libs/gst/audio/audio-resampler-x86-sse41.c
In file included from ../subprojects/gst-plugins-base/gst-libs/gst/audio/audio-resampler.h:24:0,
from ../subprojects/gst-plugins-base/gst-libs/gst/audio/audio-resampler-private.h:23,
from ../subprojects/gst-plugins-base/gst-libs/gst/audio/audio-resampler-macros.h:25,
from ../subprojects/gst-plugins-base/gst-libs/gst/audio/audio-resampler-x86-sse41.h:23,
from ../subprojects/gst-plugins-base/gst-libs/gst/audio/audio-resampler-x86-sse41.c:24:
../subprojects/gst-plugins-base/gst-libs/gst/audio/audio.h:26:39: fatal error: gst/audio/audio-enumtypes.h: No such file or directory
#include <gst/audio/audio-enumtypes.h>
^
compilation terminated.
Workaround source_root being the root directory of all projects
in the subproject case.
Remove now unneeded getpluginsdir and define c++ tests in the same loop.
Bump meson requirement to 0.35
This makes sure that we only build files that need explicit SIMD support
with the relevant CFLAGS. This allows the rest of the code to be built
without, and specific SSE* code is only called after runtime checks for
CPU features.
https://bugzilla.gnome.org/show_bug.cgi?id=729276
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
They are false positive overflows, because coverity doesn't realize that
hours <= 24, minutes < 60 and seconds < 60 in all functions. Also casting the
number 60 (seconds in minute, minutes in hour) to guint64 for the
calculations, in order to avoid overflowing once we allow more than 24-hour
timecodes.
CIDs #1371459, #1371458
_stdint.h is generated by Autotools and we don't really need it.
stdint.h is now available on all supported platforms.
This really only makes a difference for MSVC, which has it starting from
Visual Studio 2015.
Add GST_FD_MEMORY_FLAG_DONT_CLOSE to avoid closing the fd when the
memory is freed. When you can guarantee the lifetime of the fd is
longer than the memory, this can save a dup() call.
Most of them are overflow related and false positives, but coverity can't know
that these can't overflow without us giving it more information. Add some
assertions for this.
One was an actual issue with flags comparison.
CIDs #1369051, #1369050, #1369049, #1369048, #1369045
WAV is too generic to impose more-or-less arbitrary boundaries on the
sample rate and channel count caps. For example, there are 384 kHz WAV
files. Another example: it is in theory possible that somebody puts DSD
data into a WAV file, which will then have a sample rate of ~2.8 MHz.
For this reason, get rid of the rate and channel caps unless they are
fixed values. Downstream anyway usually knows the limitations better.
https://bugzilla.gnome.org/show_bug.cgi?id=761514
gst_rtp_buffer_add_extension_onebyte_header() and
gst_rtp_buffer_add_extension_twobytes_header() can have a const argument for
the actual extension data.
The _pull_sample() and _pull_preroll() functions block
until a sample is available, EOS happens or the pipeline
is shut down (returning NULL in the last two cases).
This adds _try_pull_sample() and _try_pull_preroll()
functions with a timeout argument to specify the maximum
amount of time to wait for a new sample.
To avoid code duplication, wait forever if the timeout is
GST_CLOCK_TIME_NONE and use that to implement
_pull_sample/_pull_preroll with the original behavior.
Add also corresponding action signals "try-pull-sample"
and "try-pull-preroll".
https://bugzilla.gnome.org/show_bug.cgi?id=768852
Remove unnecessary helper struct for callbacks. The bclass
member of the helper struct was not used, so we can just
remove it and the GET_CLASS() call and simplify the whole
affair by passing the depayloader directly to the callback.
parsed, framed, stream-format and alignment are only relevant for parsers and
should not matter here. We still want to be able to use an encoder that can
only output byte-stream if the input was avc.
https://bugzilla.gnome.org/show_bug.cgi?id=768566
Caps are cleaned up for missing plugins, and for creating encoding profiles
and caps descriptions.
Fields like streamheader, parsed, framed, stream-format and alignment are not
relevant here. The last ones all because a parser will take care of them.
https://bugzilla.gnome.org/show_bug.cgi?id=768566
We need to take into account the input segment flags to know whether
we should drain the decoder after a new keyframe in trick mode.
Otherwise we would have to wait for the next frame to be outputted (and
the segment to be activated) which ... well ... kind of beats the whole
point of this draining :)
And especially don't use the stream lock for that, as otherwise non-serialized
queries (CONVERT) will cause the stream lock to be taken and easily causes the
application to deadlock.
https://bugzilla.gnome.org/show_bug.cgi?id=768361
By default we'll wait for a certain amount of data before
attempting typefinding. However, if the stream is fairly
short, we might get EOS before we ever attempted any
typefinding, so at this point we should force typefinding
and output any pending data if we manage to detect the
type.
https://bugzilla.gnome.org//show_bug.cgi?id=768178
In 0.10 the source pad was a dynamic pad that was only added once
the type had been detected, but in 1.x it's an always source pad,
so checking whether it's still NULL won't work to detect if the
type has been detected.
Makes tagdemux error out when we get EOS but haven't managed to
identify the format of the data after the tag.
https://bugzilla.gnome.org//show_bug.cgi?id=768178
Fix problem with the line cache where it would forget the first line in
the cache in some cases.
Keep as much backlog as we have taps. This generally works better and we
could do even better by calculating the overlap in all taps.
Allocated enough lines for the line cache.
Use only half the number of taps for the interlaced lines because we
only have half the number of lines.
The pixel shift should be relative to the new output pixel size so scale
it.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=767921
gst_buffer_copy_region() does not copy the duration if it doesn't start
with the first byte. We just skip the tag here, so the duration is still
valid.
https://bugzilla.gnome.org/show_bug.cgi?id=767791
Elements inherited from GstAudioDecoder, supporting PLC and introducing
delay produce invalid timestamps. Good example is opusdec with in-band FEC
enabled. After receiving GAP event it delays the audio concealment until
the next buffer arrives. The next buffer will have DISCONT flag set which
will make GstAudioDecoder to reset it's internal state, thus forgetting
the timestamp of GAP event. As a result the concealed audio will have the
timestamp of the next buffer (with DISCONT flag) but not the timestamp
from the event.
The serialization of double typed geographical
coordinates to DMS system supported by the exif
standards was previously truncated without need.
The previous code truncated the seconds part of
the coordinate to a fraction with denominator
equal to 1 causing a bug on the deserialization
when the test for the coordinate to be serialized
was more precise.
This patch applies a 10E6 multiplier to the numerator
equal to the denominator of the rational number.
Eg. Latitude = 89.5688643 Serialization
DMS Old code = 89/1 deg, 34/1 min, 7/1 sec
DMS New code = 89/1 deg, 34/1 min, 79114800UL/10000000UL
Deserialization
DMS Old code = 89.5686111111
DMS New code = 89.5688643
The new test tries to serialize a higher precision
coordinate.
The types of the coordinates are also guint32 instead
of gint like previously. guint32 is the type of the
fraction components in the exif.
https://bugzilla.gnome.org/show_bug.cgi?id=767537
For reverse playback it is important to handle correctly the frame sync
points, which is set when the input buffer doesn't have the DELTA_UNIT flag.
This is handled correctly when decoder is packetized, but when it is not the
frame's sync point is not copied, and the reverse playback never decodes frame
batches.
The current patch adds the buffer's flags to the Timestamp list, where the
timestamp and duration of the input buffers are hold.
There were two consecutive log messages in gst_video_decoder_decode_frame().
Given the information they provide, it is more efficient to squash them into a
single one.
The playback rate is hold in the input_segment member variable, not in the
output_segment, and the parse_gather list was never filled because of that.
This patch changes the comparison with input_segment.
The output segment is only set up after data is output, which might be far in
the future for reverse playback. Also we are here interested in the state at
the current *input* frame (which is the keyframe), not any possible output.
For reverse playback the same behaviour was already implemented in
flush_parse().
For reverse playback, chain_forward() is only used to gather frames and not
for decoding, and it is actually called by the draining logic, causing an
infinite recursion.
While it's a bit tricky to discard frames *before* decoding (because
we might not be sure which data is needed or not by the decoder), we
can discard them after decoding if they are too late anyway.
Any following basetransform based element or similar would drop the frame too.
When asked to just decode keyframe, if we got a keyframe drain out
the decoder straight away.
This avoids having to wait for the next frame and reduces delay even
more.
https://bugzilla.gnome.org/show_bug.cgi?id=767232
This ensures the decoder is properly drained out when receiving a
DISCONT buffer. The optimal way of doing this would have been to
receive a GAP event before hand but it is not always possible.
Fixes big delays with some decoders (ex gst-libav) that will not
drain out data when only decoding keyframes.
https://bugzilla.gnome.org/show_bug.cgi?id=767232
gst_buffer_copy_region() does not copy the timestamp if it doesn't start
with the first byte. We just skip the tag here, so the timestamp is still
valid.
https://bugzilla.gnome.org/show_bug.cgi?id=767173
The base class was setting the DISCONT flag before checking whether the buffer
would be in segment or not.
Fix issues with DISCONT flags not being properly propagated downstream when
decoders buffers were out of segment.
https://bugzilla.gnome.org/show_bug.cgi?id=766800
gst_video_sink_center_rect() can be called without a GstVideoSink
having been instantiated so we can't relly on the video sink
class_init function to init the category.
Fix a warning when running:
GST_CHECKS=test_video_center_rect GST_DEBUG=6 G_DEBUG=fatal_warnings make libs/video.check-norepeat
https://bugzilla.gnome.org/show_bug.cgi?id=766510
If we e.g. have AVI with DV container with video/audio inside the DV
container, we can't handle this at this point with an encoding profile.
Instead of erroring out, flatten the container hierarchy.
https://bugzilla.gnome.org/show_bug.cgi?id=765708
This tag match the EXIF_TAG_FOCAL_LENGTH_IN_35_MM_FILM exif tag and is
stored on a short. Hence there is a precision loss compared to the
GstTag which is a double value.
https://bugzilla.gnome.org/show_bug.cgi?id=753930
It is the 35 mm equivalent focal length of the lens, mainly used in
photography. Tag value is stored in a double value to be consistent with
GST_TAG_CAPTURING_FOCAL_LENGTH.
https://bugzilla.gnome.org/show_bug.cgi?id=753930
When converting discoverer output to an encoding profile, it makes sense to
omit these. It's very very unlikely that our encoder is going to produce bit
by bit the same codec_data or streamheader.
https://bugzilla.gnome.org/show_bug.cgi?id=765534
We add a couple of new functions gst_sdp_media_parse_keymgmt and
gst_sdp_media_parse_keymgmt. We also implement
gst_sdp_message_attributes_to_caps and gst_sdp_media_attributes_to_caps
in terms of these new functions and also gst_mikey_message_to_caps.
Current implementation requires all srtp and srtcp parameters to be
given in the caps. MIKEY uses only one algorithm for encryption and one
for authentication so we now allow passing srtp or srtcp parameters. If
both are given srtp parametres will be preferred.
https://bugzilla.gnome.org/show_bug.cgi?id=765027
As said in its doc GST_AUDIO_CHANNEL_POSITION_NONE is meant to be used
for "position-less channels, e.g. from a sound card that records 1024
channels; mutually exclusive with any other channel position".
But at the moment using such positions would raise a
'g_return_if_reached' warning as gst_audio_get_channel_reorder_map()
would reject it.
Fix this by preventing any attempt to reorder in such case as that's not
what we want anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=763799
We currently don't log much about channel positions making debugging
harder as it should be. This is the first step in my attempt to improve
this.
https://bugzilla.gnome.org/show_bug.cgi?id=763985
There is a small window of time where the audio ringbuffer thread
can access the parent thread variable, before it's initialized
by the parent thread. The patch replaces this variable use by
g_thread_self().
https://bugzilla.gnome.org/show_bug.cgi?id=764865
Since the allocation query caps contains memory size and the pad's caps
contains the display size, an audio encoder or decoder might need to allocate
a different buffer size than the size negotiated in the caps.
This patch splits this logic distinction for audiodecoder and audioencoder.
Thus the user, if needs a different allocation caps, should set it through
gst_audio_{encoder,decoder}_set_allocation_cap() before calling the negotiate()
vmethod. Otherwise the allocation_caps will be the same as the caps in the
src pad.
https://bugzilla.gnome.org/show_bug.cgi?id=764421
Since the allocation query caps contains memory size and the pad's caps
contains the display size, a video encoder or decoder might need to allocate
a different frame size than the size negotiated in the caps.
This patch splits this logic distinction for videodecoder and videoencoder.
The user if needs a different allocation caps, should set the allocation_caps
in the GstVideoCodecState before calling negotiate() vmethod. Otherwise the
allocation_caps will be the same as the caps set in the src pad.
https://bugzilla.gnome.org/show_bug.cgi?id=764421
Doing so prevents us dropping buffers in the rare, but possible, situations,
when the stream changes SSRC and new sequence numbers does not differ
much from the last sequence number from previous SSRC. For example:
ssrc - 0xaaaa 101,102,103,104 ssrc - 0xbbbb 102, 103, 104, 105...
In the scenario above we don't want to drop the first 3 packets of
0xbbbb stream.
https://bugzilla.gnome.org/show_bug.cgi?id=764459
The function gst_discoverer_info_copy doesn't copy the data members seekable
and result of the source GstDiscovererInfo.
In the case of copying a GstDiscovererInfo for later use, the seekbale will be
undefined, which in practice usually will be false, even though the seekable of
the original GstDiscovererInfo is true.
https://bugzilla.gnome.org/show_bug.cgi?id=762710
The parameter type was wrongly documenting that a GstVideoInfo structure
pointer was needed, while it needs a GstVideoFormatInfo structure
pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=764414
P010 is a YUV420 format with an interleaved U-V plane and 2-bytes per
component with the the color value stored in the 10 most significant
bits.
https://bugzilla.gnome.org/show_bug.cgi?id=761607
---
Changes since v2:
- Set bits=16 in DPTH10_10_10_HI
Changes since v1:
- Fixed x-offset calculation in uv.
- Added 6-bit shifts to FormatInfo.
Store the filter in the desired sample format so that we can simply do a
linear or cubic interpolation to get the new filter instead of having to
go through gdouble and then convert.
Remove some unused variables from the inner product functions.
Make filter coefficients by interpolating if required.
Rename some fields.
Try hard to not recalculate filters when just chaging the rate.
Add more proprties to audioresample.
Rearrange the oversampled taps in memory to make it easier to use
SIMD instructions on them. this simplifies some sse code.
Add some more optimizations
Improve int16 resampling by using pmaddwd
Use intrinsics to scale and pack int16 samples
Align the coefficients so that we can use aligned loads
Add padding to taps and samples so that we don't have to use partial
loads for the remainder of the loops.
Remove copy_n, we can reuse the plain copy function with some new
parameters.
Align and pad the sample array.
Remove the consumed/produced output fields from the resampler and
converter. Let the caler specify the right number of input/output
samples so we can be more optimal.
Use just one function to update the converter configuration.
Simplify some things internally.
Make it possible to use writable input as temp space in audioconvert.
Base class type name should not reference libvisual since not all child
elements use this. This was an oversight when merging audiovisualizers into
a common base class.
libgstreamer currently exports some debug category
symbols GST_CAT_*, but those are not declared in any
public headers.
Some plugins and libgstvideo just use GST_DEBUG_CATEGORY_EXTERN()
to declare and use those, but that's just not right at
all, and it won't work on Windows with MSVC. Instead look
up the categories via the API.
If we don't have writable memory, make sure to make a copy of the input
samples into a temporary (writable) buffer, even if we are dealing with
a native intermediate format that we don't need to call the unpack
function for.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=761655
gst_pad_get_allowed_caps() will return NULL if the srcpad has no peer.
In that case, use gst_pad_peer_query_caps() with template caps as filter
to have negotiated output caps properly before forwarding GAP event.
https://bugzilla.gnome.org/show_bug.cgi?id=761218
Add missing ':' to tile_ws and tile_hs fields documentation to avoid
bad render of these two fields, mark reserved bytes as private to hide
field and avoid gtkdoc warning and add parameters description to
documented macro to avoid gtkdoc warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=761132
It's useful enough already to be used in other elements for audio aggregation,
let's give people the opportunity to use it and give it some API testing.
https://bugzilla.gnome.org/show_bug.cgi?id=760733
In gst_video_info_to_caps(), make sure we end up with an RGB matrix for
RGB formats and warn when the GstVideoInfo colorimetry is wrong.
In gst_video_info_from_caps(), fix the GstVideoInfo with an RGB matrix
for RGB formats and warn about inconsistent caps.
See https://bugzilla.gnome.org/show_bug.cgi?id=759624
For RGB formats, the matrix in the colorimetry (conversion from YUV to
RGB) is irrelevant and we should ignore it and assume the identity
transform for everything we do.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=759624
It's quite unexpected behaviour that various subclass settings are just
reset before set_format(). Unfortunately changing this now has the risk
of breaking existing code but we should reconsider this for 2.0.
When the input and output formats are the same and in a possible
intermediate format, avoid unpack and pack.
Never do passthrough channel mixing.
Only do dithering and noise shaping in S32 format
Add support for float and int16 mixing
Remove in-place processing, this simplifies things as we won't be using it.
Don't do clipping for float audio formats
Process as many samples as we can from the input and return the number
of processed samples from the chain. This simplifies some code.
Fix the IN_WRITABLE handling, don't overwrite the flags.
Pass flags in _converter_new() so that we can configure ourselves
differently depending on some options.
SOURCE_WRITABLE -> IN_WRITABLE because the array is called 'in'
Simplify the API, we don't need the consumed and produced output
arguments. The caller needs to use the _get_in_frames/get_out_frames API
to check how much input is needed and how much output will be produced.
When we run the loop for another time and do not have a preset name, we would
try to print the preset name of a previous iteration that is already freed.
Also move some other variables into the block where they are actually used
to prevent similar mistakes in the future.
CID 1346536
We did not take the sample size into account. Rearrange the tests to have more
conversion test and an extra test case for passthrough operations.
Fixes#759890
Rename samples to num_samples, since we also have samples in chain, but that is
the data pointer. Always use gzize for num_samples. Make the log output a bit
more homogenous.
The EOS event can be propagated to the downstream elements when
is_eos flag remains set even after leaving the flushing state.
This fix allows this element to normally restart the streaming
after receiving the flush event by clearing the is_eos flag.
https://bugzilla.gnome.org/show_bug.cgi?id=759110
Rework the main processing loop. We now create an audio processing
chain from small core functions. This is very similar to how the
video-converter core works and allows us to statically calculate an
optimal allocation strategy for all possible combinations of operations.
Make sure we support non-interleaved data everywhere.
Add functions to calculate in and out frames and latency.
Match the section 5.1.2 of the HTTP/1.0 spec by using relative URIs unless we
are using a proxy server. Also, send Host header for compatability with
HTTP/1.1 and some HTTP/1.0 servers.
https://bugzilla.gnome.org/show_bug.cgi?id=758922
gst_rtsp_connection_connect_with_response accepts a response pointer
which it fills with the response from setup_tunneling if the
connection is configured to be tunneled. The motivation for this is to
allow the caller to inspect the response header to determine if
additional authentication is required so that the connection can be
retried with the appropriate authentication headers.
The function prototype of gst_rtsp_connection_connect has been
preserved for compatability with existing code and wraps
gst_rtsp_connection_connect_with_response.
https://bugzilla.gnome.org/show_bug.cgi?id=749596
Depayloaders will look at rtpbuffer->buffer for the discont flag.
When we set the discont flag on a buffer in the rtp base depayloader
and we have to make the buffer writable, make sure the rtpbuffer
actually contains the newly-flagged buffer, not the original input
buffer. This was introduced with the addition of the process_rtp_packet
vfunc, but would only trigger if the input buffer wasn't flagged
already and was not writable already.
When we detect a discont and the input buffer isn't already flagged
as discont, handle_buffer() does a gst_buffer_make_writable() on the
input buffer in order to set the flag. This assumed it had ownership
of the input buffer though, which it didn't. This would still work
fine in most scenarios, but could lead to crashes or mini object
unref criticals in some cases when a discont is detected, e.g. when
using pcapparse in front of a depayloader. This problem was
introduced in bc14cdf529.
In the case where the stream doesn't have a framerate set and the frames
don't have a duration set, we still want to use the clipping path to
make sure we don't push buffers outside of the segment.
The problem was the previous iteration was setting a duration of 2s, which
meant that any buffer which was less than 2s before the segment start would
end up getting pushed.
Instead, use a saner 40ms (25fps single frame duration) to figure out whether
the frame could be within the segment or not
Some servers incorrectly parse header names with strict case-sensitivity. For
compatibility with these systems change X-Sessioncookie to x-sessioncookie.
https://bugzilla.gnome.org/show_bug.cgi?id=758921
Any latency query before this will not get the correct latency so a new
latency query should be triggered once the audio sink know its own latency.
Without this the initial latency query from the pipeline arrives too early
sometimes and the resulting latency is too short.
https://bugzilla.gnome.org/show_bug.cgi?id=758911
Some Opus files found on the wild have 0 in the version field of the
OpusHead header, instead of the correct value of 1. The files still
play, don't make this error fatal.
https://bugzilla.gnome.org/show_bug.cgi?id=758754
Commit ff6d1a2a25 changed sample's type from
gint to gsize (and renamed it to in_samples). gsize is an unsigned long,
which means it can never be a negative value and the check making sure that
in_samples is >= 0 is never going to be false. Removing it.
CID 1338689
Move the audio quantize code from audioconvert to the audio library.
work on making an audio converter helper function similar to the video
converter.
Fold fastrandom directly into the quantizer, add some ORC code to
optimize this later.
Rename _get_default_mask() to _get_fallback_mask() to make it more
clear that the function only provides a fallback if nothing else can be
done. Also clarify this in the documentation.
API: gst_audio_channel_get_fallback_mask()
Add a TRUNCATE_RANGE flag for unpack functions to fill the least
significate bits with 0 (as did the old code). Also add functions
that don't truncate. Use the TRUNC flag in audioconvert for
backwards compatibility for now.
No need to use G_GINT64_FORMAT for potentially negative values of
GstClockTimeDiff. Since 1.6 these can be handled with GST_STIME_ARGS.
Plus it creates more readable values in the logs.
https://bugzilla.gnome.org/show_bug.cgi?id=757480
If the flush-start is arrived during _eos_wait() in basesink,
the 'eos' flag is overwritten to TRUE after exiting the _eos_wait().
To resolve the overwritten issue,
the subclass doing the _eos_wait() call should return the right value.
If the eos flag is set to TRUE again, it will cause error(enter the eos flow)
of the following state changing from PAUSED to PLAYING in basesink.
https://bugzilla.gnome.org/show_bug.cgi?id=754980
Encrypted RTP buffers may contain encrypted padding, hence it's
necessary to have an option to relax the validation in order to
successfully map the buffer.
When the flag GST_RTP_BUFFER_MAP_FLAG_SKIP_PADDING is set
gst_rtp_buffer_map() will map the buffer like if padding is not
present.
https://bugzilla.gnome.org/show_bug.cgi?id=752705
When g_option_context_parse fails, context and error variables are not getting free'd
which results in memory leaks. Free'ing the same.
And replacing g_error_free with g_clear_error, which checks if the error being passed
is not NULL and sets the variable to NULL on free'ing.
https://bugzilla.gnome.org/show_bug.cgi?id=753852
gir include search directories should respect PKG_CONFIG_PATH,
just like we do everywhere else. Makes g-i pick up the right
paths when using ./configure --with-pkg-config-path=
https://bugzilla.gnome.org/show_bug.cgi?id=755494
v210, UYVP and IYU1 are complex formats for which pixel stride does not really
have a meaning. If we copy width*pstride bytes per line, it's not going to do
the right thing. As a fallback, copy stride bytes per line. This might copy
uninitialized bytes at the end of each line, but at least copies the frame.
https://bugzilla.gnome.org/show_bug.cgi?id=755392
Otherwise the application might push new buffers into the queue while we're
flushing, potentially causing the GQueue data structure to become inconsistent
and causing crashes soon after.
https://bugzilla.gnome.org/show_bug.cgi?id=754597
The dependency setup does not seem to work for all systems,
causing the build to fail with:
gstrtpbaseaudiopayload.c:65:0:
fatal error: gst/audio/audio-enumtypes.h: No such file or directory
My setup:
gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4
autoconf (GNU Autoconf) 2.69
automake (GNU automake) 1.14.1
libtool (GNU libtool) 2.4.2
https://bugzilla.gnome.org/show_bug.cgi?id=754344
Before we just merged everything in pretty much random ways
ad-hoc instead of keeping state properly. In 0.10 that was
how it worked, but in 1.x the tag events sent should always
reflect the latest state and replace any previous tags.
So save the upstream (stream) tags, and save the tags set
by the decoder subclass with merge mode, and then update
the merged tags whenever either of those two changes.
This slightly changes the behaviour of gst_video_decoder_merge_tags()
in case it is called multiple times, since now any call replaces
the previously-set tags. However, it leads to much more predictable
outcomes, and also we are not aware of any subclass which sets this
multiple times and expects all the tags set to be merged.
If more complex tag merging scenarios are required, we'll have
to add a new vfunc for that or the subclass has to intercept
the upstream tags itself and send merged tags itself.
https://bugzilla.gnome.org/show_bug.cgi?id=679768
Before we just merged everything in pretty much random ways
ad-hoc instead of keeping state properly. In 0.10 that was
how it worked, but in 1.x the tag events sent should always
reflect the latest state and replace any previous tags.
So save the upstream (stream) tags, and save the tags set
by the decoder subclass with merge mode, and then update
the merged tags whenever either of those two changes.
This slightly changes the behaviour of gst_audio_decoder_merge_tags()
in case it is called multiple times, since now any call replaces
the previously-set tags. However, it leads to much more predictable
outcomes, and also we are not aware of any subclass which sets this
multiple times and expects all the tags set to be merged.
If more complex tag merging scenarios are required, we'll have
to add a new vfunc for that or the subclass has to intercept
the upstream tags itself and send merged tags itself.
https://bugzilla.gnome.org/show_bug.cgi?id=679768
Apparently I forgot how gobject works, there is no need to expose
it directly as one can call it from the parent_class pointer
This reverts commit 8a64592481.
Apparently I forgot how gobject works, there is no need to expose
it directly as one can call it from the parent_class pointer
This reverts commit ea9b6a7e3c.
Add gst_audio_decoder_set_use_default_pad_acceptcaps() to allow
subclasses to make videodecoder use the default pad acceptcaps
handling instead of resorting to the caps query that is, usually,
less efficient and unecessary
API: gst_audio_decoder_set_use_default_pad_acceptcaps
Add gst_video_decoder_set_use_default_pad_acceptcaps() to allow
subclasses to make videodecoder use the default pad acceptcaps
handling instead of resorting to the caps query that is, usually,
less efficient and unecessary
API: gst_video_decoder_set_use_default_pad_acceptcaps
Use the object lock to protect the internal segment when updating
against access from getting the stats property.
Fix a critical in gst-inspect or when retrieving the stats
before any segment has arrived by checking whether the
segment has been initted..
last_segment is only being updated in dequeue_buffer(),
which is only called from _pull_sample(). _pull_preroll()
simply re-uses an old or dummy segment while the actual
one sits and waits in the queue.
https://bugzilla.gnome.org/show_bug.cgi?id=751147
Subclasses can use it to select what queries they want to handle
and forward the rest to the default handling function.
API: gst_video_decoder_sink_query_default
https://bugzilla.gnome.org/show_bug.cgi?id=753623
Subclasses can use it to select what queries they want to handle
and forward the rest to the default handling function.
API: gst_audio_decoder_sink_query_default
https://bugzilla.gnome.org/show_bug.cgi?id=753623
The payloader didn't copy anything so far, the depayloader copied every
possible meta. Let's make it consistent and just copy all metas without
tags or with only the audio tag.
https://bugzilla.gnome.org/show_bug.cgi?id=751774
There was a confusion, six depayloaders where passing through the
timestamp while the base class was re-timestamping to running
time. This inconstancy has been unnoticed has in most use cases
the incoming segment is [0, inifnity] in which case timestamps are
the same as running time. With DTS/PTS shifting added (to avoid
negative values) and pcapparse sending a different segment this
started being an issue.
https://bugzilla.gnome.org/show_bug.cgi?id=753037
gstvideoencoder.h:228: Warning: GstVideo: "@transform_meta"
parameter unexpected at this location:
* @transform_meta: Optional. Transform the metadata on ...
Push all pending events before pushing the gap. This ensures the
segment is pushed before the gap so it can be properly translated
to the running time
Includes unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=753360
When there is no clock_base provided, the start position is
set to 0 instead of the original segment start value. This
would break synchronization if start was not 0.
https://bugzilla.gnome.org/show_bug.cgi?id=752228
Add logging categories for most video objects.
Remove some useless debug lines in video-info and videotestsrc.
Add a performance debug line in the video scaler.
GST_TYPE_RTSP_LOWER_TRANS used to be defined in there, not
including the generated file makes older gst-p-good fail to build,
so it constitues an API break.
Add process_rtp_packet() vfunc that works just like the
existing process() vfunc only that it takes the GstRTPBuffer
that the base class has already mapped (with MAP_READ),
which means that the subclass doesn't have to map it again,
which allows more performant processing of input buffers
for most RTP depayloaders.
https://bugzilla.gnome.org/show_bug.cgi?id=750235
This minor update should workaround a build system bug. While the
makefile has been updated to generate more enum type, there is nothing
that updates the header and would lead to the generated code to be
produced again. This minor doc fix should ensure no one get a build with
missing symbols.
E.g.
video-scaler.c: In function 'gst_video_scaler_horizontal':
video-scaler.c:1332:3: error: 'func' may be used uninitialized in this function [-Werror=maybe-uninitialized]
func (scale, src, dest, dest_offset, width, n_elems);
^
video-scaler.c: In function 'gst_video_scaler_vertical':
video-scaler.c:1373:3: error: 'func' may be used uninitialized in this function [-Werror=maybe-uninitialized]
func (scale, src_lines, dest, dest_offset, width, n_elems);
^
GCC's analyses seem to be correct, for the simple fact that if you pass
get_functions a known format, but no hscale or vscale, it'll return
True without having done anything.
Some callers check for the scale values to be not NULL, but then
hscale->resampler.max_taps could return 0.
A different approach to the one presented in this patch is to check
for those max_taps, too, before calling get_functions.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=752051
The padding (if any) is included in the length of the last packet, see
RFC 3550.
Section 6.4.1:
padding (P): 1 bit
If the padding bit is set, this individual RTCP packet contains
some additional padding octets at the end which are not part of
the control information but are included in the length field. The
last octet of the padding is a count of how many padding octets
should be ignored, including itself (it will be a multiple of
four).
Section A.2:
* The padding bit (P) should be zero for the first packet of a
compound RTCP packet because padding should only be applied, if it
is needed, to the last packet.
* The length fields of the individual RTCP packets must add up to
the overall length of the compound RTCP packet as received.
https://bugzilla.gnome.org/show_bug.cgi?id=751883
It's needed to check if pixel-aspect-ratio exists before fixating.
It does not exist if input caps is not set yet and allowed caps
does not contain pixel-aspect-ratio (e.g. when using GST_VIDEO_CAPS_MAKE)
https://bugzilla.gnome.org/show_bug.cgi?id=751932
POOL meta just means that this specific instance of the meta is related to a
pool, a copy should be made when reasonable and the flag should just not be
set in the copy.
The default implementation copies all metadata without tags, and metadata
with only the video tag. Same behaviour as in GstVideoFilter.
This currently does not work if the ::parse() vfunc is implemented as all
metas are getting lost inside GstAdapter.
https://bugzilla.gnome.org/show_bug.cgi?id=742385
CLAMP checks both if value is '< 0' and '> max'. Value will never be a negative
number since it is a division of an unsigned integer (i). Removing that check
and only checking if it is bigger than max and setting it appropriately.
CID #1308950
For alaw/mulaw we should also try to initialize the channel positions in the
ringbuffer's audio info. This allow pulsesink to directly use the channel
positions instead of using the default zero-initialized ones, which doesn't
work well.
https://bugzilla.gnome.org/show_bug.cgi?id=751144
Add a utility function that, given a video size and a
packed stereoscopic mode, attempts to guess if the video
is packed at half resolution per view or not, since
very few videos provide the information.
We need to scale groups of 4 bytes for YUY2 formats so round up to 4.
It's possible that there is no Y byte for the last pixel so make sure
we clamp correctly.
The API does not follow the type naming convention. Re-enable
only if one take the time to box and rename (see (rename-to SYMBOL)
annotation) all types.
When copying info from the reference input state, duplicate
all the fields of the video info. The sub-class will have the
chance to override them later.
Add flags and enums to support multiview signalling in
GstVideoInfo and GstVideoFrame, and the caps serialisation and
deserialisation.
videoencoder: Copy multiview settings from reference input state
Add gst_video_multiview_* support API and GstVideoMultiviewMeta meta
https://bugzilla.gnome.org/show_bug.cgi?id=611157
This new clock slaving method allows for installing a callback that is
invoked during playback. Inside this callback, a custom slaving
mechanism can be used (for example, a control loop adjusting a PLL or an
asynchronous resampler). Upon request, it can skew the playout pointer
just like the "skew" method. This is useful if the clocks drifted apart
too much, and a quick reset is necessary.
Signed-off-by: Carlos Rafael Giani <dv@pseudoterminal.org>
https://bugzilla.gnome.org/show_bug.cgi?id=708362
Otherwise ssrc changes via rtpsession's (deprecated!) internal-ssrc property
are not possible anymore. rtpsession was now patched to only suggest an ssrc
if it makes sense to do so.
In 2.0 we should get rid of all the properties that are also negotiated via
caps, the code and behaviour is too confusing otherwise.
https://bugzilla.gnome.org/show_bug.cgi?id=749581
According to this section of the rfc.
https://tools.ietf.org/html/rfc5506#section-3.4.2
The validation should be updated to accept more types of RTCP
packages, with this mask change feedback packages will be also
accepted.
Change-Id: If5ead59e03c7c60bbe45a9b09f3ff680e7fa4868
Micro-optimisation: if the buffer consist of just one memory, we
know we have already mapped that memory to read the headers, so
no need to map it another time to get to the payload data, we
can just set up the payload data details right there and then
and avoid another map call in gst_rtp_buffer_get_payload().
Adds up when receiving RTP-payloaded raw video which can easily
be thousands of packets per frame.
Implement a chain_list function, which avoids lots of locking
compared to the default fallback implementation in GstPad.
We may also want to do some more sophisticated timestamp
tracking here at some point, but for now leave it up to the
jitterbuffer and/or subclasses (in case buffers in the
buffer list have no timestamp set on them, there may only
be a timestamp for the whole list on the first buffer).
This provides the exact same behaviour as the default
fallback implementation.
Summary:
So that the user can easily use the same encoding profile to render
with/without audio/video stream.
API:
gst_encoding_profile_is_disabled
gst_encoding_pofile_set_enabled
https://bugzilla.gnome.org/show_bug.cgi?id=749056
Instead of returning the first video meta found on a buffer, return the
one with the lowest id (which is usually the same thing, except on
multi-view buffers)
Use g_utf16_to_utf8() instead of the more generic g_convert(), so
that we can extract text in UTF-16 format even on embedded systems
with crippled iconv support.
This code path is exercised by the id3demux test_unsync_v23
check in gst-plugins-good.
https://bugzilla.gnome.org/show_bug.cgi?id=741144
From the API documentation: "Note that it is generally not
a good idea to reuse an existing cancellable for more
operations after it has been cancelled once, as this
function might tempt you to do. The recommended practice
is to drop the reference to a cancellable after cancelling
it, and let it die with the outstanding async operations.
You should create a fresh cancellable for further async
operations."
https://bugzilla.gnome.org/show_bug.cgi?id=739132
[API] gst_discoverer_info_to_variant
[API] gst_discoverer_info_from_variant
[API] GstDiscovererSerializeFlags
+ Serializes as a GVariant
+ Adds a test
+ Does not serialize potential GstToc (s)
https://bugzilla.gnome.org/show_bug.cgi?id=748814
This affects the pt, ssrc, seqnum-offset and timestamp-offset properties. If
they were set from a property, or we configured caps before, we try to use
that value for them. Even if the first structure of the downstream caps
specifies a different value, we check if the value is supported by other
structures.
Only if all this fails, we use the values given by downstream in the first
structure, i.e. if no properties were set and these are the first caps we
negotiate or downstream does not support our values.
By doing this we ensure that we don't spuriously change ssrcs or other fields
in the middle of the stream (and also consider property values more). Ssrc
changes would currently happen after sending an RTX packet (thus creating a
new internal source inside the rtpsession), and then renegotiating the
payloader (which then gets the RTX ssrc from rtpsession).
https://bugzilla.gnome.org/show_bug.cgi?id=749581
All those where super straight forward from the warnings gtkdoc prints. It kind
of makes sense to apply them before the list of warnings is >100 and people
complain that gtkdoc is noisy.
GST_VIDEO_CONVERTER_OPT_ALPHA_MODE, GST_VIDEO_CONVERTER_OPT_CHROMA_MODE,
GST_VIDEO_CONVERTER_OPT_MATRIX_MODE, GST_VIDEO_CONVERTER_OPT_GAMMA_MODE and
GST_VIDEO_CONVERTER_OPT_PRIMARIES_MODE were G_TYPE_STRING with only a few valid
options. Changed those to real enums.
https://bugzilla.gnome.org/show_bug.cgi?id=749104
2 second frame duration is rather unlikely... but if we don't clip
away buffers that far before the segment we can cause the pipeline to
lockup. This can happen if audio is properly clipped, and thus the
audio sink does not preroll yet but the video sink prerolls because
we already outputted a buffer here... and then queues run full.
In the worst case we will clip one buffer too many here now if no
framerate is given, no buffer duration is given and the actual
framerate is less than 0.5fps.
Fixes seeking on HLS/DASH streams, when seeking into the middle of
fragments and having no framerate/buffer duration.
This will be useful for elements that wish to post unhandled navigation
events on the bus to give the application a chance to do something with
it
https://bugzilla.gnome.org/show_bug.cgi?id=747245
Take into account the different steps between Y and UV when calculating
the line size for vertical resampling or else we might not resample
enough pixels and leave bad lines.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=747790
gst_message_parse_toc() returns a reffed GstToc which is owned by the
GstDiscovererInfo. But we have to make sure we unref its previous value before
setting the new one.
https://bugzilla.gnome.org/show_bug.cgi?id=747103
We only get here if we don't have any srcpad caps, and we're going
to override the GstAudioInfo a few lines below anyway without ever
using it if for whatever reason we get caps here.
Otherwise we would forward the GAP event without ever providing any caps,
which then would make decodebin expose a srcpad without any caps set. That's
confusing for applications and can lead to all kinds of interesting bugs.
Instead do the same as already is done in GstAudioDecoder, and try to invent
caps based on the sinkpad caps and the caps allowed by downstream and the
srcpad template caps.
https://bugzilla.gnome.org/show_bug.cgi?id=747190
Bypass g_convert/iconv if there's nothing to convert. That way,
conversion won't fail on systems where iconv doesn't support
converting utf-8 to latin1 and there's nothing to convert.
https://bugzilla.gnome.org/show_bug.cgi?id=723252
memcmp will blindly compare the reserved fields, as well as any
padding the compiler may choose to sprinkle in GstSegment.
Fixes valgrind complaints in unit tests, as well as some found via
https://bugzilla.gnome.org/show_bug.cgi?id=738216
The spec for this does not say nor imply how this should be
interpreted. The previous code would try to shift by 64 bits,
which is undefined.
Coverity 1195119
https://bugzilla.gnome.org/show_bug.cgi?id=727955
When generating segment, we can't assume the first buffer is actually
the first expected one. If it's not, we need to adjust the segment to
start a bit before.
Additionally, we if don't know when the stream is suppose to have
started (no clock-base in caps), it means we need to keep everything in
running time and only rely on jitterbuffer to synchronize.
https://bugzilla.gnome.org/show_bug.cgi?id=635701
Make a base class that can help with allocating fd-backed memory.
Make dmabuf extend from the base class.
We can now make methods to check if memory has an fd and get the fd for
all the different types of fd-backed memory.
Make a separate file for the code to handle the fd backed memory.
This would make it possible later to add other allocators also using
fd backed memory.
Based on patch from Mozzhuhin Andrey <nopscmn at gmail.com>
Add a table based matrix8 multiplication implementation. The algorithm
does not do any clipping so we need to make sure we never call this on
input that might need to be clipped. In general, this algorithm is
2 times faster than the orc optimized one and would be chosen for all
RGB -> YUV conversions and some YUV->YUV and RGB->RGB conversions.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=732186
When the ringbuffer is deactivated and then acquired, if the audio clock
provided by the sink gets reset to zero, we need to add an offset to the
clock to make sure that subsequent samples are written out at the right
times. While we need to leave this to derived classes to take care of
when they provide their own clock (since that clock may or may not be
reset to zero), we can do this ourselves if we know the provided clock
is our own (which does reset to zero on a re-acquire).
When we are using the fast linear resampler, use the ->inc to calculate
the first and last pixel we need so that we can do vertical resampling
on the right amount of pixels.
CLAMP checks both if value is '< 0' and '> max'. Value will never be a negative
number since it in an unsigned integer. Removing that check and only checking
if it is bigger than max and setting it appropriately.
CID #1271606
Only activate the scaler fastpath for x2 up and downscale when the
scaler method is respectively nearest and linear because that is what
those fastpaths really implement.
Add support for alpha. Make it possible to copy, set and multiply the
alpha value of a frame during conversion.
Set the border alpha to 0xff by default.
Go over some of the fastpaths and add alpha handling.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=745006
Make sure to update the output segment to track the segment
we're decoding in, but don't actually push it downstream until
after buffers are decoded.
https://bugzilla.gnome.org/show_bug.cgi?id=744806
Otherwise upstream can get confused about offsets as there will
be a jump once the tags have been parsed due to the stripped area.
If upstream pulls from 0 to 100, and then tagdemux does the
tag reading and finds out that the first 200 bytes are the tag, the
next pull from upstream will have an offset of 200 bytes. So
upstream will get the following data:
0 - 100, 300 - (EOS), as it will continue requesting from where
it has last stopped, but tagdemux will add an offset to skip the
tags.
This patch makes sure that the tags have been parsed and skipped
since the first pull range call.
https://bugzilla.gnome.org/show_bug.cgi?id=744580
This reverts commit 19b9356680.
These two "profiles" are actually a complete set of profiles, which we will
need to handle separately. Unfortunately it seems like we need information
from the SPS to detect the exact profile.
The new gst_install_plugins_context_set_confirm_search() API can be used
to pass a hint to modify the behaviour of the external installer
process.
https://bugzilla.gnome.org/show_bug.cgi?id=744465
The new gst_install_plugins_context_set_desktop_id() and
gst_install_plugins_context_set_startup_notification_id() API can be
used to pass extra details to the external installer process.
https://bugzilla.gnome.org/show_bug.cgi?id=744465
These values are for now taken from x265 and need to be checked against
the spec. Especially we need to check if information from other fields
need to be taken into consideration too, e.g. the bit depth and chroma
index from the SPS.
This however makes 4:4:4 output of x265enc actually work.
Make a convenience function that combines 2 scalers to perform a 2d
scale. This removes quite a bit of overhead in method calls when doing a
typical scale and it also can reuse a piece of unused memory in the
vertical scaler.
Use the 2d scaler in video-converter and remove the other scalers and
temp memory.
Only merge scalers for selected formats.
Use nearest neighbour scaling for chroma when doing nearest neighbour
for the luma.
Also fastpath GRAY16_OE in nearest neighbour.
configure parameters correctly for packed fastpath.
Small performance tweaks for RGB and friends.
Add, but ifdef out, alternative nearest neighbour scaling, it is slower
than the current table based version.
Use memcpy instead of orc_memcpy because it is measurably faster.
Fix YUY2 and friends vertical scaling.
video-scaler.c:1331:14: error: variable 'func' is used uninitialized whenever 'if' condition is false
[-Werror,-Wsometimes-uninitialized]
} else if (bits == 16) {
^~~~~~~~~~
video-scaler.c:1348:3: note: uninitialized use occurs here
func (scale, src_lines, dest, dest_offset, width, n_elems);
^~~~
video-scaler.c:1331:10: note: remove the 'if' if its condition is always true
} else if (bits == 16) {
^~~~~~~~~~~~~~~~
video-scaler.c:1260:27: note: initialize the variable 'func' to silence this warning
GstVideoScalerVFunc func;
^
= NULL
video-converter.c:3406:12: error: implicit conversion from enumeration type 'GstVideoFormat' to different
enumeration type 'GstFormat' [-Werror,-Wenum-conversion]
format = convert->fformat[plane];
~ ^~~~~~~~~~~~~~~~~~~~~~~
video-converter.c:3413:44: error: implicit conversion from enumeration type 'GstFormat' to different enumeration
type 'GstVideoFormat' [-Werror,-Wenum-conversion]
gst_video_scaler_horizontal (h_scaler, format,
~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~
video-converter.c:3471:12: error: implicit conversion from enumeration type 'GstVideoFormat' to different
enumeration type 'GstFormat' [-Werror,-Wenum-conversion]
format = convert->fformat[plane];
~ ^~~~~~~~~~~~~~~~~~~~~~~
video-converter.c:3487:42: error: implicit conversion from enumeration type 'GstFormat' to different enumeration
type 'GstVideoFormat' [-Werror,-Wenum-conversion]
gst_video_scaler_vertical (v_scaler, format, lines, d + out_x, i,
~~~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~
video-converter.c:3551:12: error: implicit conversion from enumeration type 'GstVideoFormat' to different
enumeration type 'GstFormat' [-Werror,-Wenum-conversion]
format = convert->fformat[plane];
~ ^~~~~~~~~~~~~~~~~~~~~~~
video-converter.c:3569:46: error: implicit conversion from enumeration type 'GstFormat' to different enumeration
type 'GstVideoFormat' [-Werror,-Wenum-conversion]
gst_video_scaler_horizontal (h_scaler, format,
~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~
video-converter.c:3577:42: error: implicit conversion from enumeration type 'GstFormat' to different enumeration
type 'GstVideoFormat' [-Werror,-Wenum-conversion]
gst_video_scaler_vertical (v_scaler, format, lines, d + out_x, i,
~~~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~
In function gst_video_scaler_vertical() the bits variable is always
set to either 8 or 16 in every possible format. No need to initialize it.
If the format isn't valid it goes to no_func, so there is no need to
handle the case of bits not being 8 or 16.
CID #1268401
Add API to add and get custom headers that are not
covered by our header fields enum. This is backwards
compatible in that it will also work for our defined
fields, so if we ever add a new header field to the
enum, get_header_by_name() for the same header string
will still work.
API: gst_rtsp_message_add_header_by_name()
API: gst_rtsp_message_take_header_by_name()
API: gst_rtsp_message_remove_header_by_name()
API: gst_rtsp_message_get_header_by_name()
Add fastpaths for all planar conversion and scaling.
Improve gray and alpha handling.
Add option to specify the chroma resampler method and set to linear as
default.
video-converter.c:3645:24: error: implicit conversion from enumeration type
'GstFormat' to different enumeration type 'GstVideoFormat'
[-Werror,-Wenum-conversion]
convert->fformat = fformat;
~ ^~~~~~~
video-converter.c:3667:24: error: implicit conversion from enumeration type
'GstFormat' to different enumeration type 'GstVideoFormat'
[-Werror,-Wenum-conversion]
convert->fformat = fformat;
~ ^~~~~~~
video-converter.c:3963:50: error: implicit conversion from enumeration type
'const GstVideoFormat' to different enumeration type 'GstFormat'
[-Werror,-Wenum-conversion]
if (!setup_scale (convert, transforms[i].fformat))
~~~~~~~~~~~ ~~~~~~~~~~~~~~^~~~~~~
If we have timestamps on input buffers and are in trickmode no-audio
mode, then don't pass anything to the subclass for decode and simply
send gap events downstream
Only for forward playback for now - reverse requires accumulating
GAP events and pushing out in reverse order.
https://bugzilla.gnome.org/show_bug.cgi?id=735666
In trickmode no-audio mode, or when receiving a GAP buffer,
discard the contents and render as a GAP event instead.
Make sure when rendering a gap event that the ring buffer will
restart on PAUSED->PLAYING by setting the eos_rendering flag.
This mostly reverts commit 8557ee and replaces it. The problem
with the previous approach is that it hangs in wait_preroll()
on a PLAYING-PAUSED transition because it doesn't commit state
properly.
https://bugzilla.gnome.org/show_bug.cgi?id=735666
The decoder can fail to drain on EOS if there was only one gather
set, because it will never have sent the segment event downstream
and set the output segment, and fail to detect that the rate < 0.0
Make sure to send pending events before sending all the gather data
for decode.
In gst_video_resampler_init () if method is GST_VIDEO_RESAMPLER_METHOD_NEAREST
then params.envelope is not initialized but still used later in line 382.
Make sure this variable is initiliazed to avoid undefined behaviour.
CID #1256568
Don't render out silence samples to a buffer, just
start the clock running, since any buffer with the
GAP flag will be discarded in render() now anyway.
Make the base audio sink throw away buffers marked GAP, or all
incoming buffers when performing a trick play with
GST_SEGMENT_TRICKMODE_NO_AUDIO flag set, and make sure to start
the ringbuffer when that happens so the clock starts running.
Preserve the timing calculations when rendering, so state is all
updated the same, but just don't render samples.
https://bugzilla.gnome.org/show_bug.cgi?id=735666
video-converter.c:3073:48: error: implicit conversion from enumeration type 'GstFormat' to different enumeration type 'GstVideoFormat'
[-Werror,-Wenum-conversion]
gst_video_scaler_horizontal (h_scaler, format,
~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~
video-converter.c:3081:44: error: implicit conversion from enumeration type 'GstFormat' to different enumeration type 'GstVideoFormat'
[-Werror,-Wenum-conversion]
gst_video_scaler_vertical (v_scaler, format, lines, d, i, out_w);
~~~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~
video-converter.c:3137:24: error: implicit conversion from enumeration type 'const GstVideoFormat' to different enumeration type 'GstFormat'
[-Werror,-Wenum-conversion]
convert->fformat = GST_VIDEO_INFO_FORMAT (in_info);
~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../gst-libs/gst/video/video-info.h:125:43: note: expanded from macro 'GST_VIDEO_INFO_FORMAT'
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../gst-libs/gst/video/video-format.h:361:59: note: expanded from macro 'GST_VIDEO_FORMAT_INFO_FORMAT'
~~~~~~~~^~~~~~
video-converter.c:3157:24: error: implicit conversion from enumeration type 'GstVideoFormat' to different enumeration type 'GstFormat'
[-Werror,-Wenum-conversion]
convert->fformat = GST_VIDEO_FORMAT_GRAY8;
Add fast path scaling for YUY2 and other packed YUV formats. Add a new
method to merge the scalers of the Y and UV components into one scaler.
Add faster horizontal 2tap scaler.
See https://bugzilla.gnome.org/show_bug.cgi?id=741987
Some audio sink sub-classes (pulsesink) don't start their clock
when the ringbuffer starts, but always have to on EOS. When we
explicitly need to start the ringbuffer, make sure sub-classes will
do it by (ab)using the existing eos_rendering flag.
Add support for scaling of images with pstride == 1. This can be used
to scale individual planes later.
Rework some of the scaling code to take the pstride as a parameter.
CLAMP checks both if value is '< 0' and '> max'. Value will never be a negative
number since it is an unsigned integer. Removing that check and only checking if
it is bigger than max and setting it appropriately.
CID 1256559
CLAMP checks both if n_taps is '< 0' and '> max_taps'. n_taps will never be a
negative number because it is an unsigned integer. Removing that check and only
making sure it isn't set bigger than max.
CID 1256558
Add an option to disable chroma resampling.
Improve the matrix option values so that you can choose to use the input
or output matrix or disable conversion.
The gst_discoverer_info_get_missing_elements_installer_details()
documentation and annotation says that the return value should be freed
with g_strfreev(), but actually it's owned by the GstDiscovereInfo
object and should definitely not get freed by the caller as well.
https://bugzilla.gnome.org/show_bug.cgi?id=742006
Video buffer pool will update video alignment to respect stride alignment
requirement. But haven't updated it to video alignment in configure.
Which will cause user get wrong video alignment.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=741501
Otherwise calls to get the clock time might change its internal state
and the internal/external time for calibration get unbalanced leading to
a clock jump
https://bugzilla.gnome.org/show_bug.cgi?id=740834
This makes sure that the element is in the same state before start() is called
the very first time and every future call after the element was used already.
Also it ensure that we always have a clean state before start(), cleaned the
same way in every case.
The same was done already in the decoder, and we cleaned some state just above
manually that would also be taken care of by reset().
This makes sure that the element is in the same state before start() is called
the very first time and every future call after the element was used already.
The stop() vfunc might mess with some of our fields we have just
reset, which could cause memory leaks or invalid state taken over
to later.
Also the stop() vfunc, or anything called until it from another thread,
might want to be able to use the fields that were just resetted and
become confused because of that.
In the decoder we already had a workaround for things like this happening,
this workaround is not needed anymore.
The implementation of that vfunc might want to use the object lock for
something too. It's generally not a good idea to keep the object lock while
calling any function implemented elsewhere.
Also the ringbuffer can only be NULL at this point, remove a useless if block.
And in the sink actually hold the object lock while setting the ringbuffer on
the instance. Code accessing this is expected to use the object lock, so do it
here ourselves too.
Allows subclasses to do custom caps query replies.
Also exposes the standard caps query handler so subclasses can just
extend on top of it instead of reimplementing the caps query proxying.
Allows decoders to proxy downstream restrictions on caps.
Also implements accept-caps query to prevent regressions caused by the
new fields on the return of a caps query that would cause the accept-caps
to fail as it uses subset caps comparisons
Allows subclasses to do custom caps query replies.
Also exposes the standard caps query handler so subclasses can just
extend on top of it instead of reimplementing the caps query proxying.
https://bugzilla.gnome.org/show_bug.cgi?id=741263
With the new caps query results the caps returned might have extra fields
that are not required by the decoder (framerate for image decoders) and it
causes a regression making, for example, jpegdec reject caps that don't
have framerates.
The accept-caps implementation will do 2 checks:
1) Do subset check with the template caps, making sure all the required
fields that are present on the template are present on the received caps.
2) Do a intersection check with the result of a caps query, making sure
that downstream can accept the fields in the received caps.
https://bugzilla.gnome.org/show_bug.cgi?id=741263
Refactor the encoder's caps query proxying function to a common place
and use it in the videodecoder to proxy downstream restrictions.
The new function is private to the gstvideo lib.
https://bugzilla.gnome.org/show_bug.cgi?id=741263
Update the new buffer size after alignment in the pool configuration
before calling the parent set_config. This ensures that the parent knows
about the buffer size that we will allocate and makes the size check
work in the release_buffer method.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=741420
This reverts commit 406f32a946.
The problem was apparently that my video-orc.h was not updated and did not
include the prototype for that function. Only a "make clean" caused it to
be regenerated.
Avoid using a constant.
Avoid doing saturated adds, results are not supposed to overflow here.
Rework the C backup function a little in preparation for custom backup
functions in ORC.
See https://bugzilla.gnome.org/show_bug.cgi?id=741015
In some cases, the user might want the stream outputted by encodebin to
be in the exact same format during all the stream. We should let the
user specify when this is the case. This commit add some API in the
GstEncodingProfile to determine whether the format can be renegotiated
after the encoding started or not.
API:
gst_encoding_profile_set_allow_dynamic_output
gst_encoding_profile_get_allow_dynamic_output
https://bugzilla.gnome.org/show_bug.cgi?id=740214
It will cause the frame to be initialized with inconsistent values that then
later can cause crashes or any other kind of interesting and hard to debug
bugs.
In cases where we just call orc directly this is somewhat
superfluous, but let's do it anyway for consistency. In
other cases the compiler can hopefully use this to optimise
memory access a little.
when using variable taps and when we are limiting the number of taps,
recalculate the lanczos parameters to match the clamped value.
Set the max number of taps to 128
Make a small object to hold a pool of allocated temp lines.
Keep track of how many temp lines each conversion stage needs and use
this to allocate just enough temp lines from the temp lines object. from
the temp lines object.
When dealing with mixed interlaced, setup a scaler and chroma-resampler
for both interlaced and progressive frames and switch between them
depending on the interlace mode of the input frame.
Add an option to limit the number of taps to use in automatic mode. The
problem is that for lanczos, we might use more taps than what we can
handle with the current precision.
Rework the other options a little to make it nicer to set defaults.
Refactor GstVideoInfo init, make function to set default colorimetry.
Call fill_planes after we configure the GstVideoInfo with parameters
from the caps.
The size of the chroma planes for interlaced vertically subsampled
formats needs to be rounded up to 2, we have 2 fields with each
the same anount of chroma lines.
Keep only 1 structure with all matrix information.
Add structure to hold gamma information.
Add more options to control gamma, primaries and color matrix handling.
Add functions to compute transformations to and from XYZ and use this
to convert between primaries.
Merge gamma into the convert to and from RGB stage.
Fix border val.
Simplify the fastpath table, remove unused fields, add some more checks.
Prepare for doing full gamma corrected conversion and scaling by first
splitting the conversions from and to RGB into separate steps.
split scaling in downscaling and upscaling steps to be performed before
and after conversion respectively.
Fix clipping of images that are partially left of the video
surface, they would get clipped on the right side instead of
the left side, because the video unpack functions currently
ignore the x offset parameter. Work around that until that
is implemented.
https://bugzilla.gnome.org/show_bug.cgi?id=739281
In case of overlay being completely or partially outside
the video frame, the offset calculations are not right,
which resulted in the overlay not being displayed as
expected, or crashes due to invalid memory access.
When the overlay rectangle is completely outside,
we need not render the overlay at all.
For partial display of overlay rectangles, src_yoff
was not being calculated, hence it was always clipping
the bottom half of the overlay, By calculating the
src_yoff, now the overlay is clipped properly.
https://bugzilla.gnome.org/show_bug.cgi?id=739281
Make an ORC version of the 2x vertical upsampling code.
Improve unit tests, test chroma up and down sampling.
memset buffer in conversion to make valgrind happy.
Combine multiplies in 4x filters.
Rename conversion functions to make them nicer in orc.
Add ORC versions for various downsampling algorithms
Add unit test chroma resampler
We only need to do the horizontal subsampling on 1 line if we do it
after vertical subsampling and we also avoid doing vertical subsampling
on unused pixels.
Rework the converter, keep track of the conversion steps by chaining the
cache objects together. We can then walk the chain and decide the
optimal allocation pattern.
Remove the free function, we're not going to need this anytime soon.
Keep track of what output line we're constructing so that we can let the
allocator return a line directly into the target image when possible.
Directly read from the source pixels when possible.
We need to allocate the templine with the amount of pixels we are going
to handle, which we only know for the vertical resampler when we are
asked to resample.
Add scaler functions for 16 bits formats.
Rename the scaler functions so that 16bits versions don't look too
weird.
Remove old unused h_2tap functions
Fix v_ntap functions, it was using 1 tap too little.
Rework the way we track the current state of the video through the
different conversion phases and use this to make sure we use the right
format and pstride where needed.
A faster version of 4tap horizontal scaling causes segfaults in ORC
presumably because it uses too many registers so disable it to avoid
crashing in the ORC tests.
video-scaler.c:151:58: error: implicit conversion from enumeration type
'GstVideoScalerFlags' to different enumeration type
'GstVideoResamplerFlags' [-Werror,-Wenum-conversion]
gst_video_resampler_init (&scale->resampler, method, flags, out_size,
~~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~
Only apply an offset that is a multiple of the subsampling. To handle
arbitrary offsets in the future, we need to be able to chroma-resample
part of the borders.
Add support for cropping the source and placing the converted image
into a rectangle in the destination frame.
Add an option to add a border and border color.
Add the old ORC functions for nearest and linear. Label them as Low
quality because they are not as accurate but ORC lacks opcodes to
express this for now.
Add a video scaler object build on top of the resampler. It has
implementation to deal with interlaced video as well as horizontal and
vertical scaling functions.
Use a LineCache object to track and process lines between unpack,
upsample, convert, downsample and pack stages. This simplifies the
main core processing function a lot and allows for future additions
easily.
Add support for interlaced formats in chroma up and downsampling.
There are some few but certain conditions where it is possible for the
dest_width to be smaller than x. So we check this before assigning a negative
value to src_width, which is a unsigned and would be promoted to a number that
can segfault videoblend.
https://bugzilla.gnome.org/show_bug.cgi?id=738242
This was never reset when going from PAUSED->READY and resulted
in encoders being not reusable after EOS. They just rejected any
buffer because they received EOS in their previous life.
The flag wasn't used anywhere except for rejecting buffers after
EOS, and this is now handled by GstPad directly.
The spec mentions a version of the MPEG-2 frame with a base frame and
extension frame. I don't have IEC 13818-3 to figure out what that is,
and don't see any references in search results, so it's a FIXME for now.
https://bugzilla.gnome.org/show_bug.cgi?id=736797
Move the conversion code used in videoconvert to the video library
and expose a simple but generic API to do arbitrary conversion. It can
currently do colorspace conversion but the plan is to add videoscale to
it as well.
See https://bugzilla.gnome.org/show_bug.cgi?id=732415
When playing chained data the audio ringbuffer is released and
then acquired again. This makes it reset the segbase/segdone
variables, but the next sample will be scheduled to play in
the next position (right after the sample from the previous media)
and, as the segdone is at 0, the audiosink will wait the duration
of this previous media before it can write and play the new data.
What happens is this:
pointer at 0, write to 698-1564, diff 698, segtotal 20, segsize 1764, base 0
it will have to wait the length of 698 samples before being able to write.
In a regular sample playback it looks like:
pointer at 677, write to 696-1052, diff 19, segtotal 20, segsize 1764, base 0
In this case it will write to the next available position and it
doesn't need to wait or fill with silence.
This solution is borrowed from pulsesink that resets the clock to
start again from 0, which makes it reset the time_offset to the time
of the last played sample. This is used to correct the place of
writing in the ringbuffer to the new start (0 again)
https://bugzilla.gnome.org/show_bug.cgi?id=737055
Move the assert to the error handling block at the end of the function so the
the logging is still triggered. Reword the logging slightly and add another
comment to hint what went wrong.
Fixes#737138
Issue:
During a PAUSED->PLAYING transition when we are rendering an audio buffer in AudioBaseSink
we make adjustments to the sink's provided clock i.e. fix clock calibration using the external
pipeline clock, within "gst_audio_base_sink_sync_latency function inside gstaudiobasesink.c".
For the calibration adjustment we need to get the sink clock time using "gst_audio_clock_get_time".
But before calling "gst_audio_clock_get_time" we acquire the Object Lock on the Sink. If sink is
a pulsesink, "gst_audio_clock_get_time" internally calls "gst_pulsesink_get_time" which needs to
acquire Pulse Audio Main Loop Lock before querying Pulse Audio for its stream time using
"pa_stream_get_time". Please see "gst_pulsesink_get_time in pulsesink.c".
So the situation here is we have acquired the Object lock on Sink and need PA Main Loop Lock.
Now Pulse Audio Main Thread itself might be in the process of posting a stream status
message after Paused to Playing transition which in turn acquires the PA Main loop lock and
needs the Object Lock on Pulse Sink. This causes a deadlock with the earlier render thread.
Fix:
Do not acquire the object Lock on Sink before querying the time on PulseSink clock. This is
similar to the way we have used get_time at other places in the code. Acquire it after the
get_time call. This way PA Main loop will be able to post its stream status message by
acquiring the Sink Object lock and will eventually release its Main Loop lock needed for
gst_pulsesink_get_time to continue.
https://bugzilla.gnome.org/show_bug.cgi?id=736071
The timeout parameter is only allowed in a session response header
but some clients, like Honeywell VMS applications, send it as part
of the session request header. Ignore everything from the semicolon
to the end of the line when parsing session id.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=736267
Fixes a crash when controlsrc, readsrc or writesrc are modified from
gst_rtsp_source_dispatch_read/write and gst_rtsp_watch_reset at the
same time.
https://bugzilla.gnome.org/show_bug.cgi?id=735569
This avoids a race where we would get new tag but we are already
prerolled and analyzing results.
It is the way it is supposed to be handled as stated in comment:
"If preroll is complete, drop these tags - the collected information is
possibly already being processed and adding more tags would be racy"
Reset last_timestamp_out when applying the output segment
change, to avoid decoder confusion over new timestamp timelines when
a seamless segment change happens.
Move some locks/unlocks to later when they're actually needed.
https://bugzilla.gnome.org/show_bug.cgi?id=734617
As was done for the base video decoder in commit 695675, don't
flush out the decoder on a new SEGMENT event. Segment events
may be a new segment, but are also often segment updates for
the current segment where the old data should be kept. For new
segments, a STREAM_START event will already trigger a drain, but
make sure to flush any remaining partial data then as well.
https://bugzilla.gnome.org/show_bug.cgi?id=734666
This fixes the reverse playback scenario when upstream is not fully
parsing the stream and does not send every keyframe chain separately
with the DISCONT flag on the keyframe.
To explain this, let's suppose we have this stream:
0 1 2 3 4 5 6 7 8
K K K
In most circumstances, the upstream parser will chain in the
decoder the buffers in the following order:
6 7 8 3 4 5 0 1 2
D D D
In this case, GstVideoDecoder will flush the parse queue every time
it receives discont (D) and we will eventually get in the output queue:
(flush here) 8 7 6 (flush here) 5 4 3 (flush here) 2 1 0
In case the upstream parser doesn't do this work, though,
GstVideoDecoder will receive the whole stream at once and will flush
the parse queue afterwards:
0 1 2 3 4 5 6 7 8
D
During the flush, it will look backwards for keyframes and will
decode in this order:
6 7 8 3 4 5 0 1 2
This is the same order that it would receive from upstream if
upstream was parsing and looking for the keyframes, only that now
there is no flushing of the output queue in between keyframes,
which will result in the output queue looking like this:
2 1 0 6 5 3 8 7 6
This will confuse downstream obviously and will play incorrectly.
This patch forces the decoder to flush the output queue every time
it picks a new keyframe to decode, so it will end up decoding 6 7 8
and then flushing before picking 3 for decoding, so the output will
get 8 7 6 before 6 5 3 and the video will play back correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=734441
Otherwize the pipeline would be in an wrong state and on the next
iteration any kind of error could happen
Everytime an error happens in a pipeline the application has to set the
pipeline back to NULL instead of READY.
https://bugzilla.gnome.org/show_bug.cgi?id=733976
This prevent implementing allocation query, as the format need to be
known in order to determin the size and number of buffers needed.
Note: This may lead to few regressions that will need fixing
https://bugzilla.gnome.org/show_bug.cgi?id=732288
Fixes regression introduced by:
commit b60888fd4b
Author: Michael Olbrich <m.olbrich@pengutronix.de>
Date: Tue May 20 11:18:56 2014 +0200
dmabuf: share the mapping with shared copies of the memory
https://bugzilla.gnome.org/show_bug.cgi?id=730441
Fix gst_video_decoder_parse_available() to really parse any pending
source data that is still available in the adapter. This is a memory
optimization to avoid expansion of video packed added to the adapter,
but also a fix to EOS condition when the subclass parse() function
ultimately only needed to call into gvd_have_frame() and no additional
source bytes were consumed, i.e. gvd_add_to_frame() is not called.
This situation can occur when decoding H.264 streams in byte-stream/nal
mode for instance. A decoder always requires the next NAL unit to be
parsed so that to determine picture boundaries. When a new picture is
found, no byte is consumed (i.e. gvd_add_to_frame() is not called)
but gvd_have_frame() is called (i.e. priv->current_frame is gone).
Also make sure to avoid infinite loops caused by incorrect subclass
parse() implementations. This can occur when no byte gets consumed
and no appropriate indication (GST_VIDEO_DECODER_FLOW_NEED_DATA) is
returned.
https://bugzilla.gnome.org/show_bug.cgi?id=731974
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Make the MIKEY message and payload objects miniobjects so that they have
a GType and are refcounted.
We can reuse the dispose method to clear our payload objects.
Add some annotations.
Implement a copy function for the MIKEY message.
Fix the unit test.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=732589
Recognize H.264 Level 5.2, as exposed by modern 2160p30+ streams,
i.e. commonly known as 4K. Also add initial support for handling
Annex.G (SVC) profiles.
https://bugzilla.gnome.org/show_bug.cgi?id=732269
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
With most decoder libraries, and especially when accessing codecs via
OpenMAX or similar APIs, we don't have the ability to properly related
the output buffers to a number of input samples. And could e.g. get
a fractional number of input buffers decoded at a time.
Previously this would in the end lead to an error message and stopped
playback. Change it to a warning message instead and try to handle it
gracefully. In theory the subclass can now get timestamp tracking
wrong if it completely misuses the API, but if on average it behaves
correct (and gst-omx and others do) it will continue to work properly.
Also add a test for the new behaviour.
We don't change it in the encoder yet as that requires more internal logic
changes AFAIU and I'm not aware of a case where this was a problem so far.
We are scaling from a unit in microseconds to a unit in ((1 << 32) per seconds).
We therefore scale the microseconds values by:
value of a second in the target unit (1 << 32)
--------------------------------------------------------------
value of a second in the origin format (1 000 000 microsecond)
A simple '&' is not sufficiant. With mmapping_flags == PROT_READ and
prot == PROT_READ|PROT_WRITE the check produces the wrong result.
Change the check to make sure that prot is a subset of mmapping_flags.
https://bugzilla.gnome.org/show_bug.cgi?id=730559