This speeds up rendering a fair bit by not requiring colorspace
conversion, whether there is anything to overlay or not.
The blending code was nicked from textoverlay. I would think
this might be a helpful thing to put in, say, libgstvideo at
some point.
https://bugzilla.gnome.org/show_bug.cgi?id=660528
The spec I found says "16 bits".
The existing code used log2(somevalue)+1.
ffmpeg uses log2(somevalue-1)+1.
The code now uses log2(somevalue-1)+1, and this makes it work with
some sample video without breaking another sample.
Now, I'm far from certain I've got the right spec, I found it by
searching the internet, so...
https://bugzilla.gnome.org/show_bug.cgi?id=654666
Some streams declare PIDs but will not send data for them.
Ensure we time out on those, and both send new segments to
keep their time synchronized with the rest, and do not wait
forever before deciding to signal no-more-pads.
https://bugzilla.gnome.org/show_bug.cgi?id=659924
We track streams for which a data callback is set (and for which
pads will be added only when data is received), and signal
no-more-pads when the last pad is added.
https://bugzilla.gnome.org/show_bug.cgi?id=659924
There was a second threshold, which apparently needs to be smaller
than the first, though I'm not certain of it as I don't understand
yet this nest of wtf that is the mpeg demuxer timing logic.
Fixes video freezing on one (corrupted) MPEG sample. It would
previously never think it was out of the discontinuity, and would
push buffers with no timestamp.
Now this took me more than a day's poking at the thing, for just
one constant change, and I'm scared to have to touch this again :S
https://bugzilla.gnome.org/show_bug.cgi?id=655804
In a test stream, I get one buffer with a PTS of about 15 seconds
in the future compared to the previous one, and next buffers with
timestamps continuing where the original ones left off.
This caused the sink to wait 15 seconds to display the frame while
more frames queued up, and then dump all the subsequent frames as
they "arrived too late".
Maybe that threshold should be made configurable, but for now,
make it more smaller to catch more of these.
https://bugzilla.gnome.org/show_bug.cgi?id=655804
Non AV streams keep using the larger threshold (10 minutes), as
subtitles may arrive only every so often.
replaced broken if-return logic for fixating rate and number
of channels that caused that modules were always (after
successful fixation of rate) played as mono (instead of
stereo) by correct one with appropiate warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=619035
It would ideally be better to leave this to a rgvolume element,
but we don't control the pipeline. So do it by default, and allow
disabling it via a property, so the correct volume should always
be output.
This allows reconstruction of lost packets if FEC info is included
in the next packet, at the cost of extra latency. Since we do not
know if the stream has FEC (and this can change at runtime), we
always incur the latency, even if we never lose any frame, or see
any FEC information. Off by default.
