... since it is specified in _finish_frame that input buffer may be invalidated
after calling it, and is as such not reliably available for further encoding.
Also, requesting or allowing several frames is only useful if subclass intends
to process these "in 1 run" (as in, 1 output buffer), not for having another
(inner) loop in subclass where the baseclass one will do just fine.
_BAD_CFLAGS should always come first, then GST_PLUGINS_BASE_CFLAGS,
then GST_BASE_CFLAGS then GST_CFLAGS. Same for libs: first plugins
base libs, then GST_BASE_LIB then GST_LIBS.
This will help elements that cannot deal with multistream,
such as the RTP payloader.
The caps now do not include a "streams" field anymore, but
a "multistream" boolean, since we have no real use for knowing
the exact amount of streams.
https://bugzilla.gnome.org/show_bug.cgi?id=665078
There are two of them, unintuitively enough; the one passed
to the encoder should not be the one that gets written to the
file. The former maps the input to an ordering which puts
paired channels first, while the latter moves the channels
to Vorbis order. So add code to calculate both, and we now
have properly paired channels where appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=665078
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.
Go from the bounds mentioned in the spec, and allow some more
variation.
In particular, don't allow silly low bitrates, and allow reaching
the maximum useful bitrate.
Asking for 1 bit/s would select a 0 byte buffer, leading
to a crash. Buffer size is now controlled by a max-payload-size
property, which can't be less than 2.
Additionally, since Opus packets may change between stereo
and mono as the encoder sees fit, assume two channels when
we do not see a header, and use the header value otherwise.
Opus headers appear only when muxed in Ogg, so only place them
on the caps, where oggmux will find them, but other elements will
be blithely unaware of them.
