For those who would like to test a Java 1.8 based version of ELAN for MacOS, it is now available for download on the usual download page. Please read the release notes first!
-Han
Thanks for making this available for testing.
Spaces in file paths stop the media files loading. From the log file:
WARNING: Could not create a valid URL for the media: Illegal character in path at index 29: file:///Users/tomh/Dropbox/Ku Waru Data/session alignment/T sessions_otc reviewed/20140418Philip/T20140418_vs_small.m4v
Moving the files to a location without spaces meant that it worked. A minor bug, but one that might slow down testers. Easy to work around for now.
I assume from your notes that you’re aware that the playback point cursor jumps forward by about 200 milliseconds after playing a selection. I found that it did it separately at times for the waveform cursor and the annotation cursor, and sometimes in unison. It appears to only be in rendering too, as playback resumes from the right position.
Both methods of file conversion result in much larger files than the original source file. I probably shouldn’t be testing with a 40 minute file to start with (!), but it might be good to warn testers (or constrain the bitrate/frame size etc in the configurations you suggest).
I cannot edit the media offset in the linked files dialog box.
I usually keep my audio and video streams in separate files because in the past syncing issues seem to be fewer this way. My impression initial impression is that the audio-included file works better. But playback is affected for both in specific scenarios. I’m still testing though.
A problem across all ELAN versions is multiple audio streams at different sampling rates (one drifts from the other). This is still a problem in this version (but I’m guessing is not fixable). Initially I had problems in playback that were fixed by using the same audio sample rate for the wav and video files. Throwing an error for multiple audio sources at different sampling rates might b a good feature to add though.
Switching to the newer Java resolves two bugs for me. A longstanding one related to Apple’s implementation of Java:
https://tla.mpi.nl/topic/os-x-elan-bug-popups-remain-upon-loosing-focus/
And also a rendering issue that I get when scrolling (screenshot from the non-beta version):
https://www.dropbox.com/s/pik7grfd7cs4yuk/Screenshot%202016-02-04%2011.50.20.png?dl=0
Otherwise, I’m still testing.
It’s to be expected that different sampling rates will create issues. With regards to the file sizes of the I-frame mpg4 files, in Handbrake you can alter the CRF (which is set to 18) by dragging the slider. CRF 22 would yield a somewhat smaller file, with no real visual loss.
If you use ffmpeg, you can set the CRF integer from 12 to 18, or 22. The higher the number, the more compressed the output file will be.
Thanks Tom. The spaces in the file path problem should be easy to fix. I’ll check the media offset issue in the linked files dialog (nothing changed in that area, as far as I know, but maybe setting the offset for this player doesn’t always work well).
Is the drift in multiple audio streams at different sampling rates (only) noticeable if you “mix” them? A warning in case of audio sources with different sampling rates might be possible.
Yes, we noticed the 200 ms (or more, probably depending on number of key frames) jumps too. Combined with the frame stepping issues this led us to the suggested “workaround” of using key frames only videos. Recordings of 40 minutes should be ok, even for testing, but files sizes can become problematic this way.
It seems the JavaFX media player was not developed for this kind of work (playing selections, frame forward/backward etc.). It seemed to make sense to at least try whether it would be usable in the ELAN context, but the experiences during development and first testing don’t look too promising.
The drift issue only occurs for separate audio streams mixed on output. I haven’t tested if it affects a muted audio source in a muxed video file, as I mostly keep audio and video streams in separate files. And it is mainly noticeable if the file is longer (e.g. > 30 minutes).
Would having annotations not aligned to key frames also be a problem?
I was going to comment more after further testing, but yes, I noticed that jumping around also wasn’t great. It seemed to make a difference whether I was manually selecting a region, or highlighting an annotation as to how accurate the jump would be too. But I haven’t properly tested this yet.
It seems to me like you face a real dilemma. Balancing a (presumably more) unified code base against decent media support seems quite tricky for a Java app. I wouldn’t say that the actual media playback in the JavaFX version was all that bad (ignoring the quirks). But if working around these quirks means overly specific video formats, it does indeed not look all that promising. That said, I can actually see some sense in constraining users to a set of “supported” formats and containers, as this seem to be the number one support issue for you (JavaFX or otherwise).
This is just an unprofessional stab in the dark, but is it possible to embed a webkit instance in Java(FX). It would be an odd way to get video support, but it seems to me that it is a framework that cares about cross-platform media support. It might, by the by, be a good way of supporting server based media as well?
It would be great to have built-in, cross-platform media support, even if it was only for one or two media formats. So, if JavaFX’s support for any mp4 with a reasonable key frame rate would be really good, that would already be a strong basis to rely on. And there are indeed advantages to promoting one or two formats.
My first tests on Windows seem to indicate similar or the same problems as on Mac OS. So, I don’t know.
JavaFX includes a kind of webkit but I assume media support in that kit will just be provided by the JavaFX media player. I don’t assume it is possible to embed just any webkit.
Supporting server based media in ELAN might mainly be a matter of removing checks for the file:/ protocol here and there in the code; I guess most native media frameworks we use, support media over http (but I don’t know for sure).
It would surprise me if annotations not aligned to key frames would be more problematic than manually selecting a region or jumping to a specific media time.