Age | Commit message (Collapse) | Author | Files | Lines |
|
In order to be backwards compatible with previous behaviour, make sure
we don't end up using invalid offsets from the adapter
|
|
We need to reset ourself if the incoming discont buffer is *not* at
the beginning of a sample.
|
|
We actually need to make sure the returned sample has the same offset
as the input buffer since the find_index_* function will return the
sample just before the requested position.
|
|
The output of deinterlace at startup, or when receiving a new DISCONT
buffer, should have the DISCONT flag set on the first buffer.
|
|
Instead of guessing the right offset of the moof, use the exact
offset from the adapter.
|
|
This is to handle cases where upstream handles the fragmented streaming in TIME
base and sends us data with gaps within fragments. This would happen when dealing
with trick-modes.
When upstream (push-based, TIME SEGMENT) wishes to send discontinuous samples,
it must obey the following rules:
* The buffer containing the [moof] must have a valid GST_BUFFER_OFFSET
* The buffers containing the first sample after a gap:
* MUST start at the beginning of a sample,
* MUST have the DISCONT flag set,
* MUST have a valid GST_BUFFER_OFFSET relative to the beginning of the fragment.
|
|
That variable is only needed for a debug statement, move it there
|
|
No variables were added/removed. This was just a good excuse to:
* Comment what most variables are used for (and when)
* Order them in such a way as to show first the common variables used
in all cases, followed by those only used in push-mode
|
|
Let's just remove it, been commented for 7+ years :)
|
|
Makes it easier to trace what's going on
|
|
query position in GST_FORMAT_BUFFER returns
offset from start-index rather than index.
https://bugzilla.gnome.org/show_bug.cgi?id=752462
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=766870
|
|
Input buffer memory was not unmapped
https://bugzilla.gnome.org/show_bug.cgi?id=766870
|
|
gst_v4l2_object_probe_caps() was taking an extra ref on the returned
caps for no reason.
https://bugzilla.gnome.org/show_bug.cgi?id=766610
|
|
|
|
When early returning in gst_soup_http_src_read_buffer() because the
element is FLUSHING, we need to unmap and unref the buffer which was just created.
https://bugzilla.gnome.org/show_bug.cgi?id=766718
|
|
Some were forgotten.
See https://bugzilla.gnome.org/show_bug.cgi?id=765935
|
|
SEGMENT_DONE messages/events
See https://bugzilla.gnome.org/show_bug.cgi?id=765935
|
|
Also actually store the seqnum in pull mode seeks.
See https://bugzilla.gnome.org/show_bug.cgi?id=765935
|
|
The caps returned by gst_pad_get_current_caps() was never unreffed when
not early returning.
Fix a leak with the elements/deinterlace test.
https://bugzilla.gnome.org/show_bug.cgi?id=766558
|
|
Some endpoints (like Tandberg E20) can send BYE packet containing our
internal SSRC. I this case we would detect SSRC collision and get rid
of the source at some point. But because we are still sending packets
with that SSRC the source will be recreated immediately.
This brand new internal source will not have some variables incorrectly
set in its state. For example 'seqnum-base` and `clock-rate` values will be
-1.
The fix is not to act on BYE RTCP if it contains internal or unknown
SSRC.
https://bugzilla.gnome.org/show_bug.cgi?id=762219
|
|
Keeping the lock while emitting the stats signal introduces potential
deadlock in those situations when the signal callback wants the access
to rtpsession's properties which also requre the lock.
https://bugzilla.gnome.org/show_bug.cgi?id=762216
|
|
matroskademux would take the GST_OBJECT_LOCK in
- gst_matroska_demux_push_codec_data_all()
- gst_matroska_demux_query()
Some parse element such as FLAC checks upstream seekability, and
there is some use cases that matroska-demux is linked to a parse element
(e.g.,FLAC format) without intermediate elements (e.g., queue).
In this case, matroska-demux never returns from _push_codec_data_all()
because the parser can return only after it receives the response to
the upstream query, but that's not going to happen because it's
deadlocked.
Elements must not hold the object lock whilst pushing out events
or data.
https://bugzilla.gnome.org/show_bug.cgi?id=766645
|
|
freeing
Otherwise we might use an already freed list later and crash or worse.
|
|
|
|
gst_system_clock_obtain() returns a new ref.
https://bugzilla.gnome.org/show_bug.cgi?id=766521
|
|
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=758059
|
|
Fix a race in splitmuxsrc by properly connecting to the
demuxer signals we're interested in *before* setting it running.
|
|
|
|
The GST_BUFFER_OFFSET of output buffers returned to GstRtpBasePayload
should reflect the number of "samples" in the unit of the RTP clock in this
buffer. If this is not true, then it shouldn't be set.
https://bugzilla.gnome.org/show_bug.cgi?id=761943
|
|
Just use g_strcmp0 which can handle NULL entries
|
|
Directly setting audio/x-raw caps leads to problems when the delivered
data blocks do not align properly at sample boundaries (for example, a
data block with 391 bytes). So, instead, set audio/x-unaligned-raw to
let a parser be autoplugged.
https://bugzilla.gnome.org/show_bug.cgi?id=689460
|
|
segment_duration and media_time should be parsed based on version
of elst box. Specification defines that an elst box with version 1
has uint64 and int64 values for segment_duration and media_time,
respectively.
https://bugzilla.gnome.org/show_bug.cgi?id=766301
|
|
It might be that the request was aborted by the application and
we can return immediatelly
|
|
Remove from the session creation parameters
|
|
We already depend on 2.48
|
|
Non-blocking read will return the amount of data available without
blocking to wait for the full requested size.
The downside is that now it souphttpsrc needs to have a waiting
mechanism in case there is no data available yet to avoid busy
looping arond the inputstream.
|
|
the hash table
https://bugzilla.gnome.org/show_bug.cgi?id=766025
|
|
|
|
Set the async-handling property on GstBin to let it manage
async-handling instead of the local handling from the previous
commit. Works because of #174a5e in core
|
|
Replace the async API with the sync API to remove all the extra mainloop
and context handling. Currently it blocks reading until 'blocksize'
bytes are available but that can be improved by using:
https://developer.gnome.org/gio/unstable/GPollableInputStream.html#g-pollable-input-stream-read-nonblocking
https://bugzilla.gnome.org/show_bug.cgi?id=693911
|
|
Avoid using soup_server_run_async and old get_port() APIs,
replace with me soup_server_listen and get the port through the
URIs list returned from the server.
|
|
It causes the entire pipeline to fail, it should be easier to find.
|
|
When switching fragments, hide the async-start/async-done
messages from the parent bin, as otherwise we sometimes (very rarely)
hang in PAUSED instead of returning / continuing to PLAYING
state.
|
|
|
|
|
|
Fixes criticals with e.g.
videotestsrc num-buffers=1 ! identity drop-probability=1.0 ! avimux ! fakesink
https://bugzilla.gnome.org/show_bug.cgi?id=748700
|
|
header correctly.
1. according to RFC, T bit is only set when either the RTP packet only contains the J2K main header, or the packet contains tile parts from multiple tiles. This is now being managed correctly in the code. The second scenario cannot happen with our payloader, since tile headers are always placed in their own RTP packet, and so a packet cannot contain tile parts from multiple tiles.
However, I have added code to track if multiple tile parts are included in a single RTP packet, in case in the future we want to put header and data in same packet.
2. Old code would set the tile id to zero for all J2K packets. This is now set correctly to the appropriate tile id.
https://bugzilla.gnome.org/show_bug.cgi?id=745187
|
|
J2K main header framentation across multiple RTP packets is now handled correctly
https://bugzilla.gnome.org/show_bug.cgi?id=745187
|