Home - About me - Browse by categories

Introduction à Windows Azure Media Services

Windows Azure Media Services

Il s’agit d’une nouvelle brique de Windows Azure qui permet de gérer l’hébergement, l’encodage, la mise à disposition de médias, sur Internet. Il est notamment possible de gérer des workflows de publication de vidéo. Par exemple, vous allez pouvoir choisir d’envoyer un fichier vidéo au format HD dans un espace de stockage Windows Azure (blob), et faire en sorte que ce fichier soit automatiquement encodé dans différents formats (basse résolution etc…) et publié sur Internet. Pour se faire, Microsoft propose un ensemble d’API dans le SDK Windows Azure Media Services. ### Création d’un service de média

Connectez-vous sur le site de management Windows Azure et cliquez sur la section « Services de média » imageCliquez ensuite sur le lien « Créer un service de média ». Vous devrez alors fournir trois informations : - Le nom du service que vous souhaitez créer (chiffres et lettre, tout en minuscules) - La localisation géographique - Le stockage Windows Azure qui doit être utilisé pour stocker les fichiers

image

Patientez ensuite jusqu’à ce que le service soit créé. Une fois ceci fait, il est possible de récupérer la clé de management qui permettra d’utiliser le SDK pour envoyer des fichiers vidéos sur Azure et les traiter, au sein d’une application .NET. Pour cela, rendez-vous sur le dashboard du service de média que vous venez de créer et cliquez sur le lien « Gérer les clés » : imageCopiez alors la clé d’accès primaire que vous allez réutiliser par la suite. ### Utilisation de l’API .NET

Afin de pouvoir utiliser les APIs Windows Azure Media Service, il est nécessaire d’inclure ce package Nuget dans votre projet. Le premier objet à instancier est un CloudMediaContext. C’est lui qui représente le point d’entrée de l’API Windows Azure Media Services. Il est nécessaire de passer le nom du service ainsi que la clé d’accès primaire au constructeur :```csharp var context = new CloudMediaContext(“nom de votre service Azure Media Services”, “votre clé”);

Via ce context, vous allez pouvoir créer un nouvel asset. Un asset représente une vidéo, dans les différents formats sous lesquels elle sera publié. Pour créer un asset, il faut exécuter le code suivant :

```csharp
string videoFilePath = @"E:\VIDEOS\Test.mp4";
string fileName = Path.GetFileName(videoFilePath);
string assetName = string.Format("{0} - {1}", Path.GetFileNameWithoutExtension(videoFilePath), DateTime.Now);

//création de l'asset sur le CloudMediaContext
IAsset asset = context.Assets.Create(assetName, AssetCreationOptions.StorageEncrypted);

L’asset est a présent crée, il est alors possible d’envoyer le fichier vidéo qui est associé :

IAssetFile file = asset.AssetFiles.Create(fileName);
file.Upload(videoFilePath);

Vous pouvez vous arrêter à ce code si vous ne souhaitez pas ré encoder le fichier derrière pour le publier dans différents formats. D’ailleurs, si vous vous connectez à l’interface de gestion de Windows Azure Media Services, vous devriez voir apparaitre le contenu vidéo qui a été envoyé.

Dans le cas présent, nous allons pousser un peu plus loin puisque nous allons lancer un job d’encodage. Pour se faire, il est nécessaire de récupérer un media processor, c’est à dire un outils qui va permettre d’effectuer l’encodage vidéo. Windows Azure Media Services en propose plusieurs :

  • Windows Azure Media Encoder
  • Windows Azure Media Packager
  • Windows Azure Media Encryptor
  • Storage Decryption

Pour plus d’info sur les media processors, consultez cette page de la MSDN.

Ici, c’est le premier de la liste qui va être utilisé. Pour le récupérer, il suffit de faire une simple requête LINQ sur la collection MediaProcessors du contexte :

var mediaProcessor = context.MediaProcessors.Where(f => f.Name == "Windows Azure Media Encoder").AsEnumerable().FirstOrDefault();

Afin de lancer une tâche d’encodage, il est également nécessaire de préciser une configuration à utiliser. Il est possible de récupérer les différentes configuration sur cette page, en fonction du media processor utilisé ! Dans le cas présent, c’est le preset H.264 256k DSL CBR qui va être utilisé :

string encodingConfiguration = "H.264 256k DSL CBR";

Il est désormais possible de créer la tâche d’encodage :

