dbedouillat@ -- Thanks for reporting this issue. Could you please provide the sample application supporting Android and iOS where the issue can be reproduced. This would help us in further triaging the issue.

As per the GIT blame results for the file packet_buffer.cc, 
CL: https://webrtc.googlesource.com/src.git/+/675513b96a7a1c79528a5f93099e4c21bb9acf53

and 

As per the GIT blame results for the file webrtcvideoengine.cc, CC'ing mbonadei@
CL: https://webrtc.googlesource.com/src.git/+/d4fcfb8ba14a70be73e708aa9a1d8992c0af0157

mbonadei@ -- Could you please look into this issue.



Thanks!

I don't think my commit is related (it is just switching from LOG to RTC_LOG).
I have no context on media/engine/webrtcvideoengine.cc. Magnus, can you take a look anr/or re-assign?

I have put the sample Android application on a github repository :
https://github.com/bedouillat/testWebRTC

The application can test VP8 or H264 loopback webrtc using the AppRTC features

It can also test a real WebRTC from Android to a IOS browser (see README)

Thank you for providing more feedback. Adding requester "pnangunoori@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

dbedouillat@ -- Thanks for providing the test link. Below are my observations by navigating to the URL: https://github.com/bedouillat/testWebRTC on Chrome #63.0.3239.111 and Chrome Canary #65.0.3323.3 on SM-J710F Android 7.0.0 Build/NRD90M.

Steps Followed:
1. Launched the Chrome browser.
2. Navigated to the URL provided: https://appr.tc/r/roomid?vrc=VP8&debug=loopback&vsc=VP8 and observed that user is able to see himself and same voice is repeated.
3. Navigated to the URL provided: https://appr.tc/r/roomid?vrc=H264&debug=loopback&vsc=H264 and observed that user is able to see himself and same voice is repeated.
4. Navigated to the URL provided: https://appr.tc/r/roomid and observed '404 Not Found' error.

Please look into the above observations and let us know if we have missed anything or please share the screencast to reproduce the issue.

Thanks in advance!

Maybe my explanations were not clear enough, sorry

Opening https://appr.tc/r/<myroomid>?vrc=H264&debug=loopback&vsc=H264 in Chrome Canary #65 will actually work

(please note that <myroomId> must be replaced by your own room name)

But opening this url in a webview, rendered by Chrome Canary #65 will fail

I have put on github the application code that embeds this webview : https://github.com/bedouillat/testWebRTC (I can also provide you the apk)

Best regards

Thank you for providing more feedback. Adding requester "pnangunoori@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

dbedouillat@ -- could you please provide the APK file which will reproduce the issue. That would really help us.

Thanks!

Here is my apk file

You have to install it on an Android 7+ device, with Chrome Canary 65 installed and after having set "use Chrome Canary" in Android Parameters / Developer options / Webview

To use it :
- define your room name in the edit text (default is roomid)
- click on "LOAD H264 LOOPBACK" button to reproduce the bug on loopback (URL used will be "https://appr.tc/r/%s?vrc=H264&debug=loopback&vsc=H264") then click on "Join" button
- button "LOAD VP8 LOOPBACK" allows to check that it is working in VP8 (URL used will be "https://appr.tc/r/%s?vrc=VP8&debug=loopback&vsc=VP8")
- button LOAD P2P allows to make the test with another device (who will have to open the "https://appr.tc/r/%s" url on his web browser)
- button "LOAD MP4" allows to check that a MP4 video can be read on the webview  (URL used is "http://techslides.com/demos/sample-videos/small.mp4")

Apk source code is available on https://github.com/bedouillat/testWebRTC if you want to check webview parameters

Thanks
 

Deleted: app-debug.apk 1.5 MB

app-debug.apk 1.5 MB Download

Thank you for providing more feedback. Adding requester "pnangunoori@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

cc'ing webrtc PoC for android - do you have any idea why this doesn't work?

Assigning owner to make sure this isn't forgotten. Feel free to reassign if appropriate.

