Azt hiszem mindenki találkozott már olyan weboldallal amin ugyan volt média/video elhelyezve, csak éppen a minősége és/vagy a (lejátszás) felhasználói élménye a 0-t közelítette.
(ez egészen a kis álateledel webshopoktól egészen a nagy video-tartalom szolgáltatókon át az igazi nagyágyúkig… mindenki ismeri őket?!? ugye?!?)

Mi sem egyszerűbb hogy ezen túllépjünk:

Smooth Streaming

Kell hozzá:

• IIS7+Media Extensions
  Web Platfrom Installer : www.microsoft.com/web
  http://www.microsoft.com/web/downloads/platform.aspx
• Expression Encoder
  http://www.microsoft.com/expression
• Expression Encoder SDK
• Silverlight 3

Lépések

1. Video beszerzése
   (kelleően jó minőségű, pl. 720p-1080p)
2. Video enkódolása
   Történthet “kézzel” Expression Encoder-ben.
   1. New Job
   2. Import media
   3. Válasszuk ki a Smooth Streaming output formatot:
   
   4. Adjunk meg igény szerint a különböző profilokat:
   
   5. Adjunk meg Output template-t így egy kész Silverlight 3 lejtásztót tartalmazó HTML oldalt is kapunk.
    
   6. Encode :) ami eltart egy darabig… nagy fileoknál akár 10-20-60 perceket is, sőt!!!
   7. A kész output-ot másoljuk be az IIS7 alá, amibe már előtte telepítettük a Media Extension-t, ami képessé teszi Smooth Streaming-re
3. Hogy megy ez “kézzel”, egészen pontosan kódda, c#-al?!?
   Új console app, majd adjunk referenciát a Expression Encoder SDK dll-ekre.
   "C:\Program Files\Microsoft Expression\Encoder 3\SDK"
   (Itt találunk pléda programot is!!!!)
   És…
   

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Expression.Encoder;
using Microsoft.Expression.Encoder.Live;
using Microsoft.Expression.Encoder.Profiles;
using System.IO;

namespace Live
{
    class Program
    {
        static void Main(string[] args)
        {

            //
            MediaItem mediaItem 
            = new MediaItem(@"forras.mp4");


            //ezt kell használni a profile-ok összeállítására....aspect ratio tartásával
            Console.WriteLine("size={0}", mediaItem.VideoSize);

            AdvancedVC1VideoProfile videoProfile = new AdvancedVC1VideoProfile();

            // When you create a VideoProfile you'll get one stream by default.
            // In this example remove that one as we’re going to explicity 
            // add the three streams below.
            videoProfile.Streams.RemoveAt(0);

            //!!!!
            // a megfelelő méret és aspect ration megadását meg kell csinálni,
            // a forrás méretei alapján
            // pl. érdemes puskázni az Expression Encoder default beállításaiból
            // pl. ~3mbps, ~1600kbps, ~1200kbps, ~800kbps, ~500kbps
            //  hozzá a megfelelő arányos méretekkel...
            //!!!!

            //videoProfile.Streams.Add(
            //    new VariableConstrainedBitrate(1450, 1600),
            //    new System.Drawing.Size(800, 600));
            videoProfile.Streams.Add(
                new VariableConstrainedBitrate(1050, 1600),
                new System.Drawing.Size(640, 480));
            videoProfile.Streams.Add(
                new VariableConstrainedBitrate(600, 1600),
                new System.Drawing.Size(400, 300));

            // Use smooth streaming with automatically sized streams.
            videoProfile.SmoothStreaming = true;
            videoProfile.Streams.AutoSize = true;


            mediaItem.OutputFormat.VideoProfile = videoProfile;
            
            Job job = new Job();
            job.MediaItems.Add(mediaItem);
            

            // Set up the progress callback function
            job.EncodeProgress 
                += new EventHandler<EncodeProgressEventArgs>(OnProgress);

            // Set the output directory and encode.
            job.OutputDirectory = "c:\\temp";

            job.CreateSubfolder = true;
            job.Encode();
          
        }

        static void OnProgress(object sender, EncodeProgressEventArgs e)
        {
            Console.WriteLine(e.Progress);
        }

    }
}

4. Majd az eredményhez a megfelelő lejátszó alkotása… ezt szintén lehet puskázni az Encoder által gyárott HTML-ből, esetleg puskázunk a forráskódból…
   (szintén megtalálható az SDK Sample könyvtárának bugyraiban…)
   
   

Info : http://blogs.msdn.com/expressionencoder/archive/2009/07/29/9853000.aspx

