- Sep 19, 2013
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Sep 18, 2013
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Sep 17, 2013
-
-
Olivier Crête authored
-
- Sep 16, 2013
- Sep 12, 2013
-
-
Wim Taymans authored
Delay forwarding the segment event until we pushed caps. Send STREAM_START in pull mode.
-
Sebastian Dröge authored
They tend to be inaccurate and having them in the sinkpad caps prevents playback of files that would otherwise play fine.
-
- Sep 10, 2013
-
-
Thiago Santos authored
Pass the seqnum to other events that are consequence of the original seek event
-
Sebastian Dröge authored
-
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/
-
- Sep 09, 2013
- Sep 05, 2013
-
-
Olivier Crête authored
-
Olivier Crête authored
In 1.0, segment events are sticky and not additive, no need to prevent their accumulation.
-
Tim-Philipp Müller authored
-
- Sep 04, 2013
-
-
Julien Isorce authored
So that GstEGLImageBufferPool does not depend on GstEglGlesSink The goal is still to move it into gstegl lib
-
Julien Isorce authored
Because it does not use it and also it may not know it when we create the pool
-
Julien Isorce authored
The goal here is to prepare GstEGLBufferPool to be moved into gstegl lib. So it has to not depend on 'gst_eglglessink_queue_object'
-
Julien Isorce authored
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
-
- Sep 03, 2013
-
-
Sebastian Dröge authored
It used FLOAT_SAMPLES/INTEGER_SAMPLES #defines instead of ones properly prefixed with a namespace. https://bugzilla.gnome.org/show_bug.cgi?id=707390
-
Tim-Philipp Müller authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
-
- Sep 02, 2013
-
-
Tim-Philipp Müller authored
-
Someone might be waiting for certain events with a probe. https://bugzilla.gnome.org/show_bug.cgi?id=707317
-
Andoni Morales Alastruey authored
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
-
Tim-Philipp Müller authored
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
-
Tim-Philipp Müller authored
-
-
- Aug 30, 2013
-
-
Josep Torra authored
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'
-
Josep Torra authored
gstmpdparser.h:530: warning: type qualifiers ignored on function return type gstmpdparser.c:4177: warning: type qualifiers ignored on function return type
-
Edward Hervey authored
note: I/SI also covers the S_I/S_SI variants
-
- Aug 29, 2013
-
-
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
-
Tim-Philipp Müller authored
-
-
-