It uses random data streams but dashdemux nowadays actually looks into the
streams and doesn't like randomness very much. The tests should probably just
become validate tests on real streams.
https://bugzilla.gnome.org/show_bug.cgi?id=769553
As is done everywhere else.
From what I can gather from make -C tests/check V=1 $(GST_PLUGINS_BAD_CFLAGS) is
required in order to find in-tree headers as well as srcdir != builddir
configurations.
Adds unit tests similar to the ones that we have for DASH and HLS.
Tests:
* manifest parsing finishes successfully
* some queries (duration, seekable, latency)
* seeking with various values and flags
Using the new GstAdaptiveDemux test framework, add tests that
exercise hlsdemux. The following tests are added:
simpleTest
A simple playlist that contains some media URLs
testMediaPlaylist
A master playlist with a variant playlist that contains media URLs
testMediaPlaylistNotFound
A master playlist that points to a missing variant playlist
testFragmentNotFound
A master playlist with a variant playlist that contains media URLs
There is a missing media file referenced from the variant playlist.
testFragmentDownloadError
A master playlist with a variant playlist that contains media URLs
During the download of one media file, the test simulates the network
connection being dropped.
testSeek
A simple test of trying to perform a seek on an HLS stream.
To allow code from dash_demux.c to be used by other elements
that are based upon GstAdaptiveDemux, the code has been
refactored into four new files:
adaptive_demux_engine.[ch]
adaptive_demux_common.[ch]
The code in adaptive_demux_engine.c provides a generic
test engine for elements based upon GstAdaptiveDemux.
The code in adaptive_demux_common.c provides a set
of utility functions that are common between the tests
for hlsdemux and dashdemux.
As part of the refactoring, variables in structures were
renamed from using camelCase to underscore_case to match other
GStreamer source code.
The fake_http_src was renamed test_http_src and changed to use
callbacks to provide input data and error conditions. Rather than
using an array of input data that tries to encode all the
possible use cases for the GstTestHTTPSrc element, use a struct of
callbacks.
Users of this element are obliged to implement at least the src_start
callback, which provides a way to link from a URI to the settings
for that URI.
The videoframe-audiolevel element acts like a synchronized audio/video "level"
element. For each video frame, it posts a level-style message containing the
RMS value of the corresponding audio frames. This element needs both video and
audio to pass through it. Furthermore, it needs a queue after its video
source.
https://bugzilla.gnome.org/show_bug.cgi?id=748259
Split the unit tests for rtponviftimestamp and rtponvifparse
elements in separate files.
Setup and cleanup the element and pads in fixures. Make the tests work
with CK_FORK=no as well, by cleaning up the 'buffers' list when needed.
Make unit tests work when run in valgrind by unreffing all buffers,
and by not allocating any payload in RTP buffers. Since we're not
doing anything with the payload part, but we're memcmp-aring the
complete buffer memory, valgrind complained about non-initialized
memory being used.
https://bugzilla.gnome.org/show_bug.cgi?id=757688
Created a unit test for dashdemux. It relies on a fake SOUP HTTP src plugin
that will feed data to dashdemux. The test controls the data to be
generated and checks the correct data was received for each expected
stream.
https://bugzilla.gnome.org/show_bug.cgi?id=756322
We need to sync the pad values before taking the aggregator and pad locks
otherwise the element will just deadlock if there's any property changes
scheduled using GstController since that involves taking the aggregator and pad
locks.
Also add a test for this.
https://bugzilla.gnome.org/show_bug.cgi?id=749574
We verify that all the buffers on an obscured sinkpad are skipped by overriding
the map() function in the GstVideoMeta of the buffers to set a variable when
called. We also test that the buffers do get mapped when they're not obscured.
Blame^WCredit for the GstVideoMeta map() idea goes to Tim.
https://bugzilla.gnome.org/show_bug.cgi?id=746147