Mindamellett hogy a PDC-ről letölthető számos előadás ill. a gyári blogokban kezdenek szállingózni a demok, oktatási példák, egy egész komoly anyag jelent meg a CH9-en is Azure-al kapcsolatban.

(Step By Step jellegű, elég részletesek)

http://channel9.msdn.com/learn/courses/Azure/

Találtam egy ingyenes könyvet, ennek apropóján gondoltam összeszedem, összeszedhetjük az ingyenes ebook-okat, amik elérhetők .Net technológiákról:

• .NET Application Architecture xxx Guide, 2nd Edition   ~500 oldal
  http://www.microsoft.com/downloads/en/confirmation.aspx?familyId=ce40e4e1-9838-4c89-a197-a373b2a60df2&displayLang=en
• Performance Testing Guidance  ~220 oldal
  http://www.codeplex.com/PerfTestingGuide/Release/ProjectReleases.aspx?ReleaseId=6690
• Composite Application Guidance and MVVM (ViewModel) – PRISM
  http://www.microsoft.com/downloads/details.aspx?FamilyID=387c7a59-b217-4318-ad1b-cbc2ea453f40&displaylang=en

Majd megjegyzésbe megy a többi…

Tudom tudom a 3 már történelem :D, de már az is tudta, hogy nem Soap borítékban mindenféle buta enkódlásban küldük át a bináris adat a kliensre, hanem binárisan. Ez persze alap a WCF-ben, de egy 3-4mbyte-os pluginban nem volt magától érthetődő (gondolom én), ezért pl. a SL2 nem is tudta (maradt a jó öreg basicHttpBinding-> HTTP+SOAP).

Most egy (még) titkos projekt keretében bináris adatok kellene Server-Kliens kommunikációban Silverlight-ba küldeni, és azt tudtam hogy “komolyabb” binding-ot nem tud az SL, de rájöttem (rákerestem Google-ben és Bing-ben) hogy építeni tudok sajátot, így azzal megoldható a történet :
(miért nem jutott ez eszembe magamtól is?!?!? )

 <customBinding>
        <binding name="binaryHttpBinding">
          <binaryMessageEncoding>         
          </binaryMessageEncoding>
          <httpTransport>           
          </httpTransport>
        </binding>
      </customBinding>

…

<endpoint address="" binding="customBinding" bindingConfiguration="binaryHttpBinding"
      contract="IService">
          <identity>
            <dns value="localhost" />
          </identity>
        </endpoint>

Előbb vagy útóbb minden fejlesztő szembesül azzal a problémával, hogy olyan alkalmazást kellene írni, amely tulajdonképpen egy keretrendszer bizonyos alapfunkciókkal, amihez idővel újabb és újabb modulok kerülnek majd illesztésre.

Ha ez egy zárt projekt, és mi vagyunk a fejlesztői a keretnek és a moduloknak is, akkor nem is biztos hogy “keretrendszert” építünk általános megoldásokkal, hanem egyszerűen add new project, add refenrece, aztán ‘jónapot, had ‘szóljon, hivatkozunk az új dolgokra, rebuild, már mehet is az új exe+dll valahogy a usereknek.

Ez a megoldás gyors, egyszerű, ellenben ha sokan dolgozunk a projekten pl. *nd*aiakkal :D, és nem kellőképen dokumentált a fejlesztés módja, akkor egy nagy káosz kialakulásának leszünk jobb esetben csak szemtanui, rosszabb esetben résztvevői.
Továbbá ez e megoldás kivitelezhetetlen, ha ténylegesen egy szuper-világmegváltó-hiperfrankó-keretrendszert alkottunk, pl. egy grafikai eszközt, egy hitel/pénzügyitermék-prortfóliót kezelő rendszert. És azt akarjuk hogy bárki a világon fejleszthessen hozzá (bizonyos feltételekkel) modulokat: egy új effectet, egy új terméket/jutalékszámító eszközt,stb.
Ilyen esetben nem megoldás az hogy megkérjük a ‘világot hogy küldje már el a forráskódot, mi meg belefordítjuk… mert A usernek M modul, B usernek meg N modul kell, stb…

Mit lehet tenni?

Alkutunk egy saját leíró nyelvet: XML-ben össze lehet tenni a felületet, algoritmust, szabályokat, stb. Publikáljuk a “leírónyelvünk” specifikációját, és a modul futtatása nem más XML parszolás (saját parszerrel), majd futtatás…
Egyszerű dolgoknál működik, sőt néha ez a “tökéletes” megoldás (pl workflow rule engine), de ugye látjuk a korlátait, nehézségeit?

Nem marad más hátra, minthogy dll-t gyártatunk az önjelölt modulfejlesztőkkel, amit _nem_ teszünk be a keretalkalmazásba, és ezt a modult valahogy elérjük futási időben.
Nos, ez ugye a Reflection .Net-ben.

