And use the average to go up in resolution, and the last fragment
bitrate to go down.
This allows the demuxer to react rapidly to bitrate loss, and
be conservative for bitrate improvements.
+ Add a construct only property to define the number of fragments
to consider when calculating the average moving bitrate.
https://bugzilla.gnome.org/show_bug.cgi?id=742979
Add the diff between the external time when we went to playing and
the external time when the pipeline went to playing. Otherwise we
will always start outputting from 0 instead of the current running
time.
If the src framerate and videoaggreator's output framerate were
different, then we were taking every single buffer that had duration=-1
as it came in regardless of the buffer's start time. This caused the src
to possibly run at a different speed to the output frames.
https://bugzilla.gnome.org/show_bug.cgi?id=744096
gstdecklink.cpp: In member function 'virtual HRESULT GStreamerDecklinkInputCallback::VideoInputFrameArrived(IDeckLinkVideoInputFrame*, IDeckLinkAudioInputPacket*)':
gstdecklink.cpp:498:22: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
if (capture_time > m_input->clock_start_time)
^
gstdecklink.cpp:503:22: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
if (capture_time > m_input->clock_offset)
^
The driver has an internal buffer of unspecified and unconfigurable size, and
it will pull data from our ring buffer as fast as it can until that is full.
Unfortunately that means that we pull silence from the ringbuffer unless its
size is by conincidence larger than the driver's internal ringbuffer.
The good news is that it's not required to completely fill the buffer for
proper playback. So we now throttle reading from the ringbuffer whenever
the driver has buffered more than half of our ringbuffer size by waiting
on the clock for the amount of time until it has buffered less than that
again.
The ringbuffer's acquire() is too early, and ringbuffer's start() will only be
called after the clock has advanced a bit... which it won't unless we start
scheduled playback.
Not from the decklink clock. Both will return exactly the same time once the
decklink clock got slaved to the pipeline clock and received the first
observation, but until then it will return bogus values. But as both return
exactly the same values, we can as well use the pipeline clock directly.
Detect invisible pixels, and skip gstspu_vobsub_blend_comp_buffers()
when there are only invisible pixels. This significantly reduces the
CPU load in cases of DVDs which don't use the clip_rect to exclude
processing for parts of the screen where the video is visible.
https://bugzilla.gnome.org/show_bug.cgi?id=667221
Add parsed/framed=true to allow negotiation with some
muxers that required parsed input. Encoders already provide
parsed/framed output so it should say so in caps.
There's no reason why audiomixer should override the segment
base of upstream with whatever value it got from a SEEK event,
or even worse... with 0 if there was no SEEK event yet. This
broke synchronization if upstream provided a segment base other
than 0, e.g. when using pad offsets.
Also that this code did things conditional on the element's state
should've been a big warning already that something is just wrong.
If this breaks anything else now, let's fix it properly :)
Also don't do fancy segment position trickery when receiving a
segment event. It's just not correct.
There is no reason to pre-roll more buffers here as we have our own ringbuffer
with more segments around it, and we can immediately provide more buffers to
OpenSL ES when it requests that from the callback.
Pre-rolling a single buffer before starting is necessary though, as otherwise
we will only output silence.
Lowers latency a bit, depending on latency-time and buffer-time settings.
4 is the "typical" number of buffers defined by Android's OpenSL ES
implementation, and its code is optimized for this. Also because we
have our own ringbuffer around this, we will always have enough
buffering on our side already.
Allows for more efficient processing.
