J'ai maintenant réussi à compiler le support MKV dans JavaFX avec succès, et cela prend un peu, mais pas beaucoup d'efforts sur la couche native également. Voir icipour la discussion qui l'entoure, et ici pour le résultat soumis en tant que ticket patch / JIRA.

J'ai écrit un guide beaucoup plus complet sur le processus ici qui peut intéresser quiconque cherche à suivre cette voie.

Ce qui suit est-ce que ma brève enquête avant que je ne regarde sérieusement la compilation d'autres supports médiatiques, bien que je le laisse ici pour référence.

Maintenant que JFX8 a été publié et est complètement open source, j'ai passé un peu de temps à regarder comment cela pourrait être fait, et si cela pourrait être fait sans patcher la source JFX. Malheureusement, la réponse à ce dernier point est un non presque définitif, du moins pas sans hacks horribles de manipulation de bytecode. Je peux examiner cela plus pratiquement à une date ultérieure, mais je vais documenter ce que j'ai travaillé jusqu'à présent à partir de la source disponible.

La magie commence à partir du Media constructor, qui est finalement d'où sort le MediaException (avec l'indicateur MEDIA_UNSUPPORTED si vous essayez de lire un format non pris en charge.) À partir de là, il crée le Locator, dont le constructeur garantit que l'URL est prise en charge. Sa méthode init() est ensuite appelée dans un thread séparé, qui effectue une vérification de la santé mentale sur la chaîne d'URL, lit le fichier, puis procède à essayer de déterminer quel est le format.

Le code pour cette partie de la méthode est donc:

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;
}

De cela, nous pouvons voir une première tentative "stupide" est faite pour récupérer le contenu du fichier en fonction de son nom (c'est ce que fait MediaUtils.filenameToContentType().) Il y a alors quelques cas spéciaux pour vérifier différents types de fichiers wav, mais si cela échoue, nous nous rabattons sur une vérification plus intelligente qui regarde la signature réelle du fichier. Ces deux contrôles sont en MediaUtils . Ce dernier contrôle est beaucoup plus vaste, et regarde les premiers octets du fichier pour voir s'il peut travailler sur un format moyen. S'il ne peut pas, alors il renfloue et jette l'exception qui apparaît alors comme notre drapeau redouté MEDIA_UNSUPPORTED.

Si le type est correctement identifié, il y a encore un autre obstacle à franchir - il doit être pris en charge par la plate-forme actuelle. Certaines plates-formes sont chargées dynamiquement en fonction de l'environnement, cependant GSTPlatform existe toujours, nous aurions donc besoin de mettre tous les formats supplémentaires (universels) ici. C'est relativement simple, un tableau CONTENT_TYPES existe qui contient juste le tableau des formats pris en charge.

Malheureusement, le clonage du dépôt JavaFX semble échouer pour le moment, sinon j'essaierais de mettre cela en pratique. Mais au lieu de ce qui précède, que doit-il se passer pour ajouter la prise en charge d'autres formats? Cela ne semble pas énorme difficile.

1. Dans MediaUtils, le support doit être ajouté à la filenameToContentType() méthode pour gérer la nouvelle extension de fichier. C'est trivial.

2. Dans la même classe, le support doit être ajouté à la méthode fileSignatureToContentType() pour calculer le type de fichier en fonction de sa signature. C'est un peu plus complexe, mais toujours pas trop mal. Cela peut même être facultatif, car le code actuel ne semble l'utiliser que si le format n'est pas identifié correctement (ou pas du tout) à partir de l'extension de fichier. Une liste complète des signatures de fichiers pour différents formats peut être trouvée ici ce qui devrait aider à cette tâche.

3. Dans GSTPlatform, le nouveau type de contenu doit être ajouté à la liste des types de contenu pris en charge.

Du côté Java des choses, cela semble être tout ce qui est nécessaire pour l'amener à accepter le type de contenu et au moins tenter de le transmettre au Gstreamer natif couche .

Cependant, je ne suis pas un expert en GStreamer, donc bien que je sache qu'il peut gérer et lire beaucoup plus de formats que JavaFX refuse actuellement, je ne sais pas comment comment exactement ils ont supprimé cette capacité. Ils l'ont certainement fait dans la couche Java ci - dessus, mais ils l'ont peut-être également fait au niveau GStreamer natif-à ce stade, je ne suis pas sûr.

Je suppose qu'ils ont apporté quelques modifications à GStreamer pour JFX8-mais à l'heure actuelle, ils ne sont pas répertoriés sur lapage de projet pertinente , il est donc assez difficile de déterminer exactement ce qu'ils ont changé pour cette version.

L'étape suivante consisterait à saisir la source JFX8, à construire avec les modifications proposées ci-dessus pour un nouveau type de contenu, puis à voir quelles erreurs (le cas échéant) se produisent au niveau natif, puis à le prendre à partir de là.