Ora sono riuscito a compilare il supporto MKV in JavaFX con successo, e ci vuole un po', ma non un grande sforzo anche sul livello nativo. Vedere qui per la discussione che lo circonda e qui per il risultato inviato come ticket patch / JIRA.

Ho scritto una guida molto più completa sul processo qui che potrebbe essere di interesse per chiunque voglia seguire questa strada.

Cosa segue è la mia breve indagine prima di aver seriamente esaminato la compilazione di altri supporti multimediali, anche se lo lascerò qui per riferimento.

Ora che JFX8 è stato rilasciato ed è completamente open source, ho passato un po ' di tempo a guardare come questo potrebbe essere fatto, e se potrebbe essere fatto senza patch il sorgente JFX. Sfortunatamente la risposta a quest'ultimo punto è un no quasi definitivo, almeno non senza orribili hack di manipolazione del bytecode. Potrei indagare più praticamente in un secondo momento, ma documenterò ciò che ho elaborato finora dalla fonte disponibile.

La magia inizia dal Media constructor, che è in definitiva dove il MediaException salta fuori da (con il flag MEDIA_UNSUPPORTED se si tenta di riprodurre un formato non supportato.) Da lì crea il localizzatore , il cui costruttore assicura che l'URL sia supportato. Il metodo init() viene quindi chiamato in un thread separato, che esegue un controllo di integrità la stringa URL, legge il file, quindi procede per cercare di capire qual è il formato.

Il codice pertinente per questa parte del metodo è quindi:

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

Da questo possiamo vedere un primo tentativo "stupido" è fatto per afferrare il contenuto del file in base al suo nome (questo è ciò che fa MediaUtils.filenameToContentType().) Ci sono poi alcuni casi speciali per il controllo di diversi tipi di file wav, ma se ciò fallisce, ricorriamo a un controllo più intelligente che esamina la firma effettiva del file. Entrambi questi controlli sono in MediaUtils . Quest'ultimo controllo è molto più esteso e esamina i primi byte del file per vedere se può elaborare un formato in questo modo. Se non può, allora esce e lancia l'eccezione che poi salta fuori come la nostra temuta bandiera MEDIA_UNSUPPORTED.

Se il tipo è identificato correttamente, c'è ancora un altro ostacolo da superare: deve essere supportato dalla piattaforma corrente. Alcune piattaforme vengono caricate dinamicamente a seconda dell'ambiente, tuttavia il GSTPlatform esiste sempre, quindi avremmo bisogno di mettere tutti i formati aggiuntivi (universali) qui. Questo è relativamente semplice, esiste un array CONTENT_TYPES che contiene solo l'array di formati supportati.

Sfortunatamente la clonazione del repository JavaFX sembra fallire per me al momento, altrimenti tenterei di mettere in pratica qualcosa di questo. Ma al posto di quanto sopra, cosa deve effettivamente accadere per aggiungere il supporto per ulteriori formati? In realtà non sembra enormemente difficile.

1. In MediaUtils , il supporto deve essere aggiunto al metodo filenameToContentType() per gestire la nuova estensione del file. Questo è banale.

2. Nella stessa classe, il supporto deve essere aggiunto al metodo fileSignatureToContentType() per elaborare il tipo di file in base alla sua firma. Questo è un po ' più complesso, ma ancora non troppo male. Questo potrebbe anche essere facoltativo, poiché il codice corrente sembra usarlo solo come fallback se il formato non è identificato correttamente (o del tutto) da l'estensione del file. Un elenco completo di firme di file per diversi formati può essere trovato qui che dovrebbe aiutare con questa attività.

3. In GSTPlatform, il nuovo tipo di contenuto deve essere aggiunto all'elenco dei tipi di contenuto supportati.

Sul lato Java delle cose, questo sembra essere tutto ciò che è necessario per farlo accettare il tipo di contenuto e almeno tentare di passarlo al Gstreamer nativo livello.

Tuttavia, non sono esperto in GStreamer, quindi mentre sono consapevole che ci sono molti altri formati che può gestire e riprodurre che JavaFX attualmente rifiuta, non sono sicuro di come esattamente hanno rimosso questa capacità. L'hanno sicuramente fatto nel livello Java sopra, ma potrebbero averlo fatto anche a livello nativo di GStreamer - a questo punto non sono sicuro.

Presumo che abbiano apportato alcune modifiche a GStreamer per JFX8-ma al momento non sono elencati su la pagina del progetto pertinente , quindi è piuttosto difficile capire esattamente cosa hanno cambiato per questa versione.

Il passo successivo sarebbe quello di afferrare il sorgente JFX8, costruire con le modifiche proposte sopra per un nuovo tipo di contenuto, e quindi vedere quali errori (se presenti) si verificano a livello nativo, quindi prenderlo da lì.