rtph263ppay should accept any input compatible with its sink template
caps if it just outputs to e.g. udpsink or fakesink.
rtph263ppay ! rtph263pdepay should also work with any compatible input.
This would fail before with not-negotiated errors because the get_caps
function would see the encoding-name in the depayloader's template caps
and default to baseline H.263 because there's no profile/level information
in those caps, which is the right thing to do if downstream has filtercaps
from an SDP, but not if those fields are absent because they can be
anything like with the depayloader's template caps. Makes
videotestsrc ! avenc_h263p ! rtph263ppay ! rtph263pdepay ! fakesink
work.
Since the initial decoded still image buffer will have dts=pts=0, and
we only set PTS on buffers we push out, all buffers pushed out would
have a DTS of 0. Sinks, however, will prefer DTS over PTS if both are
set, and will therefore always see a timestamp of 0 no matter what
the PTS is set to.
Fixes unit test too.
When it receives a seek in push mode, the qtdemux should first try to push the event upstream, and only if upstream fails fall back to
its own seek logic.
Don't reset the time in flush-stop. Live sources can do this flush in the
playing state and so the pipeline will never have a chance to update the
base_time of the elements, which only happens when going from paused to
playing.
Always send the flushing events to the udp elements now that basesrc supports
this. This makes sure a segment event is sent correctly after a flush.
Keep track of the currently executing command and make it possible to specify
what command you want to cancel when starting a new async command.
See https://bugzilla.gnome.org/show_bug.cgi?id=677905
These should all be int instead of long, to avoid bugs
when passing these as varargs with g_object_set(), and
there was no reason to use long in the first place here.
Fixes FIXME.
They should take the filter caps into account and always return
the template caps appended to the actual caps. Otherwise the
parsers stop to accept unparsed streams where upstream does not
know about channels, rate, etc.
Fixes bug #677401.
From RFC 2250
2. Encapsulation of MPEG System and Transport Streams
...
For MPEG2 Transport Streams the RTP payload will contain an integral
number of MPEG transport packets. To avoid end system
inefficiencies, data from multiple small MTS packets (normally fixed
in size at 188 bytes) are aggregated into a single RTP packet. The
number of transport packets contained is computed by dividing RTP
payload length by the length of an MTS packet (188).
....
Since it needs to contain "an integral number of MPEG transport packets", a
simple fix is to check that's the case, and strip off any leftover data.
Fixes#676799
Conflicts:
gst/rtp/gstrtpmp2tdepay.c
