Come caricare il stream su Servizi multimediali di Azure

Stiamo utilizzando ASP.NET MVC 4 per consentire agli utenti di caricare video e audio attraverso il nostro sito web. Mi piacerebbe utilizzare Azure Media Service come back-end per questo.

Seguendo il tutorial di Azure , il problema che ho riscontrato è che l’SDK di Servizi multimediali di Azure non sembra consentire il caricamento di un stream di dati non elaborato. Invece, l’unico metodo di caricamento che ho trovato utilizza un argomento stringa di percorso.

Vorrei evitare di salvare il file su disco ( è già in streaming su disco per impostazione predefinita ) ed essere in grado di eseguire lo streaming del file inviato della richiesta direttamente in Azure.

Ecco il mio codice finora:

public void SaveMedia(string fileName, System.IO.Stream stream) { CloudMediaContext mediaCloud = new CloudMediaContext("account", "key"); AssetCreationOptions assetOptions = new AssetCreationOptions(); var asset = mediaCloud.Assets.Create(fileName, assetOptions); var assetFile = asset.AssetFiles.Create(fileName); var accessPolicy = mediaCloud.AccessPolicies.Create(fileName, TimeSpan.FromDays(3), AccessPermissions.Write | AccessPermissions.List); var locator = mediaCloud.Locators.CreateLocator(LocatorType.Sas, asset, accessPolicy); assetFile.Upload("????????????"); locator.Delete(); accessPolicy.Delete(); } 

Come si realizza questo? Questo conflitto con le “migliori pratiche” per la gestione dei caricamenti utilizzando ASP.NET MVC 4 e Azure Media Services?

    Non utilizzare i servizi multimediali di Azure per eseguire il caricamento, non è progettato per il blob in-stream-to-to-azure-storage-in-stream, che è ciò che stai descrivendo.

    Utilizzare direttamente l’SDK di archiviazione di Azure (utilizzare la versione 1.7 per evitare problemi di rebinding). L’SDK di archiviazione consente alle scritture di stream di eseguire il blob. Per fare ciò, devi prima ottenere un localizzatore di scrittura SAS (sembra che tu sia lì), quindi utilizzare locator.Path.Segments per trovare il contenitore di risorse. Quindi utilizzalo per caricare direttamente utilizzando CloubBlobClient nell’SDK di archiviazione: offre da qualche parte una funzione di scrittura del stream.

    Nota nel tuo codice qui sopra: non stai specificando AssetCreationOptions.None, quindi supporrà che i file presenti nella memoria siano crittografati in memoria (il meccanismo di trasferimento predefinito è sicuro, non non protetto). Non penso che tu stia andando a fare la crittografia di archiviazione sul tuo file-stream prima del caricamento, quindi è meglio impostarlo su AssetCreationOptions.None.

    Personalmente, non vorrei seguire questa strada. Leggi il mio post sul blog “crea il tuo youtube”: http://blog-ndrouin.azurewebsites.net/?p=1471

    In esso, c’è un esempio completo di contenuto caricato dal client utilizzando un URL SAS fornito dal lato server (che ha le credenziali del tuo account, che probabilmente non vorrai essere presente sul tuo lato client!).

    Il client, tuttavia, deve essere in grado di eseguire l’archiviazione in PUT utilizzando tale URL SAS. Nel mio caso, ho usato un’app per la riga di comando C #. Non potrai farlo in HTML5 a meno che la tua pagina Web non sia ospitata nello stesso dominio dell’account di archiviazione di destinazione. Se la tua pagina web (o un I-Frame che gestisce i caricamenti) non si trova nello stesso dominio dell’account di archiviazione, verrà triggersta una chiamata CORS “OPTIONS” in HTML5 al livello REST di archiviazione di Azure, che non supporta ancora CORS .

    Le alternative a un I-Frame HTML5 ospitato nel tuo account di archiviazione sono: shim di caricamento Sliverlight o Flash con un file interdominio nella radice $ del tuo account di archiviazione (o forse quegli oggetti plug-in ospitati nel tuo account di archiviazione per evitare il dominio incrociato -file richiesta).

    Scorporrei il caricamento del filestream sul server in un POST. Ciò rende il tuo servizio web un collo di bottiglia per tutti i file in entrata; e un POST lungo non è particolarmente stabile: il tuo pool di app può essere riciclato nel bel mezzo di un caricamento e tu sei brindisi.

    PS. Il nostro team (Windows Media Services di Azure) monitora principalmente questo forum:

    http://social.msdn.microsoft.com/Forums/en-US/MediaServices/threads