| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
segment.time and segment.start can stay the same, and were always the same
before anyway because of a mistake.
https://bugzilla.gnome.org/show_bug.cgi?id=755623
|
|
|
|
|
|
|
| |
This unbreaks building when some headers are under a non-standard path.
e.g. /usr/X11R6/include as on OpenBSD.
https://bugzilla.gnome.org/show_bug.cgi?id=755850
|
|
|
|
|
|
|
| |
Remove weird use of private gtype defines and fix compilation
with older glib versions such as 2.36.
https://bugzilla.gnome.org/show_bug.cgi?id=755754
|
| |
|
|
|
|
|
|
|
| |
Fixes this error with chromium gpu process:
GL_INVALID_OPERATION, glBindBuffer: buffer bound to more than 1 target
https://bugzilla.gnome.org/show_bug.cgi?id=755618
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=755456
|
|
|
|
|
| |
557ca6fda5f831be4aba5819bf7b30b296e575cd didn't change to the
necessary gst_gl_window_resize() call for the dispmanx backend.
|
|
|
|
|
|
|
| |
When in live mode, the queue needs to hold the currently processed
buffer and one more at least.
https://bugzilla.gnome.org/show_bug.cgi?id=754851
|
|
|
|
|
|
|
| |
It was only added during 1.5.x so we might just as well remove it
immediately.
https://bugzilla.gnome.org/show_bug.cgi?id=754686
|
|
|
|
|
|
| |
Keep old define around for now.
https://bugzilla.gnome.org/show_bug.cgi?id=754686
|
|
|
|
|
| |
557ca6fda5f831be4aba5819bf7b30b296e575cd introduced the queueResize
call without implementing the selector
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- glimagesink needs to be able to resize the viewport on aspect ratio
changes resulting from either caps changes or 3d output mode changes.
- Performing a glViewport outside the GstGLWindow::resize callback
will not have the winsys' stack of viewports required to correctly
place the output frame.
Provide a function to request a resize on the next draw event from the
winsys.
Also track size changes inside the base GstGLWindow class rather
than in each subclass.
https://bugzilla.gnome.org/show_bug.cgi?id=755111
|
|
|
|
| |
small typo s/width/height/
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=755140
|
|
|
|
|
|
|
|
|
|
|
| |
dashdemux seeks each live stream to its current fragment in the beginning, but
the base class does not know about this. Update the demuxer segment with this
seek so we generate the correct SEGMENT event and can actually play the
stream.
This needs some refactoring at some point.
https://bugzilla.gnome.org/show_bug.cgi?id=755047
|
|
|
|
|
|
|
| |
Prevents overwriting other conditions that would be more important,
such as EOS.
https://bugzilla.gnome.org/show_bug.cgi?id=755042
|
|
|
|
|
|
|
|
| |
when allocating memory. Fixes crashes with avdec_h265 in the AVX2
code path which requires 32-byte stride alignment, but the
GstAllocationParams only specified a 16-byte alignment.
https://bugzilla.gnome.org/show_bug.cgi?id=754120
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have to queue buffers based on their running time, not based on
the segment position.
Also return running time from GstAggregator::get_next_time() instead of
a segment position, as required by the API.
Also only update the segment position after we pushed a buffer, otherwise
we're going to push down a segment event with the next position already.
https://bugzilla.gnome.org/show_bug.cgi?id=753196
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=753196
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Each period will start again with pts 0 + period presentation offset, which is
also going to be the presentation time inside the container stream if any.
However all periods together should form a continuous timeline, with regard to
stream time and running time.
For making this possible we keep track of the "user requested segment", i.e.
the seek events, inside the demuxer without adjusting anything and taking this
demuxer segment only as orientation for modified segments per stream.
This per stream segments will have their segment.start at pts that would be
produced for this stream in this period, and the segment.base/time adjusted so
that this pts maps to the running and stream time this period should have in
the context of all other periods.
https://bugzilla.gnome.org/show_bug.cgi?id=754222
|
|
|
|
|
|
|
|
|
|
|
|
| |
Only accept alpha if downstream has alpha as well. It could
theoretically accept alpha unconditionally if blending is
properly implemented for handle it but at the moment this
is a missing feature.
Improves the caps query by also comparing with the template
caps to filter by what the subclass supports.
https://bugzilla.gnome.org/show_bug.cgi?id=754465
|
|
|
|
|
|
|
|
|
|
|
| |
If short_term_ref_pic_set_sps_flag is FALSE, the ShortTermRefPicSet
structure is supposed to derive from slice header. Which means,
CurrRpsIdx is equal to num_short_term_ref_pic_sets. But the number
of refpicsets communicated via sps header is only num_short_term_ref_pic_sets - 1.
And we are using slice_header structure to reference the last entry, which is
ShortTermRefPicSet[num_short_term_ref_pic_sets].
https://bugzilla.gnome.org/show_bug.cgi?id=754834
|
|
|
|
|
|
| |
Fix the default_scaling_list values based on Table 7-6
https://bugzilla.gnome.org/show_bug.cgi?id=754834
|
|
|
|
|
|
|
|
| |
HAVE_IOS is only defined for the build of this module so
attempting to use gstgl in iOS would result in incorrect GL
includes.
Use GST_GL_HAVE_PLATFORM_EAGL instead for choosing the iOS GL
header.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=754757
|
|
|
|
|
|
|
|
|
| |
next line
Also binding the framebuffer again is unnecessary then as it was just bound a
few lines before while the context was current.
https://bugzilla.gnome.org/show_bug.cgi?id=754757
|
|
|
|
|
|
|
| |
The videoaggregator can convert PAR, there is no reason for
restricting it.
https://bugzilla.gnome.org/show_bug.cgi?id=754291
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=753806
|
|
|
|
|
|
|
|
|
|
|
|
| |
Section 6.5.1: Coding tree block raster and tile scanning conversion process
Follow the equations 6-3 and 6-4
This will provide correct offset_max in slice_header for parsing
num_entry_point_offsets.
https://bugzilla.gnome.org/show_bug.cgi?id=754024
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
|
|
|
|
|
|
| |
gst_gl_window_get_context() returns a new reference.
Hopefully fixes https://bugzilla.gnome.org/show_bug.cgi?id=753758
|
|
|
|
|
|
|
|
| |
As per 7-42 and 7-43 the ScalingFactor's scanIdx is 0,
which is "up-right-diagonal" scan. Add APIs for converting
up-right-diagonal to raster and vise versa.
https://bugzilla.gnome.org/show_bug.cgi?id=754024
|
|
|
|
|
|
|
|
| |
Being more strict on specification, According to 7.4.7.3,
delta_chroma_log2_weight_denom should be in the range of
[(0 - luma_log2_weight_denom), (7 - luma_log2_weight_denom)]
https://bugzilla.gnome.org/show_bug.cgi?id=754024
|
|
|
|
|
|
|
|
| |
During allocation query, when this element is not passthrough, it must
relay the overlay compostion meta and it's parameters. Fortunatly, base
transform can do this for us.
https://bugzilla.gnome.org/show_bug.cgi?id=753850
|
|
|
|
|
|
|
|
| |
GL_SHADING_LANGUAGE_VERSION was introduced since ES 2.0, but in some
android emulator doesn't support this feature. To prevent confusion for
developer, the error message need to be more clear.
https://bugzilla.gnome.org/show_bug.cgi?id=753905
|
|
|
|
|
|
|
|
| |
Removes the redundant GL object creation/deletion on every
decide_allocation call which is being called for every caps change.
Thus reduces the required GL state changes on reconfigure events
which are being sent by glimagesink/xvimagesink
|
|
|
|
|
|
|
| |
Otherwise it might be unset, and then the buffer is used and
gst_video_frame_map() will crash because of invalid video-info.
https://bugzilla.gnome.org/show_bug.cgi?id=753805
|
|
|
|
|
|
|
|
|
|
| |
Instead of checking for the gstreamer-video-1.0 package is installed,
just assume it is since we already check for the -base dependency.
With this replace the GST_VIDEO_* variables in makefiles and directly
link with libgstvideo.
https://bugzilla.gnome.org/show_bug.cgi?id=753820
|
|
|
|
|
|
| |
As we only expose the mapped portion of the frame into the GL
memory object (and not the original padding) we need to
re-calculate the size and offset.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are several cases where a HLS server could temporarily have wrong
fragments, or reconfigure the playlist. In those cases, when we get
fragment download failures, we *really* want to wait a bit (for the next
playlist update) before retrying to get fragments.
Previously this method was first checking to see if there was next fragments
(according to the previous manifest update) before waiting for the next update.
The problem was that if that if there is a temporary failure on the server,
that's uncorrelated to whether the manifest contains next fragments or not.
|
| |
|
|
|
|
|
|
| |
As the upload is asynchronous, we need to enable the sync meta to
gain correct rendering. The buffer pool receiver don't know about
that.
|
|
|
|
| |
GLclampd does not exist on GLES, only desktop GL.
|
|
|
|
|
|
| |
The ClearDepth call is missing.
https://bugzilla.gnome.org/show_bug.cgi?id=753639
|
|
|
|
|
|
|
|
|
|
|
| |
The SPS struct might be filled out by a call to
gst_h264_parser_parse_subset_sps, which fills out
dynamically allocated data and requires a call
to gst_h264_sps_clear() to free it. Also make sure
to clear out any allocated SPS data when returning
an error.
https://bugzilla.gnome.org/show_bug.cgi?id=753306
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The urn:mpeg:dash:utc:http-head:2014 method of time synchronisation
uses an HTTP HEAD request to a specified URL and then parses the
Date: HTTP response header.
This commit adds support to dashdemux for this method of time
synchronisation by making a HEAD request and then parsing the Date:
response.
This commit adds support to gstfragment to return the HTTP headers
and to uridownloader to support HEAD requests. To avoid creating a
new API, the RANGE get function is re-used (abused?) with start=-1
and end=-1 to indicate a HEAD request.
https://bugzilla.gnome.org/show_bug.cgi?id=752413
|
|
|
|
|
|
|
|
|
|
|
| |
ChromaLog2WeightDenom = luma_log2_weight_denom + delta_chroma_log2_weight_denom
The value of ChromaLog2WeightDenom should be in the range of 0 to 7 and
the value luma_log2_weight_denom should be also in the range of 0 to 7.
Which means , delta_chroma_log2_weight_denom can have values in the range
between -7 and 7.
https://bugzilla.gnome.org/show_bug.cgi?id=753552
|