- 18 Nov, 2016 5 commits
-
-
Sebastian Dröge authored
And return FLUSHING instead of NOT_NEGOTIATED on flushing pads. https://bugzilla.gnome.org/show_bug.cgi?id=774623
-
Sebastian Dröge authored
And return FLUSHING instead of NOT_NEGOTIATED on flushing pads. https://bugzilla.gnome.org/show_bug.cgi?id=774623
-
Sebastian Dröge authored
And consider negotiation failures on flushing pads as FLUSHING, not as NOT_NEGOTIATED. https://bugzilla.gnome.org/show_bug.cgi?id=774623
-
Sebastian Dröge authored
Return NOT_NEGOTIATED if sending the caps event fails, or FLUSHING if the pad was flushing at that point. https://bugzilla.gnome.org/show_bug.cgi?id=774623
-
-
- 17 Nov, 2016 3 commits
-
-
Vinod Kesti authored
splitmuxsink requests pad from element using pad template like "video_%u", "audio_%u" and "sink_%d". This is true for most of the muxers. But splitmuxsink not able to request pad to flvmux as flvmux has "audio" and "video" as pad templates. fix: splitmuxsink should fallback to "audio" and "video" when template not found. https://bugzilla.gnome.org/show_bug.cgi?id=774507
-
-
Nicola Murino authored
This is the same change as a3a55305 for the parser. https://bugzilla.gnome.org/show_bug.cgi?id=774566
-
- 16 Nov, 2016 1 commit
-
-
Philippe Normand authored
A new signal named on-bundled-ssrc is provided and can be used by the application to redirect a stream to a different GstRtpSession or to keep the RTX stream grouped within the GstRtpSession of the same media type. https://bugzilla.gnome.org/show_bug.cgi?id=772740
-
- 15 Nov, 2016 2 commits
-
-
Vinod Kesti authored
aacparse resizes input buffer while converting ADTS stream to RAW, During buffer resize buffer write permission is not checked. This throws gst_buffer_is_writable assertion and leads to AV sync issue some times. It is corrected by making buffer writeable using gst_buffer_make_writable https://bugzilla.gnome.org/show_bug.cgi?id=774129
-
Seungha Yang authored
TIME segment implies that stream/running time is being handled by upstream. So, we shouldn't override it without any clue. This patch is for fixing seek in DASH streaming. https://bugzilla.gnome.org/show_bug.cgi?id=774196
-
- 14 Nov, 2016 4 commits
-
-
Arun Raghavan authored
-
Sebastian Dröge authored
The accumulator is filled by intersecting with all the pad caps, as such it must be initialized with ANY (like it is before the iteration is started) and not to EMPTY. Fixes the CAPS query always returning EMPTY caps when resyncing happened during the query, e.g. because pads were added/removed.
-
Petr Kulhavy authored
The g_object_unref (saddr) before receiving message seems to be redundant as it is done just before jumping to retry Though not directly related, part of https://bugzilla.gnome.org/show_bug.cgi?id=772841
-
Petr Kulhavy authored
Control messages are used only in multicast mode - to detect if the destination address is not ours and possibly drop the packet. However in non-multicast modes the messages are still allocated and freed even if not used. Therefore request control messages from g_socket_receive_message() only in multicast mode. https://bugzilla.gnome.org/show_bug.cgi?id=772841
-
- 12 Nov, 2016 2 commits
-
-
Scott D Phillips authored
The underlying integer type of the enum GstVideoMultiviewFlags is implementation defined and may not have the same size as guint. https://bugzilla.gnome.org/show_bug.cgi?id=774293
-
-
- 11 Nov, 2016 1 commit
-
-
- 10 Nov, 2016 2 commits
-
-
-
Sean DuBois authored
Allow users to set metadatacreator value in the meta packet https://bugzilla.gnome.org/show_bug.cgi?id=774131
-
- 08 Nov, 2016 1 commit
-
-
Vivia Nikolaidou authored
Do not use last buffer TS + buffer duration because buffer duration might be inaccurate, especially for frame rates like 30fps where a rounding error is observed. https://bugzilla.gnome.org/show_bug.cgi?id=773785
-
- 04 Nov, 2016 3 commits
-
-
Havard Graff authored
When doing rtx, the jitterbuffer will always add an rtx-timer for the next sequence number. In the case of the packet corresponding to that sequence number arriving, that same timer will be reused, and simply moved on to wait for the following sequence number etc. Once an rtx-timer expires (after all retries), it will be rescheduled as a lost-timer instead for the same sequence number. Now, if this particular sequence-number now arrives (after the timer has become a lost-timer), the reuse mechanism *should* now set a new rtx-timer for the next sequence number, but the bug is that it does not change the timer-type, and hence schedules a lost-timer for that following sequence number, with the result that you will have a very early lost-event for a packet that might still arrive, and you will never be able to send any rtx for this packet. Found by Erlend Graff - erlend@pexip.com https://bugzilla.gnome.org/show_bug.cgi?id=773891
-
Havard Graff authored
The lost-event was using a different time-domain (dts) than the outgoing buffers (pts). Given certain network-conditions these two would become sufficiently different and the lost-event contained timestamp/duration that was really wrong. As an example GstAudioDecoder could produce a stream that jumps back and forth in time after receiving a lost-event. The previous behavior calculated the pts (based on the rtptime) inside the rtp_jitter_buffer_insert function, but now this functionality has been refactored into a new function rtp_jitter_buffer_calculate_pts that is called much earlier in the _chain function to make pts available to various calculations that wrongly used dts previously (like the lost-event). There are however two calculations where using dts is the right thing to do: calculating the receive-jitter and the rtx-round-trip-time, where the arrival time of the buffer from the network is the right metric (and is what dts in fact is today). The patch also adds two tests regarding B-frames or the “rtptime-going-backwards”-scenario, as there were some concerns that this patch might break this behavior (which the tests shows it does not).
-
Havard Graff authored
The new timeout is always going to be (timeout + delay), however, the old behavior compared the current timeout to just (timeout), basically being (delay) off. This would happen if rtx-delay == rtx-retry-timeout, with the result that a second rtx attempt for any buffers would be scheduled immediately instead of after rtx-delay ms. Simply calculate (new_timeout = timeout + delay) and then use that instead. https://bugzilla.gnome.org/show_bug.cgi?id=773905
-
- 03 Nov, 2016 2 commits
-
-
-
Sebastian Dröge authored
We would like to check later on EOS if we found a known stream type or not, to possibly post an error message. https://bugzilla.gnome.org/show_bug.cgi?id=773861
-
- 02 Nov, 2016 5 commits
-
-
Sebastian Dröge authored
That tends to crash.
-
Jan Schmidt authored
The API was reverted. Just use the plain gst_video_colorimetry_to_string() function.
-
Jan Schmidt authored
Commit 83e718 added a pad template to splitmux request pads, which means that GstElement now releases the pads on dispose, but after having removed all elements in the bin and unlinked them. Make sure we can handle cleanup in that case without throwing assertions. https://bugzilla.gnome.org/show_bug.cgi?id=773784
-
Jan Schmidt authored
GES relies on the EOS event having the seqnum of the seek that caused it.
-
Jan Schmidt authored
Handle not-linked as for other fatal errors and post it onto the bus so the app knows
-
- 01 Nov, 2016 9 commits
-
-
Sebastian Dröge authored
qtdemux.c: In function ‘qtdemux_parse_tree’: qtdemux.c:10139:16: error: ‘color_table_id’ may be used uninitialized in this function [-Werror=maybe-uninitialized] if (color_table_id != 0) { ^ qtdemux.c:10121:19: note: ‘color_table_id’ was declared here guint16 color_table_id; ^~~~~~~~~~~~~~
-
-
Sebastian Dröge authored
The ProRes guidelines suggest an interleave of 0.5s is common, but specifies that for ProRes at most 2MB (for SD) and 4MB (for HD) should be used per chunk. It might also make sense to use similar numbers in general. https://bugzilla.gnome.org/show_bug.cgi?id=773217
-
Sebastian Dröge authored
Previously we were switching from one chunk to another on every single buffer. This wastes some space in the headers and, depending on the software, might depend in more reads (e.g. if the software is reading multiple samples in one go if they're in the same chunk). The ProRes guidelines suggest an interleave of 0.5s is common, but specifies that for ProRes at most 2MB (for SD) and 4MB (for HD) should be used per chunk. This will be handled in a follow-up commit. https://bugzilla.gnome.org/show_bug.cgi?id=773217
-
Sebastian Dröge authored
This is also required by some software to handle ProRes files. https://bugzilla.gnome.org/show_bug.cgi?id=769048
-
Sebastian Dröge authored
And also 4444 in the muxer. https://bugzilla.gnome.org/show_bug.cgi?id=769048
-
Sebastian Dröge authored
It's required for ProRes to work with other software. It is also in the MP4 standard, but inventing values here seems a bit tricky for the general case and it does not really give any extra information. https://bugzilla.gnome.org/show_bug.cgi?id=769048
-
-
-