EOI are not always at the last 4 bytes. We need to search
the last 5 bytes to find the 0xFFD9 sequence as jpegenc seems
to round the buffer size to the next 4 multiple.
timestamps are now chosen in the following order:
upstream -> parsed by decoder -> calculated from timestamp offset
we also check the timestamps supplied from upstream/decoder to see if they
atleast is increasing.
0.4.7 creates code with unavailable symbols
0.4.8 creates buggy code
Let's use git head of orc (which still won't work because git head
of orc still claims to be 0.4.8)
This allows all the rest of -bad to build properly.
The PES header length is calculated before setting the dynamic flags, returning
a wrong value. Small frames that should be sent in a single TS packet are
spawned to a new packet because of that error. For audio streams where a single
frame can cope in one TS packet it introduces a huge overhead.
For a 100B packet, we prepare a TS packet with a payload of(100+9)B. Then, we
write the TS header using this value in tsmux_write_ts_header, and call
tsmux_stream_get_data(). The dynamic flags where not set yet and now
tsmux_stream_pes_header_length() returns 14B instead of 9B. The payload of the
TS packet is 114B, 5B more than what was calculated. 109B are sent in a first
packet and the remaining 5B are sent in another one.
Fixes bug #628548.
The mutex locked is for the 'mux' object, but we unlock the
pad, which means that if the rtpmux gets a flush, then the
object lock will stay locked forever, causing it to freeze
the next time it tries to take it.
Fixes bug #627991
This fixes an infinite loop if an EOS event is received before
GstBaseVideoDecoder::start() is called, e.g. immediately when the
pads are activated.
Fixes bug #626815.
When the test is run, the schema file won't be installed yet,
and there doesn't seem to be an environment variable to set
to force GSettings to look in a different directory.
https://bugzilla.gnome.org/show_bug.cgi?id=626603
This commit is out of sequence, it really belongs between commits
1509833141 (Automatic update of
common submodule) and dd26f378b0
(configure: Fix the CELT checks to ...)
This commit is out of sequence, it really belongs between commits
1509833141 (Automatic update of
common submodule) and dd26f378b0
(configure: Fix the CELT checks to ...)
This commit is out of sequence, it really belongs between commits
1509833141 (Automatic update of
common submodule) and dd26f378b0
(configure: Fix the CELT checks to ...)
This commit is out of sequence, it really belongs between commits
1509833141 (Automatic update of
common submodule) and dd26f378b0
(configure: Fix the CELT checks to ...)