dbedouillat@ -- Tried to reproduce the issue by following the below steps on SM-J710F Android 7.0.0 Build/NRD90M using latest Canary #66.0.3328.0:

1. In the device settings, update the WebView implementation to Chrome Canary.
2. Install the test APK file provided in C#10.
3. Launch the application and update the "Room ID".
4. Tried to open the respective link on iPhone with iOS 11 on Chrome browser to setup a video call: "https://appr.tc/r/%s?vrc=H264&debug=loopback&vsc=H264%22" or "https://appr.tc/r/%s?vrc=VP8&debug=loopback&vsc=VP8%22" or "https://appr.tc/r/%s"
5. Observed that above links redirected to "404 Not Found" page.

Please let us know if we have missed anything. Please provide the screencast if possible.

Note: However, upon tapping on "LOAD MP4" button will play the video.

Attached the screenshot for reference.

Thanks!

Deleted: 801501.png 23.0 KB

	801501.png 23.0 KB View Download

Hello

sorry my explanation does not seem to be very clear

on step 4, when opening the URL on Iphone, you have to replace "%s" by the room Id you defined in the test APK

so for example if you set room ID as "myroomid123" on the Android application, the URL to use in the iPhone browser will be "https://appr.tc/r/myroomid123"

so there is actually 2 ways to reproduce the bug with the test APK :

First way (from an Android device to a real iPhone callee)
1. In the device settings, update the WebView implementation to Chrome Canary.
2. Install the test APK file provided in C#10.
3. Launch the application, update the "Room ID"as something unique (for example myroomid12345) click on LOAD P2P button, wait for the page to load then click on "Join" 
4. Open iPhone with IOS 11 on any browser on the link using the chosen roomId, for example "https://appr.tc/r/myroomid12345", wait for the page to load then click on "Join" => the IOS user can see his callee but the android user doesn't see the ios user

