summary |
shortlog | log |
commit |
commitdiff |
tree
first ⋅ prev ⋅ next
Luis de Bethencourt [Fri, 15 Jan 2016 15:19:41 +0000 (15:19 +0000)]
rtph265pay: change config-interval property type from uint to int
This way we can use -1 as special value, which is nicer than MAXUINT.
https://bugzilla.gnome.org/show_bug.cgi?id=757892
Luis de Bethencourt [Sat, 15 Aug 2015 15:22:20 +0000 (16:22 +0100)]
rtph265depay: make sure we call handle_nal for each NAL
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
Luis de Bethencourt [Sat, 15 Aug 2015 13:45:34 +0000 (14:45 +0100)]
rtph265pay: Copy metadata in the payloader, but only the relevant ones
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
Luis de Bethencourt [Sat, 15 Aug 2015 10:41:40 +0000 (11:41 +0100)]
rtph265pay: Use GST_WARNING_OBJECT() instead of GST_WARNING()
https://bugzilla.gnome.org/show_bug.cgi?id=753228
Luis de Bethencourt [Sat, 15 Aug 2015 10:30:36 +0000 (11:30 +0100)]
rtph265pay: fix potential crash when shutting down
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
Luis de Bethencourt [Fri, 14 Aug 2015 14:08:08 +0000 (15:08 +0100)]
rtph265pay: fix buffer leak when using SPS/PPS
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
Luis de Bethencourt [Fri, 14 Aug 2015 10:49:51 +0000 (11:49 +0100)]
rtph265depay: copy metadata in the depayloader, but only the relevant ones
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
Luis de Bethencourt [Wed, 12 Aug 2015 16:54:52 +0000 (17:54 +0100)]
rtph265depay: checking if depay has sps/pps nals before insertion
Related to: https://bugzilla.gnome.org/show_bug.cgi?id=753430
https://bugzilla.gnome.org/show_bug.cgi?id=753228
Luis de Bethencourt [Wed, 12 Aug 2015 16:22:42 +0000 (17:22 +0100)]
rtph265depay: only update the srcpad caps if something else than the codec_data changed
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
Luis de Bethencourt [Wed, 12 Aug 2015 15:43:48 +0000 (16:43 +0100)]
rtph265depay: PPS replaces old PPS if it has the same id
https://bugzilla.gnome.org/show_bug.cgi?id=753228
Luis de Bethencourt [Wed, 12 Aug 2015 15:11:00 +0000 (16:11 +0100)]
rtph265depay: Insert SPS/PPS NALs into the stream
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.
Luis de Bethencourt [Wed, 12 Aug 2015 14:49:50 +0000 (15:49 +0100)]
rtph265depay: implement process_rtp_packet() vfunc
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
Luis de Bethencourt [Wed, 12 Aug 2015 14:14:50 +0000 (15:14 +0100)]
rtph265depay: Use GST_BUFFER_PTS() instead of GST_BUFFER_TIMESTAMP()
Switching to GST_BUFFER_TIMESTAMP() to be consistent with other rtp code.
Luis de Bethencourt [Wed, 12 Aug 2015 13:59:53 +0000 (14:59 +0100)]
rtph265depay: prevent trying to get 0 bytes from adapter
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
Luis de Bethencourt [Wed, 29 Jul 2015 16:29:28 +0000 (17:29 +0100)]
rtp: remove dead assignment
Value set to ret will be overwritten at least once at the end of the while
loop, removing assignment.
Luis de Bethencourt [Fri, 24 Apr 2015 15:48:23 +0000 (16:48 +0100)]
remove unused enum items PROP_LAST
This were probably added to the enums due to cargo cult programming and are
unused.
Luis de Bethencourt [Fri, 6 Mar 2015 14:54:41 +0000 (14:54 +0000)]
rtp: donl_present variable unused
donl_present is not implemented, yet the value is set and checked a few times.
Cleaning this.
CID #1249687
Luis de Bethencourt [Thu, 8 Jan 2015 15:36:04 +0000 (15:36 +0000)]
rtp: value truncated too short creates dead code
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.
Luis de Bethencourt [Thu, 8 Jan 2015 15:27:44 +0000 (15:27 +0000)]
rtp: fix nal unit type check
After further investigation the previous commit is wrong. The code intended to
check if the type is 39 or the ranges 41-44 and 48-55. Just like gsth265parse.c
does. Type 40 would not be complete.
Luis de Bethencourt [Thu, 8 Jan 2015 13:47:09 +0000 (13:47 +0000)]
rtp: fix dead code and check for impossible values
nal_type is the index for a GstH265NalUnitType enum. There are two types of dead
code here:
First, after checking if nal_type is >= 39 there are two OR conditionals that
check if the value is in ranges higher than that number, so if nal_type >= 39
falls in the True branch those other conditions aren't checked and if it falls
in the False branch and they are checked, they will always also be False. They
are redundant.
Second, the enum has a range of 0 to 40. So the checks for ranges higher than 41
should never be True.
Removing this redundant checks.
CID 1249684
Thijs Vermeir [Thu, 16 Oct 2014 08:34:01 +0000 (10:34 +0200)]
rtp: add h265 RTP payloader + depayloader
Thomas Vander Stichele [Mon, 17 Dec 2001 18:37:01 +0000 (18:37 +0000)]
building up speed
Original commit message from CVS:
building up speed