When a segment event is received on the active pad, forward it downstream
immediately instead of deferring it until the next data buffer arrives. This
fixes problems with segment updates never being sent downstream, like those
needed for sparse streams, or for closing previously opened segments.
This fixes playback of DVD menus with a still video frame and an audio track,
for example.
Fixes: #577843
Add a virtual method in rawparse to set buffer flags. This doesn't
use API from unreleased -base, since it defines GST_VIDEO_BUFFER_TFF
if it's not defined yet.
This should remove the bogus error messages while still keeping the original
intent of this, which is to inform the pipeline/application/user that we
could not find any valid streams.
There are many reasons why pushing an event can fail, and not all of them are
because there's no link downstream (it could be because it was blocked, or
flushing).
itvhd masks its h264 video stream as a private stream making it harder for
other set top boxes to decode. this checks for specific program number, video
pid and stream type combination before declaring it as h264.
For this add a "mode" property that defaults to "interlaced" for now as
most decoders/demuxers don't properly set the "interlaced" field on the
caps yet.
If this property is set to "auto" the element will work in passthrough
mode unless the caps contain the "interlaced" field.
Don't allow setting filename via img-done signal parameter but force app
use filename property. Don't stop capture when setting filename property.
Update check unit test based on the change.
Sending the flush-start event forward before taking the stream lock actually
works, in contrast to deadlocking in downstream preroll_wait (hunk 1).
After that we get the chain function being stuck in a busy loop. This is fixed
by updating the minimum frame size inside the synchronization loop because the
subclass asks for more data in this way (hunk 2).
Finally, this leads to a very probable crash because the subclass can find a
valid frame with a size greater than the currently available data in the
adapter. This makes the subsequent gst_adapter_take_buffer call return NULL,
which is not expected (hunk 3).
