There is no reason to send a flush-stop when receiving a seek event.
In the case of a flushing seek, we could eventually want to, but in
the code path were we check if the seek is "flushing", we have the
following comment that makes sense:
"we can't send FLUSH_STOP here since upstream could start pushing data
after we unlock mix->collect.
We set flush_stop_pending to TRUE instead and send FLUSH_STOP after
forwarding the seek upstream or from gst_videomixer_collected,
whichever happens first."
https://bugzilla.gnome.org/show_bug.cgi?id=684237
In case qtdemux is handling a mss stream, do not mark the stream to wait
for EOS after a segment. Even if it seems to be the last one according to
the current streams information.
MSS handling is different here because there is another demuxer driving
the pipeline
The samplerate field in the STSD atom is not right for some ALAC files
(usually when audio is 96kHz/24bits), so the audio caps must be
extracted from the codec data.
https://bugzilla.gnome.org/show_bug.cgi?id=700382
I took the opportunity to simplify that code a bit. We now use
gst_buffer_make_writable() to make the buffer writable and map twice the
same buffer, with first map being read/write, and second read only. This
get rid of the critical:
GStreamer-CRITICAL **: gst_structure_set_name: assertion `IS_MUTABLE
https://bugzilla.gnome.org/show_bug.cgi?id=700044
The exist one case where that we endup with original caps in ret, in which
case we are not guaratied to have writable caps. Simply ensure this is the
caps are writable before entering the loop.
https://bugzilla.gnome.org/show_bug.cgi?id=700044
This reverts commit 84ae670ab4.
Actually this is not how it is supposed to work. videomixer
creates a [0,-1] segment and then puts frames of the different
streams there based on their running times in their own segments.
For receiving video data via RTSP when the video is sent via
multicast there is no way to specify the udpsrc buffer-size.
On windows the native network buffer is not large and with video
i-frames being huge the buffer is to small and you get i-frame corruption,
it looks terrible, and there is no (easy) way to set the udpsrc buffer-size.
https://bugs.freedesktop.org/show_bug.cgi?id=52264
Whenever the demuxer has a new caps on a stream, it should set the
new_caps variable to true and a new caps event will be pushed before
the next buffer
qtdemux takes its buffers from a GstAdapter. Those buffers are created
from the larger buffer that it obtained from upstream and they carry
the same flags, including DISCONT if it is set. In these cases, all
buffers that qtdemux is going to push would be marked as DISCONT.
This scenario can make parsers/decoders flush on every buffer leading
to no decoding at all hapenning. This patch prevents this by unsetting
the flag if it shouldn't be set.
* Explicitly init variables for fragmented formats at init
* Do not use GstClockTime type if the variable isn't a timestamp
* Fix a style/readability issue at an if block
* Group 2 mss mode conditional blocks together to improve readability
Conflicts:
gst/isomp4/qtdemux.c
This can confuse downstream when they get a byte segment after receiving
the natural time segment from qtdemux that it sends when starting to
push buffers. This is specially the case with parsers that try to
convert the position from byte to time format and might miss the
correct position for playback to start.
Reset different variables on state changes to ready and when
handling a flush-stop. For handling flush stops we should check
if there is an upstream adaptive demuxer driving the pipeline as this
means that qtdemux will get a new moov atom. For 'standard' isomedia
streams this isn't true and qtdemux should keep the previous moov
information around.
Conflicts:
gst/isomp4/qtdemux.c
Whenever dashdemux switches bitrates it sends a new moov with the
new stream configuration. qtdemux should now handle this by splitting
the exposing and configuration of streams into separate functions. When
the stream is new it is configured and exposed, when it is a new bitrate
of an existing stream it is only reconfigured.
Conflicts:
gst/isomp4/qtdemux.c
smoothstreaming streams should be handled as a special kind of
fragmented isomedia. In MSS the fragments will not contain a
'moov' atom with the media descriptions, this has to be extracted
from the caps.
Additionally, there should be another demuxer upstream that is likely
going to be the one to answer/act on queries and events, so qtdemux has
to forward those upstream.
This is equivalent to multicast-group currently for backwards compatibility.
In 2.0 this should be handled separately, the former only being the multicast
group and the latter always being the address the socket is bound to, even if
a multicast group is given.
Return the output buffer from the process function instead of pushing
it ourselves. This way, the subclass can actually deal with the return
value of the push.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=693727
A marker bit on an audio packet does not mean a DISCONT (in the GStreamer sense
of missing data) but it means that the packet is the end of a talkspurt and thus
a good opportunity to resync to the clock. Use the RESYNC buffer flag to note
this.
Real discontinuities are marked with DISCONT still when the seqnum has a GAP or
when the input buffer has the DISCONT flag set.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=627204
When the server suggests a GstNetTimeProvider in the SDP, set up a
GstNetClientClock that slaves to the remote clock and suggest this clock in
provide_clock.
Previously we would skip level message when processing buffers > the requested
interval. Also the message frequency would contain quite some jitter due to only
considering them at the end of buffers.
Cleanup the tests while we're at it.
Otherwise we get a race where if the RTCP packet comes in first and while
it is added the pads, the segment event arrives on the RTP stream, the event
may be lost completely and never forwarded.
