Moved most of the code to GstBaseAudioCodec, GstBaseAudioDecode is
now really small, maybe we do not really need it (or its encoder
counterpart). Added more API for subclasses and documentation.
Otherwise, discoverer will generated an "inner" codec
where there can be a tranformation (eg, kate -> DVD SPU,
and various ->text/x-pango-markup).
https://bugzilla.gnome.org/show_bug.cgi?id=639055
Without the perfect timestamp machinery, the RTP timestamp can be
computed directly from the running time of a buffer, but the perfect
timestamp patch broke that assumption. This patch restores it by
having the first perfect timestamp be the running time of that buffer
and counting from there.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=654434
After all, we do hope to find actual data for these streams.
However, warn if we could not set up a chain when we find a
non BOS page, as that means we don't have a valid Ogg stream.
https://bugzilla.gnome.org/show_bug.cgi?id=657151
While the casual reader might end up bewildered by just why this
change might increase clarity, it just happens than, in the libogg
and associated sources, op is the canonical name for an ogg_packet
whlie og is the canonical name for an ogg_page, and reading this
code confuses me.
https://bugzilla.gnome.org/show_bug.cgi?id=657151
Headers are inherently durationless.
Instead, set duration to 0 to avoid increasing tracked granpos,
and do not warn about it, since it is totally expected.
https://bugzilla.gnome.org/show_bug.cgi?id=657151
Version written is 3.0
Base times are left empty for now.
Content-Type should be the MIME type of the stream. It is set to
the GStreamer media type for now, which is probably the same for
the streams oggmux supports.
https://bugzilla.gnome.org/show_bug.cgi?id=563251
vorbisenc currently reacts in a rater draconian fashion if input
timestamps are more than 1/2 sample off what it considers ideal. If data
is 'too late' it truncates buffers, if it is 'too soon' it completely
shuts down encode and restarts it. This is causingvorbisenc to produce
corrupt output when encoding data produced by sources with bugs that
produce a smple or two of jitter (eg, flacdec)
If ints are 64 bits, 32 bits should get promoted in varargs anyway,
and we don't care about 16 bit ints.
This makes the code a lot more readable, and still gets us nice
hexadecimal 32 bit serialnos.
https://bugzilla.gnome.org/show_bug.cgi?id=656775
Instead of just assuming all pads are created at the same time,
remember which ones are actually new (via ->pending_blocked_pads).
This allows the following use-case to properly work:
* Upstream starts with audio-only
* Only that pad gets data, blocks and a real audio sink is created
* Upstream laters adds a video stream
* A new pad is requested, blocks and reconfiguration kicks in in
order to add a new real video sink
