gst_matroska_mux_best_pad adjusts the buffer timestamp to running time using
the segment stored in the pad's collect data. However, the event handler didn't
pass the newsegment event on to collectpads' handler, so this segment was never
updated at all.
Re-fixes bug #432612.
The RTP clock-rate used for G722 is 8000, even though the samplerate is
16000. Compensate for this by pretending G722 has 8 bits per sample
instead of the 4 bits as if it were a codec that ran at half the speed,
but with twice the number of bits. Fixes#661376
Since matroskademux will attempt to push unaligned buffers,
downstream might have trouble with those, especially if downstream
uses ORC, such as audioconvert.
Ensure we push buffers aligned to the basic type at least for
those raw buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=659798
... to at least having it trigger a/v synchronization, possibly without
using provided values which are still not considered sane
(as previously dropped).
... when operating in non slave mode, and reset if detected.
This should avoid some (large) bogus outgoing timestamp due to jumps
in rtp time, as result of PAUSE/PLAY or seek or ...
... at least if not syncing to NPT time:
* either sync using RTCP SR data (as currently)
* only perform the above once using initial RTCP SR packets
* discard RTCP and sync by equating provided stream's clock-base rtptime,
as provided by jitterbuffer (typically obtained from RTP-Info in RTSP).
Changed the ebml reader's gst_ebml_peek_id_length() function so
that it returns the actual reason for why the peek failed, instead
of (almost) always returning GST_FLOW_UNEXPECTED. This prevents
the pulling task from sending EOS when doing a flushing seek.
matroskademux performs segment tricks to skip gaps in streams,
notably at start for non 0 based files. There may however be
cases when full presentation (including intermediate gaps) is
desired, so a property allows to configure as of which gap
to act (or not at all).
API: GstMatroskaDemux::max-gap-time
Fixes#659009.
Subtract the first timestamp of a stream from all input buffers to
get 0-based timestamps for creating a sane ctts table. Without this
patch the ctts could have larger values than needed, causing the
playback to have a delay at startup.
As the first timestamp is only found after a few buffers are queued
(due to possible reordered buffers), once we find the first timestamp
we subtract it from all buffers on the queue, from that point on,
all buffers have their timestamps subtract when they are collected.
https://bugzilla.gnome.org/show_bug.cgi?id=658659
Frame duration might vary for 1 usecond, in this case matroskamux
decides to create BLOCKGROUP instead of SIMPLEBLOCK.
Convert duration to timecodescale which is (typically) less precise, and
then also allow the difference of 1/-1 to arrange for less sensitive check.
Based on patch by Alexey Fisher <bug-track@fisher-privat.net>
Fixes#653080.
Some encoders (Arecont) do not like the long OPTIONS sent at startup as sent by
GStreamer, but do accept the short header as sent by Live555.
This patch makes the extending the request optional by adding a property
(short-header).
Fixes#655805.
API: GstRTSPSrc:short-header
This likely breaks stuff. The good: all of the methods now create
field images aligned with input frames, without timestamp mangling.
The bad: this touches a lot of code, much of which is hairy and in
need of cleanup. However, at this point we can reasonably create a
PSNR-based test.
In particular, do so even if failing to read while prerolling,
such as when reading from a partial file (eg, while it is being
downloaded).
This fixes a wedge in playbin2.
https://bugzilla.gnome.org/show_bug.cgi?id=651965
Yes, I was tracking another bug and the small test file I generated
to test with improbably just happened to trigger this, with a second
and last frame of 1615 bytes.
https://bugzilla.gnome.org/show_bug.cgi?id=656649
We need to keep the lock held because we don't want a push before the "new-ssrc-pad"
handler has completed. But we may want to push an event from inside that handler, hence
the recursive mutex.
https://bugzilla.gnome.org/show_bug.cgi?id=650916
Some h264 payloaders are unfortunately buggy and don't correctly set the
E bit in FU-A NAL when they have ended. Work around this by assuming
such a fragmentation unit has ended when there was no packet loss and a
new NAL is started
When pushing out buffers over S/PDIF or HDMI, IEC 61937 payloading
requires each buffer to contain 6 blocks from each substream. This adds
code to collect all the frames needed to meet this requirement before
pushing out a buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=650313
Using the current RTCP interval to timeout SSRC collision can lead to
collisions being timed out immediately if a BYE packet is sent because
it is sent immediately, so the interval is 0. This is not what we
want. So just set a static 10 times the default RTCP interval, it
should be enough
https://bugzilla.gnome.org/show_bug.cgi?id=648642
... which is particularly needed when merging NAL units, where not resetting
would lead to output of an older (pre-flush) AU (with unintended timestamp).
Current matroska demux calculates the pixel aspect ratio only if both
DisplayHeight and DisplayWidth are set, but it is legal to use only
one variable if the other is equal to PixelWidth or PixelHeight, at
least the mkclean utility is doing that. So this makse mkcleaned
files play correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=654744
A missing sys/param.h include results in:
/usr/include/sys/proc.h:64: error: 'MAXLOGNAME' undeclared here (not in a
function)
/usr/include/sys/proc.h:285: error: 'MAXCOMLEN' undeclared here (not in a
function)
when compiling goom on openbsd/ppc. We can just remove the two sys/ includes
here, they are not needed for anything.
https://bugzilla.gnome.org/show_bug.cgi?id=654749