Second Way (loopback test on a single Android device)
1. In the device settings, update the WebView implementation to Chrome Canary.
2. Install the test APK file provided in C#10.
3. Launch the application, update the "Room ID"as something unique (for example myroomid12345) click on LOAD H264 LOOPBACK button, wait for the page to load and click on Join => the user see himself but not his callee (see attached screenshot #1)

And if you want to check that it is working using VP8 codec :
1. In the device settings, update the WebView implementation to Chrome Canary.
2. Install the test APK file provided in C#10.
3. Launch the application, update the "Room ID"as something unique (for example myroomid12345) click on LOAD VP8 LOOPBACK button and click on Join => the user see his callee + in a corner of the view he can see himself (though since it is loopback, callee is the same as caller), see attached screenshot #2

Deleted: Screenshot_1.png 1.2 MB

	Screenshot_1.png 1.2 MB View Download

Deleted: Screenshot_2.png 1.1 MB

	Screenshot_2.png 1.1 MB View Download

Thank you for providing more feedback. Adding requester "pnangunoori@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

niklase@, could you take a look or triage this issue?

Brave, what's the status of H264 in WebView? Should this work?

Similar issue happened before, as  issue734313  shows. Chrome and WebView are same version, but H264 decoding doesn't work in WebView. And H264 encoding works in this case though. 
I guess this may be due to hw-decoding flag is not correctly set in WebView? Otherwise it should work as same as Chrome does.
Maybe the later WebView version may work again. Anyway there is nothing we can do here. So close for now.

Hi

I have tried to do the webRTC test on the latest Chrome Beta web view (65.0.3325.53) and there is still the NullVideo problem :
 
02-09 12:06:40.797 15717-16332/? E/chromium: [ERROR:webrtcvideoengine.cc(133)] Can't initialize NullVideoDecoder.
02-09 12:06:40.797 15717-16332/? E/chromium: [ERROR:webrtcvideoengine.cc(148)] Can't register decode complete callback on NullVideoDecoder.
02-09 12:06:40.797 15717-16332/? E/chromium: [ERROR:webrtcvideoengine.cc(142)] The NullVideoDecoder doesn't support decoding.

If trying to open the AppRTC directly in Chrome with a IOS callee, it still works (for example : loading https://appr.tc/r/myroomid)

On Chrome Canary (66.0.3342.3), the problem is the same (though I couldn’t retrieve NullVideoDecoder traces in the logcat)

I read Brave’s answer that it might work in a future WebView and there is nothing we can do here => but is there a way to push this bug to someone anyway ???

The only workaround we found on our product is to avoid using a web view for now...

We shouldn't have differences between WebView and Chrome here, as far as I know. This should be investigated and fixed. The WebView team don't have much expertise related to media/webrtc. Where does hardware decoding get initialised in Chrome? What flags might affect this?

Can't really tell without debug logging or adding more debug logging.

There are a few switches might be related, kDisableAcceleratedVideoDecode and kDisableWebRtcHWDecoding and GPU_FEATURE_TYPE_ACCELERATED_VIDEO_DECODE. Or there may be other reasons. 
Can we assign Chromium as WebView implementation?

Yes, you can build monochrome and use it as the webview implementation, but it shouldn't make any difference at all - the exact same code runs in both cases and startup sets all the same settings.

Based on the multiple reports, it might work differently :)

I found the page about building monochrome and will try it later.

BTW: what about the 'Multipleprocess WebView' option now? I can't find it in developer options on Android O. Does it mean the assigned Chrome will work in either multi-process mode or single-process mode, or the option only impacts WebView itself?

What I mean is that using Monochrome as WebView vs using standalone WebView as WebView works identically, because it's the exact same code running in both cases. That doesn't mean it's the same as using Monochrome as *chrome*, which runs different code.

So, building monochrome vs standalone webview is primarily about what's convenient/compatible with the device you intend to test on - standalone WebView works on all OS versions and builds faster (less code), but can be fiddly to install as you need to have it signed with the correct keys (there's internal-only instructions for this but you need to be on the right ACL to check out our dev key repository). Monochrome only works on N+ devices, but as long as you flash the device to a userdebug image first you don't have to worry about signing keys, so it's usually easier for people who don't already work on webview.

WebView is always multiprocess from O. The developer setting was removed. The option only impacts WebView, not Chrome.

Hello
Do you have anything new on this issue ?

It seems that HW decoder is never enabled in WebView at all.
https://cs.chromium.org/chromium/src/android_webview/lib/aw_main_delegate.cc?l=86, which is there since 2014.

Remove the switch will get decoder working. But it seems there is still rendering issue, which might be due to HW decoder will output to surface directly.

torne@, could you please help to forward this to the right person from WebView for a re-assessment? 

Hello

Any news on this issue ?

Bo, Michael:

The flag that disables webrtc hw decoding was added due to b/15075307, which was closed with a followup to re-enable it in b/16538854. However, that was also closed without turning it back on.

Should we just be able to remove this flag now, or is there more work that would need to be done after what was implemented in b/16538854 ?

> But it seems there is still rendering issue, which might be due to HW decoder will output to surface directly.

Webview should not create more surfaces. Is there a mode for webrtc that forces it into a texture and have it be composited along with everything else?

+ liberato@ for more inputs.

looking at RTCVideoDecoder, i don't see it setting COPY_REQUIRED on the VideoFrame's metadata anywhere.  AVDA needs this in WebView.

does enabling HW decoding re c#27, and unconditionally setting COPY_REQUIRED in RTCVideoDecoder make it work?  the code would look something like:

frame->metadata()->SetBoolean(VideoFrameMetadata::COPY_REQUIRED, true);

one would just add that line somewhere after the frame is created in RTCVideoDecoder::PictureReady .

that's not the right permanent fix (should check the capabilities returned by the VDA, see gpu_video_decoder.cc), but should tell us if it's the problem or not.

should also add some logging to AndroidVideoDecodeAccelerator::Decode to make sure that it's actually enabled properly.

