将其他视频编解码器/ DVD支持添加到JavaFX 2.2

Question

更新：

由于JFX的媒体方面是开源的，因此我本人对此进行了调查，确实可以，但是需要更改和重建JFX源（包括Java和C部分）。
此处
为任何想要了解此过程的人介绍了该过程。-我在该示例中添加了MKV支持，但对于其他插件，它应该非常相似。

因此，该问题的其余部分主要是历史性的，但我在这里留作参考。

到目前为止，我一直在使用VLCJ在应用程序中播放视频。它可以工作，但是如果可能的话，我想看看我是否可以通过迁移到JavaFX并为自己节省多个VM的麻烦来实现对通用编解码器的类似支持，例如VLCJ需要可靠地播放多个视频。我不会在这里讨论，但是如果您对详细信息感兴趣，请参阅我对这个问题的回答。还存在跨平台兼容性的问题，它可以在Mac和Linux上正常运行，但是我还没有弄清楚如何使其在Mac上显示（我相信有一些安全措施可以阻止一个进程访问另一个本地的进程组件，但这再次超出了此问题的范围。）

归结为这样一个事实，即它在工作时需要大量维护，并且在使用多个VM时麻烦，并且如果有另一个更简单的解决方案，则可以稳定地桥接它们。VLC确实具有传奇般的支持水平，可以播放几乎所有内容，这就是为什么我迄今为止不喜欢它，我很想知道我是否可以在JavaFX中获得类似的结果-
至少可以提供以跨平台方式执行此操作的方法。

研究

JavaFX 2.0支持视频-
太棒了！但目前官方线路是它支持“包含VP6视频和MP3音频的FLV”。有没有一种方法可以扩展它以增加对更多编解码器的支持？我没有想要支持的硬编解码器，更多情况是尽可能多的，因此我正在寻找一种可扩展的方法来解决上述问题。

我想知道它是否会播放本地安装在计算机上的编解码器的视频，并且它只是不会自己宣传（因为功能显然是与机器相关的，而不是跨平台的。）但是没有骰子，我尝试了很多常见的格式，它确实拒绝播放其声明以外的任何内容。

从JavaFX
1.3的角度来看，它还支持其他依赖于平台的编解码器，具体取决于安装位置。有没有办法用JavaFX
2来获得这种行为？还是完全计划用于后续版本？我还没有在路线图上找到任何信息，也没有得到Oracle的任何评论。

我唯一可以从广泛的搜索找到的是这里这意味着它有可能，但没有人似乎知道怎么办。我也想知道它是否基于GStreamer，为什么默认情况下也不包含GStreamer支持的所有格式？

就用JavaFX播放DVD而言，我绝对是无能为力，所以我认为目前这只是一事无成。但是，如果有人有任何想法或信息，我将不知所措。

其他方法

我半想知道的一种方法可能是，像这里描述的那样，将JMC
jar从旧的JavaFX中淘汰出来，并试图使其与JavaFX 2一起工作。我不认为有人对这种方法或类似方法有任何运气吗？

万事大吉，如果任何人都拥有开箱即用的支持/何时支持其他编解码器的任何信息或链接，那么我也想听听。或者，如果有人对Oracle的某人有任何联系方式，我也想问一问，不胜感激！我一直渴望在Java中提供体面的视频支持，而且我想这归结为试图弄清楚JavaFX是解决问题的办法，还是另一半尝试，永远不会比它发挥更多的作用现在呢！我希望不是后者，但是我还没有看到太多可以证明这种情况的信息。

Answer 1

现在，我已经成功地将MKV支持编译到JavaFX中，并且在本机层上确实需要一些但不是很大的努力。
请参阅此处的相关讨论，并查看以修补程序/ JIRA票证提交的结果。

我写的过程中更加全面的指南 在这里可能会感兴趣的其他任何人希望沿着这条路走下去。

接下来是我的简短调查，然后我才认真考虑将其他媒体支持纳入其中，尽管在此我将留作参考。

既然JFX8已经发布并且是完全开源的，我已经花了一些时间来研究如何完成此工作以及是否可以在不修补JFX源代码的情况下完成。不幸的是，对后一点的答案几乎是肯定的，至少在没有可怕的字节码操纵黑客的情况下。稍后我可能会更实际地对此进行研究，但是我将记录到目前为止我已经从可用资源中得出的结论。

