The LOAS variant seems to have three different subvariants itself,
only one of them is implemented as my two samples happen to be
using that one.
The sample rate is not always reported correctly, as the "main"
sample rate is apparently sometimes half what it should be (both
of my samples report 24000 Hz there), and there are two other
parts of the subvariant with different sampling rates. One of them
is parsed, but not the other, as it's located after some other
large amount of variable data that needs parsing first, and there
seems to be a LOT of it, which is useless for our needs here.
This ends up being rather inconsequential, as ffdec_aac_latm,
which is the only decoder that can decode such streams, does not
need the sample rate on the caps anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=665394
Use unsigned specifiers for all unsigned values.
A lot of the values used here are unsigned, and some can take
high enough values that their signed counterpart will be negative.
https://bugzilla.gnome.org/show_bug.cgi?id=665911
Add private replacements for deprecated functions such as
g_mutex_new(), g_mutex_free(), g_cond_new() etc., mostly
to avoid the deprecation warnings. We'll change these
over to the new API once we depend on glib >= 2.32.
Fix crash or hang in generic/states unit test when doing stop()
right after start(). Create main loop in the start function already
and not just in the thread function, so that stop() always has a
valid main loop to quit on. Also, calling g_main_loop_quit() before
g_main_loop_run() won't work and result in the stop function waiting
for the thread to join forever. Therefore, wait for the thread to
be ready and get the main loop running in the start() function, to
be sure stop() always works.
Some tests assumed that tag events would always pushed through
immediately, which isn't the case any longer, so push a newsegment
event and an empty buffer first.
A JPEG image inside an RTP stream has a preceeding RFC2435 header that
conveys width/height. The dimensions in this header are limited to be
multiples of 8. Since JPEG uses an MCU of 8x8 pixels any image must
already indirectly have image data dimensions that are rounded up in
order to contain enough data to render the image. Therefore this fix
safely rounds the image dimensions in the RFC2435 header up to the
closest multiple of 8.
