The channel property allows multiple intersrc/sink pairs to find
each other. It's a free-form text string that must match among
various inter elements. Also fixed up documentation and latency
handling.
When a face disappears, we seem to get a message from facedetect with
a face count of 0, which we want to just ignore instead of trying to
access face #-1, which causes nasty warnings.
Use generic and unspecififed rgb/caps for now. The exact caps
supported depend on the facedetect element and rsvgoverlay. It's
not clear how this worked before, since facedetect only accepts
24-bit RGB, but the caps advertised 32-bit ARGB/BGRA. In any case,
we don't want to force anything really, so that if any of those
elements acquires support for additional formats we pick those up
automatically.
The element would create normal pads in its instance_init function,
and then later in NULL->READY create the elements it needs, remove
the pads created in the instance_init function, and add new ghost
pads instead. Not without saving the external peer pads of the old
pads of course, which it would promptly re-link to the new ghost
pads. Do all of that a bit differently.
Fixes the generic/states.check unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=670588
This always happens with GstByteReader/Writer and friends when
not taking into account returned boolean of the _read/_write functions
(which is actually wrong).
Make use of the *_unchecked variant as much as possible, or take the
returned value into account.
When the PES header tells us how big the outgoing packet is, push the
packet downstream as soon as we have the specified size instead of waiting
for the beginning of the next packet.
Reduces latency and removes issues with very sparse streams (like subtitles
and subpictures).
If we *really* can't figure out the first start position, that most
likely means the data to push out doesn't have any timestamp.
Use a default value of 0 then
Allows PCR<=>PTS<=>offset estimation/calculation
Right now the calculation is very naive, but can be extended later on
without disrupting the code in tsdemux/mpegtsbase
* Don't take into account packets that arrived at the same time as
previous ones for clock skew estimation
* Add convenience method for processing the next ts packet
This is probably the cause for an occasional crash while streaming
MPEG. Blind fix after staring at the code and following logic, so
may or may not fix the issue, I cannot test.
(Port of 4275a70cb5 from mpegdemux)
