Home Forums Software ELAN Linux – low player's cursor update rate during play

Linux – low player's cursor update rate during play

This topic contains 10 replies, has 4 voices, and was last updated by  Han 4 months, 2 weeks ago.

Viewing 10 posts - 1 through 10 (of 11 total)
Author Posts
Author Posts
October 11, 2017 at 15:59 #11710

duongthuan

Hi, I’m trying to use ELAN 4.7.3 in Linux and the cursor moves with sensible lag while playing (kinda 4 updates per second), it was not this way for me in Windows Vista. Things I tried:
– switch painting strategy to ‘Paint to a buffer first’ (no effect);
– switch media framework to ‘Java Media Framework’ (got worse);
– ELAN version 4.6.2 (got worse, because of JMF, I guess);
– run with -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel (no effect on the lag).
My primary setup is Gentoo Linux with Oracle JRE 1.8, but I experience the same problem in Debian 7 with IcedTea 1.6.
Any hints/ideas? Or is it just a problem of Java in Linux?

October 12, 2017 at 23:08 #11711

Han

This is almost certainly an artifact of the VLC-based media player. In the installation folder of ELAN there should be a file “Media playback Read Me” with some information about the media players (available within ELAN) on Linux. The, sometimes, poor performance or behavior of the VLC based player is mentioned there.
The lag you mention could be caused by this: apparently with some media (container)formats, the player returns as “current media time” the time stamp of the first sample in the loaded buffer. So, the cursor only jumps to a new position when a new interval has been loaded into the buffer.
Not sure if this is it and I don’t know which container/format works best.

-Han

November 14, 2017 at 23:03 #11748

mattroddy

I have been getting the same behavior on Manjaro Linux using ELAN 5.0. When using VLC (playing .wav) the crosshair updates very infrequently. I tried switching to the Java Media Framework player but a slightly different issue occurs with that: the crosshair doesn’t move for about a second (while the audio is playing) and then it jumps to the proper position and plays normally. In both cases the problems make annotation quite difficult. If there was any way to fix this it would be hugely appreciated.

Matt

November 16, 2017 at 10:12 #11750

Han

Hmm, even with just .wav alone…? Disappointing.
I’ve no immediate solution but I was thinking that maybe a JavaFX based player might perform better on Linux then the other available players. I don’t know, never tried it on Linux, only on MacOS so far. We once made a test version of ELAN 4.9.2 for that, maybe we can create another test version based on 5.0 but then with a JavaFX player for Linux (and Windows) too. I can see if I can find some time in e.g. in the next two weeks.
I’m also looking into the possibility of integrating a pure Java audio player, but that will definitely take longer.

-Han

December 4, 2017 at 10:02 #11778

Han

I’ve now uploaded an ELAN version for Linux which includes a JavaFX media player (.mp4 and .wav) and a JavaSound player (.wav). Available on the download page, this version requires Java 1.8 to be installed.
On the Linux system I have available here, the crosshair updating isn’t very smooth with these players either. But maybe acceptable; the main problem might be the overshoot when playing a selection.
The JavaFX player should support mp4 video but on my test system this failed with an unknown error.

December 12, 2017 at 17:49 #11791

mattroddy

Thanks very much for your work Han. I just tried out the new version. With the JavaFX player it does run a lot smoother. There are still problems (which you probably know about) in that the cursor seems to jump ahead erratically when playback is stopped. But when playback is started again it seems to start from the correct position. The JavaSound player for me is still very jumpy though. Anyway, the JavaFX player does make things more manageable. Thanks again.

Matt

December 14, 2017 at 09:31 #11792

Han

Yes, the JavaFX player is disappointing in several aspects. When I tried to run the same code on Windows I got some errors (this concerned video), so the player isn’t actually cross-platform (yet). You didn’t try video, by any chance?
The JavaSound player is also not very promising, alas. And I forgot to mention that the current implementation only can handle files that are small enough to be loaded into memory completely.

February 21, 2018 at 14:44 #11911

lucien

Hi,
I have similar issues as mentioned using ELAN 5.1 on Debian 9 (Java 8) with both the MP4 and MOV containers, and both JMF and VLC players (‘paint directly’ strategy) :
– low cursor update rate
– the cursor stops after the annotation boundary (and the player actually plays this overshoot)

Just to tell, with the last VLC 3.0, performances are improved, although there are still this overshoot issue. For e.g. the cursor stops between 100ms and 400ms after the annotation boundaries when the annotation has a 1.8 seconds length. It is unfortunately too much when you realize for e.g. that the modal response time between two turns is 200ms according to Levinson (2016). Interestingly, this overshoot eventually change when playing several times the same sample Sometimes it stops at the right position. It seems to be the buffer/time stamp problem you mentioned Han.

Just a floating idea from a coding-ignorant:
Maybe mpv would be a great alternative to vlc but I don’t know if it would be compliant with the instructions that ELAN needs to send to the player and the informations the later should return to the former. Or maybe ffmpeg : to compare with comparable software functions, Aegisub uses ffmpeg and it performs well both playing sound from the spectrogram and playing video from the embedded player. The player always stop at the closest image. However I do not realize how much work it represents.
Thank you for this great software.

February 22, 2018 at 11:28 #11915

Han

Thanks for this information, Lucien. Just to be curious, did you try ELAN 5.0 with JavaFX too?
Integrating other players is unfortunately a lot of work. Even if there is already a “Java-Native bridge” (because that is one of the big challenges). E.g. I believe there is a “Java bridge” for ffmeg, but we might still have to invest considerable time just to discover (maybe) that the performance is poor (similar to VLC).
For another platform we are looking into the possibility of decoding video natively and doing the rendering in Java/ELAN. I don’t know what to expect when it comes to performance (I believe JVLC does the same for one of the available players).

March 6, 2018 at 13:55 #12071

lucien

Thank you Han for your response. I tried ELAN 5.0 with JavaFX but unfortunately it does not work. I do not know why. It does not load the whole project (it keeps initializing) if JavaFX has been selected.
Debian 9, jdk & jre 1.8-58
swing.properties : added swing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel
accessibility.properties :
commented out assistive_technologies=org.GNOME.Accessibility.AtkWrapper

However I made some comparison tests between VLC and JMF and the behaviour is pretty similar (see below). Each time selected the player and then restarted ELAN.
File :
Container : MOV
Size : 228 Mo
Length : 15:22
Format : h264 (video) & AAC (audio)
Resolution : 1280*720
Framerate : 25.025

ELAN 5.1 VLC
Selection : 6:50.990 – 6:52.290 (1,3 seconds total)
Overshoot (10 tries) :
71 (6:52.361)
71 (6:52.361)
321 (6:52.611)
71 (6:52.361)
321 (6:52.611)
321 (6:52.611)
71 (6:52.361)
71 (6:52.361)
321 (6:52.611)
71 (6:52.361)
Next frames after 6:52.361 if I click the “next frame” button : 402 442 482 522 562 602

ELAN 5.1 JMF
Selection : 6:50.990 – 6:52.290 (1,3 seconds total)
Overshoot (10 tries) :
321 (6:52.611)
71 (6:52.361)
71 (6:52.361)
321 (6:52.611)
71 (6:52.361)
71 (6:52.361)
321 (6:52.611)
321 (6:52.611)
71 (6:52.361)
71 (6:52.361)
Next frames after 6:52.361 if I click the “next frame” button : 402 442 482 522 562 602

As you can see it behaves the same way whether it is JMF or VLC.

Viewing 10 posts - 1 through 10 (of 11 total)

You must be logged in to reply to this topic.