The tests were done in 2 steps, first there was a suite
that generated the files (while checking that camerabin
was operating correctly). Then there was a second suite
that was run to check that all files were playable with
playbin2. Those second tests were not being run because
they were checking if camerabin was initialized, and it
never was as those tests didn't use a 'setup' function.
This commit refactors the tests by removing this second
suite and merging its validation with the first suite's
functions.
Use guint instead of guint16 to represent the size of the encoded image,
this would make some recombined images lose most of their data and
show like a big black image with a small line of content on top.
Also adds a minor log message.
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.
