Age | Commit message (Collapse) | Author | Files | Lines |
|
It is quite possible that we might get PTS/DTS before the first
PCR/Offset observation.
In order to end up with valid timestamp we wait until at least one
stream was able to get a proper running-time for any PTS/DTS.
Until then, we queue up the pending buffers to push out.
Once we see a first valid timestamp, we re-evaluate the amount of
running-time elapsed (based on returned inital running-time and amount
of data/DTS queued up) for any given stream.
Taking the biggest amount of elapsed time, we set that on the packetizer
as the initial offset and recalculate all pending buffers running-time
PTS/DTS.
Note: The buffer queueing system can also be used later on for the
dvb fast start proposal (where we queue up all stream packets before
seeing PAT/PMT and then push them once we know if they belong to the
chosen program).
|
|
|
|
This allows:
* Better duration estimation
* More accurate PCR location
* Overall more accurate running-time location and calculation
Location and values of PCR are recorded in groups (PCROffsetGroup)
with notable PCR/Offset observations in them (when bitrate changed
for example). PCR and offset are stored as 32bit values to
reduce memory usage (they are differences against that group's
first_{pcr|offset}.
Those groups each contain a global PCR offset (pcr_offset) which
indicates how far in the stream that group is.
Whenever new PCR values are observed, we store them in a sliding
window estimator (PCROffsetGroupCurrent).
When a reset/wrapover/gap is detected, we close the current group with
current values and start a new one (the pcr_offset of that new group
is also calculated).
When a notable change in bitrate is observed (+/- 10%), we record
new values in the current group. This is a compromise between
storing all PCR/offset observations and none, while at the same time
providing better information for running-time<=>offset calculation
in VBR streams.
Whenever a new non-contiguous group is start (due to seeking for example)
we re-evaluate the pcr_offset of each groups. This allows detecting as
quickly as possible PCR wrapover/reset.
When wanting to find the offset of a certain running-time, one can
iterate the groups by looking at the pcr_offset (which in essence *is*
the running-time of that group in the overall stream).
Once a group (or neighbouring groups if the running-time is between two
groups) is found, once can use the recorded values to find the most
accurate offset.
Right now this code is only used in pull-mode , but could also
be activated later on for any seekable stream, like live timeshift
with queue2.
Future improvements:
* some heuristics to "compress" the stored values in groups so as to keep
the memory usage down while still keeping a decent amount of notable
points.
* After a seek compare expected and obtained PCR/Offset and if the
difference is too big, re-calculate position with newly observed
values and seek to that more accurate position.
Note that this code will *not* provide keyframe-accurate seeking, but
will allow a much more accurate PCR/running-time/offset location on
any random stream.
For past (observed) values it will be as accurate as can be.
For future values it will be better than the current situation.
Finally the more you seek, the more accurate your positioning will be.
Conflicts:
gst/mpegtsdemux/mpegtspacketizer.c
gst/mpegtsdemux/mpegtspacketizer.h
|
|
These are not public headers, it just adds complexity for no reason
|
|
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
|
|
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=703520
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=703520
|
|
including the following supports and fixes:
* Create DirectFB surfaces from GstBufferPool
* Add NV12 pixel format support
* Don't use the cursor in the exclusive mode
- EnableCusor() can be only used when the administrative mode is set
in DirectFB 1.6.0 and later.
* Support multiple plane rendering for planar color formats
- This accommodates the chroma plane offsets of the framebuffer
in planar formats.
* Invoke SetConfiguration regardless of video mode setting in setcaps()
- SetConfiguration() method should be invoked regardless of
the result of gst_dfbvideosink_get_best_vmode(), since the two are
unrelated.
* Disable DirectFB signal handler
- "--dfb:no-sighandler" option is passed to DirectFBInit().
This prevents DirectFB from trying to kill the process and allows
GStreamer's termination sequence to proceed normally.
https://bugzilla.gnome.org/show_bug.cgi?id=703520
|
|
|
|
Signed-off-by: Bernhard Miller <bernhard.miller@streamunlimited.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=705452
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=705452
|
|
|
|
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=706285
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=655622
|
|
|
|
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=704760
|
|
|
|
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=706574
|
|
Due to function decorations on Windows AC_CHECK_LIB can't be used to check for bz2.
https://bugzilla.gnome.org/show_bug.cgi?id=465924
|
|
And remove a check which was done before
|