See https://bugzilla.gnome.org/show_bug.cgi?id=773666
This would ideally be solved in baseparse but that requires further
thought at this point, and in the meantime it would be good to have
rawbaseparse not assert on this but handle it gracefully instead.
DVDs always have subpictures that start on an even Y
coordinate, but gstspu does more generic vobsubs these
days, so handle ones that start on an odd vertical position.
https://bugzilla.gnome.org/show_bug.cgi?id=777400
timecodestamper will post an element message which contains the current
timecode it just stamped. If a timecode was already found and not
replaced, it will still post it in a message.
https://bugzilla.gnome.org/show_bug.cgi?id=777048
... rather than when determining when to end the frame.
The opportunity to do so might not come when forced to drain,
and it seems nicer anyway to do so at parse wrapup time.
This happens if we had no CAPS event yet but e.g. got an EOS event. We
would then try to output a 0-sized buffer, but getting that from the
adapter will give an assertion, return NULL and then crash.
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
Compositor 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 frame->buffer, baseparse is doing that automatically for us. For
frame->output_buffer it doesn't and assumes that the subclass is already
doing that. Consistency!
This is useful e.g. if audio buffers should be exactly the duration of a
video frame, or if a audio buffers should never be too large because of
latency constraints.
The element is taking a fractional buffer duration, to allow working
with e.g. 1001/30000 as output duration and it accumulates rounding
errors in the buffer durations and compensates for them by making some
buffers one sample larger than the others.
https://bugzilla.gnome.org/show_bug.cgi?id=774689
We will allocate a screen area of width*height*bpp bytes, however this
calculation can easily overflow if too high width or height are given
inside the stream. Nonetheless we would just assume that enough memory
was allocated, try to fill it and overwrite as much memory as wanted.
Also allocate the screen area filled with zeroes to ensure that we start
with full-black and not any random (or not so random) data.
https://scarybeastsecurity.blogspot.gr/2016/11/0day-poc-risky-design-decisions-in.html
Ideally we should just remove this plugin in favour of the one in
gst-libav, which generally seems to be of better code quality.
https://bugzilla.gnome.org/show_bug.cgi?id=774533
Type cast has higher precedence than bitwise shift, so the third
argument will truncate to 8 bits and then shift right by 8 bits
resulting in constant zero.
https://bugzilla.gnome.org/show_bug.cgi?id=774293
Consistently use GST_ROUND_UP_4(width) as stride for
bayer buffers. Bayer data will usually come in widths
that are multiples of 4 anyway, so hopefully this
should not have any adverse impact on anyone in
practice.
Before, bayer2rgb required input buffers to are sized
accordingly, but then didn't actually round up when
calculating row offsets. rgb2bayer didn't use a rounded
stride nor buffer size.
https://bugzilla.gnome.org/show_bug.cgi?id=752014
rawvideoparse wouldn't error out on not-negotiated,
but would just keep on going, because it didn't pass
the flow return value back to the parent class and
thus upstream, so the source wouldnt' stop streaming.
MSVC warns about this because it's a C++ compiler, and this actually
results in useful things such as the incorrect 'gboolean' return value
for functions that return GstFlowReturn, so let's do explicit
conversions to reduce the noise and increase its efficacy.
With MSVC, this gives the following warning:
warning C4305: 'function': truncation from 'double' to 'gfloat'
Apparently, MSVC does not figure out what type to use for constants
based on the assignment. This warning is very spammy, so let's try to
fix it.
In file included from ../subprojects/gst-plugins-base/gst-libs/gst/video/video.h:27:0,
from ../subprojects/gst-plugins-bad/gst/segmentclip/gstvideosegmentclip.c:25:
../subprojects/gst-plugins-base/gst-libs/gst/video/video-format.h:27:39: fatal error: gst/video/video-enumtypes.h: No such file or directory
#include <gst/video/video-enumtypes.h>
^
compilation terminated.
https://ci.gstreamer.net/job/GStreamer-master-meson/269/console
In M2TS mode, we need an extra 4 bytes in the buffer, so need
to ensure the buffer can contain these. The allocation site
does not know the mode, so this is done in all cases.
This was a regression.
We only have a upstream-id via STREAM_START if we were in push-mode.
In pull-mode we need to create one.
Note: It would be good to eventually have that method (copied from
gst_pad_get_stream_id_internal()) public in the future
For each MpegTSBaseStream, we have a GstStream object which
subclasses can extend with information.
For each program a GstStreamCollection is created with all
GstStream from each stream.
When dealing with TIME-based input, the incoming stream could have
potentially changed completely.
In order to check whether it did or not, we need to re-check all sections
(PAT, PMT...). If it didn't, we will keep using the existing streams/pad,
and if it did we will act as if there was a program switch.
Fixes HLS streaming with decodebin3/playbin3
The default value of D-bit is changed to TRUE so discontinuity
is set for initial request and seek request as well.
Only set the e_bit flag for the CUSTOM_DOWNSTREAM event if
a cached buffer exists.
https://bugzilla.gnome.org/show_bug.cgi?id=770221
EAC3 bit streams shall be identified with a stream_type value of 0x87 when
transmitted as PES streams conforming to ATSC-published standards. It is specified
in ATSC Standard A/52.
https://bugzilla.gnome.org/show_bug.cgi?id=770528
The headers passed as parametter are relative to the build dir
basically "../subproject/gst-plugins-bad/gst-libs/gst/mpegts/XXX.h"
but that does not match what is needed at build time when building as
subproject, also we always add current dir as include_dir so we are
safe including directly.
And link mpegtsdemux against the 'math' library as it is needed.
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Matej Knopp <matej.knopp@gmail.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.
_stdint.h is generated by Autotools and we don't really need it. All
supported platforms now ship with stdint.h. The only stickler was MSVC,
and since Visual Studio 2015 it also ships stdint.h now.
After seeking in aiff files the information about the data end offset is
discarded, leading to audio artifacts with metadata chunks at the end of
a file.
This patch retains the end offset information after a seek event.
https://bugzilla.gnome.org//show_bug.cgi?id=769376
timecodewait receives a timecode as an argument (either as string or as
GstVideoTimeCode - one is gst-launch-friendly and the other is code-friendly),
and it will drop all audio and video buffers until that timecode has been
reached.
https://bugzilla.gnome.org/show_bug.cgi?id=766419
When draining a program, we might send a newsegment event on the pads
that are going to be removed (and then the pending data).
In order to do that, calculate_and_push_newsegment() needs to know
what list of streams it should take into account (instead of blindly
using the current one).
All callers to calculate_and_push_newsegment() and push_pending_data()
can now specify the program on which to act (or NULL for the default
one).
