It is allowed to send/receive UDP packets with no data. When such
a packet is available, select() will return with success but
ioctl(FIONREAD) will return 0. But a read() must still occur in
order to clear off the UDP packet from the queue.
This patch will read the dataless packet from the socket. If
select() was woken for other reasons (and FIONREAD returns 0),
this may result in a UDP packet getting accidentally dropped.
But since UDP is not reliable, this is acceptable.
NOTE: This patch fixes a nasty bug where sending a dataless
UDP packet to a udpsrc instance will cause an infinite
loop.
https://bugzilla.gnome.org/show_bug.cgi?id=666644
Signed-off-by: John Ogness <john.ogness@linutronix.de>
remove unused variable to fix compile error:
make -C audioparsers
make[3]: Betrete Verzeichnis '/home/lex/tmp/gst-plugins-good/gst/audioparsers'
CC libgstaudioparsers_la-gstaacparse.lo
gstaacparse.c: In function 'gst_aac_parse_read_loas_audio_specific_config':
gstaacparse.c:446:12: error: variable 'sbr' set but not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors
Signed-off-by: Oleksij Rempel (Alexey Fisher) <bug-track@fisher-privat.net>
... rather than having (potentially) unnecessary duplicates written all over,
or even contradictory varying filesize info, or duration info that will not
be rewritten upon header rewrite.
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.
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.
Since unsigned types are used, a negative value would show as very, very
positive.
Fixes A/V sync on some... less than well made files where timestamps go
backwards.
We assume for now that all buffers in a buffer list
should end up in the same file (so we can group GOPs
in buffer lists, for example). Could optimise this
a bit to avoid the memcpy.
This also copies the caps. Otherwise we could end up pusing
the first buffer without any caps, which causes downstream
to not get notified about the caps.
Fixes bug #664892.
there is at least two use cases where default frame rate
should or may be disabled:
- vp8 stream with altref frame enabled. If default frame rate
is enabled, some players will missinterprete it (critical!)
- for webm container, to reduce micro overhead
- for stream with variable frame rate.
Signed-off-by: Alexey Fisher <bug-track@fisher-privat.net>
Handle corner case where we try to read beyond the end of the
last file part, in which case we want to return a short read.
If we get fewer bytes than expected for any other file part,
we should just error out, since something fishy's going on
then.
Looks like some parsers (in some versions at least) expect the
offsets to be set, and behave weird if that's not the case
(e.g. off-by-one in h264parse).
Let's initialize them to zero. It looks alright, but then it
also looks alright with v3, or with the corresponding pixels
from the source. I don't know what the original intent would
be, and the original effectv source also has this bug/feature.
https://bugzilla.gnome.org/show_bug.cgi?id=661841
If the sample/block number happens to be the same as the block
size, we assume variable block size, and thus counters in samples
in the headers. This can only get us a false positive for a block
size of 1, which is invalid. We can get false negatives more
often though (eg, if not starting at the start of the stream),
but then that's already GIGO.
