Subsequent entry time calculations use blockalign value to determine
number of frames per chunk, and blockalign == 1 is then most unlikely to result
in reasonable values (which also aligns with "spec").
So matroska's Block structure has no keyframe flag, only the SimpleBlock has it.
To detect keyframes in Blocks, it is just the BlockGroup container that needs
to have a ReferenceBlock attached if it is a delta frame in video.
Use new dts audio typefinder from -base to check if the PCM data
contains a dts stream. This way we recognise more varieties more
reliably and also detect the dts stream if there isn't a frame
sync right at the start of the data.
Fixes#413942.
Start cluster at every keyframe or when we would overflow the previous
cluster's relative timestamp field. This would avoid as much as possible
starting clusters at non-keyframes.
Don't send them upstream because for upstream a BYTES seek
might make sense but is completely wrong because upstream
can't seek to a byte position of the audio or video stream.
Also don't build the index in push mode for non-TIME seeks,
things will go wrong here otherwise.
This allows us to skip delta units earlier and is a bit clearer in my
opinion. It also makes only video buffers ever be delta units, not
just for SimpleBlock as before.
When the keyframe bit of SimpleBlock Flags wasn't set, the buffer was being
marked with GST_BUFFER_FLAG_DELTA_UNIT, causing all buffers to be skipped
after a seek. This may be a problem with the Sorenson Squish encoder, but
arguably the keyframe bit should only be applied to video.
Fixes bug #620358.
Even though we don't use delivery-method in our payloader, older versions of
the theora payloader in gstreamer required it. As such we need to keep this
around in the caps for backwards-compatibility.
This reverts part of 49463a37cbFixes#618940
When we calculate the frame duration, we need to use the amount of
frames in the _previous_ packet, not the current packet. The frame duration is
needed to correctly de-interleave interleaved streams. This fixes the case where
there are a variable number of frames in a packet.
Fixes#620494
This commit basically puts _get_caps() in sync with accept_caps().
If we don't have a master pad OR the master pad caps aren't negotiated
then we just return the downstream allowed caps.
If we have a master pad with negotiated caps, we return those caps
with a free range of width/height/framerate
When using RTP_JITTER_BUFFER_MODE_BUFFER, make sure that the ringbuffer doesn't
get stuck buffering forever when there isn't enough data left to fill the
buffer.
