Use AVCaptureAudioPreview and AVCaptureVideoPreviewLayer for previewing audio and video when possible.
<rdar://problem/29297727>
Created attachment 294988 [details] Proposed patch.
Created attachment 294991 [details] Updated patch.
Created attachment 294995 [details] Updated patch.
Comment on attachment 294995 [details] Updated patch. View in context: https://bugs.webkit.org/attachment.cgi?id=294995&action=review r=me with minor nit. > Source/WebCore/platform/mediastream/MediaStreamTrackPrivate.cpp:185 > +RealtimeMediaSourcePreview* MediaStreamTrackPrivate::preview() > +{ > + if (m_preview) > + return m_preview.get(); > + > + m_preview = m_source->preview(); > + return m_preview.get(); > +} > + Is there any reason to cache the value of m_source->preview() at this level? m_source can never change, but it may want to swap out the preview layer (in some future patch), and caching this here would make that harder.
(In reply to comment #5) > Comment on attachment 294995 [details] > Updated patch. > > View in context: > https://bugs.webkit.org/attachment.cgi?id=294995&action=review > > r=me with minor nit. > > > Source/WebCore/platform/mediastream/MediaStreamTrackPrivate.cpp:185 > > +RealtimeMediaSourcePreview* MediaStreamTrackPrivate::preview() > > +{ > > + if (m_preview) > > + return m_preview.get(); > > + > > + m_preview = m_source->preview(); > > + return m_preview.get(); > > +} > > + > > Is there any reason to cache the value of m_source->preview() at this level? > m_source can never change, but it may want to swap out the preview layer (in > some future patch), and caching this here would make that harder. I will commit this patch as-is, but we can talk about changing this in another patch.
Comment on attachment 294995 [details] Updated patch. Clearing flags on attachment: 294995 Committed r208851: <http://trac.webkit.org/changeset/208851>
All reviewed patches have been landed. Closing bug.