because _release_pad tries to release it from ctx->sinkpad, which is
multiqueue's sink pad, and currently fails because the probe is not
installed there
This also happens in the very beginning when we receive the first packet, a
warning would be very confusing here. In all places where we should warn about
this, we would've printed a warning already before.
Right above we consider lost_packet packets, each of them having duration,
as lost and triggered their timers immediately. Below we use expected_dts
to schedule retransmission or schedule lost timers for the packets that
come after expected_dts.
As we just triggered lost_packets packets as lost, there's no point in
scheduling new timers for them and we can just skip over all lost packets.
https://bugzilla.gnome.org/show_bug.cgi?id=739868
Resetting the jitterbuffer drops all packets and other things, and will cause
a discontinuity in the packets received by the depayloaders. They should now
also flush anything they had pending as the new data will start at a different
position.
https://bugzilla.gnome.org/show_bug.cgi?id=739868
When doing key uint seek, qtdemux calls gst_qtdemux_adjust_seek
to get proper offset. And then this offset is set to
segment.position and segment.time in gst_qtdemux_perform_seek but
segment.start is not updated.
After that, application sends segment query,
qtdemux sets start and stop to query using gst_segment_to_stream_time. Due
to the wrong value in segment.start, the stop position is smaller than
it should.
https://bugzilla.gnome.org/show_bug.cgi?id=746822
We always write the CTTS in qtmux. Ideally we only want to do that
for streams that need DTS, it should be present on the track information
rather than be decided based on each buffer
As qt uses durations, it doesn't matter, only the difference
between consecutive buffers is important. Also, collectpads
already replaces PTS/DTS with the running times for them.
Both input streams in this test have a segment.start = 10s, so
output should start from 0 anyway.
Another test has both starting at non-0 segments, but the running
time of both streams should still start from 0
Commit #1018aa made rtprtxsend handle buffer lists, breaking
the test which probes for buffers, but not buffer lists.
Use a utility function to run the probe callback on each buffer
in the list in turn and remove any buffers that are dropped.
Instead of checking various state variables around the muxer,
track the current muxing mode in a single 'mux_mode' enum.
Add some implementation notes about the different mux modes
gst_segment_do_seek() does that for us already, and doing it twice
will break non-flushing seeks in interesting ways. Leftover from 1.0
porting.
Also copy over segment offset and applied_rate, just in case.
Sometimes we can get segment-done before we got async-done. If we waited
for async-done only, the segment-done would be dropped and we would wait
forever for it a few lines below.
When multifilesink is operating in any mode other than one file
per buffer, the last file created won't have a file message posted
as multifilesink doesn't handle the EOS event.
This patch fixes it by using the last position to post a file
message when EOS is received. This should ensure at least the
time related data and the filename are posted to the application
or other elements
https://bugzilla.gnome.org/show_bug.cgi?id=747000
When not in fast-start or fragmented mode, we need to be able
to rewrite the size of the mdat atom, or else the output just
won't be playable - the mdat placeholder with size == 0 will
cover the rest of the file, including any moov atom we write out.
https://bugzilla.gnome.org/show_bug.cgi?id=708808
The v4l2 device restarts the sequence counter in case of streamoff/streamon,
the GST offset values are supposed to increment strictly monotonic, so
adjust the sequence counter/offset values in case of caps
renegotiation.
https://bugzilla.gnome.org/show_bug.cgi?id=745441
In case of v4l2 driver filled offset/sequence values add frame
loss detection (and write a warning message).
Move offset meta data setting and frame loss checking after the
timestamp adjustment code to get proper timestamps for the
warning message.
https://bugzilla.gnome.org/show_bug.cgi?id=745441
If propose_allocation() had not been called yet, it was possible that the driver was not asked at all.
In buffer pool: Consider minimum number of buffers requested by driver when setting config.
https://bugzilla.gnome.org/show_bug.cgi?id=746834
