compose-jb

Tree: 4a65b1a1d8

hehua2008 568fc1b837 Fix replay issue in DesktopVideoPlayer.kt (#4048 ) See https://github.com/caprica/vlcj/tree/vlcj-4.x#threading-model # Threading Model This section is very important. With vlcj-4, every native event coming from LibVLC is processed on the native callback thread. This should give some small performance gains when compared with vlcj-3. The critical issue is that it is generally not permitted to call back into LibVLC from the event callback thread. Doing so may cause subtle failures or outright hard JVM crashes. A prime example of the sort of trap waiting for you is the very common case of handling a media player "finished" event so that you can then play the next item in a play-list: ```java mediaPlayer.events().addMediaPlayerEventListener(new MediaPlayerEventAdapter() { @Override public void finished(MediaPlayer mediaPlayer) { mediaPlayer.media().play(nextMrl); // <-- This is VERY BAD INDEED } }); ``` In this example, the finished method is being invoked on a native callback thread owned by LibVLC. The implementation of this method is calling back into LibVLC when it invokes play. This is very likely to cause a JVM crash and kill your application. In cases such as this, you should make use of an asynchronous task-executor queue conveniently provided by the MediaPlayer object passed to the listener method: ```java mediaPlayer.events().addMediaPlayerEventListener(new MediaPlayerEventAdapter() { @Override public void finished(final MediaPlayer mediaPlayer) { mediaPlayer.submit(new Runnable() { @Override public void run() { mediaPlayer.media().play(nextMrl); } }); } }); ```	9 months ago
..
src	Fix replay issue in DesktopVideoPlayer.kt (#4048 )	9 months ago
build.gradle.kts	Move cef and videoplayer to experimental folder (#1277 )	3 years ago

hehua2008 568fc1b837

Fix replay issue in DesktopVideoPlayer.kt (#4048 )

See https://github.com/caprica/vlcj/tree/vlcj-4.x#threading-model

# Threading Model

This section is very important.

With vlcj-4, every native event coming from LibVLC is processed on the
native callback thread. This should give some small performance gains
when compared with vlcj-3.

The critical issue is that it is generally not permitted to call back
into LibVLC from the event callback thread. Doing so may cause subtle
failures or outright hard JVM crashes.

A prime example of the sort of trap waiting for you is the very common
case of handling a media player "finished" event so that you can then
play the next item in a play-list:

```java
mediaPlayer.events().addMediaPlayerEventListener(new MediaPlayerEventAdapter() {
    @Override
    public void finished(MediaPlayer mediaPlayer) {
        mediaPlayer.media().play(nextMrl); // <-- This is VERY BAD INDEED
    }
});
```
In this example, the finished method is being invoked on a native
callback thread owned by LibVLC. The implementation of this method is
calling back into LibVLC when it invokes play. This is very likely to
cause a JVM crash and kill your application.

In cases such as this, you should make use of an asynchronous
task-executor queue conveniently provided by the MediaPlayer object
passed to the listener method:

```java
mediaPlayer.events().addMediaPlayerEventListener(new MediaPlayerEventAdapter() {
    @Override
    public void finished(final MediaPlayer mediaPlayer) {
        mediaPlayer.submit(new Runnable() {
            @Override
            public void run() {
                mediaPlayer.media().play(nextMrl);
            }
        });
    }
});
```

9 months ago

src

Fix replay issue in DesktopVideoPlayer.kt (#4048 )

9 months ago

build.gradle.kts

Move cef and videoplayer to experimental folder (#1277 )

3 years ago