RTCP header can be (2^16 + 1) * 4 bytes long, so when validating a bogus
packet it was possible to get a 16bit overflow resulting in a length of 0.
This would put the gst_rtcp_buffer_validate_data function in a endless loop.
https://bugzilla.gnome.org/show_bug.cgi?id=667313
... to avoid unnecessary spurious errors (upon e.g. shutdown).
If a real error is applicable in this unusual circumstance (missing other pad),
other (STREAM_LOCK protected) call paths can take care of that.
Pads are initialized twice: when requesting pads and when
initializing collectpads. Avoid double initialization by
checking if collectpads are still going to be initialized when
creating request pads.
When the payload for an Exif tag is less than or equal to 4 bytes,
the data is simply put into the offset field. Fix writing these
kinds of payloads on big endian systems (and possibly also on
little endian systems). The caller will have already formatted
the bytes in memory according to the writer's endianness, so just
write out the bytes as they are in this case. Fixes tags unit test
on big endian systems.
We used to add a trailing \n to the end of generated xmp packets.
Windows viewer was unhappy with it and we fixed it in
96d2120c2b
The problem is that this caused xmp generated before this fix
to not be recognized and parsed anymore. This patch makes it
recognize xmp with the trailing \n and without, fixing the
regression. Also adds tests for it.
This option will produce duplicate frames if we get
a frame with GAP flag. This will reduce CPU load and file size.
This option should be disabled for real time applications, because it
collects GAP frames and waits until it gets a non GAP frame to start
encoding.
v30.06.2011: make some spell changes.
v03.07.2011: add handling of EOS and discontinuous for dup-on-gap.
v19.12.2011: fix pointer dangling in theora_timefifo_free
v20.12.2010: fix timestamp bug for dup-on-gap=0
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=627459
Signed-off-by: Oleksij Rempel (Alexey Fisher) <bug-track@fisher-privat.net>
Whereas the previous default 0 was backwards compatible in that it lead
to erroring out immediately upon any error, elements that are really
ported and using the base class error macro can be assumed to intend to
improve behaviour rather than maintaining the old one. So, make it easy
on those and any future one and tolerate some errors by default, as intended.
Fixes#666579.
GstCollectPads2 locking was changed from GstCollectPads to use
the stream lock instead of the object lock for those cases, so
change it so here as well to match.
https://bugzilla.gnome.org/show_bug.cgi?id=666379
This prevents trying to seek and failing, then ending up unable
to stream because we can't get back at the headers.
A more robust way would be to find a good place to reinject the
headers when a seek fails, but I can't seem to get this to work.
When using g_convert, we should only pass the length
of the string content (without the \0) as g_convert will
only parse the real contents when changing formats. Including
the \0 causes it to add another \0, increasing the string
size when not needed.
For example, when writting a North geo location ref entry, that should
be a string with a single N letter, it would write:
"N\0\0", causing the string to have size 3, instead of 2 as expected.
In our case, we can pass -1 and let g_convert calculate the strlen as
we don't use the length anywhere else.
This fixes jifmux's tests on gst-plugins-bad.
... to also properly indicate chain's endpad if no elements are in the
chain (due to the endpad being a raw demuxer pad, or one setup without
decoders since uridecodebin or higher up decided not to need those).
Previously we always used textoverlay for rendering the output of
a parser, now the same code as for the renderers is used and the
element with the highest rank is used.
Fixes bug #663822.
We added the utf typefinder because the mp3 typefinder was a tad
overzealous when it came to typefinding things as mp3, and replaced
it with even more overzealous utf16/32 typefinders.
Fixes unit test.
Slight change in semantics for convenience. Shouldn't cause any
problems since this function is usually only used on pre-filtered
caps and not random caps, and it's hard to imagine a situation
where someone would want to rely on the previous behaviour.
