"README.md" did not exist on "765497c49fcaf9f015a1ecf0edc8b09c189546a5"
Select Git revision
Search by author
- Any Author
- authors
-
Administrator root
-
Alaric Senat
asenat
-
Alexandre Janniaux alexandre-janniaux
-
Bart - The Review Bot
Bart
-
Benjamin Arnaud
bunjee
-
Christophe Massiot cmassiot
-
Claudio Cambra
claucambra
-
David dfuhrmann
-
Denis Charmet
typx
-
Fatih Uzunoğlu fuzun
-
Felix Paul Kühne
fkuehne
-
François Cartegnie
fcartegnie
-
Gabriel Lafond-Thenaille gabriel_lt
-
**** project_435_bot
-
**** project_435_bot_867220ea9cbb40f38051abad33491375
-
Ilkka Ollakka
ileoo
-
Jean-Baptiste Kempf
jbk
-
Jean-Paul Saman
jpsaman
-
Johannes Kauffmann
JohannesKauffmann
-
Konstantin Pavlov
thresh
- May 14, 2022
-
-
-
-
Mostly convenient for the audio output since the render date are in the fure (the aout delay).
-
-
To let tracer users send their own timestamp.
-
-
- May 13, 2022
-
-
- May 12, 2022
-
-
This fixes a timebase mismatch between values from tracer entries (NS vs US).
-
-
-
The player code in src/player/player.c is setting player->started to true when starting a media with vlc_player_Start() and setting it to false when calling vlc_player_Stop(). However, vlc_player_Stop() will only queue the input for stopping, so the input is stopped asynchronously with no control from the player after this. In the situation where we enabled :play-and-pause on the input, for instance using vlc_player_SetMediaStoppedAction(), the media will transition itself from PLAYING_S to PAUSE_S from the input thread mainloop, asynchronously from any vlc_player_Stop() call. If vlc_player_Stop() is called soon enough for player->started to be set to false, but late enough so that the input thread still has the time to reach EOF and trigger pause, PAUSE_S will be reported to the player, which will handle it as VLC_PLAYER_STATE_PAUSED in the function vlc_player_input_HandleState, and it will expected the player and the input to be started, which is in this situation, not true. Figure 1: interleaving leading to the assertion | | PLAYER DESTRUCTOR CONTROL/INPUT | | vlc_player_Stop() input_Stop() | | | ------------------> | ----------------> is_stopped = true | | | | player->started = false MainLoop | | ChangeState(PAUSE_S) | | | <---------------------------------------------| | assert(player->started) | | while (!input_Stopped(input)) | | | Input was supposed | to be stopped at this | point. CONTROL/INPUT here represents both the control state, modified by input_Stop() and read at each MainLoop loop, and the input_thread running the MainLoop function. Other solutions have been taken into account to solve the issues: 1/ Provide a separate set of boolean to track the playback state of the player separately from what the user requested (Start/Stop). This is quite overlapping the existing player->global_state variable and it has been confusing to implement and read again. It does restrict the testing surface of the assertion anyway so it doesn't bring much compared to the submitted approach. 2/ Ensure in vlc_player_Stop() that input_Stop() has been called and check whether the input has been stopped before signalling PAUSE_S. By far, it would have been my preferred method to prevent signaling the PAUSE_S state only in the case when it has already been stopped, meaning that the current assertion could have stayed the same, ie. that we could keep the testing surface on the player state too, but it's unfortunately not compatible with the current model. input_Stop require the lock_control in order to modify the state of the input asynchronously, and we'd need input_Stop to wait while we would be checking the input state and sending the PAUSE_S state change event. In addition vlc_player_Stop and the player callback for input state change events are run under player lock. So vlc_player_Stop() would lock the player (from the outside) and then the lock_control, whereas the input thread would lock the lock_control to check the state and then the player lock to report the event, leading to a lock inversion and thus deadlocks. Figure 2: fixed interleaving | | PLAYER CONTROL/INPUT | | | MainLoop | | | | | [lock lock_control] | | from input thread | | ... | | | | vlc_player_Stop() input_Stop() | | ----------------------------------> [Waiting lock_control] | | | | ... | | ChangeState(PAUSE_S) | | | <---------------------------------------------| | assert(player->started) | | | [unlock lock_control] | | from input thread | | ... | | | | ... | | | | | [locked lock_control] | | from player thread | | | | | -------------------------------------> is_stopped = true | player->started = false | | | | while (!input_Stopped(input)) | | | Input is now dead 3/ Reduce the scope of the assertion. The current submission reduce the guarantees on the player state, which where checking that we couldn't call vlc_player_Pause from the player with a stopped player, and only check that the state reported by the input is still correct. It does check that we didn't reach END_S, or VLC_PLAYER_STATE_STOPPING in the player, when pausing though. This is enough to fix the assertion, and not confusing to read in the code. Note that the check on input->started is also removed since input_Stop() will also stop the input asynchronously, leaving the possibility for the input to unroll to EOF regardless of whether input_Stop is called from vlc_player_Stop() or the destructor thread. A test has been written to replicate this bug quite reliably on my machine, but because of the racy nature of this interleaving and the lack of infrastructure to test such interleaving directly in tests, it has been removed from this patch. Fixes #26876
-
-
improves movie info (show name, season and episode number) matching by trying meta data as well as the cleaned up filename and trying out additional patterns
-
Substracting 1 to refcount first, means it goes back to unused state temporarily. It may be picked by another thread as well before calling atomic_fetch_sub(). In the end we don't need the -1,+1 it's already in the "used once" state (2) after the atomic_compare_exchange() call.
-
It returns 0 or -1, not a VLC_xxx error message.
-
It returns 0 or -1, not a VLC_xxx error message.
-
It returns 0 or -1, not a VLC_xxx error message.
-
- May 11, 2022
-
-
-
-
-
-
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.
-
The encoder test is not used anymore, we'll try to open the encoder at the moment we have something to encode and using the output of filters.
-
Pictures are now pushed towards the encoder directly and not queued for encoding.
-
Some decoders have the decoder_QueueVideo called asynchronously wrt. the decode() call, which is allowed and expected by the API. The MediaCodec decoder also has a limited number of input buffers and output buffers when mediacodec-dr is enabled. This creates a strong backpressure linking the output buffers to the input ones, meaning that no input buffer can be decoded unless the already submitted output buffers are processed and released. By running the decode() call followed by the processing of output buffers at the same location, we're linking the output buffers processing to the execution of the decode() call: no processing of outputs can happen until decode() hasn't returned. Except that decode() can be called to saturate the input buffers while the output was already saturated, leading it to a non deterministic deadlock. By processing the buffer synchronously with the decoder_QueueVideo() call, we ensure that the processing of the picture happens regardless of the decode() blocking state. It will typically call the filter and encode callbacks from the thread of the asynchronous module or from the decode callback itself for synchronous decoders, leading to either the same behaviour or difference wrt. depth-first vs breadth-first processing at the decoder level (do we decode all the pictures we can or do we process every new picture before decoding the others). The refactor is made so that the actual processing function is isolated and can be reused in a latter refactor involving a new thread if needed to bring those difference in execution. The previous transcode function is still handling the decoder and encoder drain(), waiting for the decoder to queue all the video frames and then waiting for the encoder to output every packets. It fixes a systematic non-deterministic deadlock happening when having the MediaCodec decoder in direct rendering mode within the transcode pipeline, when implementing #25153.
-
-
When the encoder is opened, it cannot change format anymore, and we cannot change it behind its back.
-
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.
-
Some decoders are pushing format update synchronously during their activation but others have an asynchronous behaviour and may push it before their activation function has finished, or even after the first decode call when the decoder is asynchronously configured and ready. Thus, previously, the decoder format from the decoder was not necessarily known when opening the filters and the encoder. This patchset shifts the initialization of previously mentioned objects to the decoder update callback. In addition, encoders will now need to get the final video context to configure and it cannot open correctly without it, so the encoder test typically makes no sense anymore for video. In this patch, since we create the encoder only when the final format is finally supplied by the decoder, we can directly create the encoder that will be used for transcoding. In addition, since format update would still happen at activation for the synchronous decoders, the format and encoders will already be available, effectively replacing the encoder test afterwards.
-
In future commits, we'll create the filter chain and encoder as soon as the decoder outputs the format it will generate through decoder_UpdateVideoOutput. It means that if the decoder doesn't report any format, we won't have an encoder anymore.
-
If transcode failed, we want to forward the error to the stream output pipeline, so we need to store it for later and to abort the transcoding process.
-
They will be reused differently when refactoring the initialization later at the format update site.
-
The object is needed to forward the elementary streams and data to the sout stream components following the transcode. Note that having the stream object here means that we must ensure we don't call it after the transcode is supposed to be closed, so we must ensure every asynchronous components are drained and destroyed before leaving the close functions. The constraint was already there though, given p_obj actually pointed to the p_stream object too.
-
-
