Links the specified #GstPad the GstHarness srcpad.
Links the specified #GstPad the GstHarness sinkpad. This can be useful if perhaps the srcpad did not exist at the time of creating the harness, like a demuxer that provides a sometimes-pad after receiving data.
A convenience function to allows you to call gst_pad_add_probe on a #GstPad of a #GstElement that are residing inside the #GstHarness, by using normal gst_pad_add_probe syntax
Add api with params as one of the supported metadata API to propose when receiving an allocation query.
Similar to gst_harness_add_sink_harness, this is a convenience to directly create a sink-harness using the sink_element_name name specified.
Similar to gst_harness_add_src, this allows you to send the data coming out of your harnessed #GstElement to a sink-element, allowing to test different responses the element output might create in sink elements. An example might be an existing sink providing some analytical data on the input it receives that can be useful to your testing. If the goal is to test a sink-element itself, this is better achieved using gst_harness_new directly on the sink.
Similar to gst_harness_add_sink, this allows you to specify a launch-line instead of just an element name. See gst_harness_add_src_parse for details.
Similar to gst_harness_add_src_harness, this is a convenience to directly create a src-harness using the src_element_name name specified.
A src-harness is a great way of providing the #GstHarness with data. By adding a src-type #GstElement, it is then easy to use functions like gst_harness_push_from_src or gst_harness_src_crank_and_push_many to provide your harnessed element with input. The has_clock_wait variable is a great way to control you src-element with, in that you can have it produce a buffer for you by simply cranking the clock, and not have it spin out of control producing buffers as fast as possible.
Similar to gst_harness_add_src, this allows you to specify a launch-line, which can be useful for both having more then one #GstElement acting as your src (Like a src producing raw buffers, and then an encoder, providing encoded data), but also by allowing you to set properties like "is-live" directly on the elements.
The number of #GstBuffers currently in the #GstHarness sinkpad #GAsyncQueue
The total number of #GstBuffers that has arrived on the #GstHarness sinkpad. This number includes buffers that have been dropped as well as buffers that have already been pulled out.
Similar to gstcheck.harness.Harness.crankSingleClockWait, this is the function to use if your harnessed element(s) are using more then one gst_clock_id_wait. Failing to do so can (and will) make it racy which #GstClockID you actually are releasing, where as this function will process all the waits at the same time, ensuring that one thread can't register another wait before both are released.
A "crank" consists of three steps: 1: Wait for a #GstClockID to be registered with the #GstTestClock. 2: Advance the #GstTestClock to the time the #GstClockID is waiting for. 3: Release the #GstClockID wait. Together, this provides an easy way to not have to think about the details around clocks and time, but still being able to write deterministic tests that are dependent on this. A "crank" can be though of as the notion of manually driving the clock forward to its next logical step.
Allocates a buffer using a #GstBufferPool if present, or else using the configured #GstAllocator and #GstAllocationParams
Allows you to dump the #GstBuffers the #GstHarness sinkpad #GAsyncQueue to a file.
The number of #GstEvents currently in the #GstHarness sinkpad #GAsyncQueue
The total number of #GstEvents that has arrived on the #GstHarness sinkpad This number includes events handled by the harness as well as events that have already been pulled out.
Most useful in conjunction with gst_harness_new_parse, this will scan the #GstElements inside the #GstHarness, and check if any of them matches element_name. Typical usecase being that you need to access one of the harnessed elements for properties and/or signals.
Gets the allocator and its params that has been decided to use after an allocation query.
Get the timestamp of the last #GstBuffer pushed on the #GstHarness srcpad, typically with gst_harness_push or gst_harness_push_from_src.
Get the #GstTestClock. Useful if specific operations on the testclock is needed.
This will set the harnessed #GstElement to gst.types.State.Playing. #GstElements without a sink-#GstPad and with the gst.types.ElementFlags.Source flag set is considered a src #GstElement Non-src #GstElements (like sinks and filters) are automatically set to playing by the #GstHarness, but src #GstElements are not to avoid them starting to produce buffers. Hence, for src #GstElement you must call gstcheck.harness.Harness.play explicitly.
Pulls a #GstBuffer from the #GAsyncQueue on the #GstHarness sinkpad. The pull will timeout in 60 seconds. This is the standard way of getting a buffer from a harnessed #GstElement.
Pulls an #GstEvent from the #GAsyncQueue on the #GstHarness sinkpad. Timeouts after 60 seconds similar to gst_harness_pull.
Pulls a #GstBuffer from the #GAsyncQueue on the #GstHarness sinkpad. The pull will block until an EOS event is received, or timeout in 60 seconds. MT safe.
Pulls an #GstEvent from the #GAsyncQueue on the #GstHarness srcpad. Timeouts after 60 seconds similar to gst_harness_pull.
Pushes a #GstBuffer on the #GstHarness srcpad. The standard way of interacting with an harnessed element.
Basically a gst_harness_push and a gst_harness_pull in one line. Reflects the fact that you often want to do exactly this in your test: Push one buffer in, and inspect the outcome.
Pushes an #GstEvent on the #GstHarness srcpad.
Transfer data from the src-#GstHarness to the main-#GstHarness. It consists of 4 steps: 1: Make sure the src is started. (see: gst_harness_play) 2: Crank the clock (see: gst_harness_crank_single_clock_wait) 3: Pull a #GstBuffer from the src-#GstHarness (see: gst_harness_pull) 4: Push the same #GstBuffer into the main-#GstHarness (see: gst_harness_push)
Transfer one #GstBuffer from the main-#GstHarness to the sink-#GstHarness. See gst_harness_push_from_src for details.
Pushes an #GstEvent on the #GstHarness sinkpad.
Get the min latency reported by any harnessed #GstElement.
Setting this will make the harness block in the chain-function, and then release when gstcheck.harness.Harness.pull or gstcheck.harness.Harness.tryPull is called. Can be useful when wanting to control a src-element that is not implementing gst.clock.Clock.idWait so it can't be controlled by the #GstTestClock, since it otherwise would produce buffers as fast as possible.
Sets the GstHarness srcpad and sinkpad caps.
Sets the GstHarness srcpad and sinkpad caps using strings.
When set to true, instead of placing the buffers arriving from the harnessed #GstElement inside the sinkpads #GAsyncQueue, they are instead unreffed.
As a convenience, a src-harness will forward gst.types.EventType.StreamStart, gst.types.EventType.Caps and gst.types.EventType.Segment to the main-harness if forwarding is enabled, and forward any sticky-events from the main-harness to the sink-harness. It will also forward the gst.types.QueryType.Allocation.
Sets the liveness reported by #GstHarness when receiving a latency-query. The default is true.
Sets the allocator and params to propose when receiving an allocation query.
Sets the GstHarness sinkpad caps.
Sets the GstHarness sinkpad caps using a string.
Sets the GstHarness srcpad caps. This must be done before any buffers can legally be pushed from the harness to the element.
Sets the GstHarness srcpad caps using a string. This must be done before any buffers can legally be pushed from the harness to the element.
Advance the #GstTestClock to a specific time.
Sets the min latency reported by #GstHarness when receiving a latency-query
Convenience that calls gst_harness_push_to_sink pushes number of times. Will abort the pushing if any one push fails.
Transfer data from the src-#GstHarness to the main-#GstHarness. Similar to gst_harness_push_from_src, this variant allows you to specify how many cranks and how many pushes to perform. This can be useful for both moving a lot of data at the same time, as well as cases when one crank does not equal one buffer to push and v.v.
Similar to what gst_harness_src_push does with #GstBuffers, this transfers a #GstEvent from the src-#GstHarness to the main-#GstHarness. Note that some #GstEvents are being transferred automagically. Look at sink_forward_pad for details.
Pulls all pending data from the harness and returns it as a single #GBytes.
Pulls all pending data from the harness and returns it as a single buffer.
Tears down a GstHarness, freeing all resources allocated using it.
Pulls a #GstBuffer from the #GAsyncQueue on the #GstHarness sinkpad. Unlike gst_harness_pull this will not wait for any buffers if not any are present, and return null straight away.
Pulls an #GstEvent from the #GAsyncQueue on the #GstHarness sinkpad. See gst_harness_try_pull for details.
Pulls an #GstEvent from the #GAsyncQueue on the #GstHarness srcpad. See gst_harness_try_pull for details.
The number of #GstEvents currently in the #GstHarness srcpad #GAsyncQueue
The total number of #GstEvents that has arrived on the #GstHarness srcpad This number includes events handled by the harness as well as events that have already been pulled out.
Sets the system #GstClock on the GstHarness #GstElement
Sets the #GstTestClock on the #GstHarness #GstElement
Waits for timeout seconds until waits number of #GstClockID waits is registered with the #GstTestClock. Useful for writing deterministic tests, where you want to make sure that an expected number of waits have been reached.
Stop the running #GstHarnessThread
#GstHarness is meant to make writing unit test for GStreamer much easier. It can be thought of as a way of treating a #GstElement as a black box, deterministically feeding it data, and controlling what data it outputs.
The basic structure of #GstHarness is two "floating" #GstPads that connect to the harnessed #GstElement src and sink #GstPads like so:
__________________________ _____ | _____ _____ | _____ | | | | | | | | | | | src |--+-| sink| Element | src |-+--| sink| |_____| | |_____| |_____| | |_____| |__________________________|With this, you can now simulate any environment the #GstElement might find itself in. By specifying the #GstCaps of the harness #GstPads, using functions like gstcheck.harness.Harness.setSrcCaps or gstcheck.harness.Harness.setSinkCapsStr, you can test how the #GstElement interacts with different caps sets.
Your harnessed #GstElement can of course also be a bin, and using gstcheck.harness.Harness.newParse supporting standard gst-launch syntax, you can easily test a whole pipeline instead of just one element.
You can then go on to push #GstBuffers and #GstEvents on to the srcpad, using functions like gstcheck.harness.Harness.push and gstcheck.harness.Harness.pushEvent, and then pull them out to examine them with gstcheck.harness.Harness.pull and gstcheck.harness.Harness.pullEvent.
A simple buffer-in buffer-out example
Another main feature of the #GstHarness is its integration with the #GstTestClock. Operating the #GstTestClock can be very challenging, but #GstHarness simplifies some of the most desired actions a lot, like wanting to manually advance the clock while at the same time releasing a #GstClockID that is waiting, with functions like gstcheck.harness.Harness.crankSingleClockWait.
#GstHarness also supports sub-harnesses, as a way of generating and validating data. A sub-harness is another #GstHarness that is managed by the "parent" harness, and can either be created by using the standard gst_harness_new type functions directly on the (GstHarness *)->src_harness, or using the much more convenient gstcheck.harness.Harness.addSrc or gstcheck.harness.Harness.addSinkParse. If you have a decoder-element you want to test, (like vp8dec) it can be very useful to add a src-harness with both a src-element (videotestsrc) and an encoder (vp8enc) to feed the decoder data with different configurations, by simply doing:
and then feeding it data with: