WXInlinePlayer
1.3.6
Com o aumento das transmissões ao vivo e dos vídeos curtos, o vídeo tornou-se um método muito comum de transmissão de informações operacionais/de produtos porque transporta uma maior quantidade de informações. No entanto, devido aos interesses de vários fabricantes nacionais de navegadores, eles impuseram muitas restrições aos recursos de vídeo do HTML5, que não se limitam a:
Para perguntas específicas, consulte "Implementação de mineração de vídeo em terminal móvel de animação de quadro complexo" escrito pela equipe IMWeb da Tencent.
Para resolver esses problemas, implementamos o WXInlinePlayer por meio de decodificação suave de FLV. A tecnologia de terceiros e a API da plataforma usadas são as seguintes:
Ao mesmo tempo, também escrevemos a versão WebAssembly do FLV Demuxer. Você pode encontrar o código relevante em lib/codec.
O teste de compatibilidade usa os modelos relevantes fornecidos pelo serviço BrowserStack, apenas para referência:
https://eroszy.github.io/WXInlinePlayer/example/index.html
Certifique-se de ter instalado o pacote/emscripten 1.38.45/cmake e o make e execute o seguinte comando:
npm install # 初始化工程
npm update # 更新工程有关的插件。如果网络错误，改用 cnpm update
bash build.shO produto final estará na pasta de exemplo.
Observe:
- Por favor, construa em um ambiente *nix. A compilação do OpenH264 no Windows não é garantida.
- Certifique-se de que o emscripten esteja na versão 1.38.45, caso contrário, ocorrerão erros de wasm32.
- a versão do cmake precisa ser 3.16+
<!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 >No diretório raiz do projeto, digite o comando para iniciar o servidor:
npm run serveEm seguida, insira o URL para acessar a demonstração:
http://localhost:8888/example/index.html
Se o ambiente de execução atual oferece suporte a WXInlinePlayer.
if ( WXInlinePlayer . isSupport ( ) ) {
console . log ( 'WXInlinePlayer support' ) ;
}Para inicializar o WXInlinePlayer, você precisa passar o endereço específico da biblioteca de decodificação H264 carregada. Para a seleção da biblioteca de decodificação, consulte: Como escolher dependências de decodificação.
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 está pronto e pode ser inicializado com segurança.
if ( WXInlinePlayer . isSupport ( ) ) {
WXInlinePlayer . init ( { /*.....*/ } ) ;
WXInlinePlayer . ready ( ) . then ( ( ) => {
console . log ( 'WXInlinePlayer ready' ) ;
} ) ;
}Construtor WXInlinePlayer, consulte: Parâmetros de inicialização para parâmetros de inicialização relacionados.
WXInlinePlayer . ready ( ) . then ( ( ) => {
const player = new WXInlinePlayer ( { /*...*/ } ) ;
} ) ;para reprodução de vídeo. Deve-se observar que, devido às limitações do navegador (excluindo as versões WeChat e Chrome abaixo de 66), as versões superiores desativaram a reprodução automática de áudio, portanto, chamar esse método diretamente pode não ser eficaz. Clique/touchstart/touchend/touchmove, etc. desencadear eventos ativamente.
document . body . addEventListener ( 'click' , ( ) => {
player . play ( ) ;
} ) ;Pára o player inteiro e não pode ser retomado.
player . stop ( ) ;Pausar a reprodução atual.
player . pause ( ) ;Retoma uma operação pausada causada por uma pausa.
player . resume ( ) ;Obtenha/defina o volume atual.
const volume = player . volume ( ) ; // get volume
player . volume ( volume ) ; // set volumeObtenha/defina o status mudo.
const muted = player . mute ( ) ; // get mute
player . mute ( muted ) ; // set muteDestrua o player e libere toda a memória para reciclagem.
player . destroy ( ) ;Obtenha o tempo de reprodução atual. Observe que pode haver valores negativos, portanto, manuseie-os com cuidado.
player . on ( 'timeUpdate' , ( ) => {
let currentTime = player . getCurrentTime ( ) ;
currentTime = currentTime <= 0 ? 0 : currentTime ;
} ) ;A duração jogável pode ser entendida como a duração do buffer.
player . on ( 'timeUpdate' , ( ) => {
const duration = player . getAvaiableDuration ( ) ;
} ) ; Existem atualmente 3 conjuntos de bibliotecas de decodificação, a saber:
A diferença é:
Recomendamos o uso de baseline.asm/baseline.wasm ao reproduzir vídeos publicitários/vídeos de marketing/pequenos vídeos de animação que são sensíveis ao tamanho da biblioteca dependente e usá-lo ao reproduzir vídeos sob demanda/vídeos ao vivo que não são sensíveis a o tamanho da biblioteca dependente all.asm/all.wasm.
Na máquina de desenvolvimento, para o mesmo vídeo, as implementações WXInlinePlayer e FFMpeg, como Taobao e Huajiao, têm uso de memória e uso de CPU semelhantes. O desempenho geral do WXInlinePlayer é cerca de 5-10% melhor do que a solução FFMpeg, enquanto o H265 reduziu o desbloqueio. Seu desempenho é cerca de 30% melhor que a solução FFMpeg. A seguir está uma comparação do desempenho de reprodução do H265:
Os atrasos e atrasos do WXInlinePlayer vêm principalmente de três lugares:
De modo geral, se o ambiente de rede do usuário for bom, é difícil causar gargalos devido ao uso de WebGL na renderização (a operação é muito simples), o que geralmente causa atrasos e atrasos constantes devido ao desempenho insuficiente da decodificação suave.
Para otimizar o atraso causado pelo desempenho insuficiente da decodificação suave, geralmente começamos de vários lugares:
Atualmente, o WXInlinePlayer pode decodificar vídeos de 1280x720, taxa de código de 1024 e taxa de quadros de 24fps em máquinas de médio a alto padrão de forma relativamente suave.
Em relação aos parâmetros de vídeo mencionados acima, você pode visualizá-los através do FFmpeg:
ffmpeg -i " your.flv "Aqui fornecemos o perfil/taxa de quadros/taxa de código/resolução das plataformas principais para referência:
| plataforma | tipo | clareza | perfil | Taxa de quadros | Taxa de código | resolução |
|---|---|---|---|---|---|---|
| Dentes de tigre | Tela horizontal | SD | Alto | vinte e quatro | 500 mil | 800x450 |
| Dentes de tigre | Tela horizontal | alta definição | Alto | vinte e quatro | 1200 mil | 1280x720 |
| Dentes de tigre | Tela vertical | alta definição | Principal | 16 | 1280 mil | 540x960 |
| Qi Xiu | Tela vertical | SD | Alto | 15 | 307 mil | 204x360 |
| Qi Xiu | Tela vertical | alta definição | Alto | 15 | 512 mil | 304x540 |
| Qi Xiu | Tela vertical | ultra claro | Linha de base | 15 | 1440 mil | 720x1280 |
| Tik Tok | Tela vertical | padrão | Alto | 30 | 1600k (mais alterações, apenas para referência) | 720x1280 |
| trabalhador rápido | Tela vertical | padrão | Alto | 25 | 2880k (mais alterações, apenas para referência) | 720x1280 |
Recomendamos você:
Nossos parâmetros de configuração de baixa latência comumente usados do WXInlinePlayer são os seguintes, apenas para referência. Ajuste-os de acordo com sua configuração de arquivo de transmissão ao vivo/sob demanda:
{
chunkSize : 128 * 1024 ,
preloadTime : 5e2 ,
bufferingTime : 1e3 ,
cacheSegmentCount : 64 ,
}Ao mesmo tempo, você pode usar o evento de desempenho para determinar o desempenho de decodificação atual e, em seguida, solicitar ao usuário e fazer o downgrade para sua solução de backup (como reprodução direta de vídeo/imagens estáticas/quadros de sequência, etc.):
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' ) ;
}
} ) ; A solução FFmpeg atualmente tem vários problemas importantes. O primeiro é o tamanho da biblioteca de decodificação. Após a redução, é de cerca de 2M e o gzip é de cerca de 600k. Em segundo lugar, a solução do FFmpeg é difícil de otimizar por conta própria. Por exemplo, o WXInlinePlayer fará a decodificação de vários trabalhadores no 2.0, o que é muito caro para modificar tal solução.
As razões para atrasos e atrasos são complicadas. Para WXInlinePlayer, a velocidade de decodificação geralmente não consegue acompanhar a velocidade de reprodução.
Tanto o iOS quanto o Android UC castraram o WebAssembly/ASM.js, então eles simplesmente não o suportam.
Use FFmpeg ou outras ferramentas semelhantes. Aqui está um exemplo de comando simples:
ffmpeg -i " your.mp4 " -vcodec libx264 -acodec aac out.flvA especificação FLV do WXInlinePlayer segue a especificação de expansão FLV da Kingsoft. Se precisar executar a codificação relacionada, você pode consultar o patch FFmpeg relacionado ou o codificador escrito pela Kingsoft.
