Ottieni latenza simile a webrtc con ffmpeg?

Lo sto usando tra Chrome e il mio telefono:

http://www.webrtc.org/demo

E la latenza è davvero buona - meno di 1 secondo.

Ho provato a replicarlo sul mio computer senza successo.

ffmpeg -f video4linux2 -i /dev/video0  -s 320x200 -r 50 -deadline realtime -vcodec libvpx -f webm -fflags nobuffer udp://10.0.0.55:9002

E poi usando ffplay dall'altra parte.

Ha ancora un paio di secondi di ritardo.

Alla fine mi piacerebbe trasmettere in streaming dal mio computer al telefono Android, ma la latenza deve essere buona.

Modifica : funziona molto meglio. Se potessi radermi un po 'di questo, sarei felice:

ffmpeg -vcodec rawvideo -f video4linux2 -i /dev/video0  -s 320x200 -r 25 -vcodec libvpx -f rtp -deadline realtime rtp://10.0.0.55:9002

ffmpeg video-streaming

— David N. Welton
fonte

Il link è morto. Fondamentalmente vuoi convertire video e trasmetterlo in streaming sul tuo telefono? Su wifi o esterno?

— jiggunjer,

Quello che voglio fare è lo streaming da una videocamera collegata a un dispositivo e farlo apparire su un tablet Android (Nexus 10) collegato tramite USB.

— David N. Welton,

Non so molto su questi codec ma hai verificato che sono accelerati dall'hardware, ove possibile? Sarebbe la mia ipotesi sul motivo per cui vedi più di 1 secondo di latenza.

— snoopen,

vpx sarà difficile da chiudere in tempo reale, so che x264 ha una melodia "bassa latenza" o qualcosa del genere FWIW

— rogerdpack

Il problema è principalmente dovuto al fatto che si sta utilizzando la transcodifica software anziché la transcodifica hardware .

Come regola generale, se la conversione utilizza l'accelerazione hardware, la latenza sarà di ordine inferiore al secondo (in genere millisecondi). Se viene eseguito nel software, la latenza sarà dell'ordine di più di un secondo.

FFmpeg supporta l'accelerazione hardware, ma di solito è difficile farlo funzionare per te.

https://trac.ffmpeg.org/wiki/HWAccelIntro

D'altra parte, Google Chrome supporta la codifica / decodifica hardware VP8 e H264 (dove è disponibile), sia sul tuo computer che sul tuo telefono Android:

http://code.google.com/p/chromium/issues/detail?id=428223

— HO1
fonte

Non si tratta solo di accelerazione hardware ... la configurazione del codec gioca un ruolo molto più ampio nella latenza. Il codec deve essere ottimizzato per mantenere bassa la latenza, a scapito della qualità e della larghezza di banda. Questo può essere fatto indipendentemente dal fatto che tu stia utilizzando codec con accelerazione hardware.

— Brad,

Questo link dice specificamente che Chrome NON supporta la codifica hardware sul desktop, SOLO su Android.

— davr

Ci dispiace ma Brad ha ragione, la risposta è totalmente sbagliata: finché imposti le stesse impostazioni del codec, non c'è alcuna differenza se esegui la codifica hardware o software (purché tu abbia abbastanza potenza della CPU per eseguire la codifica in tempo reale con il tuo impostazioni del codec). Corretto è che non si tratta solo delle impostazioni del codec video, ma soprattutto del tipo di trasporto e comportamento di buffering del decoder. WebRTC funziona perché è ottimizzato per la bassa latenza. Il tipico decodificatore Webm non ha lo scopo di eseguire la bassa latenza

— Harry