A couple weeks ago I had been working on something I thought would be pretty cool. The idea was a video player that could stream videos from external servers. The way I had planned on accomplishing this was via JavaFX and a signed applet. Needless to say (if you read the title) it didn’t really work out. I had managed to stream traditional FLV video files… but a large portion of video sites – at least the more popular ones that I’ve tried – make use of H.264 video files. JavaFX supposedly supports all media that is supported by Windows media player [1]

Problem 1: I couldn’t stream H.264 files.
Fine print: I COULD play a local H.264 file

I tried working around the problem of not being able to stream H264 files by downloading portions of the video – luckily the bleeding edge version of JavaFX (1.2) allowed the output of httprequests to be redirected to file – and playing those portions in sequence.

Problem 2: javafx.io.http.HttpRequest locks file while downloading… which makes using a media file impossible until the download is complete.
Fine Print: I imagine that HttpRequest wasn’t meant to download media files…  but it would be incredibly useful to download and play a media file.

I then tried to build a library in native java that would release the file lock and allow JavaFX to load the media. This worked for the first bit that had been downloaded (and flushed to a file), but then I had to update file. I deleted the media object that made use of the local file and was hoping that it would release the file lock it put on the file while reading it.

Problem 3: It didn’t release the file lock… and there IS NOW WAY to force the release of system resources held by JavaFX.

There is no fine print for this… this is completely inexcusable.  It makes it impossible to update any resource (I am assuming this problem exists beyond video files I tried to play.) Whoever designed the language and omitted an interface – or a means – to delete a language native object, had a very narrow minded view on how the language should be used. I could’ve wrote each bit to a new file and then load the new file, but I would have to keep track of FLV offsets and correctly build a new FLV header for each new file and even then it will end up looking like a series of clips. At this point I had given up and moved onto a new idea that caught my interest. These are some more problems I’ve encountered that relate to JavaFX.

Problem 4: JavaFX had a problem handling  fileoffsets meta tag in the FLV header for some videos for me. To play videos I had to filter them out.  (Yes, it meant correctly rebuilding an FLV stream… yes… I did it =\)

Problem 5: The JavaFX forums were inactive. Not one person had replied to any thread I had started.

Problem 6: No one wants to wait 20 seconds for the JVM to fire-up just to play a quick game or music video.

Problem 7: Video support doesn’t come out of the box. So if you want your users to be able to watch videos… they will not only have to download Java and JavaFX (both are bundled), but also a third party codec pack.

In retrospect, I put a lot of work in hacking away at the problem. I don’t think I failed… I got it to work… it’s just that the effort  I – and a user – would have to go through makes using JavaFX impractical. At least it was fun learning about FLVs [2].

[1] http://www.javafx.com/docs/articles/media/format.jsp
[2] http://www.adobe.com/devnet/flv/pdf/video_file_format_spec_v10.pdf