Add an accumulator that stops the signal emission as soon as a caps has
been retrieved. Otherwise the default handler would continue emitting
the signal and possibly overwrite the result with NULL again.
Uses information gathered during EBML parsing to
forge a more suitable set of caps instead of blindly
assuming everything is video/x-matroska.
For consistency, stream type reset was added to
matroska-demux too.
https://bugzilla.gnome.org/show_bug.cgi?id=722311
Now with rtprtxsend pushing rtx buffers from a different thread,
this is necessary to ensure that the result of the test is deterministic.
This code makes use of GstCheck's global GMutex and GCond that are
being used inside GstCheck's sink pad chain() function in order
to synchronize with it.
Now with rtprtxsend pushing rtx buffers from a different thread,
this is necessary to ensure that the result of the test is deterministic.
This code makes use of GstCheck's global GMutex and GCond that are
being used inside GstCheck's sink pad chain() function in order
to synchronize with it.
Now with rtprtxsend pushing rtx buffers from a different thread,
this is necessary to ensure that the result of the test is deterministic.
This code makes use of GstCheck's global GMutex and GCond that are
being used inside GstCheck's sink pad chain() function in order
to synchronize with it.
To do that, enqueue the EOS event to be sent from the srcpad task
thread and flush the queue right afterwards, so that no more rtx
buffers can be sent, even if there are more requests coming in.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=722370
The reason behind this is to minimize the retransmission delay.
Previously, when a NACK was received, rtprtxsend would put a
retransmission packet in a queue and it would send it from chain(),
i.e. only after a new buffer would arrive.
This unfortunately was causing big delays, in the order of 60-100 ms,
which can be critical for the receiver side.
By having a separate GstTask for pushing buffers out of rtxsend,
we can push buffers out right after receiving the event, without
waiting for chain() to get called.
Those are advertised in the template caps, but the
setcaps handler didn't handle them. But then oggmux
and oggparse at least for now still always output
application/ogg anyway, so that wasn't a real problem.
Instead do it like all other demuxers and let parsers and decoders
handle that. The keyframe information inside the container might
be completely wrong like in the sample file of the bug report,
and if it is correct and we push no keyframes, then the parsers
and decoders will handle that properly anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=682276
Make sure empty segments are used and pushed with a gap event
to represent its data (or lack of it)
Each QtSegment is mapped into a GstSegment with the corresponding
media range. For empty QtSegments a gap event is pushed instead
of GstBuffers and it advances to the next QtSegment.
To make this work with seeks, need to keep track of the starting
'base' to make sure it remains consistently increasing when
pushing new segment events.
For example: if a seek makes qtdemux start from 5s, the first
segment will have a base=0. When the next segment is activated,
its base time will be QtSegment.time - qtdemux.segment_base so
that it doesn't include the first 5s that weren't played and
shouldn't be accounted on the running time
This purposedly will remove the fix made for
https://bugzilla.gnome.org/show_bug.cgi?id=700264, at this
point it was decided to respect the gaps, even if they cause
a delay on playback, because that's the way the file was crafted.
https://bugzilla.gnome.org/show_bug.cgi?id=345830
1) pt can be lower than 96
2) there is no point in checking that because rtprtxsend will not
even store buffers for payload types that it doesn't know about,
so this case will never be reached
This patch moves the creation of rtx packets to be done early,
in the src_event() function, when they are requested. The purpose
is to run gst_rtp_rtx_buffer_new() with the object locked to
protect internal data, because if it is done at the pushing stage,
we would have to lock and unlock multiple times in a row while we
are pushing the rtx buffers.
Previously there was no locking at all, which was terribly wrong.
This may not be defined. Since the previous version used
only the other define (V4L2_CAP_VIDEO_OUTPUT_MPLANE), fall
back on this only when not available.
According to ISO/IEC 13818-7, "channel_config" field in ADTS header
may have value of 0, as in the case of frame with PCE.
gst_aac_parse_detect_streams() returned FALSE for those frames
and discarded them.
