Scaletempo was missing an update of 'stop' in
new segment parameters when pushing it downstream,
which caused files to end earlier when rate < 1.
Fixes#599903
Based on patch by: Bastian Hecht <hechtb@gmail.com>
The scenario where you have a gap in a steady flow of packets of
say 10 seconds (500 packets of with duration of 20ms), the jitterbuffer
will idle up until it receives the first buffer after the gap, but will
then go on to produce 499 lost-events, to "cover up" the gap.
Now this is obviously wrong, since the last possible time for the earliest
lost-events to be played out has obviously expired, but the fact that
the jitterbuffer has a "length", represented with its own latency combined
with the total latency downstream, allows for covering up at least some
of this gap.
So in the case of the "length" being 200ms, while having received packet
500, the jitterbuffer should still create a timeout for packet 491, which
will have its time expire at 10,02 seconds, specially since it might
actually arrive in time! But obviously, waiting for packet 100, that had
its time expire at 2 seconds, (remembering that the current time is 10)
is useless...
The patch will create one "big" lost-event for the first 490 packets,
and then go on to create single ones if they can reach their
playout deadline.
See https://bugzilla.gnome.org/show_bug.cgi?id=667838
Ignore other commands when reconnecting, otherwise the loop function would pause
and the reconnection would not happen. Continue looping after doing a reconnect
so that we have a chance to actually read the new data.
The src pad caps always describe a single audio channel so only the
first position matters if deinterleave is configured to keep channel
positions in its src pads.
Make it possible to set the timeout after we went to the READY state by using
the timeout when checking the condition. This also makes it possible to set the
timeout with a higher granularity than seconds.
* gst/rtsp/gstrtspsrc.c (gst_rtspsrc_play): state change might be
happening in the application thread, so we don't change the state to
PLAYING in the gstrtspsrc thread unless it is safe.
A specific case is when chaning the state to NULL from the application
thread. This will synchronously try to stop the task (with the element
state lock acquired), but we will try a gst_element_set_state from
gstrtspsrc thread which will block on the element state lock causing a
deadlock.
https://bugzilla.gnome.org/show_bug.cgi?id=684312
Shout2send only accepts webm format, not matroska, but due
to a bug in matroskamux, webmmux's source pad is also created
with the matroska source pad template as pad template, which
makes the link function think it can't link webmmux to shout2send.
Also add unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=689336
Make a segment event when we send a new range header to a client (first PLAY
request or after a seek). Send the segment event in interleaved mode.
Clean the segment event on cleanup
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=688382
* gst/rtsp/gstrtspsrc.[ch]: added new "udp-reconnect" property. Before,
rtspsrc always tried to reconnect to the server when the RTSP
connection was closed by the server. This property lets the user
decide whether it wants rtspsrc to reconnect or not.
https://bugzilla.gnome.org/show_bug.cgi?id=683912
When the user configured a port-range, propose ports from this range
as the multicast ports. The server is free to ignore this request but if it
honours it, increment our ports so that we suggest the next port pair for the
next stream.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=639420
This change enable automatic cropping using -1 set to left, top, right or
bottom property. In the case both side are set to automatic cropping, the
croping will be done equally on both side (in the odd case, right and
bottom cropping will be 1 pixel more).
https://bugzilla.gnome.org/show_bug.cgi?id=687761
This could have prevented images showing that should have when the
source height is greater than its width.
When width exceeds height, as is common, it probably only caused a
miniscule amount of unnecessary work. I haven't tested.
Spec is still in draft state, but should hopefully not
change much now. Besides, we announce things as VP8-DRAFT-IETF-01
in our caps, so even if things change in incompatible ways it
should not break anything.
https://bugzilla.gnome.org/show_bug.cgi?id=687263
VP8 uses a probabilistic bool coder, not a straight bit coder.
This fixes parsing when error-resilient is set.
This commit includes a copy of libvpx's bool coder, BSD licensed.
https://bugzilla.gnome.org/show_bug.cgi?id=652694
When setting up the initial mapping just act as if the global frame
information is another partition. This saves special-casing it later in
the actual packetizing code.
Caps events are sometimes not followed by a buffer but by an event. Flush any
pending caps before we make a packet with the event.
Chain up to the parent event handler before we attempt to push RTP packets, it
might be a segment event.
We currently only send tags and custom events. The other events
might interfere with the receiver timings or are otherwise handled
by RTP.
Conflicts:
gst/rtp/gstrtpgstpay.c
Use adapter to assemble the payload and make a flush function to
turn this payload into (fragmented) packets.
Conflicts:
gst/rtp/gstrtpgstpay.c
gst/rtp/gstrtpgstpay.h
Make sure we only insert the rtp packet in the adapter when the
frag_offset matches. When the first packet of a fragment is dropped,
it avoids putting the remaining packets in the adapter and processing
the partial fragment.
Conflicts:
gst/rtp/gstrtpgstdepay.c
Set the C flags on all the fragments instead of only those with
caps in them. This makes it easier in the receiver to check if there
is a caps in the assembled fragments just by looking at the last RTP
packet flags.
Place the capsversion on the outgoing caps so that they end up in
an SDP as well. Receivers need to know what capsversion a particular
caps is for to be able to match the caps to the CV in the RTP packets.
Place the caps inside the RTP packet whenever the caps change.
Based on patch by Andrzej Bieniek <andrzej.bieniek@pure.com>
Conflicts:
gst/rtp/gstrtpgstpay.c
gst/rtp/gstrtpgstpay.h
* Also expose unknown tags as key=value pairs.
* Arrange tag map in the same order tags are listed in Matroska spec, leaving
unmapped tags as comments.
* More specific TODOs.
* Remove duplicate DATE define.
Fixes#682615
Depends on #682524
* Reads TargetType and TargetTypeValue from a Tag.
* After Tag is completely read, processes taglist, substituting some of the
tags depending on target type value and the presence of video/subtitle streams.
* Supports reading two new simpletags - PART_NUMBER and TOTAL_PARTS
Depends on #682448Fixes#682524
If we run into any header parsing issues and we have a valid
STREAMINFO header already, don't error out, but just stop
header parsing and try to find some audio frames.
https://bugzilla.gnome.org/show_bug.cgi?id=684701
If both pads receive data at the same time, they will both get their
sink_setcaps called which will call the src_setcaps, but there is
a race condition where the second one might not be called.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=683842
Since it's not spec'ed, consider it a VfW compatibility
case. Many applications (e.g. avidemux) don't understand
the unofficial V_MJPEG id.
Fixes#659837.
Conflicts:
gst/matroska/matroska-mux.c
Inform the source when caps changed. This was removed in the port to 1.0
leaving the source unaware of the clock-rate and unable to interpollate
rtp timestamps for SR packets.
When use-pipeline-clock is set, use the running-time of the
pipeline to calculate the NTP timestamps. This method would previously
only work when the base-time is set to 0 but with this change it can
also work with different offsets and we can also implement pause/resume
of the sender and receiver now.
Fixes abort in push mode where the source is not seekable and the
size of the file is not available, as with
cat foo.mp4 | gst-launch-1.0 playbin uri=fd://0
Less noticable with releases, since we disable all
g_assert() there.
https://bugzilla.gnome.org/show_bug.cgi?id=686008
