Alexandre Janniaux authored 3 years ago and Jean-Baptiste Kempf committed 3 years ago

In the case count=0, the loop is not processed and the picture array's
single element is not initialized, leading to a warning. We don't use
count=0 anyway so remove the case.

Fix the warnings (<unknown> is the VLA):

../../src/misc/picture_pool.c: In function ‘picture_pool_NewFromFormat’:
../../src/misc/picture_pool.c:140:28: warning: ‘<unknown>’ may be used uninitialized [-Wmaybe-uninitialized]
  140 |     picture_pool_t *pool = picture_pool_New(count, picture);
      |                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../src/misc/picture_pool.c:102:17: note: by argument 2 of type ‘picture_t * const*’ to ‘picture_pool_New’ declared here
  102 | picture_pool_t *picture_pool_New(unsigned count, picture_t *const *tab)
      |                 ^~~~~~~~~~~~~~~~

Romain Vimont authored 3 years ago and Jean-Baptiste Kempf committed 3 years ago

This will ensure that the callback has the expected signature.

Alexandre Janniaux authored 3 years ago and Hugo Beauzée-Luyssen committed 3 years ago

emnm is a wrapper of llvm-nm and is actually located in the SDK binaries
path added in the PATH when the SDK environment is sourced
(/etc/profile.d/emscripten.sh) or when adding the compiler to the PATH
by sourcing emsdk_env.sh like in the CI configuration.

This avoid defining the EMSDK variable when emscripten is installed on
the system.

Alexandre Janniaux authored 3 years ago and Hugo Beauzée-Luyssen committed 3 years ago

Those defines are always needed and should be defined by configure.ac so
as to also be present when using ./configure directly.

Steve Lhomme authored 3 years ago and Hugo Beauzée-Luyssen committed 3 years ago

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

Johannes Kauffmann authored 3 years ago and Hugo Beauzée-Luyssen committed 3 years ago

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 LibVLCSharp#374.

Backport from upstream mfx_dispatch, fixed since
https://github.com/lu-zero/mfx_dispatch/commit/7e4d221c36c630c1250b23a5dfa15657bc04c10c.

Pierre Lamot authored 4 years ago and Jean-Baptiste Kempf committed 3 years ago

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

Alexandre Janniaux authored 3 years ago and Steve Lhomme committed 3 years ago

...after checking GPU affinity.

Alexandre Janniaux authored 4 years ago and Steve Lhomme committed 3 years ago

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.

Alexandre Janniaux authored 3 years ago and Steve Lhomme committed 3 years ago

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.

Steve Lhomme authored 3 years ago and Hugo Beauzée-Luyssen committed 3 years ago

Reverts 7f51eb6c and
382ee822.

Steve Lhomme authored 3 years ago and Hugo Beauzée-Luyssen committed 3 years ago

We don't need an expensive lldiv() in the normal case.
In this variant, the read value is simplify divided by 10.

Steve Lhomme authored 3 years ago and Hugo Beauzée-Luyssen committed 3 years ago

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.

Steve Lhomme authored 3 years ago and Hugo Beauzée-Luyssen committed 3 years ago

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.

Steve Lhomme authored 3 years ago and Hugo Beauzée-Luyssen committed 3 years ago

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.

Steve Lhomme authored 3 years ago and Hugo Beauzée-Luyssen committed 3 years ago

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

Benjamin Arnaud authored 3 years ago and Hugo Beauzée-Luyssen committed 3 years ago

fix #26161

Zhao Zhili authored 3 years ago and Hugo Beauzée-Luyssen committed 3 years ago

Fix #26191

Zhao Zhili authored 3 years ago and Hugo Beauzée-Luyssen committed 3 years ago

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.

Romain Vimont authored 3 years ago and Hugo Beauzée-Luyssen committed 3 years ago

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.

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

This should help against transient errors, and parsing of the javascript
URL isn't the part that's most likely to break.