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_867220ea9cbb40f38051abad33491375
-
**** project_435_bot
-
Ilkka Ollakka
ileoo
-
Jean-Baptiste Kempf
jbk
-
Jean-Paul Saman
jpsaman
-
Johannes Kauffmann
JohannesKauffmann
-
Konstantin Pavlov
thresh
- Aug 08, 2022
-
-
Denis Charmet authored -
Denis Charmet authored
-
Denis Charmet authored
-
Denis Charmet authored
-
Denis Charmet authored
-
If vlc_clock_Wait() has been interrupted to release the display_lock quickly, then the next rendering must be performed ASAP, without waiting for any deadline.
-
On resize, the UI thread waits for the end of any current rendering at the old size before returning. To limit its waiting, interrupt the wait between prepare() and display() on the vout thread to complete the rendering as soon as possible. As a consequence, the display() call might be performed early (before its expected PTS). Refs !324
-
Denis Charmet authored
-
Denis Charmet authored
-
Denis Charmet authored
-
-
Signed-off-by:Claudio Cambra <claudio.cambra@gmail.com>
-
Signed-off-by:
-
- Aug 07, 2022
-
-
In exec_DataSharedMem() memory is allocated via the call to picture_New(). This memory is correctly freed via picture_Release() if an error occurs, but if no error occurs and the function proceeds normally, the memory is never freed. When the DataSharedMem routine is called repeatedly (e.g., to update a picture continuously), this leak accumulates very quickly.
-
We need to update the ICC profile either if the window moves to a new display, or if the root window atom associated with a given display is updated. To this end, we need to start tracking property changes on the root window, as well as updating this atom every time the window moves to a new display. Unfortunately, this code again requires one memcpy more than I'd like to have there, as a result of xcb not letting me fetch properties into my own buffers. If we determine this to be a performance issue later on, the straightforward fix would be to make vlc_icc_profile_t refcounted with a custom free callback.
-
Needed for RandR-related code in future commit.
-
This is non-functional on its own, but introduces necessary display tracking information that will be useful in the following commit(s), like figuring out which display's ICC profile to query for the VLC window.
-
Pretty straightforward. Rather than wasting cycles computing a checksum each frame, just update the signature once per received ICC change control event.
-
The window backend triggers a callback of the vout, and the vout forwards this to the display using another callback. There are several unfortunate layers of glue and indirections in the callchain. In particular, we need to persist these ICC profile objects in some layer, because of init order between windowing system and the window / vout display module itself. I've chosen to add them to `vout_display_cfg_t` because it fits well with the other "dynamic window state" properties in there. This approach also allows capable vouts to read directly from the allocated ICC profile memory, minimizing the number of memcpys.
-
Emscripten currently does not support picking a file from the DOM with the element, and reading it from a webassembly application. This access plugin will be able to receive a File object handle in the input thread, and read into buffers in linear memory with the file content while keeping track of the offset. A basic setup could look like : ``` <input type="file" id="fpicker_btn">Select File</input> <script> let instance = _libvlc_new(); let media_player_ptr = _libvlc_media_player_new(instance); /* Module is the emscripten runtime object, it has the vlc_access_file array as a property */ let inputElement = document.getElementById("fpicker_btn"); function handleFile() { var name = this.files.item(0).name; console.log("opened file: ", name); // id starts at 1 let id = 1; let path_ptr = Module.allocateUTF8("emjsfile://" + id); let media_ptr = _libvlc_media_new_location(path_ptr); Module._free(path_ptr); _libvlc_media_player_set_media(media_player_ptr, media_ptr); Module['vlc_access_file'][id] = this.files.item(0); } inputElement.addEventListener("change", handleFile, false); _libvlc_media_player_play(media_player_ptr); </script> ```
-
- Aug 06, 2022
-
-
-
It should be handled better in the conversion matrices.
-
The "black level" should not be adjusted in that case. The conversion matrix is already converting [0,255] to [0,255] the "black levels" are the same. We only need to do the achromacy conversion (128 shift of U/V). We don't need to manual range adjust in the shader anymore as those shift values are also taken in account in our color conversion matrices and in a cleaner way (differentiation between Y and UV ranges).
-
-
This should never happen as the demuxer/packetizer/decoder/core should have tried to get the most accurate value. No need to set the same value twice.
-
The shifts in values are slightly different than in 8 bits. The proper values should be used to be more accurate.
-
The Kr and Kb values are defined in the 601/709/2020 standards. The ranges for Y and U/V values in "studio" mode as well. The BT2020 matrix is slightly different should give more accurate values.
-
Signed-off-by: -
Signed-off-by: -
Signed-off-by: -
-
-
-
-
-
input_SendEventTimes() used by the es_out was already using double.
-
- Aug 05, 2022
-
-
Signed-off-by: -
-
-
-
