| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
From 6b03ba7 to 865aa20
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=702495
|
|
|
|
| |
From b613661 to 6b03ba7
|
| |
|
|
|
|
| |
It caused static linking to fail.
|
|
|
|
| |
From 74a6857 to b613661
|
|
|
|
| |
From 098c0d7 to 74a6857
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=708106
|
|
|
|
|
| |
Delay forwarding the segment event until we pushed caps.
Send STREAM_START in pull mode.
|
|
|
|
|
| |
They tend to be inaccurate and having them in the sinkpad caps
prevents playback of files that would otherwise play fine.
|
|
|
|
|
| |
Pass the seqnum to other events that are consequence of the
original seek event
|
| |
|
|
|
|
|
|
|
| |
modplug stopped exposing their directory in their pcfile, meaining
consumers accessing the headers directly fail to build.
http://sourceforge.net/p/modplug-xmms/git/ci/75e9b166982ed637b59ef7cbc1835a09f768923e/
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=705333
|
| |
|
|
|
|
|
| |
In 1.0, segment events are sticky and not additive, no need to prevent
their accumulation.
|
| |
|
|
|
|
|
| |
So that GstEGLImageBufferPool does not depend on GstEglGlesSink
The goal is still to move it into gstegl lib
|
|
|
|
|
| |
Because it does not use it and also it may not know it when
we create the pool
|
|
|
|
|
| |
The goal here is to prepare GstEGLBufferPool to be moved into
gstegl lib. So it has to not depend on 'gst_eglglessink_queue_object'
|
|
|
|
|
|
|
| |
into gstegl lib or splited between gstegl lib and gstgl lib
because it both depends on egl and gl
So it has to not depend on GstEglAdaptationContext
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When outputting in AVC3 stream format, the codec_data should not
contain any SPS or PPS, because they are embedded inside the stream.
In case of avc->bytestream h264parse will push the SPS and PPS from
codec_data downstream at the start of the stream, at intervals
controlled by "config-interval" and when there is a codec_data change.
In the case of avc3->bytstream h264parse detects that there is
already SPS/PPS in the stream and sets h264parse->push_codec to FALSE.
Therefore avc3->bytstream was already supported, except for the stream
type.
In the case of bystream->avc h264parse will generate codec_data caps
from the parsed SPS/PPS in the stream. However it does not remove these
SPS/PPS from the stream. bytestream->avc3 is the same as bytestream->avc
except that the codec_data must not have any SPS/PPS in it.
|--------------+-------------+-------------------|
|stream-format | SPS in-band | SPS in codec_data |
|--------------+-------------+-------------------|
| avc | maybe | always |
|--------------+-------------+-------------------|
| avc3 | always | never |
|--------------+-------------+-------------------|
Amendment 2 of ISO/IEC 14496-15 (AVC file format) is defining a new
structure for fragmented MP4 called "avc3". The principal difference
between AVC1 and AVC3 is the location of the codec initialisation
data (e.g. SPS, PPS). In AVC1 this data is placed in the initial MOOV box
(moov.trak.mdia.minf.stbl.stsd.avc1) but in AVC3 this data goes in the
first sample of every fragment.
https://bugzilla.gnome.org/show_bug.cgi?id=702004
|
|
|
|
|
|
|
| |
It used FLOAT_SAMPLES/INTEGER_SAMPLES #defines instead of ones properly
prefixed with a namespace.
https://bugzilla.gnome.org/show_bug.cgi?id=707390
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Someone might be waiting for certain events with a probe.
https://bugzilla.gnome.org/show_bug.cgi?id=707317
|
|
|
|
|
|
|
|
| |
On a device lost, all the surfaces allocated in the
device need to be released before resetting the device,
which can't be done for the allocated buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=706566
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Generate win32/common/config.h-new directly from config.h.in,
using shell variables in configure and some hard-coded information.
Change top-level makefile so that 'make win32-update' copies the
generated file to win32/common/config.h, which we keep in source
control. It's kept in source control so that the git tree is
buildable from VS.
This change is similar to the one recently applied to GStreamer
and gst-plugins-good. The previous config.h file in -bad was in
pretty bad shape, so unlike core and base, I didn't attempt to
leave it strictly the same, but fixed it as necessary. Needs
testing I cannot do myself.
https://bugzilla.gnome.org/show_bug.cgi?id=569015
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=707270
|
|
|
|
|
|
| |
gstdashdemux.c:1753: warning: format '%llu' expects type 'long long unsigned int', but argument 8 has type 'long unsigned int'
gstdashdemux.c:2224: warning: format '%llu' expects type 'long long unsigned int', but argument 9 has type 'guint64'
gstdashdemux.c:2224: warning: format '%llu' expects type 'long long unsigned int', but argument 10 has type 'guint64'
|
|
|
|
|
| |
gstmpdparser.h:530: warning: type qualifiers ignored on function return type
gstmpdparser.c:4177: warning: type qualifiers ignored on function return type
|
|
|
|
| |
note: I/SI also covers the S_I/S_SI variants
|
|
|
|
|
|
|
|
|
| |
gst_pad_get_negotiated_caps was removed from 1.0;
gst_pad_get_current_caps should be used instead. See
http://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/random
/porting-to-1.0.txt
https://bugzilla.gnome.org/show_bug.cgi?id=707074
|