In fragmented streaming, multiple moov/moof will be parsed and their
previously stored samples array might leak when new values are parsed.
The parse_trak and callees won't free the previously stored values
before parsing the new ones.
In step-by-step, this is what happens:
1) initial moov is parsed, traks as well, streams are created. The
trak doesn't contain samples because they are in the moof's trun
boxes. n_samples is set to 0 while parsing the trak and the samples
array is still NULL.
2) moofs are parsed, and their trun boxes will increase n_samples and
create/extend the samples array
3) At some point a new moov might be sent (bitrate switching, for example)
and parsing the trak will overwrite n_samples with the values from
this trak. If the n_samples is set to 0 qtdemux will assume that
the samples array is NULL and will leak it when a new one is
created for the subsequent moofs.
This patch makes qtdemux properly free previous sample data before
creating new ones and adds an assert to catch future occurrences of
this issue when the code changes.
Also make it so that the mtu is always set if specified, not
only in case of the rather weird bufferlist test code path.
This allows us to easily make the payloader fragment a payload
across multiple output packets by setting a small MTU on it.
This reverts commit d46631c5c7.
pad only handle EOS events but not EOS flow, and will push the buffer again
resulting in an assertion error. So we should not handle the buffer
and return EOS flow.
goom_core.c: In function 'goom_update':
goom_core.c:685:5: error: 'param2' may be used uninitialized in this function [-Werror=maybe-uninitialized]
goom_lines_switch_to (goomInfo->gmline2, mode, param2, amplitude, couleur);
^
goom_core.c:684:5: error: 'param1' may be used uninitialized in this function [-Werror=maybe-uninitialized]
goom_lines_switch_to (goomInfo->gmline1, mode, param1, amplitude, couleur);
^
https://bugzilla.gnome.org/show_bug.cgi?id=752053
endpos variable does not correctly understand in the
4.6.3 GCC version. So compile error appears when we do
compile rtph261pay using jhbuild.
This patch is fixed the compile error in 4.6.3 GCC version.
https://bugzilla.gnome.org/show_bug.cgi?id=751985
for files which have corrupted header, libflac is not able to
process the metadata properly. We just try to ignore the error
and continue with the processing, since metadata parsing is not
making much of a difference to libflac
https://bugzilla.gnome.org/show_bug.cgi?id=751334
ximage metadata can't be transformed or copied, but provide an empty
transformation function instead of NULL to allow unconditional calling
of metas' transform functions.
https://bugzilla.gnome.org/show_bug.cgi?id=751778
Draft 16 of "RTP Payload Format for VP8" states in section 4.2 that:
R: Bit reserved for future use. MUST be set to zero and MUST be
ignored by the receiver.
https://bugzilla.gnome.org/show_bug.cgi?id=751929
gstrtph261pay.c: In function 'gst_rtp_h261_pay_class_init':
gstrtph261pay.c:1003:17: error: variable 'gobject_class' set but not used [-Werror=unused-but-set-variable]
GObjectClass *gobject_class;
Implementation according to RFC 4587.
Payloader create fragments on MB boundaries in order to match MTU size
the best it can. Some decoders/depayloaders in the wild are very strict
about receiving a continuous bit-stream (e.g. no no-op bits between
frames), so the payloader will shift the compressed bit-stream of a
frame to align with the last significant bit of the previous frame.
Depayloader does not try to be fancy in case of packet loss. It simply
drops all packets for a frame if there is a loss, keeping it simple.
https://bugzilla.gnome.org/show_bug.cgi?id=751886
If we have a clock, update "now" now with the very latest running time we have.
If timers are unscheduled below we otherwise wouldn't update now (it's only updated
when timers expire), and also for the very first loop iteration now would otherwise
always be 0.
Also the time is used for the timeout functions, e.g. to calculate any times
for the next timeouts and we would otherwise pass too old times there.
https://bugzilla.gnome.org/show_bug.cgi?id=751636
We always pushed one buffer into the adapter, then handled exactly that one
buffer and flushed it from the adapter. Now also don't memcpy() the actual
payload but just attach the input buffer's data to the output buffer.
This code still needs some serious refactoring/rewriting.
