The original code (old mpegtsparse) from which this plugin was based on
was dual-licensed. This allowed usage of the code under any of the
licenses (which including LGPL):
"""
* Alternatively, the contents of this file may be used under the terms of
* the GNU Lesser General Public License Version 2 or later (the "LGPL"),
* in which case the provisions of the LGPL are applicable instead
* of those above. If you wish to allow use of your version of this file only
* under the terms of the LGPL, and not to allow others to
* use your version of this file under the terms of the MPL, indicate your
* decision by deleting the provisions above and replace them with the notice
* and other provisions required by the LGPL. If you do not delete
* the provisions above, a recipient may use your version of this file under
* the terms of the MPL or the LGPL.
"""
When refactored (leading to the creation of this new plugin), I chose all
new code to be LGPL-only (which was allowed for pre-existing code) by removing
the MPL sections.
The headers were all updated, but not the plugin license field. This commit
fixes this.
The thread that calls the success/failure callback can be the
same that is adding/removing the element as the IDLE probe can
happen instantly if the pad is not 'busy'.
This required moving some checks for the callback counter around
as well as removing some pad pushes from the main test thread as
they were made useless after the IDLE pad probe was fixed in core
by commit 0324358ebc
In order to be able to change the caps on multiple capsfilters the
source element needs to be stopped, otherwise it will get a few
reconfigure events and might try to renegotiate while the bin
is still transitioning its caps, leading to a not-negotiated failure
and the image capture won't happen because the source will be
unusable.
The solution is to keep the source in paused while the caps are being
changed in the bin, and then bring the element back to playing once
it is done. Unfortunately this increases the image capture latency,
but it should always work.
A possible improvement to reduce the latency is to add another signal
to be called before 'start-capture': 'prepare-capture'. At this step
the camera source should set all caps it needs and get the source
ready for doing the capture as soon as 'start-capture' is called.
This can be done on a future commit
* stream-start-id is mandatory at the beginning, so add that to the
gdp headers
* caps must be sent before new segment, invert the order from legacy
0.10 code
And fix the tests as a ref is now kept for those buffers that compose
the header
It is not perfect but it allows us to be sure that the mandatory 'framerate'
field is present in the caps.
As soon as some information is found in the stream, that will be
updated.
https://bugzilla.gnome.org/show_bug.cgi?id=723243
Most of the tests weren't updated after the sticky events order
and stream start. Fix that and refactor those tests check that
are the same to some common functions.
Those functions still don't actually test the content but at
least now they are in a single place and can be improved
without replication
Commit 6af387cd5a made h264parse
strip a leading 0x00 byte from some output scenarios. This broke
tests as bs_to_nal test expects one more byte on the output.
Fix this by comparing the output with the expected stripped version,
too.
An SEI RBSP could contains more than one SEI message as specified in
7.4.2.3.1.
This commit change the parser API: the gst_h264_parser_parse_sei()
function now create and fill a GArray containing GstH264SEIMessage.
https://bugzilla.gnome.org/show_bug.cgi?id=721715
The spec states that the last byte of a NAL 'shall not' be 0x00
and it is allowed for byte-stream format to add padding 0x00 for
alignment.
So our parser should strip any trailling 0x00.
https://bugzilla.gnome.org/show_bug.cgi?id=721384
It's impossible to create another pipeline with d3dvideosink after disposing
the previous one due to some problem in d3dvideosink. The message is: "Unable
to register Direct3D hidden window class".
I've evaluated the problem and it's that UnregisterClass() in working thread is
called before DestroyWindow() and UnregisterClass() does nothing.
https://bugzilla.gnome.org/show_bug.cgi?id=722622
If the first buffer that we handle for a stream has no timestamp, we
would never consider this pad again for muxing which causes queues to
fill up and pipelines to stall. Instead, try to mux pads with -1
timestamps as soon as possible.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=722330
This will be incredible slow if the upstream block size is very small. Instead
continue scanning for the header where we previously stopped.
For the standard filesrc block-size this made decoding a file about
3 times faster.
https://bugzilla.gnome.org/show_bug.cgi?id=719890
