Verbeteringen voor netwerkinteractie

Wanneer u media-inhoud op mobiele apparaten laadt, kunnen er problemen optreden die u bijna nooit zou verwachten op een bureaubladcomputer. U kunt bijvoorbeeld sneller zonder schijfruimte of geheugen raken. Als u video laadt, downloaden de desktopversie van Flash Player 10.1 en AIR 2.5 het volledige FLV-bestand (of MP 4-bestand) naar de harde schijf en slaan dit bestand in het cachegeheugen op. Vervolgens speelt de runtime de video af vanuit het cachebestand. Het komt niet vaak voor dat er onvoldoende ruimte op de harde schijf beschikbaar is. Als dit wel het geval is, stopt de desktop het afspelen van de video.

Op een mobiel apparaat is de schijfruimte eerder op. Als het apparaat onvoldoende schijfruimte heeft, stopt de runtime het afspelen niet, zoals bij de desktop. In plaats daarvan gebruikt de runtime het cachebestand opnieuw door vanaf het begin van het bestand opnieuw naar dit bestand te schrijven. De gebruiker kan doorgaan met het bekijken van de video. De gebruiker kan niet zoeken in het gebied van de video waarnaar opnieuw is geschreven behalve het begin van het bestand. Cyclische buffering wordt niet standaard gestart. Het kan worden gestart tijdens het afspelen en ook aan het begin van het afspelen als de film groter is dan de beschikbare schijfruimte of RAM-geheugen. De runtime heeft ten minste 4 MB RAM of 20 MB schijfruimte nodig om cyclische buffering te kunnen gebruiken.

Als ontwikkelaar moet u er rekening mee houden dat zoeken alleen werkt binnen de grenzen van de stream in cache. NetStream.seek() mislukt soms als de verschuiving zich buiten het bereik bevindt. In dit geval wordt een NetStream.Seek.InvalidTime -gebeurtenis verzonden.

In Flash Player 10.1 en AIR 2.5 wordt een nieuw gedrag met de naam slim zoeken geïntroduceerd om de gebruikerservaring bij het afspelen van streaming video te verbeteren. Als de gebruiker een bestemming zoekt binnen de grenzen van de buffer, gebruikt de runtime de buffer opnieuw om onmiddellijk zoeken mogelijk te maken. In eerdere versies van de runtime werd de buffer niet opnieuw gebruikt. Als een gebruiker bijvoorbeeld een video afspeelt van een streaming server en de buffertijd is ingesteld op 20 seconden ( NetStream.bufferTime ) en de gebruiker heeft geprobeerd 10 seconden vooruit te zoeken, gooit de runtime alle buffergegevens weg in plaats van de reeds geladen 10 seconden opnieuw te gebruiken. Dit gedrag dwingt de runtime om vaker nieuwe gegevens van de server op te vragen en leidt bij trage verbindingen tot een matige afspeelkwaliteit.

De onderstaande afbeelding illustreert hoe de buffer in de vorige versie van de runtime werkte. De eigenschap bufferTime geeft het aantal seconden aan dat vooruit en vooraf wordt geladen, zodat de buffer kan worden gebruikt zonder dat de video wordt gestopt als de verbinding wegvalt.

Buffergedrag vóór de functie slim zoeken

Met de functie slim zoeken gebruikt de runtime nu de buffer om onmiddellijk achteruit of vooruit te zoeken wanneer de gebruiker de video versleept. In de volgende afbeelding wordt dit nieuwe gedrag geïllustreerd:

Vooruit zoeken met de functie slim zoeken

Achteruit zoeken met de functie slim zoeken

Slim zoeken gebruikt de buffer opnieuw wanneer de gebruiker vooruit of achteruit zoekt zodat het afspelen sneller en vlotter verloopt. Een van de voordelen van dit nieuwe gedrag is het besparen van bandbreedte voor video-uitgevers. Als het zoeken echter buiten de grenzen van de buffer wordt uitgevoerd, treedt het standaardgedrag op en vraagt de runtime nieuwe gegevens aan bij de server.

Om slim zoeken in te schakelen stelt u NetStream.inBufferSeek in op true .