Milyen lehetőségeink vannak Reflection-el?

• Nem adunk meg semmilyen kötöttséget, kivéve, hogy meghatározzuk 1<= “kulcs-pontot”. Ez lehet egy belépési pont, egy osztály, egy “programkód”,stb
  Pl. a keretalkalmazásunk nem tud mást mint, hogy az adott DLL-ben megkeresi az EztInditsdEl nevű (Form-ból származott) osztályt, példányosít egyet, és meghivja rajta a Show-t:
  

Assembly a = Assembly.LoadFile(dll_path);
          Type t = null;
          foreach (Type item in a.GetTypes())
          {
              if (item.Name == "EztInditsdEl")
              {
                  t = item;
                  break;
              }
          }

          if (t!= null && t.BaseType == typeof(Form))
          {
              ConstructorInfo ci= t.GetConstructor(new Type[0]);
              object o= ci.Invoke(null);
              Form f = o as Form;
              f.MdiParent = this;                
              f.Show();
          }
          else
          {
              throw new Exception("hiba a modulban");   
          }

Persze ezt lehet fokozni, konkrét osztálynevekkel, interfészekkel, attributumokkal, stb.
Látszik, hogy nehézkes a használata: rengeteg reflection (minden egyes meghíváshoz, példányosításhoz, propertyhez,stb). ami ráadásul “lassú” is a late-binding miatt.
Macera, megint.

• A jól definiált “korlátokat”, kötelezettségeket határozunk meg, amiket be kell tartania a modul fejlesztőjének.
  Ezek tipikusan  baseclass-ok, interfészek, attribútumok, virtuális metódusok, stb…
  Ezeket betesszük egy külön DLL-be, mi adunk referenciát a DLL-re, és használjuk. A fenti megoldással szemben hatalmas az előnyünk. Reflection-t (szerencsés esetben) csak “egyszer” kell használnunk: a modul assembly betöltése után a “belépési” pont megkeresésésre és példányosítására.
  Utána már használhatjuk pl. a mi kis interfészünket.
  A modul fejlesztőjének nincs más dolga, mint az interfész megvalósítása (miután letöltötte az áltaunk publikussá tett DLL-t)
  
  Interfész:
  

  namespace ModulBase
  {
      public interface IModul
      {
          void Kiir(string mitirki);
  
          string Beolvas(string kerdes);
      }
  }
  Modul:
  

  namespace Modul1
  {
      public class MyModul:ModulBase.IModul
      {
          #region IModul Members
  
          public void Kiir(string mitirki)
          {
              Console.WriteLine(mitirki);
          }
  
          public string Beolvas(string kerdes)
          {
              Console.Write(kerdes);
              return Console.ReadLine();
          }
  
          #endregion
      }
  }
  

  Alkalmazás:
  

Assembly a = Assembly.LoadFile(dll_path);
ModulBase.IModul modul =null;
foreach (Type item in a.GetTypes())
{
   
    if ((item.GetInterface(typeof(ModulBase.IModul).FullName)) != null)
    {
        object o= item.GetConstructor(new Type[0]).Invoke(null);
        modul = o as ModulBase.IModul;
        break;
    }
}

if (modul != null)
{
    modul.Kiir("alma");
    string valasz = modul.Beolvas("barack");
    Console.WriteLine(valasz);
}
else
{
    throw new Exception("hiba a modulban");
}

Mint látható itt Reflection-t csak a példányosításra használjuk, utána már az interfészünkön keresztül programozzuk a modult.
Halleluja. Mindkét fél élete egyszerű.
De…

(persze lehetne még fokozni, rengeteg egyéb ügyesebb-okosabb, de rosszabb megoldás is van…)

Rengeteg olyan általános probléma van ami minden moduláris alkalmazásnál előjön. Tipikus generikus problémák amikre tipikus generikus válasz adható… Minek feltalálnunk újra a spanyolviaszt?!?!
És mi van ha még a fenti intefész-DLL-t sem akarom odaadni, akarja használni a modul fejlesztője?!?!

Ekkor jön be a MEF-Managed Extensibility Framework, amely választ ad ezen generikus problémákra, ill. előbb-útobb a .Net része lesz, vagyis elfogadottá válik, így máris megvan a “szerződés” a keret- ill. a modul-alkalmazás fejlesztője között…

A témával egyelőre még nem foglalkoztam sokat, de amit láttam eddig az felkeltette az érdeklődésemet, így útjára indítok egy sorozatot, ami sorra veszi szépen a MEF-es fejlesztés mérföldköveit…