There is no guarantee that the index positions are the same between
representations, and assuming this easily causes us to get into invalid
index positions.
If a MPD is On-Demand profile and no index described, demux will terminate
download loop after parsing inband SIDX with flow return custom-success.
At this moment, SIDX index is excat target position, but finish_fragment()
might cause re-advancing subfragment depending on MPD structure.
https://bugzilla.gnome.org/show_bug.cgi?id=776200
SIDX's base offset (i.e., byte offset of SIDX + sidx.first_offset)
mostly vary as per fragment. Also, target SIDX index must be zero for the
new fragment.
https://bugzilla.gnome.org/show_bug.cgi?id=776200
Try to find fragment using MPD first, then do refinement to find
target subframgnet using SIDX if possible. Note that, if target fragment
was moved from the previously activated one, we should assume that
the last SIDX is invalid for new fragment.
https://bugzilla.gnome.org/show_bug.cgi?id=776200
SIDX based playback is not restricted to SegmentBase, but it possible
with SegmentList/SegmentTemplate. In the latter case, each fragment
has its own SIDX box and might be subdivided into subfragment.
So, demux should not assume that the end of subfragment is the end
of stream. Moreover, should try advance subfragment only if there
are remaining subfragments.
With additional fixes by Sebastian Dröge <sebastian@centricular.com>
https://bugzilla.gnome.org/show_bug.cgi?id=776200
All code interacting with Objective-C objects should now use Automated
Reference Counting rather than manual memory management or Garbage
Collection. Because ARC prohibits C-structs from containing
references to Objective-C objects, all such fields are now typed
'gpointer'. Setting and gettings Objective-C fields on such a
struct now uses explicit __bridge_* calls to tell ARC about
object lifetimes.
https://bugzilla.gnome.org/show_bug.cgi?id=777847
hlsdemux tries to find type if given buffer size is large enought to
find type (currently the threshold is 2KB), or EOS in some cases.
However, since there can be small byte fragments such as WebVTT,
demux should try to find type at the end of a fragment
https://bugzilla.gnome.org/show_bug.cgi?id=779011
This appears to be the internal limit of voaacenc, higher
bitrates will be ignored and 128 kbps output will be produced
instead. Therefore, we might just as well limit the allowed
property values, so that people who try to set higher bitrates
get a big fat warning instead of silently a much lower bitrate.
The PCR_flag and PCR value is in adaptation_field, not in payload.
The MSB of adaptation_field_control is used as whether adaptation_
field is exist or not.
For the case(PCR in only adaptation_field without payload), we modify
checking condition about adaptation_field_control field.
https://bugzilla.gnome.org/show_bug.cgi?id=778731
When MPD@suggestedPresentationDelay is not present in the MPD,
dashdemux can provide default suggestedPresentationDelay. However
when applying default value of suggestedPresentationDelay, the value
should be subtracted from current time, not added to it. When streams
setup is performed and live point is calculated, we have to go to the
wall clock (current time) minus suggestedPresentationDelay, if we tried
to start with current time plus suggestedPresentationDelay, we would
be asking for future stream, which has not yet been recorded. Also
the value needs to be converted from ms to us.
https://bugzilla.gnome.org/show_bug.cgi?id=764726
For duration queries on live streams, adaptivedemux ignores the query.
The problem then is that the query is answered by the downstream
qtdemux element, with the duration of the currently passing fragment.
This commit changes the behaviour of adaptivedemux to answer the duration
queries for live streams, returning GST_CLOCK_TIME_NONE.
https://bugzilla.gnome.org/show_bug.cgi?id=753879
The same symbol also exists in libgstgl, although marked as private and
internal. This has no effect when doing static linking and there's a
symbol conflict.
When the sink receives a buffer that is neither a wl_shm one nor a
dmabuf one, this buffer is copied to an internal wl_shm buffer before
being sent to the display.
In that case, the actual size of the received buffer (which may differ
from the one negotiated in the caps) must be used.
https://bugzilla.gnome.org/show_bug.cgi?id=777841
Unless the video format has an alpha component (ARGB, ...), set the
video_surface opaque.
In the usual case where the black area_surface has the same size as the
video_surface (eg: run gst-play-1.0 video.mp4), this makes the black
surface totally occluded which makes weston compositor's life easier
since it can ignore that surface.
Also unconditionally set the black area_surface opaque.
https://bugzilla.gnome.org/show_bug.cgi?id=778078
Otherwise the destructor will never be called, and we would have to call
the constructors manually at some point... which we never did, so
calling release() on it before it got otherwise initialized caused a
crash. For example when running gst-inspect-1.0.
Vulkan handles are either pointers (64-bit) or 64-bit integer
handles (32-bit). Cast the type in failure cases.
vkwindow.c:229:561: error: return makes integer from pointer without a cast [-Werror=int-conversion]
vkwindow.c:231:194: error: return makes integer from pointer without a cast [-Werror=int-conversion]
https://bugzilla.gnome.org/show_bug.cgi?id=777979
hls live starts playback from the allowed latest fragment,
but its "sequence position" is set to zero, and so stream
time is also set to zero.
This does not make sense, because hls live allows seeking to past position,
and it's negative stream time from downstream element's point of view.
Note that, allowed seekable range (and seeking query) is
from the first fragment of playlist to the allowed latest fragment.
https://bugzilla.gnome.org/show_bug.cgi?id=777682
HLS spec 6.3.3 is saying that
"the client SHOULD NOT choose a segment which starts less than
three target durations from the end of the Playlist file."
To ensure above statement, the third fragment from the end of playlist
should be excluded from seekable range and also from available starting fragment.
(i.e., the fourth fragment from end of playlist is the starting fragment).
https://bugzilla.gnome.org/show_bug.cgi?id=777682
During live playback, the first fragment in a updated
playlist can be advanced from that of startup playlist.
Meanwhile, since hlsdemux finds target seek position
by just accumulating fragment's duration, the base should
be adjusted to the updated first fragment's timestamp.
https://bugzilla.gnome.org/show_bug.cgi?id=777682
vkimagememory.c:64:14: warning: implicit conversion from enumeration type 'GstVideoGLTextureType' to different enumeration type 'VkFormat' (aka 'enum VkFormat') [-Wenum-conversion]
return GST_VIDEO_GL_TEXTURE_TYPE_RGB16;
https://bugzilla.gnome.org/show_bug.cgi?id=777760
gstmpeg2enc.cc:224:5: warning: variable 'n' is incremented both in the loop header and in the loop body [-Wfor-loop-analysis]
n++;
^
gstmpeg2enc.cc:221:29: note: incremented here
for (n = 0; fpss[n] != 0; n++) {
^
Without failing, we would play back random parts of the stream which is
arguably a worse user experience, and failing is also recommended by the
spec here.
And also handle live streams without any media sequence numbers at all
properly, that is, make sure the sequence numbers are increasing instead
of starting again at 0 every time.
https://bugzilla.gnome.org/show_bug.cgi?id=775665
Parsing SIDX box was allowed even if "indexRange" attribute does not appear
for On-Demand profile. However, actual seeking using SIDX index did not happen
since download loop keep working on.
To use SIDX index in that case, demux should try it in the next download loop.
https://bugzilla.gnome.org/show_bug.cgi?id=777394
gst_caps_intersect () may return an increased reference of one of the
input caps.
Fixes critical in the simple-launch-lines test:
Unexpected critical/warning: gst_caps_set_features: assertion 'IS_WRITABLE (caps)' failed
Reset redraw_pending at display disconnection, so we can re-connect
later from a clean state (avoid endless buffer drops).
Add a log to inform of dropped buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=775791
sidx has "first_offset" syntax which represents the distance in bytes
from anchor point to media fragment. If present, we should adjust
sidx_base_offset.
https://bugzilla.gnome.org/show_bug.cgi?id=776431
Previous patch allows sidx box parsing from incoming buffers.
Since the incoming buffer boundary might be over sidx box,
there can be remaining buffer in isobmff parser adapter.
https://bugzilla.gnome.org/show_bug.cgi?id=776352
If they were not ported after 4+ years it seems unlikely that anybody is
ever going to need them again. They're still in the GIT history if
needed.
https://bugzilla.gnome.org/show_bug.cgi?id=774530
They often don't only contain the PCR information but also other
metadata, like title. Give this information to the pipeline.
Also strip the tags from the stream as we a) already parsed them now and
b) decoders don't like these tags to happen in the middle of the stream
(i.e. the start of each fragment) and tagdemux only can strip them off
the beginning and end.
middle textures in gleffects do not need to use GstGLMemoryPBO as they
aren't transfering data to/from the GPU. This will cost too much DMA
memory and cause performance issue. Change the allocator to use non-PBO
GstGLMemory.
https://bugzilla.gnome.org/show_bug.cgi?id=776072
glvideomixer does not support it currently and it needs special support
for handling this correctly, and is rather non-trivial to implement for
all formats.
For pre-1.1.x openssl, a callback to set the thread id needs to be
provided to openssl. In 0.9.x the thread id was an unsigned long. In
1.0.x it was expanded to be able to hold a void*. Here we change to use
the 1.0.x API so that the thread id can always hold a GThread*, even on
platforms like msvc x64 where unsigned long is only 32 bits.
All of this is still #ifdef'd out of existence when building with
openssl 1.1.x or later which changed the thread API again, and does not
need a thread id callback.
https://bugzilla.gnome.org/show_bug.cgi?id=775292
Simply produce the result into the output image provided by the base
class. This avoid useless copy. This also removes unchecked buffer map
and ensure that GstVideoMeta is respected (for stride mostly).
https://bugzilla.gnome.org/show_bug.cgi?id=775377
Simply produce the result into the output image provided by the base
class. This avoid useless copy. This also removes unchecked buffer map
and ensure that GstVideoMeta is respected (for stride mostly).
https://bugzilla.gnome.org/show_bug.cgi?id=775377
Simply produce the result into the output image provided by the base
class. This avoid useless copy. This also removes unchecked buffer map
and ensure that GstVideoMeta is respected (for stride mostly).
https://bugzilla.gnome.org/show_bug.cgi?id=775377
When a MSS server hosts a live stream the fragments listed in the
manifest usually don't have accurate timestamps and duration, except
for the first fragment, which additionally stores timing information
for the few upcoming fragments. In this scenario it is useless to
periodically fetch and update the manifest and the fragments list can
be incrementally built by parsing the first/current fragment.
https://bugzilla.gnome.org/show_bug.cgi?id=755036
The schroedinger headers unconditionally #define over C99's rint when
compiling with msvc which messes up the later inclusion of math.h.
Including math.h before schroedinger headers avoids getting syntax
errors in math.h
https://bugzilla.gnome.org/show_bug.cgi?id=775293
a) Use get_pkgconfig_variable() to get the opencv prefix
b) Place an upper limit on the opencv version
c) Ensure that headers are available
(b) and (c) just copy what the configure.ac checks do.
The way how strchr() was called here, it could easily read after the end
of the string. Use g_ascii_isspace() instead.
Detected by asan in the unit test.
When one is only updating the "stop" position (i.e. non-flushing seek,
with GST_SEEK_TYPE_NONE on the "start" (or stop in reverse) position),
we only need to store those values instead of moving the current position.
https://bugzilla.gnome.org/show_bug.cgi?id=775127
wldisplay.c:179:15: error: comparison of unsigned enum expression < 0 is always false [-Werror,-Wtautological-compare]
if (shm_fmt < 0)
~~~~~~~ ^ ~
gstsegmentation.cpp:419:40: error: implicit conversion from 'int' to 'char' changes value from 255 to -1 [-Werror,-Wconstant-conversion]
filter->cvFG->imageData[j] = 255;
~ ^~~
https://bugzilla.gnome.org/show_bug.cgi?id=775112
We set it to TRUE here, but later we set it to TRUE again anyway if the
parsing actually succeeded at this point. Let's keep the second one.
CID 1374360.
This was used by MSN messenger in prehistoric times, it's safe
to say no one needs or wants this any more these days. For
decoding old recordings there's still a decoder in ffmpeg.
https://bugzilla.gnome.org/show_bug.cgi?id=597616
Section 5.3.3 in ISO/IEC 23009-1:2014 defines that invalid references
(e.g., invalide URI or cannot be resolved) specified by "@xlink:href" attribute
shall be removed. That means, we should play it without error,
and just ignore the corresponding element.
It's similar to "urn:mpeg:dash:resolve-to-zero:2013".
https://bugzilla.gnome.org/show_bug.cgi?id=774463
It only offers one metric for now, "dssim", available if
https://github.com/pornel/dssim was installed on the system
at the time the plugin was compiled.
The spearman correlation for dssim against the TID2008 dataset
is 0.81, against 0.70 for the old ssim implementation, and
it runs 15 times faster.
https://bugzilla.gnome.org/show_bug.cgi?id=751324
External xml could have empty, one or multiple top-level "Period" elements.
Because xml parser cannot parse the multiple top-level elements
(i.e., no root element), we need to wrap a xml in order to make root element.
See also ISO/IEC 23009-1:2014 5.3.2.2
https://bugzilla.gnome.org/show_bug.cgi?id=774357
PlayReady being the one of the few DRM formats encoding its data with
base64 it was not consistent to have a special case for this. So the
base64 decoding operation now needs to be done by the protection event
consumer, if needed.
https://bugzilla.gnome.org/show_bug.cgi?id=774112
PlayReady being the one of the few DRM formats encoding its data with
base64 it was not consistent to have a special case for this. So the
base64 decoding operation now needs to be done by the protection event
consumer, if needed.
https://bugzilla.gnome.org/show_bug.cgi?id=774112
