- Feb 19, 2016
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
-
- Feb 18, 2016
-
-
Tim-Philipp Müller authored
Set GSETTINGS_BACKEND=memory, apparently there's something about fork() and the dconf backend (or whatever else that drags in or activates) that messes up locking and causes timeouts due to deadlocks in g_mutex_lock(), since everything works fine with CK_FORK=no as well.
-
Sebastian Dröge authored
Otherwise it will be mapped writable all the time and we can't read from it anywhere. https://bugzilla.gnome.org/show_bug.cgi?id=762239
-
Make sure that the packets queued when detecting a big gap are pushed after reset (5 consective seqnums) and not dropped. https://bugzilla.gnome.org/show_bug.cgi?id=762211
-
- Feb 17, 2016
-
-
Tim-Philipp Müller authored
-
Commit 7873bede (https://bugzilla.gnome.org/show_bug.cgi?id=760774) changed the behaviour of qtdemux to call gst_qtdemux_configure_stream() for every new moof. When playing a protected stream, gst_qtdemux_configure_stream() calls gst_qtdemux_configure_protected_caps(). The gst_qtdemux_configure_protected_caps() function takes the original media format, puts this in a field called "original-media-type" and then changes the caps to "application/x-cenc". The gst_qtdemux_configure_protected_caps() did not handle the case of being called multiple times, causing it to incorrectly set the caps. The second call was causing the caps to be set to: application/x-cenc, original-media-type"application/x-cenc" This commit makes gst_qtdemux_configure_protected_caps() check that the caps have already been transformed, so that it only gets changed once. https://bugzilla.gnome.org/show_bug.cgi?id=761769
-
Luis de Bethencourt authored
There is no need to have two identical implementations of the read_golomb function. https://bugzilla.gnome.org/show_bug.cgi?id=761606
-
When the trickmode key-units flag is set on the segment, simply skip any sample on a video stream that isn't a keyframe https://bugzilla.gnome.org/show_bug.cgi?id=762185
-
- Feb 16, 2016
-
-
Tim-Philipp Müller authored
Send GAP events for non-subtitle streams too if they lag too much behind, but use a higher threshold than for subtitles. This helps with fixing prerolling with a file where one of the audio streams only has data starting from 19s onwards. It's not a complete fix yet, it also requires changes elsewhere, such as in baseparse, to make sure caps are propagated. https://bugzilla.gnome.org/show_bug.cgi?id=614460 https://bugzilla.gnome.org/show_bug.cgi?id=753899
-
Quick and dirty implementation of an RTP payloader and depayloader for VP9. In particalur it assumes no spatial or temporal layering, non-flexible mode, and some other bits and pieces. https://bugzilla.gnome.org/show_bug.cgi?id=754773
-
codec_name is not being freed in all conditions leading to memory leak https://bugzilla.gnome.org/show_bug.cgi?id=762117
-
This gets the GstRTPSession element, as compared to the RTPSession object that is returned by get-internal-session. https://bugzilla.gnome.org/show_bug.cgi?id=759293
-
-
-
Tim-Philipp Müller authored
Looks like it just uses the NAL enums and nothing else from the codecparsers, and that's the only reason it had to be moved from -good to -bad when it was originally added. We can probably keep those NAL enums up to date enough, so let's remove the codecparser dependency so it can be moved back into -good. https://bugzilla.gnome.org/show_bug.cgi?id=761606
-
Tim-Philipp Müller authored
Move RTP H.265 payloader/depayloader from -bad to -good. https://bugzilla.gnome.org/show_bug.cgi?id=761606
-
Use gst_rtp_drop_meta() and the same function prototype for gst_rtp_copy_meta() to keep consistency with the RTP elements in gst-plugins-good
-
Only consider the access unit complete when the next-occurring VCL NAL unit has the first bit after its NAL unit header equal to 1.
-
We create a sub-buffer just to copy over its metas and then throw it away immediately, just use the original input buffer directly.
-
It's not enough to have timeout or event based VPS/SPS/PPS information sent in RTP packets. There are some scenarios when key frames may appear more frequently than once a second, in which case the minimum timeout for "config-interval" of 1 second for sending VPS/SPS/PPS isn't enough. It might also be desirable in general to make sure the VPS/SPS/PPS is available with every keyframe (packet loss aside), so receivers can actually pick up decoding immediately from the first keyframe if VPS/SPS/PPS is not signaled out of band. This commit adds the possibility to send VPS/SPS/PPS with every key frame. This mode can be enabled by setting "config-interval" property to -1. In this case the payloader will add VPS, SPS and PPS before every key (IDR) frame. https://bugzilla.gnome.org/show_bug.cgi?id=757892
-
This way we can use -1 as special value, which is nicer than MAXUINT. https://bugzilla.gnome.org/show_bug.cgi?id=757892
-
Call handle_nal for each NAL in the STAP-A RTP packet. This makes sure we correctly extract the SPS and PPS. https://bugzilla.gnome.org/show_bug.cgi?id=730999
-
The payloader didn't copy anything so far, the depayloader copied every possible meta. Let's make it consistent and just copy all metas without tags or with only the video tag. https://bugzilla.gnome.org/show_bug.cgi?id=751774
-
A race condition in the state change function may cause buffers to be unreffed while they are still used by the streaming thread in gst_rtp_h265_pay_send_vps_sps_pps() resulting in a crash. Chain up to the parent class first in the state change function to make sure streaming has stopped and only then free those buffers. https://bugzilla.gnome.org/show_bug.cgi?id=741381
-
Fixes a buffer leak that would occur if the pipeline was shutdown while a SPS/PPS header was being created. https://bugzilla.gnome.org/show_bug.cgi?id=741271
-
The payloader didn't copy anything so far, the depayloader copied every possible meta. Let's make it consistent and just copy all metas without tags or with only the video tag. https://bugzilla.gnome.org/show_bug.cgi?id=751774
-
h264parse and gstrtph264depay do the same, let's keep the behaviour consistent. As we now include the codec_data inside the stream, this causes less caps renegotiation. https://bugzilla.gnome.org/show_bug.cgi?id=753228
-
rtph264depay does the same and this fixes decoding of some streams with 32 SPS (or 256 PPS). It is allowed to have SPS ID 0 to 31 (or PPS ID 0 to 255), but the field in the codec_data for the number of SPS or PPS is only 5 (or 8) bit. As such, 32 SPS (or 256 PPS) are interpreted as 0 everywhere. This looks like a mistake in the part of the spect about the codec_data.
-
For more optimised RTP packet handling: means we don't need to map the input buffer again but can just re-use the mapping the base class has already done. Based on: https://bugzilla.gnome.org/show_bug.cgi?id=750235 https://bugzilla.gnome.org/show_bug.cgi?id=753228
-
Switching to GST_BUFFER_TIMESTAMP() to be consistent with other rtp code.
-
This causes an assertion and would lead to getting a NULL instead of a buffer. Without proper checking this would easily lead to a segfault. Related to rpth264depay: https://bugzilla.gnome.org/show_bug.cgi?id=737199
-
Value set to ret will be overwritten at least once at the end of the while loop, removing assignment.
-
This were probably added to the enums due to cargo cult programming and are unused.
-
donl_present is not implemented, yet the value is set and checked a few times. Cleaning this. CID #1249687
-
type is truncated to 0-31 with "& 0x1f", but right after that it is checks if the value is equivalent to GST_H265_NAL_VPS, GST_H265_NAL_SPS, and GST_H265_NAL_PPS (which are 32, 33, and 34 respectively). Obviously, this will never be True if the value is maximum 31 after the truncation. The intention of the code was to truncate to 0-63.
-