Ping folks, any opinions?

I don't have a strong opinion and both make sence. But I think audio input devices and video input devices should be in the same structure.

[triage]

On #2: audio and video are in separate folders of media
right now, and they are compiled/linked in separate
.so (/.dll/.dylib/etc). They also have separate unit tests 
(capture_unittests versus media_unittests and audio_unittests). 
Moreover, with the blocked-on bug https://crbug.com/584797,
video/content capture will become a mojo "app" of sorts so,
effectively, audio and video capture are very separate 
entities. FTR I have proposed and encouraged to bring audio
capture together with the content/video capture code, with
not much success so far :)

Ping guys.

Started working on it on https://codereview.chromium.org/2143903003

+Dale

For audio, the capture and rendering code has things in common.  Is the intention to move the audio rendering code to device as well?

#6: in due time, and if it makes sense with the audio
capture Owners, I'd be totally in favour of it. Also,
I understand there is an effort underway to mojify 
audio capture [1], so it all would make sense to me. 

This particular issue deals with media/capture --> 
device/capture, and that encompasses on ToT video 
capture from devices and content (screen, apps and tabs).

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=606707

If //device is the new home for things interacting with OS level hardware, I don't have anything against relocation. //device feels a bit nebulous, but if that ship has already sailed, I digress.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/14a3cda4337f498d01ccbf897884f343ee099805

commit 14a3cda4337f498d01ccbf897884f343ee099805
Author: mcasas <mcasas@chromium.org>
Date: Thu Jul 14 20:13:06 2016

Minor cleanups in media/s BUILD.gns and media/capture files

This CL:
- removes some unnecessary dependencies, following
up on a TODO
- removes unnecessary include and MEDIA_EXPORT
in recently landed code
- correct photo_capabilities.h header guard

BUG= 626125 ,  618718 
TEST=No new coded added, if it compiles, is good.

Review-Url: https://codereview.chromium.org/2148583003
Cr-Commit-Position: refs/heads/master@{#405553}

[modify] https://crrev.com/14a3cda4337f498d01ccbf897884f343ee099805/content/browser/BUILD.gn
[modify] https://crrev.com/14a3cda4337f498d01ccbf897884f343ee099805/media/base/BUILD.gn
[modify] https://crrev.com/14a3cda4337f498d01ccbf897884f343ee099805/media/capture/BUILD.gn
[modify] https://crrev.com/14a3cda4337f498d01ccbf897884f343ee099805/media/capture/content/android/screen_capture_jni_registrar.h
[modify] https://crrev.com/14a3cda4337f498d01ccbf897884f343ee099805/media/capture/content/android/screen_capture_machine_android.h
[modify] https://crrev.com/14a3cda4337f498d01ccbf897884f343ee099805/media/capture/video/android/photo_capabilities.h
[modify] https://crrev.com/14a3cda4337f498d01ccbf897884f343ee099805/media/gpu/BUILD.gn

This is happening in https://codereview.chromium.org/2214533002/

Re. #10, I had a conversation with other TLDs and reillyg@ and, essentially,
the latter explained that //device/ should aim for wrapping _only_ OS/hardware 
functionality, and since capture/ uses e.g. libyuv and other media/ functions, 
that seems too large for its scope. 

In parallel, chfremer@ had been querying around and it seems like his effort
for turning video_capture into a mojo service (implementation) guided him to
//services/image_capture, so for the time being, I'll put the CL linked in 
#10 in ice, let chfremer@ work on, and when there's enough critical mojo-mass
in //services/video_capture, move //media/capture code into it. SG?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c41614771c0e7efac7971738c81d05118cc31709

commit c41614771c0e7efac7971738c81d05118cc31709
Author: mcasas <mcasas@chromium.org>
Date: Wed Aug 10 23:29:08 2016

Move device monitors out of //media/capture into //media/device_monitors

This is (another) preparation CL for the linked bug. Device monitors are
in capture/ for unknown reasons but they don't belong there, since they
effectively monitor all audio and video devices in the system. Folders
are cheap, so I moved them out, further clearing the way for moving
//media/capture around, and paves the way to reusing functionality that
is now in //device.

BUG= 626125 

NOPRESUBMIT=true (this CL has the necessary LGTMs but
it hits an incorrect git cl format media presubmit check).

Review-Url: https://codereview.chromium.org/2224643002
Cr-Commit-Position: refs/heads/master@{#411181}

[modify] https://crrev.com/c41614771c0e7efac7971738c81d05118cc31709/content/browser/browser_main_loop.cc
[modify] https://crrev.com/c41614771c0e7efac7971738c81d05118cc31709/content/browser/renderer_host/media/media_stream_manager.cc
[modify] https://crrev.com/c41614771c0e7efac7971738c81d05118cc31709/media/BUILD.gn
[modify] https://crrev.com/c41614771c0e7efac7971738c81d05118cc31709/media/capture/BUILD.gn
[rename] https://crrev.com/c41614771c0e7efac7971738c81d05118cc31709/media/device_monitors/device_monitor_mac.h
[rename] https://crrev.com/c41614771c0e7efac7971738c81d05118cc31709/media/device_monitors/device_monitor_mac.mm
[rename] https://crrev.com/c41614771c0e7efac7971738c81d05118cc31709/media/device_monitors/device_monitor_udev.cc
[rename] https://crrev.com/c41614771c0e7efac7971738c81d05118cc31709/media/device_monitors/device_monitor_udev.h
[rename] https://crrev.com/c41614771c0e7efac7971738c81d05118cc31709/media/device_monitors/system_message_window_win.cc
[rename] https://crrev.com/c41614771c0e7efac7971738c81d05118cc31709/media/device_monitors/system_message_window_win.h
[rename] https://crrev.com/c41614771c0e7efac7971738c81d05118cc31709/media/device_monitors/system_message_window_win_unittest.cc

Won't have time to work on this, so passing it over to chfremer@.

Now that some of the dust has settled after the refactoring work for the video capture service, we have the following situation:

media/capture: Video capture code that is not specific to the video capture service or the browser or renderers. This code is used by both the video capture service and the browser (and probably by renderer code as well).

services/video_capture: Code that is specific to the video capture service. This code depends on media/capture.

This situation seems acceptable to me. Even though there is not too much coherency between media/capture and the rest of media/*, this seems like an okay place for this low-level video capture library code. Until we reach a point where the video capture service becomes the only consumer of this code, I feel it is best to leave it in media/capture.

=> Closing as WontFix. Let us reopen when needed.