| |||||||
Du magst keine Werbung? Wir auch nicht!
Einfach registrieren und die Werbung ist weg. Diese Nachricht sehen nur nicht registrierte Nutzer.
![]() |
| | LinkBack | Themen-Optionen | Ansicht |
| | #1 (permalink) |
| ComeFlashSome Registriert seit: Jan 2006
Beiträge: 145
| netStream.seek() Problem
Hallo, da seekToNavCuePoint() ja nur mit der flvPlayBack-Componente funktioniert, und nicht mit netStream, habe ich NavigationCuePoints bisher über netStream.seek(time) aufgerufen. Nun habe ich aber folgendes Problem: Wenn ich direkt nach dem Start des Videos zu einem CuePoint springen will, dann "landet" die seek(time)-Methode immer irgendwo vorher (vor "time") und immer irgendwo anders auch wenn "time" gleich ist. Es scheint von der Netzwerk-Geschwindigkeit abzuhängen. Kann die seek-Methode nur CuePoints aufrufen, die innerhalb der netStream.bufferLength liegen? Das fände ich seltsam, denn dafür werden doch die Navigation-CuePoints als iFrame angelegt, um sie direkt aufrufen zu können, auch wenn der vorangehende Videoabschnitt noch nicht geladen wurde. Kennt jemand das Problem? Gibt es eine Alternative zur seek(time)-Methode? Bräuchte eine Lösung in der das Video über NetStream geladen wird, hauptsächlich, weil ich alle meine Klassen schon danach ausgerichtet habe. Bitte sagt mir, das das geht |
| | |
| | #2 (permalink) |
| ComeFlashSome Registriert seit: Jan 2006
Beiträge: 145
| Weitere Versuche
Ich habe jetzt folgenden Lösungsansatz (vorläufig): Bevor NetStream.seek(offset) aufgerufen wird, überprüfe ich, ob NetStream.time (aktuelle Abspielposition) plus netStream.bufferLength größer sind, als der gewünschte "offset". Wenn ja, dann wird einfach netStream.seek(offset) aufgerufen, wenn nicht setzte ich netStream.bufferTime auf die Differenz, überprüfe mit einem Preloader den Status von netStream.bufferLength und löse dann netStream.seek(offset) erst aus, wenn "offset" innerhalb der netStream.bufferLength liegt. Das funktioniert, ist aber erstens irgendwie unelegant und scheint auch nicht die korrekte Lösung zu sein. Denn ich habe herausgefunden, dass der Buffer wohl nicht für den Erfolg von netStream.seek(time) verantwortlich ist. Ich kann seltsamer Weise manche Cuepoints bzw. deren Zeit auch "anspringen" bevor sie innerhalb der netStream.bufferLength liegen. Hat irgendjemand ne Ahnung was ich falsch mache? Wovon hängt es ab, ob netStream.seek(time) Erfolg hat oder nicht? |
| | |
![]() |
| Lesezeichen |
| Themen-Optionen | |
| Ansicht | |
| |