- 14 Nov, 2016 3 commits
-
-
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 21 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
-
-
-
Sebastian Dröge authored
This was also wrong for JPEG2000. Also write it for all MOV files and JPEG2000, not only for ProRes. https://bugzilla.gnome.org/show_bug.cgi?id=769048
-
Sebastian Dröge authored
This is working around some broken software. https://bugzilla.gnome.org/show_bug.cgi?id=769048
-
-
Vivia Nikolaidou authored
These required atoms are: colorimetry, field information, spatial/temporal quality, and vendor. https://bugzilla.gnome.org/show_bug.cgi?id=769048
-
Stian Selnes authored
Some buggy payloaders, e.g. rtph263pay, may use mode B for packets that starts with a picture (or GOB) start code although it's not allowed. Let's be nice and not drop these packets/frames. https://bugzilla.gnome.org/show_bug.cgi?id=773516
-
Havard Graff authored
Fix leaking caps when downstream has not-fixed caps. https://bugzilla.gnome.org/show_bug.cgi?id=773515
-
-
Stian Selnes authored
Bump the bitstream parsing to TRACE log level so it doesn't flood the output when trying to read the more useful DEBUG and LOG messages. Also use GST_DEBUG_OBJECT instead of GST_DEBUG in various places https://bugzilla.gnome.org/show_bug.cgi?id=773514
-
Stian Selnes authored
Altough commits 6a16be75, 64f9d08d and 0c7e3a86 fixed some issues they introduced others. This patch fixes the leak of one macroblock for every B fragment. Macroblock structures must not be freed immediately after finding the boundaries as they are stored and used later. However the inital dummy structure (used for finding the first boundary) must be freed. CID #1212156 https://bugzilla.gnome.org/show_bug.cgi?id=773512
-
Alejandro G. Castro authored
Add a check to verify all the output buffers were empty for the session in a timout and log an error. https://bugzilla.gnome.org/show_bug.cgi?id=773269
-
Alejandro G. Castro authored
Instead of sending EOS when a source byes we have to wait for all the sources to be gone, which means they already sent BYE and were removed from the session. We now handle the EOS in the rtcp loop checking the amount of sources in the session. https://bugzilla.gnome.org/show_bug.cgi?id=773218
-
-