- 22 Oct, 2021 14 commits
-
-
This should have a better precision (<1us), and we don't have to beg the system to give us a 5 ms precision. We also don't need extra LoadLibray. And we use the same code between regular/uwp builds. Some background on the latency and performance (we are in the Win7 case): https://docs.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps
-
-
intel_gfx_api-x86.dll exports InitialiseMediaSession and DisposeMediaSession, but libqsv_plugin.dll imports InitialiseMediaSession@12 and DisposeMediaSession@4. The name decorations are caused by the APIENTRY modifier, resulting in libqsv_plugin.dll not being able to load intel_gfx_api-x86.dll. It fails with an Entry Point Not Found error. On debug mode UWP, this will crash the CoreCLR. Should fix videolan/LibVLCSharp#374. Backport from upstream mfx_dispatch, fixed since https://github.com/lu-zero/mfx_dispatch/commit/7e4d221c36c630c1250b23a5dfa15657bc04c10c.
-
-
-
-
-
-
The composition works as follow: * Both the interface and the video are rendered in an offscreen window (using X11 composite extension) * We register to damage event (x11 damage extension) to get notified when the content of the offscreen video window change. When we receive a damage event we ask the rendering part of the composition to refresh * The interface is rendered in the offscreen surface using a RenderControl, when the interface do render, the composition is asked to refresh * A dedicated thread is spawned to do the rendering, upon a refresh event it will take the pictures from the offscreen surface and blend them into the actual window using X11 render extension. Using a separated thread from Qt ensure that the rendering of the video will not be stalled if Qt thread is busy. * The damage events are listened on a separate X11 connection and on a separate thread than Qt main thread (here the rendering thread). This allows to receive theses events independently from Qt (in case the Qt thread is stalled). Note that it is not possible to peek in qt X11 event queue from a non gui thread as the QX11Info::peekEventQueue is no longer thread safe since 5.12. fixes: #25627, #22155
-
-
-
...after checking GPU affinity.
-
The context and original HDC is from the decoder thread. Close() is called from the vout_thread when the vout is being stopped. This leads to one of the following error when stopping the media player: - error 2004: The requested transformation operation is not supported. - error 6: The handle is invalid Those errors means that either the hDC is still in use in another thread or that the hDC is not valid anymore. Since this was happening on Close(), there was no way to make it fail gracefully. Getting a new DC when making the context current, thus in the closing thread too, fix the error by ensuring thread-safety with those objects.
-
When MakeCurrent fails, there was not much information. Since it can fails in location where we want to release OpenGL resources, it was hard to track it down to a wgl failure. In case of failure, this patch details the last error message available.
-
- 21 Oct, 2021 19 commits
-
-
-
-
-
Hugo Beauzée-Luyssen authored -
We don't need an expensive lldiv() in the normal case. In this variant, the read value is simplify divided by 10.
-
We don't need an expensive vlc_tick_from_frac() in the normal case. In this variant, the read value is simplify divided by 10.
-
-
It was necessary for the npapi build (in release/nightly builds) but it should not be needed anymore since videolan/npapi-vlc@4c7155f3 Many Docker images already provide their own value. Only the LLVM images don't but they will soon.
-
They have the cleaner certificates in case we need them. They also include their own WINE_SDK_PATH so we don't need to set it.
-
We can't really expect the process using libvlc to always exit properly. We don't even do in VLC. So we should not assert when it does (harmless in release builds). This reverts commit 5f1dd4ca. Fixes #26205
-
-
-
fix #26161
-
Fix #26191
-
-
-
-
A codec which doesn't set AV_CODEC_CAP_DELAY but has the capability of multi-threads decoding still needs to be drained by an empty packet. According to the document, it's safe to pass NULL data to libavcodec decode function, libavcodec will not pass it along to the codec unless AV_CODEC_CAP_DELAY is set.
-
This filter crops the input pictures by adjusting the format (offsets and size), without any copy (contrary to croppadd). This is especially useful to receive pictures with arbitrary visible area (smaller than the full size), to debug vouts or filters.
-
- 20 Oct, 2021 7 commits
-
-
Pierre Ynard authored
User agents are apparently now expected to do this; failure to do so results in the video file data transfer getting throttled down to rates such as 80 kB/s, 60 kB/s or 40 kB/s, below playback rate, and usually resulting in a video that hangs upon loading or every few seconds, and is impossible to play. This behavior seems to have first appeared in June, but been fully rolled out only last week. Just like with URL signatures, we interoperate with YouTube by fulfilling what's apparently expected from us, using the same approach as so far: we parse the descrambling rules from the javascript code, and apply them. Fixes #26174
-
Pierre Ynard authored
This should help against transient errors, and parsing of the javascript URL isn't the part that's most likely to break.
-
Pierre Ynard authored
We'll be descrambling the "n" parameter in addition to the URL signature using this same javascript web asset, so we want to be able to share and reuse it.
-
Pierre Ynard authored
Use a more specific name as this isn't the only parameter anymore that we'll be descrambling by parsing and emulating javascript.
-
Pierre Ynard authored
-
Pierre Ynard authored
Javascript variables can contain other, special characters, also %a depends on the locale.
-
Pierre Ynard authored
After tightening access restrictions to it, the get_video_info YouTube API was completely retired around July 2021, with an HTTP 410 Gone code. All this fallback achieves anymore is poor UX.
-