//création du job
IJob job = context.Jobs.Create(string.Format("job d'encodage de {0}", asset.Name));

//ajout de la tâche d'encodage
ITask task = job.Tasks.AddNew(string.Format("tâche d'encodage de {0}", asset.Name), mediaProcessor, encodingConfiguration, TaskOptions.None);

//ajout de l'asset en input
task.InputAssets.Add(asset);

//création de l'asset d'output
var outputAsset = task.OutputAssets.AddNew(string.Format("{0} (output)", asset.Name), true, AssetCreationOptions.None);

//soumission du job
job.Submit();

Pour attendre la fin du job, il faut récupérer une task sur l’objet job à l’aide de la méthode GetExecutionProgressionTask. Il est alors possible de tester son état pour savoir s’il a réussi ou échoué :

//attente de la fin du job
Task jobProgressionTask = job.GetExecutionProgressTask(CancellationToken.None);
jobProgressionTask.Wait();

//test de l'état du job
if (job.State == JobState.Finished)
{
Console.WriteLine("Le job est terminé");
}
else if (job.State == JobState.Error)
{
Console.WriteLine("Une erreur est survenue pendant l'exécution du job.");
}

Il est également possible de s’abonner à l’événement StateChanged sur le job afin de récupérer les différentes transitions au fur à mesur de son exécution :

static void job_StateChanged(object sender, JobStateChangedEventArgs e)
{
Console.WriteLine("L'état du job vient de passer de {0} à {1}", e.PreviousState, e.CurrentState);
}

Et voilà, le tour est joué, vous avez pu envoyer un fichier vidéo directement dans le stockage Azure et lancer différents workflow pour réencoder la vidéo à la volée avant de la publier :

image

Et si vous allez sur l’interface Windows Azure vous pouvez constater que l’output est bien présent et publiable :

image

Un fois publié, il est possible de lire lire et de récupérer son adresse dans le blob storage Azure :

image

Enjoy Clignement d'œil

Julien

read more

[Windows Phone 8] Ecrire un tag NFC et lancement d’une application via NFC

Dans mon article précédent, je vous montrais comment utiliser l’API de proximity device pour échanger une information entre deux téléphones lors d’un tap NFC. Dans ce nouvel article, je vais vous montrer comment écrire du contenu dans un tag NFC afin de le réexploiter pour qu’il puisse fournir une URL ou encore qu’il permette de lancer une application !

Ecriture d’un tag

L’écriture d’un tag se fait très simplement. Tout d’abord, Il faut récupérer une instance de ProximityDevice grace à la méthode statique GetDefault de cette même classe :

public partial class MainPage : PhoneApplicationPage
{
private readonly ProximityDevice _proximityDevice;
// Constructor
public MainPage()
{
InitializeComponent();
_proximityDevice = ProximityDevice.GetDefault();
}
}

Une fois récupéré, le ProximityDevice permet d’écouter les messages NFC apportés par un tag sur lequel il est possible d’écrire. Pour celà, il suffit de souscrire aux messages de type <em>Writeable</em> :

private long subId = 0;
protected override void OnNavigatedTo(NavigationEventArgs e)
{
if (_proximityDevice == null)
{
Dispatcher.BeginInvoke(() =>
{
MessageBox.Show("Le NFC n'est pas supporté sur ce téléphone", "Pas de NFC", MessageBoxButton.OK);
});
}
else
{
subId = _proximityDevice.SubscribeForMessage("WriteableTag", OnWriteableTagArrived);
}

base.OnNavigatedTo(e);
}

Dans le handler OnWriteableTagArrived, on récupère le ProximityDevice qui lève l’événement, et on peut alors écrire une information à l’aide de la méthode PublishBinaryMessage :

private long pubId = 0;
private void OnWriteableTagArrived(ProximityDevice sender, ProximityMessage message)
{
var dataWriter = new DataWriter();
dataWriter.UnicodeEncoding = Windows.Storage.Streams.UnicodeEncoding.Utf16LE;
dataWriter.WriteString("http://www.juliencorioland.net");
pubId = sender.PublishBinaryMessage("WindowsUri:WriteTag", dataWriter.DetachBuffer());
}

