Re: Add "MediaStream with worker" for video processing into the new working items of WebRTC WG

[Clearing most of the CC list]

I feel very strongly that we should not support transferring MediaStreams
or MediaStreamTracks, especially across Workers. That would add great
complexity to the Gecko MediaStream and WebAudio implementations. Martin
already mentioned the multiprocess issue. Another issue is that proper
memory management for WebAudio nodes and MediaStream(Tracks), e.g. to
garbage-collect nodes, media elements or streams that are no longer
relevant, is already quite difficult, and extending that across thread
boundaries would be a nightmare. I much prefer alternatives like
Chia-Hung's current proposal, which don't require that.

Note: as Martin also mentioned, supporting WebAudio or even MediaStreams in
a worker is not itself much of a problem, if we want to do that. The key is
that all connected nodes and streams should be associated with the same
Worker or window.

As for backpressure, as I understand it, Chia-Hung's proposal does support
a form of backpressure. If a video processing or monitoring callback is
still processing frame N when frame N+1 becomes available, frame N+1 is
queued until the callback completes, but the queue only has length 1, so if
frame N+2 arrives while N is still being processed, frame N+1 is
effectively dropped.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn

Received on Tuesday, 28 July 2015 11:06:08 UTC