Is there any news on this?

Hi, i'm suffering from this issue as well.
i've tried using chrome 68 and also canary (70.0.3520.0).
is there some kind workaround for now?

Hi guys, any updates?
if this works in regular chrome, probably shouldn't be to hard to fix in the webview as well...

Any update on this issue? We see everything working when using Android Chrome 69 (both H.264 and VP8), but using app webview, there is no rendering of received H.264. H.264 encoding works. VP8 encoding/decoding works fine in webview. We tried various versions for webview, including up to Canary 72.0.3584.0, but no improvement. We see the following errors 
W chromium: [WARNING:packet_buffer.cc(351)] Received H.264-IDR frame (SPS: 0, PPS: 0). Treating as key frame since WebRTC-SpsPpsIdrIsH264Keyframe is disabled
E chromium: [ERROR:webrtcvideoengine.cc(135)] Can't initialize NullVideoDecoder.
E chromium: [ERROR:webrtcvideoengine.cc(149)] Can't register decode complete callback on NullVideoDecoder.
E chromium: [ERROR:webrtcvideoengine.cc(143)] The NullVideoDecoder doesn't support decoding.
Then this last error repeats, for what looks like for each received video packets received:

Maybe it's better to append kDisableWebRtcHWEncoding along with kDisableWebRtcHWDecoding for webview at present, https://cs.chromium.org/chromium/src/android_webview/lib/aw_main_delegate.cc?l=86.

Hi all, any update? It surprises me to see so little updates on this, as it works properly in the regular Chrome browser, just not in a Webview.

Is there any reason in particular why this does not seem to be worked on?

Very strange, when  mostly all communities are working and supporting webrtc with h264, Webview still does not support h264 decoding?

Hi all.
Any news on this subject ?

Hi all,

I modified some flags as below and it works fine in Android WebView like in the regular Android Chrome browser.
Firstly I checked all build flags by using this command: gn args out/Debug --list for both of Chromium and  Android Webview. After that, I realized some flags are different. Therefore I decided to set Android Webview build flags like  Android Chromium build flags. After set them, you need to recompile Android Webview.

Need to modify  some flags  below before build for the solution:

- Set gn arguments as below gn gen out/Debug --args='target_os="android" ffmpeg_branding="Chrome" enable_ffpmeg_video_decoders=true proprietary_codecs=true use_gold=false use_lld=true'

- Comment out kDisableWebRtcHWDecoding flag in aw_main_delegate.cc (https://cs.chromium.org/chromium/src/android_webview/lib/aw_main_delegate.cc?l=86)  as below;
   // cl->AppendSwitch(switches::kDisableWebRtcHWDecoding);

- enable_ffmpeg_video_decoders in media_options.gni (https://cs.chromium.org/chromium/src/media/media_options.gni?q=enable_ffmpeg_video_decoders+&dr=C&l=120) which is build flags needs to set true. It can’t be changed with gn argument. Therefore, it should be altered as below;
     Before modified : enable_ffmpeg_video_decoders = media_use_ffmpeg && !is_android   
     After modified    : enable_ffmpeg_video_decoders = media_use_ffmpeg && is_android
- Check these flags as below;
     gn args out/Debug --list

👏👏👏 finally some progress :)
now what? 

I am not a lawyer, but you might have to pay H.264 royalties if you enable the software encoding of it not using OpenH264, though.

I looked into logs after this solution. It seems to be using HW codec.  

The official builds of WebView from Google do already set ffmpeg_branding="Chrome" and proprietary_codecs=true (the same as Chrome does).

It seems very surprising if setting enable_ffmpeg_video_decoders makes it work on webview, because that option isn't set on Chrome for Android and it works there..

liberato@, could you take a look at this? From comment #32, you seemed to be the right person to fix this. also cc'ing ericrk@ for rendering.

The other strange behavior is that although enable_ffmpeg_video_decoder is related to sw codecs, hw codec is triggered.