Comme vous pouvez le constater, j’utilise ici le protocole WindowsUri:WriteTag, qui me permet d’écrire une information de type URL dans le tag NFC (ici il s’agit d’une carte de dev offerte par Nokia à la //build/), en l’occurrence ici l’adresse de mon blog. Du coup, lorsque je passe mon téléphone devant le tag NFC, celui ci affiche me propose d’afficher mon blog :

image

Lorsque j’accepte, le navigateur s’ouvre sur mon blog !

Lancer son application à partir d’un tag NFC

Un des cas d’utilisation de NFC prévu par Microsoft sous Windows Phone 8 est la possibilité d’associer une application à un type de tag, permettant ainsi de lancer une application par contact NFC. Par exemple, vous pouvez imaginer une borne intéractive à l’entrée d’un magasin, sur laquelle vous poser votre téléphone qui lance alors l’application pour ce magasin en particulier, avec du contenu mis en avant !

Association de protocole

Dans un premier temps, il faut créer une association de protocole pour votre application. La première étape consiste à ajouter une extension dans la manifest de l’application :

<Extensions>
<Protocol Name="samplenfc" TaskID="_default" NavUriFragment="encodedLaunchUri=%s" />
</Extensions>

Ici, on associe le protocole samplenfc: à l’application (les deux autres paramètres sont les valeurs à renseigner obligatoirement, cf. http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj206987(v=vs.105).aspx#BKMK_Protocolassociations).

Ensuite, il faut créer un UriMapper capable de traiter l’association de protocole. Pour cela on créé une classe qui dérive de UriMapperBase :

public class AssociationUriMapper : UriMapperBase
{
public override Uri MapUri(Uri uri)
{
string url = HttpUtility.UrlDecode(uri.ToString());

if (url.Contains("samplenfc:MainPage"))
{
int paramIndex = url.IndexOf("source=") + 7;
string paramValue = url.Substring(paramIndex);

return new Uri("/MainPage.xaml?source=" + paramValue, UriKind.Relative);
}

return uri;
}
}

Le code est assez simple ici : je récupère l’URL samplenfc:qqchose et je la converti en URL XAML.

Ecriture du tag NFC

Pour l’écriture du tag NFC, cela se passe à peu près comme dans la première partie de l’article, sauf que cette fois, le protocole n’est plus http, mais samplenfc :

private long pubId = 0;
private void OnWriteableTagArrived(ProximityDevice sender, ProximityMessage message)
{
var dataWriter = new DataWriter();
dataWriter.UnicodeEncoding = Windows.Storage.Streams.UnicodeEncoding.Utf16LE;
//dataWriter.WriteString("http://www.juliencorioland.net");
//pubId = sender.PublishBinaryMessage("WindowsUri:WriteTag", dataWriter.DetachBuffer());

string appLauncher = string.Format(@"samplenfc:MainPage?source=NFCWakeUp");
dataWriter.WriteString(appLauncher);
pubId = sender.PublishBinaryMessage("WindowsUri:WriteTag", dataWriter.DetachBuffer());
}

Du coup, après avoir écrit mon tag sur la carte de développement, lorsque j’approche mon téléphone de celle-ci, j’obtiens bien le résultat attendu : le téléphone me propose de lancer mon application :

</param></embed> NFC Rocks ! Julien
read more

[Windows Phone 8] Utilisation du ProximityDevice NFC

Windows Phone 8 permet de mettre en place de la communication NFC entre devices, en mode tap. Pour commencer à découvrir les APIs, je vous propose un scénario ultra simple : une application Windows Phone 8 ayant deux pages. La première est capable de publier un message via NFC, la seconde est capable de recevoir un message via NFC. Lorsque l’on tape deux téléphones entre eux celui sur la page de publication envoi un message qui est reçu sur l’autre téléphone.

Publier un message via NFC

Pour commencer, il est nécessaire de récupérer une instance de la classe ProximityDevice, défini dans Windows.Networking.Proximity.

public partial class Publish : PhoneApplicationPage
{
ProximityDevice _proximityDevice;

public Publish()
{
InitializeComponent();
_proximityDevice = ProximityDevice.GetDefault();
}
}

A partir du moment ou vous récupérez une instance, c’est que le NFC est supporté sur le device !

Pour être en capacité de publier un message, on utilise la méthode PublishMessage, à laquelle on précise un type de message et le contenu du message :

private long _messageId = 0;

protected override void OnNavigatedTo(NavigationEventArgs e)
{
if (_proximityDevice != null)//NFC is supported
{
_messageId = _proximityDevice.PublishMessage("Windows.SampleNFC", "Hello dude, Windows Phone 8 Rocks !");
}

base.OnNavigatedTo(e);
}

A partir de là, l’application enverra le message à n’importe qu’elle autre application qui écoute ce type particulier de message, ici <em>Windows.SampleNFC</em>. Le type de message indique le protocole utilisé (avant le .) et le sous type de message. Lorsque l’on utilise la méthode PublishMessage, le protocole est obligatoirement <em>Windows</em>.

La méthode PublishMessage renvoie un id. Celui-ci est très important car votre application ne peut supprimer qu’un seul type de message à la fois. Aussi, avant de pouvoir publier un autre type de message, il faut stopper la publication, à l’aide de la méthode **StopPublishingMessage **:

protected override void OnNavigatedFrom(NavigationEventArgs e)
{
if (_proximityDevice != null)
{
_proximityDevice.StopPublishingMessage(_messageId);
}
base.OnNavigatedFrom(e);
}

Voilà concernant la partie publication.

Souscrire à un message NFC

La souscription à un message NFC est assez similaire, puisqu’elle utilise également un ProximityDevice, que l’on récupère avec la méthode statique GetDefault, comme dans la partie précédente. Ensuite, on utilise la méthode SubscribeForMessage en précisant le type de message qu’on vont recevoir :

protected override void OnNavigatedTo(NavigationEventArgs e)
{
if (_proximityDevice != null)
{
_subscriptionId = _proximityDevice.SubscribeForMessage("Windows.SampleNFC", OnMessageReceived);
}
base.OnNavigatedTo(e);
}

Comme pour la publication, on obtient un id de souscription qu’il est nécessaire d’utiliser pour arrêter d’écouter ce type de message :

protected override void OnNavigatedFrom(NavigationEventArgs e)
{
if (_proximityDevice != null)
{
_proximityDevice.StopSubscribingForMessage(_subscriptionId);
}
base.OnNavigatedFrom(e);
}

Et voilà le handler appelé lors de la réception d’un message :

private void OnMessageReceived(ProximityDevice sender, ProximityMessage message)
{
if (message != null)
{
Dispatcher.BeginInvoke(() =>
{
MessageBox.Show(message.DataAsString);
});
}
}

Le tour est joué. Voilà ce que ça donne avec deux téléphones :

</param></embed> A+ Julien
read more

[Build 2012] Windows Phone 8 – tiles et notifications

Allez, on attaque la troisième session de la journée pour voir ce qu’il y a de nouveau du côté te des tiles et des notifications.

Au niveau des notifications, l’architecture reste similaire à celle de Windows Phone 7.5 avec l’envoie de requêtes http au service de push notifications Microsoft (MPNS). Quelques nouveautés quand même, puisqu’il n’y a plus de limite concernant le nombre d’applications qui peuvent utiliser les notifications sur le device (30 sous WP7).

Il y a également un nouveau type de notification push qui permet de réveiller une application VOIP.

Du côté des vignettes dynamique il y a aussi pas mal de nouveautés, puisqu’il est maintenant possible de créer des tuiles de trois tailles différentes : petite, moyenne, large. A ces trois tailles de vignettes, il est possible d’appliquer un modèle, parmi les suivants :

Flip tile

Ce modèle est similaire à celui existant sous phone 7.x. On retrouve l’image avant et arrière, le count, le titre, le contenu…

Cycle tile

Il s’agit d’un modele permettant de faire defiler plusieurs images, un peu à la manière de la vignette du hub photos.

Iconic tile

Ce modèle permet de générer des vignettes qui possèdent un count et un logo, mais en animant le count, comme la tuile Outlook, par exemple.

Côté local tiles APIs, la ShellTileSchedule peut mettre à jour TOUTES les propriétés de la vignette. Il est désormais possible de passer un payload xml pour alimenter les tiles data, plutôt que d’affecter toutes les propriétés à la main !

Il est également possible de s’intégrer avec l’écran de verrouillage du téléphone afin d’y ajouter des informations (logo, nombre et texte) identiques aux informations de la vignette principale, mais celle-ci ne doit pas obligatoirement être épinglée.

Les APIs sont toutes plus simple à utiliser les unes que les autres et beaucoup d’incohérences que l’on pouvait avoir ont disparues. Bref, ça poutre bien comme il faut !

Stay tuned 😉

Julien

read more

[Build 2012] Maps, géolocalisation et exécution en arrière plan.

Première session Windows Phone 8 de cette 3ème journée de //build/ 2012 (pas de keynote aujourd’hui!), on s’intéresse aux nouveautés concernant les maps, la géolocalisation et l’exécution en arrière plan !

image

Location Services APIs

Les APIs de géolocalisation ont été complètement repensées sous Windows Phone 8. On conserve l’ancienne API .NET avec le GeoCoordinateWatcher pour la compatibilité ascendante, mais une nouvelle API WinRT est disponible et beaucoup plus complète !

Côté WinRT, on retrouve une nouvelle classe, Geolocator pour localiser un utilisateur. Il y a plus de contrôle sur la précision souhaitée (en mètres) et il est notamment possible de récupérer la position de l’utilisateur sans la tracker en continue (Single Location Request), ce qui permet d’économiser la batterie de l’utilisateur. Comme beaucoup d’API WinRT, celle-ci est totalement asynchrone (async/await). On retrouve aussi la possibilité de contrôler la mise en cache et les timeout.

En terme de bonnes pratiques, il faut utiliser au maximum le Single Location Request, quand c’est possible, car celà permet vraiment de réduire la consommation de la batterie !

En bonus, un bout de code sur l’utilisation de l’API Geolocator :

image

###

Map Control et service de géolocalisation

Autre grosse nouveauté de la plateforme Windows Phone 8 côté cartes, l’utilisation des maps Nokia et des services de géolocalisation Nokia. On utilise un nouveau contrôle Maps qui permet notamment à l’utilisateur d’avoir ses cartes en mode offline pour ne plus consommer sa connexion de données et augmenter la fluidité ! Au passage, un nouveau launcher permet de proposer à l’utilisateur de télécharger une carte : MapsDownloader.

Le contrôle maps est capable d’afficher des cartes en 2D/3D, en vectoriel, ainsi que des itinéraires.

Avec cette carte, de nouveaux services arrivent pour effectuer directement des opérations de geocoding, géocoding inversé et de calcul d’itinéraire (il ne s’agit plus des services Bing, mais Nokia !)

Le BingMaps contrôle existe toujours pour la compatibilité des applications 7.x, mais il est déprécié !

L’utilisation du contrôle Maps et des services Nokia est gratuite, il faut juste associer son compte de développeur pour pouvoir récupérer un token.

Le maps toolkit extensions (http://phone.codeplex.com) permet d’avoir des fonctionnalités supplémentaires pour le contrôle Maps (pushpin etc..)

Géolocalisation en arrière plan

Sous Windows Phone 8, une application peut s’exécuter en arrière plan ET récupérer la position de l’utilisateur en continue (une seule application peut le faire). C’est uniquement possible pour les applications XAML (XAML, XAML+Direct3D, mais pas pur Direct3D).

En mode background, l’application n’a accès qu’à des ressources limitées et qu’à un sous ensemble des APIs :

image

Comme pour les background agent sous Windows Phone 7.5, l’utilisateur peux désactiver l’application dans les paramètres du téléphone.

L’application peut être notifiée (event) et notifier l’utilisateur lorsque la géolocalisation est désactivée au niveau du téléphone.

Au niveau du cycle de vie de l’application, on a un nouvel événement : RunningBackground (en plus de Launching, Deactivated, Activated et Close) qui permet de savoir que l’application s’exécute en arrière plan ! Ce nouvel event remplace le deactivated pour les applications de géolocalisation en arrière plan :

image

Fast Resume

Le fast resume est la capacité des applications Windows Phone 8 à reprendre là où elles étaient, même si l’utilisateur les relance depuis son écran d’accueil ou la liste des applications (contrairement à Windows Phone 7 ou l’application était totalement relancée!). Pour permettre à une application de faire du fast resume, il faut éditer le fichier manifest, au niveau de la définition de la DefaultTask (par défaut, le comportement est le même que sous Phone 7, Replace) :

image

Lorsque l’application est résumée, le mode de navigation dans la méthode OnNavigatedTo est à **Reset**, ce qui permet par exemple de vider la stack de navigation tout en conservant une ancienne instance de l’application (optimisation de la mémoire du téléphone et de la rapidité du chargement de l’application). Toutes les explications ici : http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj735579(v=vs.105).aspx

Conclusion

Beaucoup de nouveautés autour de la géolocalisation, avec le nouveau contrôle Maps de Noka, les APIs de Nokia pour le géocoding et surtout la possibilité d’avoir une application qui track la position de l’utilisateur en continue et en background !

Stay tuned Winking smile

Julien

read more