gst_buffer_ref and gst_buffer_writable is being used to create a writable copy of source buffer.
replacing the same with gst_buffer_copy as the functionality is same.
https://bugzilla.gnome.org/show_bug.cgi?id=735880
Adding an extra condition while calling gst_caps_unref (templ)
and replacing gst_caps_make_writable (gst_caps_ref (caps)) with
gst_caps_copy (caps) in line 177, since the functionality is same.
https://bugzilla.gnome.org/show_bug.cgi?id=735795
We return EOS after the first buffer, and GstPad will make sure now that we
won't get any other buffer afterwards until a flush happens. No need to check
for it ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=735581
FLV documentation stipulates that timestamp must start at zero.
In order to respect this rule, keep the first timestamp around
and offset the timestamp from this value. This allow for longer
recording time in presence of timestamp that does not start
at 0 already.
https://bugzilla.gnome.org/show_bug.cgi?id=731352
The tags in FLV are DTS. In audio cases, and for many video format this makes
no difference, but for AVC with B-Frames, PTS need to be computed from
composition timestamp CTS, with PTS = DTS + CTS.
https://bugzilla.gnome.org/show_bug.cgi?id=731352
The jitterbuffer shouldn't force clock-rate on its sink pad, this will cause a negotiation issue since rtpssrcdemux doesn't have the clock-rate and doesn't add it to the caps. The documentation states that the clock-rate can either be specified through the caps or through the request-pt-map signal, so we must remove clock-rate from the pad templates and we must accept the GST_EVENT_CAPS if the caps don't have the clock-rate.
https://bugzilla.gnome.org/show_bug.cgi?id=734322
udpsrc gtk-doc documentation refers to sockfd and closefd properties which has
been removed. This patch replaces those references to socket and close-socket
respectively.
https://bugzilla.gnome.org/show_bug.cgi?id=734987
The old default timescale of 1 millisecond produces irrational
numbers for a lot of framerate/audio-packet-duration multiples.
1/1800 is a nicer number, as it tends to produce better fractions
and therefore slightly higher accuracy overall
Change the way the output framerate is calculated
to ignore the first sample (which is sometimes truncated
in my testing) and use the new gst_video_guess_framerate()
function to recognise common standard framerates better.
Remove the code that was sorting the first 20 sample
durations and then ignoring the result.
Commit 2b9493b5 broke this in two ways: a) we should only
pass duration queries in TIME format upstream (or at least
not those in DEFAULT or BYTE format), and b) we mustn't
overwrite the default value of 'res' from TRUE to FALSE
and not set it again later. This led to bogus durations
being reported for FLV playback from file, because TIME
queries would fail (as 'res' had been set to FALSE) and
parsers then do a BYTE query as fallback and try to
guesstimate something in return, which of course goes
horribly wrong since the BYTE size returned is for the
muxed file.
When changing the properties to not be in passthrough mode anymore,
we will only accept caps we can process ourselves, potentially causing
a not-negotiated error.
https://bugzilla.gnome.org/show_bug.cgi?id=720345
This makes sense in DASH reverse playback, where the upstream dashdemux
will download DASH segments in reverse order, but push their buffers
forward to qtdemux and mark each segment start as DISCONT. This needs
to be forwarded downstream to the parser/decoder, otherwise it won't work.
https://bugzilla.gnome.org/show_bug.cgi?id=734443
When writing out a trak with an edit list, make sure the
overall file duration is also updated to reflect the
lengthening of the stream.
Add some more debug to qtdemux to warn about streams that
are longer than the file and get truncated.
