Anything non-fatal should be WARNING/INFO

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

commit 0cb34a438629ab962aa2e74b26e0894935c81b94
Author: Xiaohan Wang <xhwang@chromium.org>
Date: Thu May 17 02:29:27 2018

media: Add MEDIALOG_WARNING

Add a new MediaLog level so that we don't have to abuse MEDIALOG_ERROR,
which could end up in MediaError.message and should be carefully used.

Also update documentation on MediaLog levels.

Also use MEDIALOG_WARNING in audio_timestamp_validator.cc for non-fatal
issues.

Bug: 843808
Test: Manually tested and verified in about://media-internals
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
Change-Id: I20350d305b3f55d1f59e6d2324cc3be7452bcbbe
Reviewed-on: https://chromium-review.googlesource.com/1063009
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Xiaohan Wang <xhwang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#559399}
[modify] https://crrev.com/0cb34a438629ab962aa2e74b26e0894935c81b94/media/README.md
[modify] https://crrev.com/0cb34a438629ab962aa2e74b26e0894935c81b94/media/base/media_log.cc
[modify] https://crrev.com/0cb34a438629ab962aa2e74b26e0894935c81b94/media/base/media_log.h
[modify] https://crrev.com/0cb34a438629ab962aa2e74b26e0894935c81b94/media/base/media_log_event.h
[modify] https://crrev.com/0cb34a438629ab962aa2e74b26e0894935c81b94/media/filters/audio_timestamp_validator.cc

Given the fact that MediaError.message is web developer facing, we probably should try to standardize or stabilize the strings that could appear in  MediaError.message. Currently it's all buried in the code base, which is hard to find and track. Also they are subject to change by developers making changes.

How about we have a media/base/media_error.h/cc defining a list of strings that could appear in MediaError.message, and make sure MEDIA_LOG(ERROR) can only use strings defined in that file?

Hmm, I didn't really want to do that for the messages since it becomes a maintenance pain. I'm not totally against it though, so if there's consensus this would be easier we can go that route.

wolenetz: Any thoughts on this?

I agree with the maintenance pain, but it does provide some nice benefits:
- We could report UMA/UKM metrics about the error reason.
- A stabler error list will make it easier for web developers to track specific errors, and report issues, than strings scattered in the code base.

I like making at least the ERROR log messages centralized. That'd be a step towards ensuring stronger review of MEDIALOG_ERROR messages that can become populated in the MediaError.message, which is visible to web apps.

Note that MediaError.message contains more than what is logged in the first (if any) MEDIA_LOG(ERROR,...) prior to the MediaError object's construction (eg. pipeline status). I assume we're talking about centralizing the actual set of "msg.." currently scattered in our code in various MEDIA_LOG(ERROR, "msg.."), right?

Also, sandersd@ and I had long ago discussed maybe taking up work on something like #3/#6. #5 adds more motivation.

Yes, I was proposing to centralize the messages in MEDIA_LOG(ERROR, "msg..").

Now since we are on this topic, I wonder whether we can populate a error message on callbacks that can cause playback failure, e.g. PipelineStatusCB, such that we don't have to rely on MEDIA_LOG(ERROR) at all. I felt there's always a possibility that there'll be a mismatch between the pipeline status and the MEDIA_LOG(ERROR) message...

BTW, I won't be able to work on this any time soon. Feel free to take this bug from me if you are interested :)

Re-titling to reflect bug discussion since #3.

Per #9, => available.