The test check that the stream output is correctly flushed when the
input decoder is flushed, ensuring that previous commit didn't break
the triggering of the flush.
This test provides a non-regression test for the issue #26915, in which
a decoder with internal pool gets stuck when flush is not done correctly
and which has been fixed right before.
The test provides an infrastructure based on previous transcode tests
and video output tests, that will serve as basis for other
input_decoder.c tests.
src/video_output/video_output.c:302:44: warning: suspicious concatenation of string literals in an array initialization; did you mean to separate the elements with a comma? [-Wstring-concatenation]
"--no-auto-preparse", "--dec-dev=" MODULE_STRING,
^
,
modules/stream_out/transcode.c:370:44: warning: suspicious concatenation of string literals in an array initialization; did you mean to separate the elements with a comma? [-Wstring-concatenation]
"--no-auto-preparse", "--dec-dev=" MODULE_STRING,
^
,
... Instead of validating at encoder output.
With the last transcode refactors, a regression requiring encoder drain
to have any output of the transcode pipeline wasn't caught by the
current testing suite. [1]
This allows us to validate the output of the transcode pipeline as a
whole and covers more potential regressions.
[1] 2c8db7d8009894f0bedb0eb9f7143a0ac5c54a63
The endpoint checks that the encoder is correctly closed when reaching
the end of the test. Such failure typically happened during the refactor
of encoders function pointers into a separate virtual table.
A unit-test for the transcoder code currently is hard to achieve, as it
involves decoders, encoders, filters, sout_stream_t object, and general
transcode code.
This commit introduces an integration test which mocks the extern
components (filters, decoders, encoders) used by the transcode pipeline
and starts this pipeline using the usual input item properties.
The main end goals are to:
- check whether no part of the stream is dropped.
- check whether push model with video context is supported everywhere.
- check the different kind of decoder behaviour, in particular those
for which decode is asynchronous with the decoder_QueueVideo call,
those for which Open() is asynchronous with the decoder_UpdateVideo*
call and their synchronous variants.
- check memory leaks and use-after-free in the pipeline (through asan).
- check threading within the pipeline (through tsan).
- check decoder, encoder and filter loading failure.
- check format adaptation through filters before the encoder.
- check format conversion (called final_conv_static) before the
encoder, needed for encoders requesting a conversion.
It's currently written in an asynchronous state way spread across
multiple feature functions to handle the different stage of the pipeline
without interaction, like it was done for the video output test, but we
might want to find a way to rewrite those tests in a more sequential way
if it were to get more complex even.
This test scenario for the transcode checks that the error state is
correctly reported back to the stream output pipeline even if it
happened asynchronously.
A unit-test for the transcoder code currently is hard to achieve, as it
involves decoders, encoders, filters, sout_stream_t object, and general
transcode code.
This commit introduces an integration test which mocks the extern
components (filters, decoders, encoders) used by the transcode pipeline
and starts this pipeline using the usual input item properties.
The main goals are to:
- check whether no part of the stream is dropped.
- check whether push model with video context is supported everywhere.
- check the different kind of decoder behaviour, in particular those
for which decode is asynchronous with the decoder_QueueVideo call,
those for which Open() is asynchronous with the decoder_UpdateVideo*
call and their synchronous variants.
- check memory leaks and use-after-free in the pipeline (through asan).
- check threading within the pipeline (through tsan).
- check decoder, encoder and filter loading failure.
- check format adaptation through filters before the encoder.
- check format conversion (called final_conv_static) before the
encoder, needed for encoders requesting a conversion.
this allows an application to manage error messages outside of the UI
lifetime. For instance to store error messages before the UI is loaded and able
to handle dialogs.
ref: #26378
It is not used in POSIX systems. On other system it probably don't make a
difference anymore, only Windows has actual useful values for
VLC_THREAD_PRIORITY_XXX. The synchronization is more important than having some
threads called more often than others.
vlc_stream_NewURL() can spawn stream filters which may alter the content
or even the nature of the stream, which is not suitable here.
vlc_access_NewMRL() would avoid loading stream filters at all. But it
would also skip testing the cache filter, thus missing much of the point
of the test case.
So use a reproducible pseudorandom input using a constant seed, which
is known not to trigger any stream filter.
Fixes#26569.
Historically this function would set the device for a specified audio
output module. This required the application to somehow "know" what
audio output module it wanted to use, which is very suboptimal for
forward compatibility and portability.
Worse yet, this design failed outright in VLC 2.2 with the addition of
MMDevice and PulseAudio. This lead to the convention of leaving the
module parameter NULL to change the device of the currently active
audio output.
As with the removal of libvlc_audio_output_device_list_get(), it seems
saner to simply remove the old broken semantics.
This function does not work with MMDevice and PulseAudio, and does not
support hot-plug. To enumerate devices, the newer function
libvlc_audio_output_device_enum() ought to be used, which also works
with MMDevice and PulseAudio, and track audio device events.
No amount of documentational warnings will save developers from using
this broken function. It is better to remove it now that there is the
opportunity to do so in the form of the LibVLC 4.0 binary compatibility
break.
> WARNING : test/Makefile.am: 325: noinst_PROGRAMS was already defined in condition TRUE, which includes condition HAVE_DYNAMIC_PLUGINS ...
> test/Makefile.am:15: ... 'noinst_PROGRAMS' previously defined here
The test driver can be used to check against the screen output list or
to check whether the window module can be opened correctly, allowing
testing for real-world environment module implementation.
Since it's also a separate binary, it can be used in development cycle
to check the behaviour of new vout window module implementation.