魔术始于Media构造函数，最终是MediaException从那里弹出（MEDIA_UNSUPPORTED如果您尝试播放不受支持的格式，则带有标志）。从那里开始，它创建Locator，其构造函数确保URL受支持。init()然后在一个单独的线程中调用该方法，该线程对URL字符串执行完整性检查，读取文件，然后继续尝试确定格式是什么。

因此，该方法的这一部分的相关代码为：

if (scheme.equals("file") || scheme.equals("jar")) {
    InputStream stream = getInputStream(uri);
    stream.close();
    isConnected = true;
    contentType = MediaUtils.filenameToContentType(uriString); // We need to provide at least something
}

if (isConnected) {
    // Check whether content may be played.
    // For WAV use file signature, since it can detect audio format
    // and we can fail sooner, then doing it at runtime.
    // This is important for AudioClip.
    if (MediaUtils.CONTENT_TYPE_WAV.equals(contentType)) {
        contentType = getContentTypeFromFileSignature(uri);
        if (!MediaManager.canPlayContentType(contentType)) {
            isMediaSupported = false;
        }
    } else {
        if (contentType == null || !MediaManager.canPlayContentType(contentType)) {
            // Try content based on file name.
            contentType = MediaUtils.filenameToContentType(uriString);

            if (Locator.DEFAULT_CONTENT_TYPE.equals(contentType)) {
                // Try content based on file signature.
                contentType = getContentTypeFromFileSignature(uri);
            }

            if (!MediaManager.canPlayContentType(contentType)) {
                isMediaSupported = false;
            }
        }
    }

    // Break as connection has been made and media type checked.
    break;
}

从中我们可以看到，首次尝试根据文件名获取文件内容是“愚蠢的”（这是正确的MediaUtils.filenameToContentType()。）然后，在某些特殊情况下，将检查不同类型的wav文件，但是如果失败，我们将失败回到查看实际文件签名的巧妙检查。这些检查都在MediaUtils中。后面的检查要广泛得多，它检查文件的前几个字节，以查看它是否可以以此方式确定格式。如果不能，那么它将解救并抛出异常，然后该异常作为我们的可怕MEDIA_UNSUPPORTED标志弹出。

如果正确识别了类型，则还需要克服另一个障碍-
当前平台必须支持它。某些平台根据环境动态加载，但是GSTPlatform始终存在，因此我们需要在此处放置任何其他（通用）格式。这是相对简单的，CONTENT_TYPES存在一个仅包含受支持格式的数组的数组。

不幸的是，目前克隆JavaFX存储库似乎对我来说是失败的，否则我会尝试将其中的一部分付诸实践。但是代替上述内容，添加对其他格式的支持实际上需要发生什么呢？实际上，这似乎并不困难。

1. 在MediaUtils中，需要向该filenameToContentType()方法添加支持以处理新的文件扩展名。这是微不足道的。

2. 在同一类中，需要向该fileSignatureToContentType()方法添加支持以根据其签名确定文件类型。这有点复杂，但还算不错。这甚至可能是可选的，因为如果无法从文件扩展名中正确（或完全）识别格式，则当前代码似乎仅将其用作备用。可以在此处找到不同格式的文件签名的完整列表，这对完成此任务很有帮助。

3. 在GSTPlatform中，需要将新的内容类型添加到受支持的内容类型列表中。

在Java方面，这似乎是使它接受内容类型并至少尝试将其传递给本机Gstreamer层所需的全部操作。

但是，我不是GStreamer的专家，因此尽管我知道JavaFX当前拒绝了它可以处理和播放的更多格式，但是我不确定它们究竟 如何
删除了此功能。他们肯定已经在上面的Java层中完成了此操作，但他们也可能已经在本地GStreamer级别上完成了–目前我不确定。

我认为他们已经对GStreamer for JFX8进行了一些更改-
但目前它们尚未在相关的项目页面上列出，因此很难确切地了解他们对该版本所做的更改。

下一步将是获取JFX8源，使用上述提议的更改构建新的内容类型，然后查看在本机级别发生了什么错误（如果有），然后从那里获取错误。