Mit dem Aufkommen von Live-Übertragungen und kurzen Videos ist Video zu einer weit verbreiteten Methode zur Ausgabe von Betriebs-/Produktinformationen geworden, da es eine größere Menge an Informationen enthält. Aufgrund der Interessen verschiedener inländischer Browserhersteller haben sie jedoch den Videofunktionen von HTML5 viele Einschränkungen auferlegt, die nicht auf Folgendes beschränkt sind:
Bei spezifischen Fragen lesen Sie bitte „Mobile Terminal Video Mining Implementation of Complex Frame Animation“, geschrieben vom IMWeb-Team von Tencent.
Um diese Probleme zu lösen, haben wir WXInlinePlayer durch Soft-Decodierung von FLV implementiert. Die verwendeten Drittanbieter-Technologien und Plattform-APIs sind wie folgt:
Gleichzeitig haben wir auch die WebAssembly-Version von FLV Demuxer geschrieben. Den entsprechenden Code finden Sie in lib/codec.
Der Kompatibilitätstest verwendet die relevanten Modelle, die vom BrowserStack-Dienst bereitgestellt werden, nur als Referenz:
https://eroszy.github.io/WXInlinePlayer/example/index.html
Bitte stellen Sie sicher, dass Sie packet/emscripten 1.38.45/cmake und make installiert haben, und führen Sie dann den folgenden Befehl aus:
npm install # 初始化工程
npm update # 更新工程有关的插件。如果网络错误,改用 cnpm update
bash build.sh
Das Endprodukt befindet sich im Beispielordner.
Bitte beachten Sie:
- Bitte bauen Sie in einer *nix-Umgebung. Die Kompilierung von OpenH264 unter Windows ist nicht garantiert.
- Bitte stellen Sie sicher, dass emscripten in Version 1.38.45 vorliegt, da sonst wasm32-Fehler auftreten
- Die cmake-Version muss 3.16+ sein
<!DOCTYPE html >
< html >
< head >
< meta charset =" UTF-8 " />
< title > WXInlinePlayer </ title >
< style >
* {
margin: 0;
padding: 0;
}
html,
body {
width: 100%;
height: 100%;
}
</ style >
</ head >
< body >
< canvas id =" container " width =" 800 " height =" 450 " > </ canvas >
< script src =" ./index.js " > </ script >
< script >
if ( WXInlinePlayer . isSupport ( ) ) {
WXInlinePlayer . init ( {
asmUrl : './prod.baseline.asm.combine.js' ,
wasmUrl : './prod.baseline.wasm.combine.js'
} ) ;
WXInlinePlayer . ready ( ) . then ( ( ) => {
const player = new WXInlinePlayer ( {
url : 'https://static.petera.cn/mm.flv' ,
$container : document . getElementById ( 'container' ) ,
hasVideo : true ,
hasAudio : true ,
volume : 1.0 ,
muted : false ,
autoplay : true ,
loop : true ,
isLive : false ,
chunkSize : 128 * 1024 ,
preloadTime : 5e2 ,
bufferingTime : 1e3 ,
cacheSegmentCount : 64 ,
customLoader : null
} ) ;
const { userAgent } = navigator ;
const isWeChat = / MicroMessenger / i . test ( userAgent ) ;
if ( ! isWeChat ) {
alert ( 'click to play!' ) ;
document . body . addEventListener ( 'click' , ( ) => {
player . play ( ) ;
} ) ;
}
} ) ;
}
</ script >
</ body >
</ html >
Geben Sie im Projektstammverzeichnis den Befehl zum Starten des Servers ein:
npm run serve
Geben Sie dann die URL ein, um auf die Demo zuzugreifen:
http://localhost:8888/example/index.html
Ob die aktuelle Ausführungsumgebung WXInlinePlayer unterstützt.
if ( WXInlinePlayer . isSupport ( ) ) {
console . log ( 'WXInlinePlayer support' ) ;
}
Um WXInlinePlayer zu initialisieren, müssen Sie die spezifische Adresse der geladenen H264-Dekodierungsbibliothek übergeben. Informationen zur Auswahl der Dekodierungsbibliothek finden Sie unter: So wählen Sie Dekodierungsabhängigkeiten aus.
if ( WXInlinePlayer . isSupport ( ) ) {
WXInlinePlayer . init ( {
asmUrl : './prod.baseline.asm.combine.js' ,
wasmUrl : './prod.baseline.wasm.combine.js'
} ) . catch ( e => {
console . log ( `WXInlinePlayer init error: ${ e } ` ) ;
} ) ;
}
WXInlinePlayer ist bereit und kann sicher initialisiert werden.
if ( WXInlinePlayer . isSupport ( ) ) {
WXInlinePlayer . init ( { /*.....*/ } ) ;
WXInlinePlayer . ready ( ) . then ( ( ) => {
console . log ( 'WXInlinePlayer ready' ) ;
} ) ;
}
Informationen zum WXInlinePlayer-Konstruktor finden Sie unter: Initialisierungsparameter für verwandte Initialisierungsparameter.
WXInlinePlayer . ready ( ) . then ( ( ) => {
const player = new WXInlinePlayer ( { /*...*/ } ) ;
} ) ;
für die Videowiedergabe. Es ist zu beachten, dass höhere Versionen aufgrund von Browsereinschränkungen (ausgenommen WeChat- und Chrome-Versionen unter 66) die automatische Audiowiedergabe deaktiviert haben, sodass ein direkter Aufruf dieser Methode möglicherweise nicht effektiv ist. Bitte klicken Sie auf/touchstart/touchend/touchmove usw. Lassen Sie Benutzer aktiv Ereignisse auslösen.
document . body . addEventListener ( 'click' , ( ) => {
player . play ( ) ;
} ) ;
Stoppt den gesamten Player und kann nicht fortgesetzt werden.
player . stop ( ) ;
Aktuelle Wiedergabe anhalten.
player . pause ( ) ;
Setzt einen angehaltenen Vorgang fort, der durch eine Pause verursacht wurde.
player . resume ( ) ;
Aktuelle Lautstärke abrufen/einstellen.
const volume = player . volume ( ) ; // get volume
player . volume ( volume ) ; // set volume
Stummschaltungsstatus abrufen/einstellen.
const muted = player . mute ( ) ; // get mute
player . mute ( muted ) ; // set mute
Zerstören Sie den Player und geben Sie den gesamten Speicher zum Recycling frei.
player . destroy ( ) ;
Rufen Sie die aktuelle Wiedergabezeit ab. Bitte beachten Sie, dass es negative Werte geben kann. Gehen Sie daher vorsichtig damit um.
player . on ( 'timeUpdate' , ( ) => {
let currentTime = player . getCurrentTime ( ) ;
currentTime = currentTime <= 0 ? 0 : currentTime ;
} ) ;
Die abspielbare Dauer kann als Pufferungsdauer verstanden werden.
player . on ( 'timeUpdate' , ( ) => {
const duration = player . getAvaiableDuration ( ) ;
} ) ;
Derzeit gibt es drei Sätze von Dekodierungsbibliotheken, nämlich:
Der Unterschied ist:
Wir empfehlen die Verwendung von baseline.asm/baseline.wasm, wenn Sie Werbevideos/Marketingvideos/kleine Animationsvideos abspielen, die auf die Größe der abhängigen Bibliothek reagieren, und es zu verwenden, wenn Sie On-Demand-Videos/Live-Videos abspielen, auf die es nicht ankommt die Größe der abhängigen Bibliothek.
Auf dem Entwicklungscomputer weisen WXInlinePlayer- und FFMpeg-Implementierungen wie Taobao und Huajiao eine ähnliche Speichernutzung und CPU-Auslastung auf. Die Gesamtleistung von WXInlinePlayer ist etwa 5–10 % besser als die FFMpeg-Lösung, während H265 die Deblockierung reduziert hat. Seine Leistung ist etwa 30 % besser als die FFMpeg-Lösung. Im Folgenden finden Sie einen Vergleich der H265-Wiedergabeleistung:
Die Verzögerungen und Verzögerungen von WXInlinePlayer sind hauptsächlich auf drei Ursachen zurückzuführen:
Wenn die Netzwerkumgebung des Benutzers gut ist, verursacht das Rendern mit WebGL im Allgemeinen kaum einen Engpass (der Vorgang ist sehr einfach) und führt im Allgemeinen zu ständigen Einfrierungen und Verzögerungen aufgrund unzureichender Soft-Decodierungsleistung.
Um die durch unzureichende Soft-Dekodierungsleistung verursachte Verzögerung zu optimieren, beginnen wir im Allgemeinen an mehreren Stellen:
Derzeit kann WXInlinePlayer Videos mit einer Auflösung von 1280 x 720, einer Coderate von 1024 und einer Bildrate von 24 Bildern pro Sekunde auf Geräten der mittleren bis oberen Preisklasse relativ reibungslos dekodieren.
Die oben genannten Videoparameter können Sie über FFmpeg anzeigen:
ffmpeg -i " your.flv "
Hier geben wir das Profil/die Bildrate/Coderate/Auflösung der Mainstream-Plattformen als Referenz an:
Plattform | Typ | Klarheit | Profil | Bildrate | Coderate | Auflösung |
---|---|---|---|---|---|---|
Tigerzähne | Horizontaler Bildschirm | SD | Hoch | vierundzwanzig | 500.000 | 800x450 |
Tigerzähne | Horizontaler Bildschirm | HD | Hoch | vierundzwanzig | 1200k | 1280x720 |
Tigerzähne | Vertikaler Bildschirm | HD | Hauptsächlich | 16 | 1280k | 540x960 |
Qixiu | Vertikaler Bildschirm | SD | Hoch | 15 | 307k | 204x360 |
Qixiu | Vertikaler Bildschirm | HD | Hoch | 15 | 512k | 304x540 |
Qixiu | Vertikaler Bildschirm | ultraklar | Grundlinie | 15 | 1440k | 720x1280 |
Tik Tok | Vertikaler Bildschirm | Standard | Hoch | 30 | 1600.000 (weitere Änderungen, nur als Referenz) | 720x1280 |
schneller Arbeiter | Vertikaler Bildschirm | Standard | Hoch | 25 | 2880k (weitere Änderungen, nur als Referenz) | 720x1280 |
Wir empfehlen Ihnen:
Unsere häufig verwendeten Konfigurationsparameter mit geringer Latenz für WXInlinePlayer lauten wie folgt und dienen nur als Referenz. Bitte passen Sie sie entsprechend Ihrer Live-Stream-/On-Demand-Dateikonfiguration an:
{
chunkSize : 128 * 1024 ,
preloadTime : 5e2 ,
bufferingTime : 1e3 ,
cacheSegmentCount : 64 ,
}
Gleichzeitig können Sie das Leistungsereignis verwenden, um die aktuelle Decodierungsleistung zu ermitteln, dann den Benutzer auffordern und auf Ihre Backup-Lösung herunterstufen (z. B. direkte Videowiedergabe/statische Bilder/Sequenzbilder usw.):
player . on ( 'performance' , ( { averageDecodeCost , averageUnitDuration } ) => {
const prop = averageUnitDuration / averageDecodeCost ;
if ( prop >= 2.0 ) {
console . log ( 'good performance' ) ;
} else if ( prop < 2.0 && prop >= 1.0 ) {
console . log ( 'ok, thats fine' ) ;
} else {
console . log ( 'bad performance' ) ;
}
} ) ;
Die FFmpeg-Lösung weist derzeit mehrere große Probleme auf. Das erste ist die Größe der Dekodierungsbibliothek. Nach der Reduzierung beträgt sie etwa 2 MB und gzip ist etwa 600 KB groß. Zweitens ist es schwierig, die Lösung von FFmpeg selbst zu optimieren. Beispielsweise führt WXInlinePlayer in 2.0 eine Mehrfach-Worker-Dekodierung durch, was sehr kostspielig ist, eine solche Lösung zu ändern.
Die Gründe für Verzögerungen und Verzögerungen sind kompliziert. Bei WXInlinePlayer kann die Decodierungsgeschwindigkeit im Allgemeinen nicht mit der Wiedergabegeschwindigkeit mithalten. Bitte lesen Sie, wie Sie Verzögerungen und Verzögerungen reduzieren können.
Sowohl iOS als auch Android UC haben WebAssembly/ASM.js kastriert und unterstützen es daher einfach nicht.
Bitte verwenden Sie FFmpeg oder andere ähnliche Tools. Hier ist ein einfaches Befehlsbeispiel:
ffmpeg -i " your.mp4 " -vcodec libx264 -acodec aac out.flv
Die FLV-Spezifikation von WXInlinePlayer folgt der FLV-Erweiterungsspezifikation von Kingsoft. Wenn Sie eine entsprechende Codierung durchführen müssen, können Sie auf den zugehörigen FFmpeg-Patch oder den von Kingsoft geschriebenen Encoder zurückgreifen.