Simeon / Frank, could you please help to take care of this? Thanks.

i added a check for this flag to media/gpu recently.  i'll remove that to
unblock the rest of it.

after that, i'm not sure how the flag gets set on ATV, so sanfin@ might
have to drive it from there.

ddorwin: since your example uses base::FeatureList, and we use that in wmpi already, would you object to avoiding the setter on wmpi and just checking the feature where wmpi now checks the command line?  not sure i see the value in the added indirection.

also, we could do a similar thing in the gpu process.  else, we have to plumb the value that wmpi is given in the setter down to gpu, which is quite ugly now that i've tried it.  :)

The example I referred to uses the FeatureList in content/ to obtain the value to pass to a WMPI setter.

FeatureList seems intended for features that can be enabled/disabled and are generally intended to be enabled by default in the future. From a code organization perspective, they are essentially just global variables like base::CommandLine. However, it seems like we've decided to accept a certain set of these (media/base/media_switches.h). For short-term uses, this may make sense to avoid piping a parameter through temporarily.

As I noted in the original report, this is used by certain embedder(s), so it probably makes sense for them to just pass the correct value at construction rather than adding another global variable and implying that it may be set in some cases on all platforms.

i put out a cl for this a while ago, but, if i remember, there wasn't consensus on how it should be done.  unassigning.